diff options
author | cvs2svn <cvs2svn@FreeBSD.org> | 2001-02-26 07:13:02 +0000 |
---|---|---|
committer | cvs2svn <cvs2svn@FreeBSD.org> | 2001-02-26 07:13:02 +0000 |
commit | 9b901cc90cc55c28b5e773a4eb938c851c092170 (patch) | |
tree | a80cfb0055bb1a1d28cffab43733251c6ed7f650 | |
parent | b4134c25b6b1be6f7297d3624a0b8a78e24f4f34 (diff) | |
download | src-9b901cc90cc55c28b5e773a4eb938c851c092170.tar.gz src-9b901cc90cc55c28b5e773a4eb938c851c092170.zip |
This commit was manufactured by cvs2svn to create branch 'RELENG_4'.
Notes
Notes:
svn path=/stable/4/; revision=73067
221 files changed, 57702 insertions, 0 deletions
diff --git a/contrib/bc/FAQ b/contrib/bc/FAQ new file mode 100644 index 000000000000..32dd051d7810 --- /dev/null +++ b/contrib/bc/FAQ @@ -0,0 +1,17 @@ +Because of frequent questions ....... here is the BC FAQ + + +1) Why does BC have its own arbitrary precision number routines + (found in lib/number.c) rather than using GMP? + +GMP has "integers" (no digits after a decimal), "rational numbers" +(stored as 2 integers) and "floats". None of these will correctly +represent a POSIX BC number. Floats are the closest, but will not +behave correctly for many computations. For example, BC numbers have +a "scale" that represent the number of digits to represent after the +decimal point. The multiplying two of these numbers requires one to +calculate an exact number of digits after the decimal point regardless +of the number of digits in the integer part. GMP floats have a +"fixed, but arbitrary" mantissa and so multiplying two floats will end +up dropping digits BC must calculate. + diff --git a/contrib/bc/bc/bcdefs.h b/contrib/bc/bc/bcdefs.h new file mode 100644 index 000000000000..260cd1238469 --- /dev/null +++ b/contrib/bc/bc/bcdefs.h @@ -0,0 +1,188 @@ +/* bcdefs.h: The single file to include all constants and type definitions. */ + +/* This file is part of GNU bc. + Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License , or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; see the file COPYING. If not, write to + The Free Software Foundation, Inc. + 59 Temple Place, Suite 330 + Boston, MA 02111 USA + + You may contact the author by: + e-mail: philnelson@acm.org + us-mail: Philip A. Nelson + Computer Science Department, 9062 + Western Washington University + Bellingham, WA 98226-9062 + +*************************************************************************/ + +/* Include the configuration file. */ +#include "config.h" + +/* Standard includes for all files. */ +#include <stdio.h> +#include <sys/types.h> +#include <ctype.h> +#ifdef HAVE_STRINGS_H +#include <strings.h> +#else +#include <string.h> +#endif +#ifdef HAVE_LIMITS_H +#include <limits.h> +#endif + +#if defined(LIBEDIT) +#include <histedit.h> +#endif + +#if defined(READLINE) +#include <readline/readline.h> +#include <readline/history.h> +#endif + +/* Include the other definitions. */ +#include "const.h" +#include "number.h" + +/* These definitions define all the structures used in + code and data storage. This includes the representation of + labels. The "guiding" principle is to make structures that + take a minimum of space when unused but can be built to contain + the full structures. */ + +/* Labels are first. Labels are generated sequentially in functions + and full code. They just "point" to a single bye in the code. The + "address" is the byte number. The byte number is used to get an + actual character pointer. */ + +typedef struct bc_label_group + { + long l_adrs [ BC_LABEL_GROUP ]; + struct bc_label_group *l_next; + } bc_label_group; + +/* Argument list. Recorded in the function so arguments can + be checked at call time. */ + +typedef struct arg_list + { + int av_name; + int arg_is_var; /* Extension ... variable parameters. */ + struct arg_list *next; + } arg_list; + +/* Each function has its own code segments and labels. There can be + no jumps between functions so labels are unique to a function. */ + +typedef struct + { + char f_defined; /* Is this function defined yet. */ + char *f_body; + int f_body_size; /* Size of body. Power of 2. */ + int f_code_size; + bc_label_group *f_label; + arg_list *f_params; + arg_list *f_autos; + } bc_function; + +/* Code addresses. */ +typedef struct { + int pc_func; + int pc_addr; + } program_counter; + + +/* Variables are "pushable" (auto) and thus we need a stack mechanism. + This is built into the variable record. */ + +typedef struct bc_var + { + bc_num v_value; + struct bc_var *v_next; + } bc_var; + + +/* bc arrays can also be "auto" variables and thus need the same + kind of stacking mechanisms. */ + +typedef struct bc_array_node + { + union + { + bc_num n_num [NODE_SIZE]; + struct bc_array_node *n_down [NODE_SIZE]; + } n_items; + } bc_array_node; + +typedef struct bc_array + { + bc_array_node *a_tree; + short a_depth; + } bc_array; + +typedef struct bc_var_array + { + bc_array *a_value; + char a_param; + struct bc_var_array *a_next; + } bc_var_array; + + +/* For the stacks, execution and function, we need records to allow + for arbitrary size. */ + +typedef struct estack_rec { + bc_num s_num; + struct estack_rec *s_next; +} estack_rec; + +typedef struct fstack_rec { + int s_val; + struct fstack_rec *s_next; +} fstack_rec; + + +/* The following are for the name tree. */ + +typedef struct id_rec { + char *id; /* The program name. */ + /* A name == 0 => nothing assigned yet. */ + int a_name; /* The array variable name (number). */ + int f_name; /* The function name (number). */ + int v_name; /* The variable name (number). */ + short balance; /* For the balanced tree. */ + struct id_rec *left, *right; /* Tree pointers. */ +} id_rec; + + +/* A list of files to process. */ + +typedef struct file_node { + char *name; + struct file_node *next; +} file_node; + +/* Macro Definitions */ + +#if defined(LIBEDIT) +#define HISTORY_SIZE(n) history(hist, &histev, H_SETSIZE, n) +#define UNLIMIT_HISTORY history(hist, &histev, H_SETSIZE, INT_MAX) +#endif + +#if defined(READLINE) +#define HISTORY_SIZE(n) stifle_history(n) +#define UNLIMIT_HISTORY unstifle_history() +#endif diff --git a/contrib/bc/bc/const.h b/contrib/bc/bc/const.h new file mode 100644 index 000000000000..1a7c5b82b046 --- /dev/null +++ b/contrib/bc/bc/const.h @@ -0,0 +1,98 @@ +/* const.h: Constants for bc. */ + +/* This file is part of GNU bc. + Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License , or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; see the file COPYING. If not, write to + The Free Software Foundation, Inc. + 59 Temple Place, Suite 330 + Boston, MA 02111 USA + + You may contact the author by: + e-mail: philnelson@acm.org + us-mail: Philip A. Nelson + Computer Science Department, 9062 + Western Washington University + Bellingham, WA 98226-9062 + +*************************************************************************/ + + +/* Define INT_MAX and LONG_MAX if not defined. Assuming 32 bits... */ + +#ifndef INT_MAX +#define INT_MAX 0x7FFFFFFF +#endif +#ifndef LONG_MAX +#define LONG_MAX 0x7FFFFFFF +#endif + + +/* Define constants in some reasonable size. The next 4 constants are + POSIX constants. */ + +#ifdef BC_BASE_MAX + /* <limits.h> on a POSIX.2 system may have defined these. Override. */ +# undef BC_BASE_MAX +# undef BC_SCALE_MAX +# undef BC_STRING_MAX +# undef BC_DIM_MAX +#endif + +#define BC_BASE_MAX INT_MAX +#define BC_SCALE_MAX INT_MAX +#define BC_STRING_MAX INT_MAX + + +/* Definitions for arrays. */ + +#define BC_DIM_MAX 65535 /* this should be NODE_SIZE^NODE_DEPTH-1 */ + +#define NODE_SIZE 16 /* Must be a power of 2. */ +#define NODE_MASK 0xf /* Must be NODE_SIZE-1. */ +#define NODE_SHIFT 4 /* Number of 1 bits in NODE_MASK. */ +#define NODE_DEPTH 4 + + +/* Other BC limits defined but not part of POSIX. */ + +#define BC_LABEL_GROUP 64 +#define BC_LABEL_LOG 6 +#define BC_START_SIZE 1024 /* Initial code body size. */ + +/* Maximum number of variables, arrays and functions and the + allocation increment for the dynamic arrays. */ + +#define MAX_STORE 32767 +#define STORE_INCR 32 + +/* Other interesting constants. */ + +#define FALSE 0 +#define TRUE 1 + +/* for use with lookup (). */ +#define SIMPLE 0 +#define ARRAY 1 +#define FUNCT 2 +#define FUNCTDEF 3 + +#define EXTERN extern +#ifdef __STDC__ +#define CONST const +#define VOID void +#else +#define CONST +#define VOID +#endif diff --git a/contrib/bc/bc/global.h b/contrib/bc/bc/global.h new file mode 100644 index 000000000000..cf6945c42674 --- /dev/null +++ b/contrib/bc/bc/global.h @@ -0,0 +1,154 @@ +/* global.h: The global variables for bc. */ + +/* This file is part of GNU bc. + Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License , or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; see the file COPYING. If not, write to + The Free Software Foundation, Inc. + 59 Temple Place, Suite 330 + Boston, MA 02111 USA + + You may contact the author by: + e-mail: philnelson@acm.org + us-mail: Philip A. Nelson + Computer Science Department, 9062 + Western Washington University + Bellingham, WA 98226-9062 + +*************************************************************************/ + + +/* The current break level's lable. */ +EXTERN int break_label; + +/* The current if statement's else label or label after else. */ +EXTERN int if_label; + +/* The current for statement label for continuing the loop. */ +EXTERN int continue_label; + +/* Next available label number. */ +EXTERN int next_label; + +/* Byte code character storage. Used in many places for generation of code. */ +EXTERN char genstr[80]; + +/* Count of characters printed to the output in compile_only mode. */ +EXTERN int out_count; + +/* Have we generated any code since the last initialization of the code + generator. */ +EXTERN char did_gen; + +/* Is this run an interactive execution. (Is stdin a terminal?) */ +EXTERN char interactive; + +/* Just generate the byte code. -c flag. */ +EXTERN int compile_only; + +/* Load the standard math functions. -l flag. */ +EXTERN int use_math; + +/* Give a warning on use of any non-standard feature (non-POSIX). -w flag. */ +EXTERN int warn_not_std; + +/* Accept POSIX bc only! -s flag. */ +EXTERN int std_only; + +/* Don't print the banner at start up. -q flag. */ +EXTERN int quiet; + +/* The list of file names to process. */ +EXTERN file_node *file_names; + +/* The name of the current file being processed. */ +EXTERN char *file_name; + +/* Is the current file a named file or standard input? */ +EXTERN char is_std_in; + +/* global variables for the bc machine. All will be dynamic in size.*/ +/* Function storage. main is (0) and functions (1-f_count) */ + +EXTERN bc_function *functions; +EXTERN char **f_names; +EXTERN int f_count; + +/* Variable stoarge and reverse names. */ + +EXTERN bc_var **variables; +EXTERN char **v_names; +EXTERN int v_count; + +/* Array Variable storage and reverse names. */ + +EXTERN bc_var_array **arrays; +EXTERN char **a_names; +EXTERN int a_count; + +/* Execution stack. */ +EXTERN estack_rec *ex_stack; + +/* Function return stack. */ +EXTERN fstack_rec *fn_stack; + +/* Current ibase, obase, scale, and n_history (if needed). */ +EXTERN int i_base; +EXTERN int o_base; +EXTERN int scale; +#if defined(READLINE) || defined(LIBEDIT) +EXTERN int n_history; +#endif + +#if defined(LIBEDIT) +/* LIBEDIT data */ +EditLine *edit; +History *hist; +HistEvent histev; +#endif + +/* "Condition code" -- false (0) or true (1) */ +EXTERN char c_code; + +/* Records the number of the runtime error. */ +EXTERN char runtime_error; + +/* Holds the current location of execution. */ +EXTERN program_counter pc; + +/* For POSIX bc, this is just for number output, not strings. */ +EXTERN int out_col; + +/* Keeps track of the current number of characters per output line. + This includes the \n at the end of the line. */ +EXTERN int line_size; + +/* Input Line numbers and other error information. */ +EXTERN int line_no; +EXTERN int had_error; + +/* For larger identifiers, a tree, and how many "storage" locations + have been allocated. */ + +EXTERN int next_array; +EXTERN int next_func; +EXTERN int next_var; + +EXTERN id_rec *name_tree; + +/* For use with getopt. Do not declare them here.*/ +extern int optind; + +/* Access to the yy input file. Defined in scan.c. */ +extern FILE *yyin; diff --git a/contrib/bc/bc/proto.h b/contrib/bc/bc/proto.h new file mode 100644 index 000000000000..1e7311fc8461 --- /dev/null +++ b/contrib/bc/bc/proto.h @@ -0,0 +1,148 @@ +/* proto.h: Prototype function definitions for "external" functions. */ + +/* This file is part of GNU bc. + Copyright (C) 1991-1994, 1997, 2000 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License , or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; see the file COPYING. If not, write to + The Free Software Foundation, Inc. + 59 Temple Place, Suite 330 + Boston, MA 02111 USA + + You may contact the author by: + e-mail: philnelson@acm.org + us-mail: Philip A. Nelson + Computer Science Department, 9062 + Western Washington University + Bellingham, WA 98226-9062 + +*************************************************************************/ + +/* For the pc version using k&r ACK. (minix1.5 and earlier.) */ +#ifdef SHORTNAMES +#define init_numbers i_numbers +#define push_constant push__constant +#define load_const in_load_const +#define yy_get_next_buffer yyget_next_buffer +#define yy_init_buffer yyinit_buffer +#define yy_last_accepting_state yylast_accepting_state +#define arglist1 arg1list +#endif + +/* Include the standard library header files. */ +#ifdef HAVE_UNISTD_H +#include <unistd.h> +#endif +#ifdef HAVE_STDLIB_H +#include <stdlib.h> +#endif + +/* Define the _PROTOTYPE macro if it is needed. */ + +#ifndef _PROTOTYPE +#ifdef __STDC__ +#define _PROTOTYPE(func, args) func args +#else +#define _PROTOTYPE(func, args) func() +#endif +#endif + +/* From execute.c */ +_PROTOTYPE(void stop_execution, (int)); +_PROTOTYPE(unsigned char byte, (program_counter *pc)); +_PROTOTYPE(void execute, (void)); +_PROTOTYPE(char prog_char, (void)); +_PROTOTYPE(char input_char, (void)); +_PROTOTYPE(void push_constant, (char (*in_char)(void), int conv_base)); +_PROTOTYPE(void push_b10_const, (program_counter *pc)); +_PROTOTYPE(void assign, (int c_code)); + +/* From util.c */ +_PROTOTYPE(char *strcopyof, (char *str)); +_PROTOTYPE(arg_list *nextarg, (arg_list *args, int val, int is_var)); +_PROTOTYPE(char *arg_str, (arg_list *args)); +_PROTOTYPE(char *call_str, (arg_list *args)); +_PROTOTYPE(void free_args, (arg_list *args)); +_PROTOTYPE(void check_params, (arg_list *params, arg_list *autos)); +_PROTOTYPE(void init_gen, (void)); +_PROTOTYPE(void generate, (char *str)); +_PROTOTYPE(void run_code, (void)); +_PROTOTYPE(void out_char, (int ch)); +_PROTOTYPE(void out_schar, (int ch)); +_PROTOTYPE(id_rec *find_id, (id_rec *tree, char *id)); +_PROTOTYPE(int insert_id_rec, (id_rec **root, id_rec *new_id)); +_PROTOTYPE(void init_tree, (void)); +_PROTOTYPE(int lookup, (char *name, int namekind)); +_PROTOTYPE(char *bc_malloc, (int)); +_PROTOTYPE(void out_of_memory, (void)); +_PROTOTYPE(void welcome, (void)); +_PROTOTYPE(void warranty, (char *)); +_PROTOTYPE(void show_bc_version, (void)); +_PROTOTYPE(void limits, (void)); +_PROTOTYPE(void yyerror, (char *str ,...)); +_PROTOTYPE(void warn, (char *mesg ,...)); +_PROTOTYPE(void rt_error, (char *mesg ,...)); +_PROTOTYPE(void rt_warn, (char *mesg ,...)); + +/* From load.c */ +_PROTOTYPE(void init_load, (void)); +_PROTOTYPE(void addbyte, (int byte)); +_PROTOTYPE(void def_label, (long lab)); +_PROTOTYPE(long long_val, (char **str)); +_PROTOTYPE(void load_code, (char *code)); + +/* From main.c */ +_PROTOTYPE(int open_new_file, (void)); +_PROTOTYPE(void new_yy_file, (FILE *file)); +_PROTOTYPE(void use_quit, (int)); + +/* From storage.c */ +_PROTOTYPE(void init_storage, (void)); +_PROTOTYPE(void more_functions, (void)); +_PROTOTYPE(void more_variables, (void)); +_PROTOTYPE(void more_arrays, (void)); +_PROTOTYPE(void clear_func, (int func )); +_PROTOTYPE(int fpop, (void)); +_PROTOTYPE(void fpush, (int val )); +_PROTOTYPE(void pop, (void)); +_PROTOTYPE(void push_copy, (bc_num num )); +_PROTOTYPE(void push_num, (bc_num num )); +_PROTOTYPE(char check_stack, (int depth )); +_PROTOTYPE(bc_var *get_var, (int var_name )); +_PROTOTYPE(bc_num *get_array_num, (int var_index, long index )); +_PROTOTYPE(void store_var, (int var_name )); +_PROTOTYPE(void store_array, (int var_name )); +_PROTOTYPE(void load_var, (int var_name )); +_PROTOTYPE(void load_array, (int var_name )); +_PROTOTYPE(void decr_var, (int var_name )); +_PROTOTYPE(void decr_array, (int var_name )); +_PROTOTYPE(void incr_var, (int var_name )); +_PROTOTYPE(void incr_array, (int var_name )); +_PROTOTYPE(void auto_var, (int name )); +_PROTOTYPE(void free_a_tree, (bc_array_node *root, int depth )); +_PROTOTYPE(void pop_vars, (arg_list *list )); +_PROTOTYPE(void process_params, (program_counter *pc, int func )); + +/* For the scanner and parser.... */ +_PROTOTYPE(int yyparse, (void)); +_PROTOTYPE(int yylex, (void)); + +#if defined(LIBEDIT) +/* The *?*&^ prompt function */ +_PROTOTYPE(char *null_prompt, (EditLine *)); +#endif + +/* Other things... */ +#ifndef HAVE_UNISTD_H +_PROTOTYPE (int getopt, (int, char *[], CONST char *)); +#endif diff --git a/contrib/bc/doc/bc.texi b/contrib/bc/doc/bc.texi new file mode 100644 index 000000000000..a7cb9f667644 --- /dev/null +++ b/contrib/bc/doc/bc.texi @@ -0,0 +1,1014 @@ +\input texinfo @c -*-texinfo-*- +@c %**start of header +@setfilename bc.info +@settitle bc Command Manual +@c %**end of header + +@c This file has the new style title page commands. +@c Run `makeinfo' rather than `texinfo-format-buffer'. + +@smallbook + +@c tex +@c \overfullrule=0pt +@c end tex + +@titlepage +@title @command{bc} +@subtitle an arbitrary precision calculator language +@subtitle version 1.06 + +@author Philip A. Nelson +@page + +This manual documents @command{bc}, an arbitrary precision calculator language. + +This manual is part of GNU @command{bc}.@* +@sp4 +Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc. +59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. + +Permission is granted to make and distribute verbatim copies of +this manual provided the copyright notice and this permission notice +are preserved on all copies. + +@iftex +Permission is granted to process this file through TeX and print the +results, provided the printed document carries copying permission +notice identical to this one except for the removal of this paragraph +(this paragraph not being relevant to the printed manual). +@end iftex + +Permission is granted to copy and distribute modified versions of this +manual under the conditions for verbatim copying, provided that the entire +resulting derived work is distributed under the terms of a permission +notice identical to this one. + +Permission is granted to copy and distribute translations of this manual +into another language, under the above conditions for modified versions, +except that this permission notice may be stated in a translation approved +by the Foundation. + +You may contact the author by: +e-mail: @email{phil@@cs.wwu.edu}@* +us-mail: Philip A. Nelson@* +Computer Science Department, 9062@* +Western Washington University@* +Bellingham, WA 98226-9062 + +@end titlepage + +@node Top, Introduction, (dir), (dir) + +@menu +* Introduction:: +* Basic Elements:: +* Expressions:: +* Statements:: +* Functions:: +* Examples:: +* Readline and Libedit Options:: +* GNU @command{bc} and Other Implementations:: +* Limits:: +* Environment Variables:: +@end menu + +@node Introduction, Basic Elements, Top, Top +@chapter Introduction +@menu +* Description:: +* Command Line Options:: +@end menu + +@node Description, Command Line Options, Introduction, Introduction +@section Description + +@command{bc} [ -hlwsqv ] [long-options] [ @var{ file ...} ] + +@command{bc} is a language that supports arbitrary precision numbers +with interactive execution of statements. There are some similarities +in the syntax to the C programming language. +A standard math library is available by command line option. +If requested, the math library is defined before processing any files. +@command{bc} starts by processing code from all the files listed +on the command line in the order listed. After all files have been +processed, @command{bc} reads from the standard input. All code is +executed as it is read. (If a file contains a command to halt the +processor, @command{bc} will never read from the standard input.) + +This version of @command{bc} contains several extensions beyond +traditional @command{bc} implementations and the POSIX draft standard. +Command line options can cause these extensions to print a warning or to +be rejected. This document describes the language accepted by this +processor. Extensions will be identified as such. + +The author would like to thank Steve Sommars +(@email{Steve.Sommars@@att.com}) for his extensive help in testing the +implementation. Many great suggestions were given. This is a much +better product due to his involvement. + +Email bug reports to @email{bug-bc@@gnu.org}. Be sure to include +the word ``bc'' somewhere in the ``Subject:'' field. + +@node Command Line Options, Numbers, Description, Introduction +@section Command Line Options + +@command{bc} takes the following options from the command line: +@table @code + +@item -h, --help +Print the usage and exit. + +@item -l, --mathlib +Define the standard math library. + +@item -w, --warn +Give warnings for extensions to POSIX @command{bc}. + +@item -s, --standard +Process exactly the POSIX @command{bc} language. + +@item -q, --quiet +Do not print the normal GNU @command{bc} welcome. + +@item -v, --version +Print the version number and copyright and quit. + +@end table + + +@node Basic Elements, Expressions, Introduction, Top +@chapter Basic Elements +@menu +* Numbers:: +* Variables:: +* Comments:: +@end menu + +@node Numbers, Variables, Command Line Options, Basic Elements +@section Numbers + +The most basic element in @command{bc} is the number. Numbers are +arbitrary precision numbers. This precision is both in the integer part +and the fractional part. All numbers are represented internally in +decimal and all computation is done in decimal. (This version truncates +results from divide and multiply operations.) There are two attributes +of numbers, the length and the scale. The length is the total number of +significant decimal digits in a number and the scale is the total number +of decimal digits after the decimal point. For example, .000001 has a +length of 6 and scale of 6, while 1935.000 has a length of 7 and a scale +of 3. + +@node Variables, Comments, Numbers, Basic Elements +@section Variables + +Numbers are stored in two types of variables, simple variables and +arrays. Both simple variables and array variables are named. Names +begin with a letter followed by any number of letters, digits and +underscores. All letters must be lower case. (Full alphanumeric +names are an extension. In POSIX @command{bc} all names are a single +lower case letter.) The type of variable is clear by the context +because all array variable names will be followed by brackets ( [ ] ). + +There are four special variables, @var{scale}, @var{ibase}, @var{obase}, and +@var{last}. @var{scale} defines how some operations use digits after the +decimal point. The default value of @var{scale} is 0. @var{ibase} +and @var{obase} define the conversion base for input and output +numbers. The default for both input and output is base 10. +@var{last} (an extension) is a variable that has the value of the last +printed number. These will be discussed in further detail where +appropriate. All of these variables may have values assigned to them +as well as used in expressions. + +@node Comments, , Variables, Basic Elements +@section Comments + +Comments in @command{bc} start with the characters @code{/*} and end with +the characters @code{*/}. Comments may start anywhere and appear as a +single space in the input. (This causes comments to delimit other +input items. For example, a comment can not be found in the middle of +a variable name.) Comments include any newlines (end of line) between +the start and the end of the comment. + +To support the use of scripts for @command{bc}, a single line comment has been +added as an extension. A single line comment starts at a @code{#} +character and continues to the next end of the line. The end of line +character is not part of the comment and is processed normally. + +@node Expressions, Statements, Basic Elements, Top +@chapter Expressions + +@menu +* About Expressions and Special Variables:: +* Basic Expressions:: +* Relational Expressions:: +* Boolean Expressions:: +* Precedence:: +* Special Expressions:: +@end menu + +@node About Expressions and Special Variables, Basic Expressions, Expressions, Expressions +@section About Expressions and Special Variables + +The numbers are manipulated by expressions and statements. Since +the language was designed to be interactive, statements and expressions +are executed as soon as possible. There is no main program. Instead, +code is executed as it is encountered. (Functions, discussed in +detail later, are defined when encountered.) + +A simple expression is just a constant. @command{bc} converts constants +into internal decimal numbers using the current input base, specified by +the variable @var{ibase}. (There is an exception in functions.) The +legal values of @var{ibase} are 2 through 16. Assigning a value outside +this range to @var{ibase} will result in a value of 2 or 16. Input +numbers may contain the characters 0-9 and A-F. (Note: They must be +capitals. Lower case letters are variable names.) Single digit numbers +always have the value of the digit regardless of the value of +@var{ibase}. (i.e. A = 10.) For multi-digit numbers, @command{bc} +changes all input digits greater or equal to @var{ibase} to the value of +@var{ibase}-1. This makes the number @code{FFF} always be the largest +3 digit number of the input base. + +Full expressions are similar to many other high level languages. +Since there is only one kind of number, there are no rules for mixing +types. Instead, there are rules on the scale of expressions. Every +expression has a scale. This is derived from the scale of original +numbers, the operation performed and in many cases, the value of the +variable @var{scale}. Legal values of the variable @var{scale} are +0 to the maximum number representable by a C integer. + +@node Basic Expressions, Relational Expressions, About Expressions and Special Variables, Expressions +@section Basic Expressions + +In the following descriptions of legal expressions, "expr" refers to a +complete expression and "@var{var}" refers to a simple or an array variable. +A simple variable is just a + +@var{name} + +and an array variable is specified as + +@var{name}[@var{expr}] + +Unless specifically mentioned the scale of the result is the maximum +scale of the expressions involved. + +@table @code +@item - expr +The result is the negation of the expression. + +@item ++ @var{var} +The variable is incremented by one and the new value is the result of +the expression. + +@item -- @var{var} +The variable +is decremented by one and the new value is the result of the +expression. + +@item @var{var} ++ + The result of the expression is the value of +the variable and then the variable is incremented by one. + +@item @var{var} -- +The result of the expression is the value of the variable and then +the variable is decremented by one. + +@item expr + expr +The result of the expression is the sum of the two expressions. + +@item expr - expr +The result of the expression is the difference of the two expressions. + +@item expr * expr +The result of the expression is the product of the two expressions. + +@item expr / expr +The result of the expression is the quotient of the two expressions. +The scale of the result is the value of the variable @code{scale} + +@item expr % expr +The result of the expression is the "remainder" and it is computed in the +following way. To compute a%b, first a/b is computed to @var{scale} +digits. That result is used to compute a-(a/b)*b to the scale of the +maximum of @var{scale}+scale(b) and scale(a). If @var{scale} is set +to zero and both expressions are integers this expression is the +integer remainder function. + +@item expr ^ expr +The result of the expression is the value of the first raised to the +second. The second expression must be an integer. (If the second +expression is not an integer, a warning is generated and the +expression is truncated to get an integer value.) The scale of the +result is @var{scale} if the exponent is negative. If the exponent +is positive the scale of the result is the minimum of the scale of the +first expression times the value of the exponent and the maximum of +@var{scale} and the scale of the first expression. (e.g. scale(a^b) += min(scale(a)*b, max(@var{scale}, scale(a))).) It should be noted +that expr^0 will always return the value of 1. + +@item ( expr ) +This alters the standard precedence to force the evaluation of the +expression. + +@item @var{var} = expr +The variable is assigned the value of the expression. + +@item @var{var} <op>= expr +This is equivalent to "@var{var} = @var{var} <op> expr" with the +exception that the "@var{var}" part is evaluated only once. This can +make a difference if "@var{var}" is an array. +@end table + +@node Relational Expressions, Boolean Expressions, Basic Expressions, Expressions +@section Relational Expressions + +Relational expressions are a special kind of expression that always +evaluate to 0 or 1, 0 if the relation is false and 1 if the relation is +true. These may appear in any legal expression. (POSIX @command{bc} +requires that relational expressions are used only in @code{if}, +@code{while}, and @code{for} statements and that only one relational +test may be done in them.) The relational operators are + +@table @code +@item expr1 < expr2 +The result is 1 if expr1 is strictly less than expr2. + +@item expr1 <= expr2 +The result is 1 if expr1 is less than or equal to expr2. + +@item expr1 > expr2 +The result is 1 if expr1 is strictly greater than expr2. + +@item expr1 >= expr2 +The result is 1 if expr1 is greater than or equal to expr2. + +@item expr1 == expr2 +The result is 1 if expr1 is equal to expr2. + +@item expr1 != expr2 +The result is 1 if expr1 is not equal to expr2. +@end table + +@node Boolean Expressions, Precedence, Relational Expressions, Expressions +@section Boolean Expressions + +Boolean operations are also legal. (POSIX @command{bc} does NOT have +boolean operations). The result of all boolean operations are 0 and 1 +(for false and true) as in relational expressions. The boolean +operators are: + +@table @code +@item !expr +The result is 1 if expr is 0. + +@item expr && expr +The result is 1 if both expressions are non-zero. + +@item expr || expr +The result is 1 if either expression is non-zero. +@end table + +@node Precedence, Special Expressions, Boolean Expressions, Expressions +@section Precedence + +The expression precedence is as follows: (lowest to highest) + +@example +|| operator, left associative +&& operator, left associative +! operator, nonassociative +Relational operators, left associative +Assignment operator, right associative ++ and - operators, left associative +*, / and % operators, left associative +^ operator, right associative +unary - operator, nonassociative +++ and -- operators, nonassociative +@end example + +This precedence was chosen so that POSIX compliant @command{bc} programs +will run correctly. This will cause the use of the relational and +logical operators to have some unusual behavior when used with +assignment expressions. Consider the expression: + +@example +a = 3 < 5 +@end example + +Most C programmers would assume this would assign the result of "3 < +5" (the value 1) to the variable "a". What this does in @command{bc} is +assign the value 3 to the variable "a" and then compare 3 to 5. It is +best to use parentheses when using relational and logical operators +with the assignment operators. + +@node Special Expressions, , Precedence, Expressions +@section Special Expressions + +There are a few more special expressions that are provided in +@command{bc}. These have to do with user-defined functions and standard +functions. They all appear as +"@var{name}@code{(}@var{parameters}@code{)}". @xref{Functions}, for +user-defined functions. The standard functions are: + +@table @code +@item length ( expression ) +The value of the length function is the number of significant digits in the +expression. + +@item read ( ) +The @code{read} function (an extension) will read a number from the +standard input, regardless of where the function occurs. Beware, this +can cause problems with the mixing of data and program in the standard +input. The best use for this function is in a previously written +program that needs input from the user, but never allows program code to +be input from the user. The value of the @code{read} function is the +number read from the standard input using the current value of the +variable @var{ibase} for the conversion base. + +@item scale ( expression ) +The value of the @code{scale} function is the number of digits after the +decimal point in the expression. + +@item sqrt ( expression ) +The value of the @code{sqrt} function is the square root of the +expression. If the expression is negative, a run time error is +generated. +@end table + +@node Statements, Functions, Expressions, Top +@chapter Statements + +@menu +* Pseudo Statements:: +@end menu + +Statements (as in most algebraic languages) provide the sequencing of +expression evaluation. In @command{bc} statements are executed "as soon +as possible." Execution happens when a newline in encountered and there +is one or more complete statements. Due to this immediate execution, +newlines are very important in @command{bc}. In fact, both a semicolon +and a newline are used as statement separators. An improperly placed +newline will cause a syntax error. Because newlines are statement +separators, it is possible to hide a newline by using the backslash +character. The sequence "\<nl>", where <nl> is the newline appears to +@command{bc} as whitespace instead of a newline. A statement list is a +series of statements separated by semicolons and newlines. The +following is a list of @command{bc} statements and what they do: (Things +enclosed in brackets ( [ ] ) are optional parts of the statement.) + +@table @var +@item expression +This statement does one of two things. If the expression starts with +"<variable> <assignment> ...", it is considered to be an assignment +statement. If the expression is not an assignment statement, the +expression is evaluated and printed to the output. After the number is +printed, a newline is printed. For example, "a=1" is an assignment +statement and "(a=1)" is an expression that has an embedded assignment. +All numbers that are printed are printed in the base specified by the +variable @var{obase}. The legal values for @var{obase} are 2 through +BC_BASE_MAX (@pxref{Environment Variables}). For bases 2 through 16, +the usual method of writing numbers is used. For bases greater than 16, +@command{bc} uses a multi-character digit method of printing the numbers +where each higher base digit is printed as a base 10 number. The +multi-character digits are separated by spaces. Each digit contains the +number of characters required to represent the base ten value of +"@var{obase} -1". Since numbers are of arbitrary precision, some +numbers may not be printable on a single output line. These long +numbers will be split across lines using the "\" as the last character +on a line. The maximum number of characters printed per line is 70. +Due to the interactive nature of @command{bc}, printing a number causes +the side effect of assigning the printed value to the special variable +@var{last}. This allows the user to recover the last value printed +without having to retype the expression that printed the number. +Assigning to @var{last} is legal and will overwrite the last printed +value with the assigned value. The newly assigned value will remain +until the next number is printed or another value is assigned to +@var{last}. (Some installations may allow the use of a single period +(.) which is not part of a number as a short hand notation for for +@var{last}.) + +@item string +The string is printed to the output. Strings start with a double quote +character and contain all characters until the next double quote character. +All characters are taken literally, including any newline. No newline +character is printed after the string. + +@item @code{print} @var{list} +The @code{print} statement (an extension) provides another method of +output. The @var{list} is a list of strings and expressions separated by +commas. Each string or expression is printed in the order of the list. +No terminating newline is printed. Expressions are evaluated and their +value is printed and assigned to the variable @code{last}. Strings in +the print statement are printed to the output and may contain special +characters. Special characters start with the backslash character (\e). +The special characters recognized by @command{bc} are "a" (alert or +bell), "b" (backspace), "f" (form feed), "n" (newline), "r" (carriage +return), "q" (double quote), "t" (tab), and "\e" (backslash). Any other +character following the backslash will be ignored. + +@item @{ statement_list @} +This is the compound statement. It allows multiple statements to be +grouped together for execution. + +@item @code{if} ( expression ) statement1 [@code{else} statement2] +The if statement evaluates the expression and executes statement1 or +statement2 depending on the value of the expression. If the expression +is non-zero, statement1 is executed. If statement2 is present and +the value of the expression is 0, then statement2 is executed. (The +@code{else} clause is an extension.) + +@item @code{while} ( expression ) statement +The while statement will execute the statement while the expression +is non-zero. It evaluates the expression before each execution of +the statement. Termination of the loop is caused by a zero +expression value or the execution of a @code{break} statement. + +@item @code{for} ( [expression1] ; [expression2] ; [expression3] ) statement +The @code{for} statement controls repeated execution of the statement. +@var{Expression1} is evaluated before the loop. @var{Expression2} is +evaluated before each execution of the statement. If it is non-zero, +the statement is evaluated. If it is zero, the loop is terminated. +After each execution of the statement, @var{expression3} is evaluated +before the reevaluation of expression2. If @var{expression1} or +@var{expression3} are missing, nothing is evaluated at the point they +would be evaluated. If @var{expression2} is missing, it is the same as +substituting the value 1 for @var{expression2}. (The optional +expressions are an extension. POSIX @command{bc} requires all three +expressions.) The following is equivalent code for the @code{for} +statement: + +@example +expression1; +while (expression2) @{ + statement; + expression3; +@} +@end example + +@item @code{break} +This statement causes a forced exit of the most recent enclosing @code{while} +statement or @code{for} statement. + +@item @code{continue} +The @code{continue} statement (an extension) causes the most recent enclosing +@code{for} statement to start the next iteration. + +@item @code{halt} +The @code{halt} statement (an extension) is an executed statement that +causes the @command{bc} processor to quit only when it is executed. For +example, "if (0 == 1) halt" will not cause @command{bc} to terminate +because the @code{halt} is not executed. + +@item @code{return} +Return the value 0 from a function. (@xref{Functions}.) + +@item @code{return} ( expression ) +Return the value of the expression from a function. (@xref{Functions}.) +As an extension, the parenthesis are not required. +@end table + +@node Pseudo Statements, , Statements, Statements +@section Pseudo Statements + +These statements are not statements in the traditional sense. They are +not executed statements. Their function is performed at "compile" time. + +@table @code +@item limits +Print the local limits enforced by the local version of @command{bc}. This +is an extension. + +@item quit +When the @code{quit} statement is read, the @command{bc} processor +is terminated, regardless of where the @code{quit} statement is found. For +example, "if (0 == 1) quit" will cause @command{bc} to terminate. + +@item warranty +Print a longer warranty notice. This is an extension. +@end table + +@node Functions, Examples, Statements, Top +@chapter Functions + +@menu +* Math Library Functions:: +@end menu + +Functions provide a method of defining a computation that can be +executed later. Functions in @command{bc} always compute a value and +return it to the caller. Function definitions are "dynamic" in the +sense that a function is undefined until a definition is encountered in +the input. That definition is then used until another definition +function for the same name is encountered. The new definition then +replaces the older definition. A function is defined as follows: + +@example +@code{define} @var{name} @code{(} @var{parameters} @code{)} @code{@{} @var{newline} + @var{auto_list statement_list} @code{@}} +@end example + +A function call is just an expression of the form +"@code{name} @code{(}@var{parameters}@code{)}". + +Parameters are numbers or arrays (an extension). In the function definition, +zero or more parameters are defined by listing their names separated by +commas. Numbers are only call by value parameters. Arrays are only +call by variable. Arrays are specified in the parameter definition by +the notation "@var{name}@code{[ ]}". In the function call, actual parameters +are full expressions for number parameters. The same notation is used +for passing arrays as for defining array parameters. The named array is +passed by variable to the function. Since function definitions are dynamic, +parameter numbers and types are checked when a function is called. Any +mismatch in number or types of parameters will cause a runtime error. +A runtime error will also occur for the call to an undefined function. + +The @var{auto_list} is an optional list of variables that are for +"local" use. The syntax of the auto list (if present) is "@code{auto} +@var{name}, ... ;". (The semicolon is optional.) Each @var{name} is +the name of an auto variable. Arrays may be specified by using the +same notation as used in parameters. These variables have their +values pushed onto a stack at the start of the function. The +variables are then initialized to zero and used throughout the +execution of the function. At function exit, these variables are +popped so that the original value (at the time of the function call) +of these variables are restored. The parameters are really auto +variables that are initialized to a value provided in the function +call. +Auto variables are different than traditional local variables +because if function A calls function B, B may access function +A's auto variables by just using the same name, unless function B has +called them auto variables. Due to the fact that auto variables and +parameters are pushed onto a stack, @command{bc} supports recursive functions. + +The function body is a list of @command{bc} statements. Again, statements +are separated by semicolons or newlines. Return statements cause the +termination of a function and the return of a value. There are two +versions of the return statement. The first form, "@code{return}", returns +the value 0 to the calling expression. The second form, +"@code{return} ( @var{expression} )", computes the value of the expression +and returns that value to the calling expression. There is an implied +"@code{return} (0)" at the end of every function. This allows a function +to terminate and return 0 without an explicit @code{return} statement. + +Functions also change the usage of the variable @var{ibase}. All +constants in the function body will be converted using the value of +@var{ibase} at the time of the function call. Changes of @var{ibase} +will be ignored during the execution of the function except for the +standard function @code{read}, which will always use the current value +of @var{ibase} for conversion of numbers. + +As an extension, the format of the definition has been slightly relaxed. +The standard requires the opening brace be on the same line as the +@code{define} keyword and all other parts must be on following lines. +This version of @command{bc} will allow any number of newlines before and +after the opening brace of the function. For example, the following +definitions are legal. + +@example + define d (n) @{ return (2*n); @} + define d (n) + @{ return (2*n); @} +@end example + + +@node Math Library Functions, , Functions, Functions +@section Math Library Functions + +If @command{bc} is invoked with the @code{-l} option, a math library is +preloaded and the default @var{scale} is set to 20. The math functions will +calculate their results to the scale set at the time of their call. The +math library defines the following functions: + +@table @code +@item s (@var{x}) +The sine of @var{x}, @var{x} is in radians. + +@item c (@var{x}) +The cosine of @var{x}, @var{x} is in radians. + +@item a (@var{x}) +The arctangent of @var{x}, arctangent returns radians. + +@item l (@var{x}) +The natural logarithm of @var{x}. + +@item @var{e} (@var{x}) +The exponential function of raising @var{e} to the value @var{x}. + +@item @var{j} (@var{n,x}) +The bessel function of integer order @var{n} of @var{x}. +@end table + +@node Examples, Readline and Libedit Options, Functions, Top +@chapter Examples + +In /bin/sh, the following will assign the value of "pi" to the shell +variable @var{pi}. +@example + +pi=$(echo "scale=10; 4*a(1)" | bc -l) + +@end example + +The following is the definition of the exponential function used in the +math library. This function is written in POSIX @command{bc}. + +@example + +scale = 20 + +/* Uses the fact that e^x = (e^(x/2))^2 + When x is small enough, we use the series: + e^x = 1 + x + x^2/2! + x^3/3! + ... +*/ + +define e(x) @{ + auto a, d, e, f, i, m, v, z + + /* Check the sign of x. */ + if (x<0) @{ + m = 1 + x = -x + @} + + /* Precondition x. */ + z = scale; + scale = 4 + z + .44*x; + while (x > 1) @{ + f += 1; + x /= 2; + @} + + /* Initialize the variables. */ + v = 1+x + a = x + d = 1 + + for (i=2; 1; i++) @{ + e = (a *= x) / (d *= i) + if (e == 0) @{ + if (f>0) while (f--) v = v*v; + scale = z + if (m) return (1/v); + return (v/1); + @} + v += e + @} +@} + +@end example + +The following is code that uses the extended features of @command{bc} to +implement a simple program for calculating checkbook balances. This +program is best kept in a file so that it can be used many times +without having to retype it at every use. + +@example + +scale=2 +print "\nCheck book program\n!" +print " Remember, deposits are negative transactions.\n" +print " Exit by a 0 transaction.\n\n" + +print "Initial balance? "; bal = read() +bal /= 1 +print "\n" +while (1) @{ + "current balance = "; bal + "transaction? "; trans = read() + if (trans == 0) break; + bal -= trans + bal /= 1 +@} +quit + +@end example + + +The following is the definition of the recursive factorial function. + +@example + +define f (x) @{ + if (x <= 1) return (1); + return (f(x-1) * x); +@} + +@end example + +@node Readline and Libedit Options, GNU @command{bc} and Other Implementations, Examples, Top +@chapter Readline and Libedit Options + +GNU @command{bc} can be compiled (via a configure option) to use the GNU +@command{readline} input editor library or the BSD @command{libedit} +library. This allows the user to do +more editing of lines before sending them to @command{bc}. It also +allows for a history of previous lines typed. When this option is +selected, @command{bc} has one more special variable. This special +variable, @var{history} is the number of lines of history retained. A +value of -1 means that an unlimited number of history lines are +retained. This is the default value. Setting the value of +@var{history} to a positive number restricts the number of history lines +to the number given. The value of 0 disables the history feature. For +more information, read the user manuals for the GNU @command{readline}, +@command{history} and BSD @command{libedit} libraries. One can not +enable both @command{readline} and @command{libedit} at the same time. + +@node GNU @command{bc} and Other Implementations, Limits, Readline and Libedit Options, Top +@chapter GNU @command{bc} and Other Implementations + +This version of @command{bc} was implemented from the POSIX P1003.2/D11 +draft and contains several differences and extensions relative to the +draft and traditional implementations. It is not implemented in the +traditional way using @command{dc}. This version is a single process +which parses and runs a byte code translation of the program. There is +an "undocumented" option (-c) that causes the program to output the byte +code to the standard output instead of running it. It was mainly used +for debugging the parser and preparing the math library. + +A major source of differences is extensions, where a feature is extended +to add more functionality and additions, where new features are added. +The following is the list of differences and extensions. + +@table @var + +@item LANG environment +This version does not conform to the POSIX standard in the processing +of the LANG environment variable and all environment variables starting +with LC_. + +@item names +Traditional and POSIX @command{bc} +have single letter names for functions, variables and arrays. They have +been extended to be multi-character names that start with a letter and +may contain letters, numbers and the underscore character. + +@item Strings +Strings are not allowed to contain NUL characters. POSIX says all characters +must be included in strings. + +@item last +POSIX @command{bc} does not have a \fBlast variable. Some implementations +of @command{bc} use the period (.) in a similar way. + +@item comparisons +POSIX @command{bc} allows comparisons only in the @code{if} statement, +the @code{while} statement, and the second expression of the @code{for} +statement. Also, only one relational operation is allowed in each of +those statements. + +@item if statement, else clause +POSIX @command{bc} does not have an @code{else} clause. + +@item for statement +POSIX @command{bc} requires all expressions to be present in the +@code{for} statement. + +@item &&, ||, ! +POSIX @command{bc} does not have the logical operators. + +@item read function +POSIX @command{bc} does not have a @code{read} function. + +@item print statement +POSIX @command{bc} does not have a @code{print} statement. + +@item continue statement +POSIX @command{bc} does not have a continue statement. + +@item array parameters +POSIX @command{bc} does not (currently) support array parameters in full. +The POSIX grammar allows for arrays in function definitions, but does +not provide a method to specify an array as an actual parameter. (This +is most likely an oversight in the grammar.) Traditional implementations +of @command{bc} have only call by value array parameters. + +@item function format +POSIX @command{bc} requires the opening brace on the same line as the +@code{define} key word and the @code{auto} statement on the next line. + +@item =+, =-, =*, =/, =%, =^ +POSIX @command{bc} does not require these "old style" assignment +operators to be defined. This version may allow these "old style" +assignments. Use the @code{limits} statement to see if the installed +version supports them. If it does support the "old style" assignment +operators, the statement "a =- 1" will decrement @code{a} by 1 instead +of setting @code{a} to the value -1. + +@item spaces in numbers +Other implementations of @command{bc} allow spaces in numbers. For example, +"x=1 3" would assign the value 13 to the variable x. The same statement +would cause a syntax error in this version of @command{bc}. + +@item errors and execution +This implementation varies from other implementations in terms of what +code will be executed when syntax and other errors are found in the +program. If a syntax error is found in a function definition, error +recovery tries to find the beginning of a statement and continue to +parse the function. Once a syntax error is found in the function, the +function will not be callable and becomes undefined. +Syntax errors in the interactive execution code will invalidate the +current execution block. The execution block is terminated by an +end of line that appears after a complete sequence of statements. +For example, + +@example +a = 1 +b = 2 +@end example + +has two execution blocks and + +@example +@{ a = 1 + b = 2 @} +@end example + +has one execution block. Any runtime error will terminate the execution +of the current execution block. A runtime warning will not terminate the +current execution block. + +@item Interrupts +During an interactive session, the SIGINT signal (usually generated by +the control-C character from the terminal) will cause execution of the +current execution block to be interrupted. It will display a "runtime" +error indicating which function was interrupted. After all runtime +structures have been cleaned up, a message will be printed to notify the +user that @command{bc} is ready for more input. All previously defined +functions remain defined and the value of all non-auto variables are the +value at the point of interruption. All auto variables and function +parameters are removed during the clean up process. During a +non-interactive session, the SIGINT signal will terminate the entire run +of @command{bc}. +@end table + +@node Limits, Environment Variables, GNU @command{bc} and Other Implementations, Top +@chapter Limits + +The following are the limits currently in place for this @command{bc} +processor. Some of them may have been changed by an installation. Use +the @code{limits} statement to see the actual values. + +@table @code + +@item BC_BASE_MAX +The maximum output base is currently set at 999. The maximum input base +is 16. + +@item BC_DIM_MAX +This is currently an arbitrary limit of 65535 as distributed. Your +installation may be different. + +@item BC_SCALE_MAX +The number of digits after the decimal point is limited to INT_MAX digits. +Also, the number of digits before the decimal point is limited to INT_MAX +digits. + +@item BC_STRING_MAX +The limit on the number of characters in a string is INT_MAX characters. + +@item exponent +The value of the exponent in the raise operation (^) is limited to LONG_MAX. + +@item multiply +The multiply routine may yield incorrect results if a number +has more than LONG_MAX / 90 total digits. For 32 bit longs, this number is +23,860,929 digits. + +@item variable names +The current limit on the number of unique names is 32767 for each of +simple variables, arrays and functions. +@end table + +@node Environment Variables, , Limits, Top +@chapter Environment Variables + +The following environment variables are processed by @command{bc}: + +@table @code + + +@item POSIXLY_CORRECT +This is the same as the -s option (@pxref{Command Line Options}). + +@item BC_ENV_ARGS +This is another mechanism to get arguments to @command{bc}. The format +is the same as the command line arguments. These arguments are +processed first, so any files listed in the environent arguments are +processed before any command line argument files. This allows the user +to set up "standard" options and files to be processed at every +invocation of @command{bc}. The files in the environment variables +would typically contain function definitions for functions the user +wants defined every time @command{bc} is run. + +@item BC_LINE_LENGTH +This should be an integer specifing the number of characters in an +output line for numbers. This includes the backslash and newline +characters for long numbers. +@end table + +@contents +@bye + + diff --git a/contrib/bc/lib/testmul.c b/contrib/bc/lib/testmul.c new file mode 100644 index 000000000000..f7044d67f26e --- /dev/null +++ b/contrib/bc/lib/testmul.c @@ -0,0 +1,244 @@ +/* compute the crossover for recursive and simple multiplication */ + +#include <stdio.h> +#include <time.h> +#include "number.h" +#ifndef VARARGS +#include <stdarg.h> +#else +#include <varargs.h> +#endif + +/* from number.c ... */ +extern int mul_base_digits; +/* extern int mul_small_digits; */ +extern bc_num _one_; + +/* global variables */ +int test_n = 1000; +int test_time = 30 * CLOCKS_PER_SEC; /* 30 seconds */ + +/* Other things for number.c. */ +int std_only; + +void +out_of_memory() +{ + fprintf (stderr, "Fatal error: Out of memory for malloc.\n"); + exit (1); +} + +/* Runtime error will print a message and stop the machine. */ + +#ifndef VARARGS +#ifdef __STDC__ +void +rt_error (char *mesg, ...) +#else +void +rt_error (mesg) + char *mesg; +#endif +#else +void +rt_error (mesg, va_alist) + char *mesg; +#endif +{ + va_list args; + char error_mesg [255]; + +#ifndef VARARGS + va_start (args, mesg); +#else + va_start (args); +#endif + vsprintf (error_mesg, mesg, args); + va_end (args); + + fprintf (stderr, "Runtime error: %s\n", error_mesg); +} + +/* A runtime warning tells of some action taken by the processor that + may change the program execution but was not enough of a problem + to stop the execution. */ + +#ifndef VARARGS +#ifdef __STDC__ +void +rt_warn (char *mesg, ...) +#else +void +rt_warn (mesg) + char *mesg; +#endif +#else +void +rt_warn (mesg, va_alist) + char *mesg; +#endif +{ + va_list args; + char error_mesg [255]; + +#ifndef VARARGS + va_start (args, mesg); +#else + va_start (args); +#endif + vsprintf (error_mesg, mesg, args); + va_end (args); + + fprintf (stderr, "Runtime warning: %s\n", error_mesg); +} + +void +out_char (int ch) +{ + putchar (ch); +} + +/* Time stuff !!! */ + +int +timeit ( bc_num a, bc_num b, int *n) +{ + clock_t first; + int i, res; + bc_num c; + + bc_init_num (&c); + first = clock(); + *n = 0; + do { + for (i=0; i<test_n; i++) + bc_multiply(a,b,&c,0); + *n += test_n; + res = (int) (clock() - first); + } while (res < test_time); + return res; +} + +int debug = 0; /* Print debugging messages? */ + +int main (int argc, char **argv) +{ + bc_num ten, num, expo, big; + + int min, max, mid; + +#if 0 + int smallsize; +#endif + + int n1, n2; + clock_t t1, t2; + float permul1, permul2; + + /* args? */ + if (argc > 1) + if (strcmp (argv[1], "-d") == 0) + debug = 1; + + bc_init_numbers(); + bc_init_num (&ten); + bc_init_num (&num); + bc_init_num (&expo); + bc_init_num (&big); + bc_int2num (&ten, 10); + + if (debug) + fprintf (stderr, "Timings are for %d multiplies\n" + "Minimum time is %d seconds\n", test_n, + test_time/CLOCKS_PER_SEC); + + /* Two of the same size */ + min = 10; + max = 500; + + if (debug) + fprintf (stderr, "Testing numbers of the same length.\n"); + + while (min < max) { + mid = (min+max)/2; + if (debug) fprintf (stderr,"Checking %d...\n", mid); + + bc_int2num (&expo, mid); + bc_raise (ten, expo, &num, 0); + bc_sub (num, _one_, &num, 0); + + mul_base_digits = 2*mid+1; + t1 = timeit (num, num, &n1); + permul1 = (float)t1/(float)n1; + + mul_base_digits = 2*mid-1; + t2 = timeit (num, num, &n2); + permul2 = (float)t2/(float)n2; + + if (permul1 < permul2) + min = mid+1; + else + max = mid-1; + + if (debug) { + fprintf (stderr, "n1 = %d :: n2 = %d\n", n1, n2); + fprintf (stderr, "p1 = %f :: p2 = %f\n", permul1, permul2); + } + } + + if (debug) + fprintf (stderr, "Base digits crossover at %d digits\n", min); + printf ("#define MUL_BASE_DIGITS %d\n", 2*min); + + +#if 0 + mul_base_digits = min; + + /* Small one times a big one. */ + + smallsize = min/2; + bc_int2num (&expo, smallsize); + bc_raise (ten, expo, &big, 0); + bc_sub (num, _one_, &big, 0); + + min = min / 2; + max = 500; + + if (debug) + fprintf (stderr, "Testing numbers of the different length.\n"); + + while (min < max) { + mid = (min+max)/2; + if (debug) fprintf (stderr, "Checking %d...\n", mid); + + bc_int2num (&expo, mid-smallsize); + bc_raise (ten, expo, &num, 0); + bc_sub (num, _one_, &num, 0); + + mul_small_digits = mid+1; + t1 = timeit (big, num, &n1); + permul1 = (float)t1/(float)n1; + + mul_small_digits = mid-1; + t2 = timeit (big, num, &n2); + permul2 = (float)t2/(float)n2; + + if (permul1 < permul2) + min = mid+1; + else + max = mid-1; + + if (debug) { + fprintf (stderr, "n1 = %d :: n2 = %d\n", n1, n2); + fprintf (stderr, "p1 = %f :: p2 = %f\n", permul1, permul2); + } + } + + if (debug) + fprintf (stderr, "Non equal digits crossover at %d total digits\n", min); + printf ("#define MUL_SMALL_DIGITS = %d\n", min); + +#endif + + return 0; +} diff --git a/crypto/heimdal/ChangeLog.1998 b/crypto/heimdal/ChangeLog.1998 new file mode 100644 index 000000000000..f26dba777ed2 --- /dev/null +++ b/crypto/heimdal/ChangeLog.1998 @@ -0,0 +1,3201 @@ +Sat Dec 5 19:49:34 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/krb5/context.c: remove ktype_is_etype + + * lib/krb5/crypto.c, lib/krb5/krb5.h, acconfig.h: NEW_DES3_CODE + + * configure.in: fix for AIX install; better tests for AIX dynamic + AFS libs; `--enable-new-des3-code' + +Tue Dec 1 14:44:44 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * appl/afsutil/Makefile.am: link with extra libs for aix + + * kuser/Makefile.am: link with extra libs for aix + +Sun Nov 29 01:56:21 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_addrs.c (krb5_get_all_server_addrs): add. almost + the same as krb5_get_all_client_addrs except that it includes + loopback addresses + + * kdc/connect.c (init_socket): bind to a particular address + (init_sockets): get all local addresses and bind to them all + + * lib/krb5/addr_families.c (addr2sockaddr, print_addr): new + methods + (find_af, find_atype): new functions. use them. + + * configure.in: add hesiod + +Wed Nov 25 11:37:48 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/krb5/krb5_err.et: add some codes from kerberos-revisions-03 + +Mon Nov 23 12:53:48 1998 Assar Westerlund <assar@sics.se> + + * lib/kadm5/log.c: rename delete -> remove + + * lib/kadm5/delete_s.c: rename delete -> remove + + * lib/hdb/common.c: rename delete -> remove + +Sun Nov 22 12:26:26 1998 Assar Westerlund <assar@sics.se> + + * configure.in: check for environ and `struct spwd' + +Sun Nov 22 11:42:45 1998 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kdc/kerberos5.c (as_rep): set keytype to sess_ktype if + ktype_is_etype + + * lib/krb5/encrypt.c (krb5_keytype_to_etypes): zero terminate + etypes + (em): sort entries + +Sun Nov 22 06:54:48 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/init_creds_pw.c: more type correctness + + * lib/krb5/get_cred.c: re-structure code. remove limits on ASN1 + generated bits. + +Sun Nov 22 01:49:50 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * kdc/hprop.c (v4_prop): fix bogus indexing + +Sat Nov 21 21:39:20 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/verify_init.c (fail_verify_is_ok): new function + (krb5_verify_init_creds): if we cannot get a ticket for + host/`hostname` and fail_verify_is_ok just return. use + krb5_rd_req + +Sat Nov 21 23:12:27 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/free.c (krb5_xfree): new function + + * lib/krb5/creds.c (krb5_free_creds_contents): new function + + * lib/krb5/context.c: more type correctness + + * lib/krb5/checksum.c: more type correctness + + * lib/krb5/auth_context.c (krb5_auth_con_init): more type + correctness + + * lib/asn1/der_get.c (der_get_length): fix test of len + (der_get_tag): more type correctness + + * kuser/klist.c (usage): void-ize + + * admin/ktutil.c (kt_remove): some more type correctness. + +Sat Nov 21 16:49:20 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * kuser/klist.c: try to list enctypes as keytypes + + * kuser/kinit.c: remove extra `--cache' option, add `--enctypes' + to set list of enctypes to use + + * kadmin/load.c: load strings as hex + + * kadmin/dump.c: dump hex as string is possible + + * admin/ktutil.c: use print_version() + + * configure.in, acconfig.h: test for hesiod + +Sun Nov 15 17:28:19 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/krb5/crypto.c: add some crypto debug code + + * lib/krb5/get_in_tkt.c (_krb5_extract_ticket): don't use fixed + buffer when encoding ticket + + * lib/krb5/auth_context.c (re-)implement `krb5_auth_setenctype' + + * kdc/kerberos5.c: allow mis-match of tgt session key, and service + session key + + * admin/ktutil.c: keytype -> enctype + +Fri Nov 13 05:35:48 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/krb5.h (KRB5_TGS_NAME, KRB5_TGS_NAME_SIZE): added + +Sat Nov 7 19:56:31 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_cred.c (add_cred): add termination NULL pointer + +Mon Nov 2 01:15:06 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_req.c: adapt to new crypto api + + * lib/krb5/rd_rep.c: adapt to new crypto api + + * lib/krb5/rd_priv.c: adopt to new crypto api + + * lib/krb5/rd_cred.c: adopt to new crypto api + + * lib/krb5/principal.c: ENOMEM -> ERANGE + + * lib/krb5/mk_safe.c: cleanup and adopt to new crypto api + + * lib/krb5/mk_req_ext.c: adopt to new crypto api + + * lib/krb5/mk_req.c: get enctype from auth_context keyblock + + * lib/krb5/mk_rep.c: cleanup and adopt to new crypto api + + * lib/krb5/mk_priv.c: adopt to new crypto api + + * lib/krb5/keytab.c: adopt to new crypto api + + * lib/krb5/get_in_tkt_with_skey.c: adopt to new crypto api + + * lib/krb5/get_in_tkt_with_keytab.c: adopt to new crypto api + + * lib/krb5/get_in_tkt_pw.c: adopt to new crypto api + + * lib/krb5/get_in_tkt.c: adopt to new crypto api + + * lib/krb5/get_cred.c: adopt to new crypto api + + * lib/krb5/generate_subkey.c: use new crypto api + + * lib/krb5/context.c: rename etype functions to enctype ditto + + * lib/krb5/build_auth.c: use new crypto api + + * lib/krb5/auth_context.c: remove enctype and cksumtype from + auth_context + +Mon Nov 2 01:15:06 1998 Assar Westerlund <assar@sics.se> + + * kdc/connect.c (handle_udp, handle_tcp): correct type of `n' + +Tue Sep 15 18:41:38 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * admin/ktutil.c: fix printing of unrecognized keytypes + +Tue Sep 15 17:02:33 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/kadm5/set_keys.c: add KEYTYPE_USE_AFS3_SALT to keytype if + using AFS3 salt + +Tue Aug 25 23:30:52 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/send_to_kdc.c (krb5_sendto_kdc): care about + `use_admin_kdc' + + * lib/krb5/changepw.c (get_kdc_address): use + krb5_get_krb_admin_hst + + * lib/krb5/krbhst.c (krb5_get_krb_admin_hst): new function + + * lib/krb5/krb5.h (krb5_context_data): add `use_admin_kdc' + + * lib/krb5/context.c (krb5_get_use_admin_kdc, + krb5_set_use_admin_kdc): new functions + +Tue Aug 18 22:24:12 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/crypto.c: remove all calls to abort(); check return + value from _key_schedule; + (RSA_MD[45]_DES_verify): zero tmp and res; + (RSA_MD5_DES3_{verify,checksum}): implement + +Mon Aug 17 20:18:46 1998 Assar Westerlund <assar@sics.se> + + * kdc/kerberos4.c (swap32): conditionalize + + * lib/krb5/mk_req_ext.c (krb5_mk_req_internal): new function + + * lib/krb5/get_host_realm.c (krb5_get_host_realm): if the hostname + returned from gethostby*() isn't a FQDN, try with the original + hostname + + * lib/krb5/get_cred.c (make_pa_tgs_req): use krb5_mk_req_internal + and correct key usage + + * lib/krb5/crypto.c (verify_checksum): make static + + * admin/ktutil.c (kt_list): use krb5_enctype_to_string + +Sun Aug 16 20:57:56 1998 Assar Westerlund <assar@sics.se> + + * kadmin/cpw.c (do_cpw_entry): use asprintf for the prompt + + * kadmin/ank.c (ank): print principal name in prompt + + * lib/krb5/crypto.c (hmac): always allocate space for checksum. + never trust c.checksum.length + (_get_derived_key): try to return the derived key + +Sun Aug 16 19:48:42 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/crypto.c (hmac): fix some peculiarities and bugs + (get_checksum_key): assume usage is `formatted' + (create_checksum,verify_checksum): moved the guts of the krb5_* + functions here, both take `formatted' key-usages + (encrypt_internal_derived): fix various bogosities + (derive_key): drop key_type parameter (already given by the + encryption_type) + + * kdc/kerberos5.c (check_flags): handle case where client is NULL + + * kdc/connect.c (process_request): return zero after processing + kerberos 4 request + +Sun Aug 16 18:38:15 1998 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/crypto.c: merge x-*.[ch] into one file + + * lib/krb5/cache.c: remove residual from krb5_ccache_data + +Fri Aug 14 16:28:23 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/x-crypto.c (derive_key): move DES3 specific code to + separate function (will eventually end up someplace else) + + * lib/krb5/x-crypto.c (krb5_string_to_key_derived): allocate key + + * configure.in, acconfig.h: test for four valued krb_put_int + +Thu Aug 13 23:46:29 1998 Assar Westerlund <assar@emma.pdc.kth.se> + + * Release 0.0t + +Thu Aug 13 22:40:17 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/config_file.c (parse_binding): remove trailing + whitespace + +Wed Aug 12 20:15:11 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/x-checksum.c (krb5_verify_checksum): pass checksum type + to krb5_create_checksum + + * lib/krb5/x-key.c: implement DES3_string_to_key_derived; fix a + few typos + +Wed Aug 5 12:39:54 1998 Assar Westerlund <assar@emma.pdc.kth.se> + + * Release 0.0s + +Thu Jul 30 23:12:17 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/mk_error.c (krb5_mk_error): realloc until you die + +Thu Jul 23 19:49:03 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kdc_locl.h: proto for `get_des_key' + + * configure.in: test for four valued el_init + + * kuser/klist.c: keytype -> enctype + + * kpasswd/kpasswdd.c (change): use new `krb5_string_to_key*' + + * kdc/hprop.c (v4_prop, ka_convert): convert to a set of keys + + * kdc/kaserver.c: use `get_des_key' + + * kdc/524.c: use new crypto api + + * kdc/kerberos4.c: use new crypto api + + * kdc/kerberos5.c: always treat keytypes as enctypes; use new + crypto api + + * kdc/kstash.c: adapt to new crypto api + + * kdc/string2key.c: adapt to new crypto api + + * admin/srvconvert.c: add keys for all possible enctypes + + * admin/ktutil.c: keytype -> enctype + + * lib/gssapi/init_sec_context.c: get enctype from auth_context + keyblock + + * lib/hdb/hdb.c: remove hdb_*_keytype2key + + * lib/kadm5/set_keys.c: adapt to new crypto api + + * lib/kadm5/rename_s.c: adapt to new crypto api + + * lib/kadm5/get_s.c: adapt to new crypto api + + * lib/kadm5/create_s.c: add keys for des-cbc-crc, des-cbc-md4, + des-cbc-md5, and des3-cbc-sha1 + + * lib/krb5/heim_err.et: error message for unsupported salt + + * lib/krb5/codec.c: short-circuit these functions, since they are + not needed any more + + * lib/krb5/rd_safe.c: cleanup and adapt to new crypto api + +Mon Jul 13 23:00:59 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/send_to_kdc.c (krb5_sendto_kdc): don't advance + hostent->h_addr_list, use a copy instead + +Mon Jul 13 15:00:31 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/config_file.c (parse_binding, parse_section): make sure + everything is ok before adding to linked list + + * lib/krb5/config_file.c: skip ws before checking for comment + +Wed Jul 8 10:45:45 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/asn1/k5.asn1: hmac-sha1-des3 = 12 + +Tue Jun 30 18:08:05 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/send_to_kdc.c (krb5_sendto_kdc): do not close the + unopened file + + * lib/krb5/mk_priv.c: realloc correctly + + * lib/krb5/get_addrs.c (find_all_addresses): init j + + * lib/krb5/context.c (krb5_init_context): print error if parsing + of config file produced an error. + + * lib/krb5/config_file.c (parse_list, krb5_config_parse_file): + ignore more spaces + + * lib/krb5/codec.c (krb5_encode_EncKrbCredPart, + krb5_encode_ETYPE_INFO): initialize `ret' + + * lib/krb5/build_auth.c (krb5_build_authenticator): realloc + correctly + + * lib/kadm5/set_keys.c (_kadm5_set_keys): initialize `ret' + + * lib/kadm5/init_c.c (get_cred_cache): try to do the right thing + with default_client + + * kuser/kinit.c (main): initialize `ticket_life' + + * kdc/kerberos5.c (get_pa_etype_info): initialize `ret' + (tgs_rep2): initialize `krbtgt' + + * kdc/connect.c (do_request): check for errors from `sendto' + + * kdc/524.c (do_524): initialize `ret' + + * kadmin/util.c (foreach_principal): don't clobber `ret' + + * kadmin/del.c (del_entry): don't apply on zeroth argument + + * kadmin/cpw.c (do_cpw_entry): initialize `ret' + +Sat Jun 13 04:14:01 1998 Assar Westerlund <assar@juguete.sics.se> + + * Release 0.0r + +Sun Jun 7 04:13:14 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/addr_families.c: fall-back definition of + IN6_ADDR_V6_TO_V4 + + * configure.in: only set CFLAGS if it wasn't set look for + dn_expand and res_search + +Mon Jun 1 21:28:07 1998 Assar Westerlund <assar@sics.se> + + * configure.in: remove duplicate seteuid + +Sat May 30 00:19:51 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/convert_creds.c: import _krb_time_to_life, to avoid + runtime dependencies on libkrb with some shared library + implementations + +Fri May 29 00:09:02 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * kuser/kinit_options.c: Default options for kinit. + + * kuser/kauth_options.c: Default options for kauth. + + * kuser/kinit.c: Implement lots a new options. + + * kdc/kerberos5.c (check_tgs_flags): make sure kdc-req-body->rtime + is not NULL; set endtime to min of new starttime + old_life, and + requested endtime + + * lib/krb5/init_creds_pw.c (get_init_creds_common): if the + forwardable or proxiable flags are set in options, set the + kdc-flags to the value specified, and not always to one + +Thu May 28 21:28:06 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos5.c: Optionally compare client address to addresses + in ticket. + + * kdc/connect.c: Pass client address to as_rep() and tgs_rep(). + + * kdc/config.c: Add check_ticket_addresses, and + allow_null_ticket_addresses variables. + +Tue May 26 14:03:42 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/kadm5/create_s.c: possibly make DES keys version 4 salted + + * lib/kadm5/set_keys.c: check config file for kadmin/use_v4_salt + before zapping version 4 salts + +Sun May 24 05:22:17 1998 Assar Westerlund <assar@sics.se> + + * Release 0.0q + + * lib/krb5/aname_to_localname.c: new file + + * lib/gssapi/init_sec_context.c (repl_mutual): no output token + + * lib/gssapi/display_name.c (gss_display_name): zero terminate + output. + +Sat May 23 19:11:07 1998 Assar Westerlund <assar@sics.se> + + * lib/gssapi/display_status.c: new file + + * Makefile.am: send -I to aclocal + + * configure.in: remove duplicate setenv + +Sat May 23 04:55:19 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * kadmin/util.c (foreach_principal): Check for expression before + wading through the whole database. + + * kadmin/kadmin.c: Pass NULL password to + kadm5_*_init_with_password. + + * lib/kadm5/init_c.c: Implement init_with_{skey,creds}*. Make use + of `password' parameter to init_with_password. + + * lib/kadm5/init_s.c: implement init_with_{skey,creds}* + + * lib/kadm5/server.c: Better arguments for + kadm5_init_with_password. + +Sat May 16 07:10:36 1998 Assar Westerlund <assar@sics.se> + + * kdc/hprop.c: conditionalize ka-server reading support on + KASERVER_DB + + * configure.in: new option `--enable-kaserver-db' + +Fri May 15 19:39:18 1998 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/get_cred.c: Better error if local tgt couldn't be + found. + +Tue May 12 21:11:02 1998 Assar Westerlund <assar@sics.se> + + * Release 0.0p + + * lib/krb5/mk_req_ext.c (krb5_mk_req_extended): only set + encryption type in auth_context if it's compatible with the type + of the session key + +Mon May 11 21:11:14 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/hprop.c: add support for ka-server databases + + * appl/ftp/ftpd: link with -lcrypt, if needed + +Fri May 1 07:29:52 1998 Assar Westerlund <assar@sics.se> + + * configure.in: don't test for winsock.h + +Sat Apr 18 21:43:11 1998 Johan Danielsson <joda@puffer.pdc.kth.se> + + * Release 0.0o + +Sat Apr 18 00:31:11 1998 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/sock_principal.c: Save hostname. + +Sun Apr 5 11:29:45 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/mk_req_ext.c: Use same enctype as in ticket. + + * kdc/hprop.c (v4_prop): Check for null key. + +Fri Apr 3 03:54:54 1998 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/str2key.c: Fix DES3 string-to-key. + + * lib/krb5/keytab.c: Get default keytab name from context. + + * lib/krb5/context.c: Get `default_keytab_name' value. + + * kadmin/util.c (foreach_principal): Print error message if + `kadm5_get_principals' fails. + + * kadmin/kadmind.c: Use `kadmind_loop'. + + * lib/kadm5/server.c: Replace several other functions with + `kadmind_loop'. + +Sat Mar 28 09:49:18 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/keytab.c (fkt_add_entry): use an explicit seek instead + of O_APPEND + + * configure.in: generate ftp Makefiles + + * kuser/klist.c (print_cred_verbose): print IPv4-address in a + portable way. + + * admin/srvconvert.c (srvconv): return 0 if successful + +Tue Mar 24 00:40:33 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/keytab.c: MIT compatible changes: add and use sizes to + keytab entries, and change default keytab to `/etc/krb5.keytab'. + +Mon Mar 23 23:43:59 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/gssapi/wrap.c: Use `gss_krb5_getsomekey'. + + * lib/gssapi/unwrap.c: Implement and use `gss_krb5_getsomekey'. + Fix bug in checking of pad. + + * lib/gssapi/{un,}wrap.c: Add support for just integrity + protecting data. + + * lib/gssapi/accept_sec_context.c: Use + `gssapi_krb5_verify_8003_checksum'. + + * lib/gssapi/8003.c: Implement `gssapi_krb5_verify_8003_checksum'. + + * lib/gssapi/init_sec_context.c: Zero cred, and store session key + properly in auth-context. + +Sun Mar 22 00:47:22 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/kadm5/delete_s.c: Check immutable bit. + + * kadmin/kadmin.c: Pass client name to kadm5_init. + + * lib/kadm5/init_c.c: Get creds for client name passed in. + + * kdc/hprop.c (v4_prop): Check for `changepw.kerberos'. + +Sat Mar 21 22:57:13 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/mk_error.c: Verify that error_code is in the range + [0,127]. + + * kdc/kerberos5.c: Move checking of principal flags to new + function `check_flags'. + +Sat Mar 21 14:38:51 1998 Assar Westerlund <assar@sics.se> + + * lib/kadm5/get_s.c (kadm5_s_get_principal): handle an empty salt + + * configure.in: define SunOS if running solaris + +Sat Mar 21 00:26:34 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/kadm5/server.c: Unifdef test for same principal when + changing password. + + * kadmin/util.c: If kadm5_get_principals failes, we might still be + able to perform the requested opreration (for instance someone if + trying to change his own password). + + * lib/kadm5/init_c.c: Try to get ticket via initial request, if + not possible via tgt. + + * lib/kadm5/server.c: Check for principals changing their own + passwords. + + * kdc/kerberos5.c (tgs_rep2): check for interesting flags on + involved principals. + + * kadmin/util.c: Fix order of flags. + +Thu Mar 19 16:54:10 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos4.c: Return sane error code if krb_rd_req fails. + +Wed Mar 18 17:11:47 1998 Assar Westerlund <assar@sics.se> + + * acconfig.h: rename HAVE_STRUCT_SOCKADDR_IN6 to HAVE_IPV6 + +Wed Mar 18 09:58:18 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/get_in_tkt_with_keytab.c (krb5_keytab_key_proc): don't + free keyseed; use correct keytab + +Tue Mar 10 09:56:16 1998 Assar Westerlund <assar@sics.se> + + * acinclude.m4 (AC_KRB_IPV6): rewrote to avoid false positives + +Mon Mar 16 23:58:23 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * Release 0.0n + +Fri Mar 6 00:41:30 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/gssapi/{accept_sec_context,release_cred}.c: Use + krb5_kt_close/krb5_kt_resolve. + + * lib/krb5/principal.c (krb5_425_conv_principal_ext): Use resolver + to lookup hosts, so CNAMEs can be ignored. + + * lib/krb5/send_to_kdc.c (krb5_sendto_kdc, send_and_recv_http): + Add support for using proxy. + + * lib/krb5/context.c: Initialize `http_proxy' from + `libdefaults/http_proxy'. + + * lib/krb5/krb5.h: Add `http_proxy' to context. + + * lib/krb5/send_to_kdc.c: Recognize `http/' and `udp/' as protocol + specifications. + +Wed Mar 4 01:47:29 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * admin/ktutil.c: Implement `add' and `remove' functions. Make + `--keytab' a global option. + + * lib/krb5/keytab.c: Implement remove with files. Add memory + operations. + +Tue Mar 3 20:09:59 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/keytab.c: Use function pointers. + + * admin: Remove kdb_edit. + +Sun Mar 1 03:28:42 1998 Assar Westerlund <assar@sics.se> + + * lib/kadm5/dump_log.c: print operation names + +Sun Mar 1 03:04:12 1998 Assar Westerlund <assar@sics.se> + + * configure.in: add X-tests, and {bin,...}dir appl/{kx,kauth} + + * lib/krb5/build_auth.c,mk_priv.c,rd_safe.c,mk_safe.c,mk_rep.c: + remove arbitrary limit + + * kdc/hprop-common.c: use krb5_{read,write}_message + + * lib/kadm5/ipropd_master.c (send_diffs): more careful use + krb5_{write,read}_message + + * lib/kadm5/ipropd_slave.c (get_creds): get credentials for + `iprop/master' directly. + (main): use `krb5_read_message' + +Sun Mar 1 02:05:11 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * kadmin/kadmin.c: Cleanup commands list, and add help strings. + + * kadmin/get.c: Add long, short, and terse (equivalent to `list') + output formats. Short is the default. + + * kadmin/util.c: Add `include_time' flag to timeval2str. + + * kadmin/init.c: Max-life and max-renew can, infact, be zero. + + * kadmin/{cpw,del,ext,get}.c: Use `foreach_principal'. + + * kadmin/util.c: Add function `foreach_principal', that loops over + all principals matching an expression. + + * kadmin/kadmin.c: Add usage string to `privileges'. + + * lib/kadm5/get_princs_s.c: Also try to match aganist the + expression appended with `@default-realm'. + + * lib/krb5/principal.c: Add `krb5_unparse_name_fixed_short', that + excludes the realm if it's the same as the default realm. + +Fri Feb 27 05:02:21 1998 Assar Westerlund <assar@sics.se> + + * configure.in: more WFLAGS and WFLAGS_NOUNUSED added missing + headers and functions error -> com_err + + (krb5_get_init_creds_keytab): use krb5_keytab_key_proc + + * lib/krb5/get_in_tkt_with_keytab.c: make `krb5_keytab_key_proc' + global + + * lib/kadm5/marshall.c (ret_principal_ent): set `n_tl_data' + + * lib/hdb/ndbm.c: use `struct ndbm_db' everywhere. + +Fri Feb 27 04:49:24 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/mk_priv.c (krb5_mk_priv): bump static limit to 10240. + This should be fixed the correct way. + + * lib/kadm5/ipropd_master.c (check_acl:) truncate buf correctly + (send_diffs): compare versions correctly + (main): reorder handling of events + + * lib/kadm5/log.c (kadm5_log_previous): avoid bad type conversion + +Thu Feb 26 02:22:35 1998 Assar Westerlund <assar@sics.se> + + * lib/kadm5/ipropd_{slave,master}.c: new files + + * lib/kadm5/log.c (kadm5_log_get_version): take an `fd' as + argument + + * lib/krb5/krb5.h (krb5_context_data): `et_list' should be `struct + et_list *' + + * aux/make-proto.pl: Should work with perl4 + +Mon Feb 16 17:20:22 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/krb5_locl.h: Remove <error.h> (it gets included via + {asn1,krb5}_err.h). + +Thu Feb 12 03:28:40 1998 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_in_tkt.c (_krb5_extract_ticket): if time difference + is larger than max_skew, return KRB5KRB_AP_ERR_SKEW + + * lib/kadm5/log.c (get_version): globalize + + * lib/kadm5/kadm5_locl.h: include <sys/file.h> + + * lib/asn1/Makefile.am: add PA_KEY_INFO and PA_KEY_INFO_ENTRY + + * kdc/kerberos5.c (get_pa_etype_info): remove gcc-ism of + initializing local struct in declaration. + +Sat Jan 31 17:28:58 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/524.c: Use krb5_decode_EncTicketPart. + + * kdc/kerberos5.c: Check at runtime whether to use enctypes + instead of keytypes. If so use the same value to encrypt ticket, + and kdc-rep as well as `keytype' for session key. Fix some obvious + bugs with the handling of additional tickets. + + * lib/krb5/rd_req.c: Use krb5_decode_EncTicketPart, and + krb5_decode_Authenticator. + + * lib/krb5/rd_rep.c: Use krb5_decode_EncAPRepPart. + + * lib/krb5/rd_cred.c: Use krb5_decode_EncKrbCredPart. + + * lib/krb5/mk_rep.c: Make sure enc_part.etype is an encryption + type, and not a key type. Use krb5_encode_EncAPRepPart. + + * lib/krb5/init_creds_pw.c: Use krb5_decode_PA_KEY_INFO. + + * lib/krb5/get_in_tkt.c: Use krb5_decode_Enc{AS,TGS}RepPart. + + * lib/krb5/get_for_creds.c: Use krb5_encode_EncKrbCredPart. + + * lib/krb5/get_cred.c: Use krb5_decode_Enc{AS,TGS}RepPart. + + * lib/krb5/build_auth.c: Use krb5_encode_Authenticator. + + * lib/krb5/codec.c: Enctype conversion stuff. + + * lib/krb5/context.c: Ignore KRB5_CONFIG if *not* running + setuid. Get configuration for libdefaults ktype_is_etype, and + default_etypes. + + * lib/krb5/encrypt.c: Add krb5_string_to_etype, rename + krb5_convert_etype to krb5_decode_keytype, and add + krb5_decode_keyblock. + +Fri Jan 23 00:32:09 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/{get_in_tkt,rd_req}.c: Use krb5_convert_etype. + + * lib/krb5/encrypt.c: Add krb5_convert_etype function - converts + from protocol keytypes (that really are enctypes) to internal + representation. + +Thu Jan 22 21:24:36 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/asn1/k5.asn1: Add PA-KEY-INFO structure to hold information + on keys in the database; and also a new `pa-key-info' padata-type. + + * kdc/kerberos5.c: If pre-authentication fails, return a list of + keytypes, salttypes, and salts. + + * lib/krb5/init_creds_pw.c: Add better support for + pre-authentication, by looking at hints from the KDC. + + * lib/krb5/get_in_tkt.c: Add better support for specifying what + pre-authentication to use. + + * lib/krb5/str2key.c: Merge entries for KEYTYPE_DES and + KEYTYPE_DES_AFS3. + + * lib/krb5/krb5.h: Add pre-authentication structures. + + * kdc/connect.c: Don't fail if realloc(X, 0) returns NULL. + +Wed Jan 21 06:20:40 1998 Assar Westerlund <assar@sics.se> + + * lib/kadm5/init_s.c (kadm5_s_init_with_password_ctx): initialize + `log_context.socket_name' and `log_context.socket_fd' + + * lib/kadm5/log.c (kadm5_log_flush): send a unix domain datagram + to inform the possible running ipropd of an update. + +Wed Jan 21 01:34:09 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/get_in_tkt.c: Return error-packet to caller. + + * lib/krb5/free.c (krb5_free_kdc_rep): Free krb5_kdc_rep->error. + + * kdc/kerberos5.c: Add some support for using enctypes instead of + keytypes. + + * lib/krb5/get_cred.c: Fixes to send authorization-data to the + KDC. + + * lib/krb5/build_auth.c: Only generate local subkey if there is + none. + + * lib/krb5/krb5.h: Add krb5_authdata type. + + * lib/krb5/auth_context.c: Add + krb5_auth_con_set{,localsub,remotesub}key. + + * lib/krb5/init_creds_pw.c: Return some error if prompter + functions return failure. + +Wed Jan 21 01:16:13 1998 Assar Westerlund <assar@sics.se> + + * kpasswd/kpasswd.c: detect bad password. use krb5_err. + + * kadmin/util.c (edit_entry): remove unused variables + +Tue Jan 20 22:58:31 1998 Assar Westerlund <assar@sics.se> + + * kuser/kinit.c: rename `-s' to `-S' to be MIT-compatible. + + * lib/kadm5/kadm5_locl.h: add kadm5_log_context and + kadm5_log*-functions + + * lib/kadm5/create_s.c (kadm5_s_create_principal): add change to + log + + * lib/kadm5/rename_s.c (kadm5_s_rename_principal): add change to + log + + * lib/kadm5/init_s.c (kadm5_s_init_with_password_ctx): initialize + log_context + + * lib/kadm5/delete_s.c (kadm5_s_delete_principal): add change to + log + + * lib/kadm5/modify_s.c (kadm5_s_modify_principal): add change to + log + + * lib/kadm5/randkey_s.c (kadm5_s_randkey_principal): add change to + log + + * lib/kadm5/chpass_s.c (kadm5_s_chpass_principal): add change to + log + + * lib/kadm5/Makefile.am: add log.c, dump_log and replay_log + + * lib/kadm5/replay_log.c: new file + + * lib/kadm5/dump_log.c: new file + + * lib/kadm5/log.c: new file + + * lib/krb5/str2key.c (get_str): initialize pad space to zero + + * lib/krb5/config_file.c (krb5_config_vget_next): handle c == NULL + + * kpasswd/kpasswdd.c: rewritten to use the kadm5 API + + * kpasswd/Makefile.am: link with kadm5srv + + * kdc/kerberos5.c (tgs_rep): initialize `i' + + * kadmin/kadmind.c (main): use kadm5_server_{send,recv}_sp + + * include/Makefile.am: added admin.h + +Sun Jan 18 01:41:34 1998 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/asn1/gen_copy.c: Don't return ENOMEM if allocating 0 bytes. + + * lib/krb5/mcache.c (mcc_store_cred): restore linked list if + copy_creds fails. + +Tue Jan 6 04:17:56 1998 Assar Westerlund <assar@sics.se> + + * lib/kadm5/server.c: add kadm5_server_{send,recv}{,_sp} + + * lib/kadm5/marshall.c: add kadm5_{store,ret}_principal_ent_mask. + + * lib/kadm5/init_c.c (kadm5_c_init_with_password_ctx): use + krb5_getportbyname + + * kadmin/kadmind.c (main): htons correctly. + moved kadm5_server_{recv,send} + + * kadmin/kadmin.c (main): only set admin_server if explicitly + given + +Mon Jan 5 23:34:44 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/hdb/ndbm.c: Implement locking of database. + + * kdc/kerberos5.c: Process AuthorizationData. + +Sat Jan 3 22:07:07 1998 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kdc/string2key.c: Use AFS string-to-key from libkrb5. + + * lib/krb5/get_in_tkt.c: Handle pa-afs3-salt case. + + * lib/krb5/krb5.h: Add value for AFS salts. + + * lib/krb5/str2key.c: Add support for AFS string-to-key. + + * lib/kadm5/rename_s.c: Use correct salt. + + * lib/kadm5/ent_setup.c: Always enable client. Only set max-life + and max-renew if != 0. + + * lib/krb5/config_file.c: Add context to all krb5_config_*get_*. + +Thu Dec 25 17:03:25 1997 Assar Westerlund <assar@sics.se> + + * kadmin/ank.c (ank): don't zero password if --random-key was + given. + +Tue Dec 23 01:56:45 1997 Assar Westerlund <assar@sics.se> + + * Release 0.0m + + * lib/kadm5/ent_setup.c (attr_to_flags): try to set `client' + + * kadmin/util.c (edit_time): only set mask if != 0 + (edit_attributes): only set mask if != 0 + + * kadmin/init.c (init): create `default' + +Sun Dec 21 09:44:05 1997 Assar Westerlund <assar@sics.se> + + * kadmin/util.c (str2deltat, str2attr, get_deltat): return value + as pointer and have return value indicate success. + + (get_response): check NULL from fgets + + (edit_time, edit_attributes): new functions for reading values and + offering list of answers on '?' + + (edit_entry): use edit_time and edit_attributes + + * kadmin/ank.c (add_new_key): test the return value of + `krb5_parse_name' + + * kdc/kerberos5.c (tgs_check_authenticator): RFC1510 doesn't say + that the checksum has to be keyed, even though later drafts do. + Accept unkeyed checksums to be compatible with MIT. + + * kadmin/kadmin_locl.h: add some prototypes. + + * kadmin/util.c (edit_entry): return a value + + * appl/afsutil/afslog.c (main): return a exit code. + + * lib/krb5/get_cred.c (init_tgs_req): use krb5_keytype_to_enctypes + + * lib/krb5/encrypt.c (krb5_keytype_to_enctypes): new function. + + * lib/krb5/build_auth.c (krb5_build_authenticator): use + krb5_{free,copy}_keyblock instead of the _contents versions + +Fri Dec 12 14:20:58 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/{mk,rd}_priv.c: fix check for local/remote subkey + +Mon Dec 8 08:48:09 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/context.c: don't look at KRB5_CONFIG if running setuid + +Sat Dec 6 10:09:40 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/keyblock.c (krb5_free_keyblock): check for NULL + keyblock + +Sat Dec 6 08:26:10 1997 Assar Westerlund <assar@sics.se> + + * Release 0.0l + +Thu Dec 4 03:38:12 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/send_to_kdc.c: Add TCP client support. + + * lib/krb5/store.c: Add k_{put,get}_int. + + * kadmin/ank.c: Set initial kvno to 1. + + * kdc/connect.c: Send version 5 TCP-reply as length+data. + +Sat Nov 29 07:10:11 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_req.c (krb5_rd_req): fixed obvious bug + + * kdc/kaserver.c (create_reply_ticket): use a random nonce in the + reply packet. + + * kdc/connect.c (init_sockets): less reallocing. + + * **/*.c: changed `struct fd_set' to `fd_set' + +Sat Nov 29 05:12:01 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/get_default_principal.c: More guessing. + +Thu Nov 20 02:55:09 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/rd_req.c: Use principal from ticket if no server is + given. + +Tue Nov 18 02:58:02 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kuser/klist.c: Use krb5_err*(). + +Sun Nov 16 11:57:43 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kadmin/kadmin.c: Add local `init', `load', `dump', and `merge' + commands. + +Sun Nov 16 02:52:20 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/mk_req_ext.c (krb5_mk_req_ext): figure out the correct + `enctype' + + * lib/krb5/mk_req.c (krb5_mk_req): use `(*auth_context)->enctype' + if set. + + * lib/krb5/get_cred.c: handle the case of a specific keytype + + * lib/krb5/build_auth.c (krb5_build_authenticator): enctype as a + parameter instead of guessing it. + + * lib/krb5/build_ap_req.c (krb5_build_ap_req): new parameter + `enctype' + + * appl/test/common.c (common_setup): don't use `optarg' + + * lib/krb5/keytab.c (krb5_kt_copy_entry_contents): new function + (krb5_kt_get_entry): retrieve the latest version if kvno == 0 + + * lib/krb5/krb5.h: define KRB5_TC_MATCH_KEYTYPE + + * lib/krb5/creds.c (krb5_compare_creds): check for + KRB5_TC_MATCH_KEYTYPE + + * lib/gssapi/8003.c (gssapi_krb5_create_8003_checksum): remove + unused variable + + * lib/krb5/creds.c (krb5_copy_creds_contents): only free the + contents if we fail. + +Sun Nov 16 00:32:48 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kpasswd/kpasswdd.c: Get password expiration time from config + file. + + * lib/asn1/{der_get,gen_decode}.c: Allow passing NULL size. + +Wed Nov 12 02:35:57 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_for_creds.c (krb5_get_forwarded_creds): + restructured and fixed. + + * lib/krb5/addr_families.c (krb5_h_addr2addr): new function. + +Wed Nov 12 01:36:01 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/get_addrs.c: Fall back to hostname's addresses if other + methods fail. + +Tue Nov 11 22:22:12 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kadmin/kadmin.c: Add `-l' flag to use local database. + + * lib/kadm5/acl.c: Use KADM5_PRIV_ALL. + + * lib/kadm5: Use function pointer trampoline for easier dual use + (without radiation-hardening capability). + +Tue Nov 11 05:15:22 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/encrypt.c (krb5_etype_valid): new function + + * lib/krb5/creds.c (krb5_copy_creds_contents): zero target + + * lib/krb5/context.c (valid_etype): remove + + * lib/krb5/checksum.c: remove dead code + + * lib/krb5/changepw.c (send_request): free memory on error. + + * lib/krb5/build_ap_req.c (krb5_build_ap_req): check return value + from malloc. + + * lib/krb5/auth_context.c (krb5_auth_con_init): free memory on + failure correctly. + (krb5_auth_con_setaddrs_from_fd): return error correctly. + + * lib/krb5/get_in_tkt_with_{keytab,skey}.c: new files + +Tue Nov 11 02:53:19 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/auth_context.c: Implement auth_con_setuserkey. + + * lib/gssapi/init_sec_context.c: Use krb5_auth_con_getkey. + + * lib/krb5/keyblock.c: Rename krb5_free_keyblock to + krb5_free_keyblock_contents, and reimplement krb5_free_keyblock. + + * lib/krb5/rd_req.c: Use auth_context->keyblock if + ap_options.use_session_key. + +Tue Nov 11 02:35:17 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/net_{read,write}.c: change `int fd' to `void *p_fd'. + fix callers. + + * lib/krb5/krb5_locl.h: include <asn1.h> and <der.h> + + * include/Makefile.am: add xdbm.h + +Tue Nov 11 01:58:22 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/get_cred.c: Implement krb5_get_cred_from_kdc. + +Mon Nov 10 22:41:53 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/ticket.c: Implement copy_ticket. + + * lib/krb5/get_in_tkt.c: Make `options' parameter MIT-compatible. + + * lib/krb5/data.c: Implement free_data and copy_data. + +Sun Nov 9 02:17:27 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/kadm5: Implement kadm5_get_privs, and kadm5_get_principals. + + * kadmin/kadmin.c: Add get_privileges function. + + * lib/kadm5: Rename KADM5_ACL_* -> KADM5_PRIV_* to conform with + specification. + + * kdc/connect.c: Exit if no sockets could be bound. + + * kadmin/kadmind.c: Check return value from krb5_net_read(). + + * lib/kadm5,kadmin: Fix memory leaks. + +Fri Nov 7 02:45:26 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/kadm5/create_s.c: Get some default values from `default' + principal. + + * lib/kadm5/ent_setup.c: Add optional default entry to get some + values from. + +Thu Nov 6 00:20:41 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/error/compile_et.awk: Remove generated destroy_*_error_table + prototype + + * kadmin/kadmind.c: Crude admin server. + + * kadmin/kadmin.c: Update to use remote protocol. + + * kadmin/get.c: Fix principal formatting. + + * lib/kadm5: Add client support. + + * lib/kadm5/error.c: Error code mapping. + + * lib/kadm5/server.c: Kadmind support function. + + * lib/kadm5/marshall.c: Kadm5 marshalling. + + * lib/kadm5/acl.c: Simple acl system. + + * lib/kadm5/kadm5_locl.h: Add client stuff. + + * lib/kadm5/init_s.c: Initialize acl. + + * lib/kadm5/*: Return values. + + * lib/kadm5/create_s.c: Correct kvno. + +Wed Nov 5 22:06:50 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/log.c: Fix parsing of log destinations. + +Mon Nov 3 20:33:55 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/principal.c: Reduce number of reallocs in unparse_name. + +Sat Nov 1 01:40:53 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kadmin: Simple kadmin utility. + + * admin/ktutil.c: Print keytype. + + * lib/kadm5/get_s.c: Set correct n_key_data. + + * lib/kadm5/init_s.c: Add kadm5_s_init_with_password_ctx. Use + master key. + + * lib/kadm5/destroy_s.c: Check for allocated context. + + * lib/kadm5/{create,chpass}_s.c: Use _kadm5_set_keys(). + +Sat Nov 1 00:21:00 1997 Assar Westerlund <assar@sics.se> + + * configure.in: test for readv, writev + +Wed Oct 29 23:41:26 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/warn.c (_warnerr): handle the case of an illegal error + code + + * kdc/kerberos5.c (encode_reply): return success + +Wed Oct 29 18:01:59 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos5.c (find_etype) Return correct index of selected + etype. + +Wed Oct 29 04:07:06 1997 Assar Westerlund <assar@sics.se> + + * Release 0.0k + + * lib/krb5/context.c (krb5_init_context): support `KRB5_CONFIG' + environment variable + + * *: use the roken_get*-macros from roken.h for the benefit of + Crays. + + * configure.in: add --{enable,disable}-otp. check for compatible + prototypes for gethostbyname, gethostbyaddr, getservbyname, and + openlog (they have strange prototypes on Crays) + + * acinclude.m4: new macro `AC_PROTO_COMPAT' + +Tue Oct 28 00:11:22 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/connect.c: Log bad requests. + + * kdc/kerberos5.c: Move stuff that's in common between as_rep and + tgs_rep to separate functions. + + * kdc/kerberos5.c: Fix user-to-user authentication. + + * lib/krb5/get_cred.c: Some restructuring of krb5_get_credentials: + - add a kdc-options argument to krb5_get_credentials, and rename + it to krb5_get_credentials_with_flags + - honour the KRB5_GC_CACHED, and KRB5_GC_USER_USER options + - add some more user-to-user glue + + * lib/krb5/rd_req.c: Move parts of krb5_verify_ap_req into a new + function, krb5_decrypt_ticket, so it is easier to decrypt and + check a ticket without having an ap-req. + + * lib/krb5/krb5.h: Add KRB5_GC_CACHED, and KRB5_GC_USER_USER + flags. + + * lib/krb5/crc.c (crc_init_table): Check if table is already + inited. + +Sun Oct 26 04:51:02 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/asn1/der_get.c (der_get_length, fix_dce): Special-case + indefinite encoding. + + * lib/asn1/gen_glue.c (generate_units): Check for empty + member-list. + +Sat Oct 25 07:24:57 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/error/compile_et.awk: Allow specifying table-base. + +Tue Oct 21 20:21:40 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos5.c: Check version number of krbtgt. + +Mon Oct 20 01:14:53 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/prompter_posix.c (krb5_prompter_posix): implement the + case of unhidden prompts. + + * lib/krb5/str2key.c (string_to_key_internal): return error + instead of aborting. always free memory + + * admin/ktutil.c: add `help' command + + * admin/kdb_edit.c: implement new commands: add_random_key(ark), + change_password(cpw), change_random_key(crk) + +Thu Oct 16 05:16:36 1997 Assar Westerlund <assar@sics.se> + + * kpasswd/kpasswdd.c: change all the keys in the database + + * kdc: removed all unsealing, now done by the hdb layer + + * lib/hdb/hdb.c: new functions `hdb_create', `hdb_set_master_key' + and `hdb_clear_master_key' + + * admin/misc.c: removed + +Wed Oct 15 22:47:31 1997 Assar Westerlund <assar@sics.se> + + * kuser/klist.c: print year as YYYY iff verbose + +Wed Oct 15 20:02:13 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kuser/klist.c: print etype from ticket + +Mon Oct 13 17:18:57 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * Release 0.0j + + * lib/krb5/get_cred.c: Get the subkey from mk_req so it can be + used to decrypt the reply from DCE secds. + + * lib/krb5/auth_context.c: Add {get,set}enctype. + + * lib/krb5/get_cred.c: Fix for DCE secd. + + * lib/krb5/store.c: Store keytype twice, as MIT does. + + * lib/krb5/get_in_tkt.c: Use etype from reply. + +Fri Oct 10 00:39:48 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/connect.c: check for leading '/' in http request + +Tue Sep 30 21:50:18 1997 Assar Westerlund <assar@assaris.pdc.kth.se> + + * Release 0.0i + +Mon Sep 29 15:58:43 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_req.c (krb5_rd_req): redone because we don't know + the kvno or keytype before receiving the AP-REQ + + * lib/krb5/mk_safe.c (krb5_mk_safe): figure out what cksumtype to + use from the keytype. + + * lib/krb5/mk_req_ext.c (krb5_mk_req_extended): figure out what + cksumtype to use from the keytype. + + * lib/krb5/mk_priv.c (krb5_mk_priv): figure out what etype to use + from the keytype. + + * lib/krb5/keytab.c (krb5_kt_get_entry): check the keytype + + * lib/krb5/get_for_creds.c (krb5_get_forwarded_creds): figure out + what etype to use from the keytype. + + * lib/krb5/generate_seq_number.c (krb5_generate_seq_number): + handle other key types than DES + + * lib/krb5/encrypt.c (key_type): add `best_cksumtype' + (krb5_keytype_to_cksumtype): new function + + * lib/krb5/build_auth.c (krb5_build_authenticator): figure out + what etype to use from the keytype. + + * lib/krb5/auth_context.c (krb5_auth_con_init): set `cksumtype' + and `enctype' to 0 + + * admin/extkeytab.c (ext_keytab): extract all keys + + * appl/telnet/telnet/commands.c: INET6_ADDRSTRLEN kludge + + * configure.in: check for <netinet6/in6.h>. check for -linet6 + +Tue Sep 23 03:00:53 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/encrypt.c: fix checksumtype for des3-cbc-sha1 + + * lib/krb5/rd_safe.c: fix check for keyed and collision-proof + checksum + + * lib/krb5/context.c (valid_etype): remove hard-coded constants + (default_etypes): include DES3 + + * kdc/kerberos5.c: fix check for keyed and collision-proof + checksum + + * admin/util.c (init_des_key, set_password): DES3 keys also + + * lib/krb/send_to_kdc.c (krb5_sendto_kdc): no data returned means + no contact? + + * lib/krb5/addr_families.c: fix typo in `ipv6_anyaddr' + +Mon Sep 22 11:44:27 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kdc/kerberos5.c: Somewhat fix the etype usage. The list sent by + the client is used to select wich key to encrypt the kdc rep with + (in case of as-req), and with the server info to select the + session key type. The server key the ticket is encrypted is based + purely on the keys in the database. + + * kdc/string2key.c: Add keytype support. Default to version 5 + keys. + + * lib/krb5/get_in_tkt.c: Fix a lot of etype/keytype misuse. + + * lib/krb5/encrypt.c: Add des3-cbc-md5, and des3-cbc-sha1. Add + many *_to_* functions. + + * lib/krb5/str2key.c: Add des3 string-to-key. Add ktype argument + to krb5_string_to_key(). + + * lib/krb5/checksum.c: Some cleanup, and added: + - rsa-md5-des3 + - hmac-sha1-des3 + - keyed and collision proof flags to each checksum method + - checksum<->string functions. + + * lib/krb5/generate_subkey.c: Use krb5_generate_random_keyblock. + +Sun Sep 21 15:19:23 1997 Assar Westerlund <assar@sics.se> + + * kdc/connect.c: use new addr_families functions + + * kpasswd/kpasswdd.c: use new addr_families functions. Now works + over IPv6 + + * kuser/klist.c: use correct symbols for address families + + * lib/krb5/sock_principal.c: use new addr_families functions + + * lib/krb5/send_to_kdc.c: use new addr_families functions + + * lib/krb5/krb5.h: add KRB5_ADDRESS_INET6 + + * lib/krb5/get_addrs.c: use new addr_families functions + + * lib/krb5/changepw.c: use new addr_families functions. Now works + over IPv6 + + * lib/krb5/auth_context.c: use new addr_families functions + + * lib/krb5/addr_families.c: new file + + * acconfig.h: AC_SOCKADDR_IN6 -> AC_STRUCT_SOCKADDR_IN6. Updated + uses. + + * acinclude.m4: new macro `AC_KRB_IPV6'. Use it. + +Sat Sep 13 23:04:23 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/hprop.c: Don't encrypt twice. Complain on non-convertable + principals. + +Sat Sep 13 00:59:36 1997 Assar Westerlund <assar@sics.se> + + * Release 0.0h + + * appl/telnet/telnet/commands.c: AF_INET6 support + + * admin/misc.c: new file + + * lib/krb5/context.c: new configuration variable `max_retries' + + * lib/krb5/get_addrs.c: fixes and better #ifdef's + + * lib/krb5/config_file.c: implement krb5_config_get_int + + * lib/krb5/auth_context.c, send_to_kdc.c, sock_principal.c: + AF_INET6 support + + * kuser/klist.c: support for printing IPv6-addresses + + * kdc/connect.c: support AF_INET6 + + * configure.in: test for gethostbyname2 and struct sockaddr_in6 + +Thu Sep 11 07:25:28 1997 Assar Westerlund <assar@sics.se> + + * lib/asn1/k5.asn1: Use `METHOD-DATA' instead of `SEQUENCE OF + PA-DATA' + +Wed Sep 10 21:20:17 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos5.c: Fixes for cross-realm, including (but not + limited to): + - allow client to be non-existant (should probably check for + "local realm") + - if server isn't found and it is a request for a krbtgt, try to + find a realm on the way to the requested realm + - update the transited encoding iff + client-realm != server-realm != tgt-realm + + * lib/krb5/get_cred.c: Several fixes for cross-realm. + +Tue Sep 9 15:59:20 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/string2key.c: Fix password handling. + + * lib/krb5/encrypt.c: krb5_key_to_string + +Tue Sep 9 07:46:05 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_addrs.c: rewrote. Now should be able to handle + aliases and IPv6 addresses + + * kuser/klist.c: try printing IPv6 addresses + + * kdc/kerberos5.c: increase the arbitrary limit from 1024 to 8192 + + * configure.in: check for <netinet/in6_var.h> + +Mon Sep 8 02:57:14 1997 Assar Westerlund <assar@sics.se> + + * doc: fixes + + * admin/util.c (init_des_key): increase kvno + (set_password): return -1 if `des_read_pw_string' failed + + * admin/mod.c (doit2): check the return value from `set_password' + + * admin/ank.c (doit): don't add a new entry if `set_password' + failed + +Mon Sep 8 02:20:16 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/verify_init.c: fix ap_req_nofail semantics + + * lib/krb5/transited.c: something that might resemble + domain-x500-compress + +Mon Sep 8 01:24:42 1997 Assar Westerlund <assar@sics.se> + + * kdc/hpropd.c (main): check number of arguments + + * appl/popper/pop_init.c (pop_init): check number of arguments + + * kpasswd/kpasswd.c (main): check number of arguments + + * kdc/string2key.c (main): check number of arguments + + * kuser/kdestroy.c (main): check number of arguments + + * kuser/kinit.c (main): check number of arguments + + * kpasswd/kpasswdd.c (main): use sigaction without SA_RESTART to + break out of select when a signal arrives + + * kdc/main.c (main): use sigaction without SA_RESTART to break out + of select when a signal arrives + + * kdc/kstash.c: default to HDB_DB_DIR "/m-key" + + * kdc/config.c (configure): add `--version'. Check the number of + arguments. Handle the case of there being no specification of port + numbers. + + * admin/util.c: seal and unseal key at appropriate places + + * admin/kdb_edit.c (main): parse arguments, config file and read + master key iff there's one. + + * admin/extkeytab.c (ext_keytab): unseal key while extracting + +Sun Sep 7 20:41:01 1997 Assar Westerlund <assar@sics.se> + + * lib/roken/roken.h: include <fcntl.h> + + * kdc/kerberos5.c (set_salt_padata): new function + + * appl/telnet/telnetd/telnetd.c: Rename some variables that + conflict with cpp symbols on HP-UX 10.20 + + * change all calls of `gethostbyaddr' to cast argument 1 to `const + char *' + + * acconfig.h: only use SGTTY on nextstep + +Sun Sep 7 14:33:50 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos5.c: Check invalid flag. + +Fri Sep 5 14:19:38 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/verify_user.c: Use get_init_creds/verify_init_creds. + + * lib/kafs: Move functions common to krb/krb5 modules to new file, + and make things more modular. + + * lib/krb5/krb5.h: rename STRING -> krb5_config_string, and LIST + -> krb5_config_list + +Thu Sep 4 23:39:43 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/get_addrs.c: Fix loopback test. + +Thu Sep 4 04:45:49 1997 Assar Westerlund <assar@sics.se> + + * lib/roken/roken.h: fallback definition of `O_ACCMODE' + + * lib/krb5/get_in_tkt.c (krb5_get_in_cred): be more careful when + checking for a v4 reply + +Wed Sep 3 18:20:14 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/hprop.c: Add `--decrypt' and `--encrypt' flags. + + * lib/hdb/hdb.c: new {seal,unseal}_keys functions + + * kdc/{hprop,hpropd}.c: Add support to dump database to stdout. + + * kdc/hprop.c: Don't use same master key as version 4. + + * admin/util.c: Don't dump core if no `default' is found. + +Wed Sep 3 16:01:07 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kdc/connect.c: Allow run time port specification. + + * kdc/config.c: Add flags for http support, and port + specifications. + +Tue Sep 2 02:00:03 1997 Assar Westerlund <assar@sics.se> + + * include/bits.c: Don't generate ifndef's in bits.h. Instead, use + them when building the program. This makes it possible to include + bits.h without having defined all HAVE_INT17_T symbols. + + * configure.in: test for sigaction + + * doc: updated documentation. + +Tue Sep 2 00:20:31 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * Release 0.0g + +Mon Sep 1 17:42:14 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/data.c: don't return ENOMEM if len == 0 + +Sun Aug 31 17:15:49 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/hdb/hdb.asn1: Include salt type in salt. + + * kdc/hprop.h: Change port to 754. + + * kdc/hpropd.c: Verify who tries to transmit a database. + + * appl/popper: Use getarg and krb5_log. + + * lib/krb5/get_port.c: Add context parameter. Now takes port in + host byte order. + +Sat Aug 30 18:48:19 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/connect.c: Add timeout to select, and log about expired tcp + connections. + + * kdc/config.c: Add `database' option. + + * kdc/hpropd.c: Log about duplicate entries. + + * lib/hdb/{db,ndbm}.c: Use common routines. + + * lib/hdb/common.c: Implement more generic fetch/store/delete + functions. + + * lib/hdb/hdb.h: Add `replace' parameter to store. + + * kdc/connect.c: Set filedecriptor to -1 on allocated decriptor + entries. + +Fri Aug 29 03:13:23 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_in_tkt.c: extract_ticket -> _krb5_extract_ticket + + * aux/make-proto.pl: fix __P for stone age mode + +Fri Aug 29 02:45:46 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/45/mk_req.c: implementation of krb_mk_req that uses 524 + protocol + + * lib/krb5/init_creds_pw.c: make change_password and + get_init_creds_common static + + * lib/krb5/krb5.h: Merge stuff from removed headerfiles. + + * lib/krb5/fcache.c: fcc_ops -> krb5_fcc_ops + + * lib/krb5/mcache.c: mcc_ops -> krb5_mcc_ops + +Fri Aug 29 01:45:25 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/krb5.h: Remove all prototypes. + + * lib/krb5/convert_creds.c: Use `struct credentials' instead of + `CREDENTIALS'. + +Fri Aug 29 00:08:18 1997 Assar Westerlund <assar@sics.se> + + * lib/asn1/gen_glue.c: new file. generates 2int and int2 functions + and units for bit strings. + + * admin/util.c: flags2int, int2flags, and flag_units are now + generated by asn1_compile + + * lib/roken/parse_units.c: generalised `parse_units' and + `unparse_units' and added new functions `parse_flags' and + `unparse_flags' that use these + + * lib/krb5/krb5_locl.h: moved krb5_data* functions to krb5.h + + * admin/util.c: Use {un,}parse_flags for printing and parsing + hdbflags. + +Thu Aug 28 03:26:12 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_addrs.c: restructured + + * lib/krb5/warn.c (_warnerr): leak less memory + + * lib/hdb/hdb.c (hdb_free_entry): zero keys + (hdb_check_db_format): leak less memory + + * lib/hdb/ndbm.c (NDBM_seq): check for valid hdb_entries implement + NDBM__get, NDBM__put + + * lib/hdb/db.c (DB_seq): check for valid hdb_entries + +Thu Aug 28 02:06:58 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/send_to_kdc.c: Don't use sendto on connected sockets. + +Thu Aug 28 01:13:17 1997 Assar Westerlund <assar@sics.se> + + * kuser/kinit.1, klist.1, kdestroy.1: new man pages + + * kpasswd/kpasswd.1, kpasswdd.8: new man pages + + * kdc/kstash.8, hprop.8, hpropd.8: new man pages + + * admin/ktutil.8, admin/kdb_edit.8: new man pages + + * admin/mod.c: new file + + * admin/life.c: renamed gettime and puttime to getlife and putlife + and moved them to life.c + + * admin/util.c: add print_flags, parse_flags, init_entry, + set_created_by, set_modified_by, edit_entry, set_password. Use + them. + + * admin/get.c: use print_flags + + * admin: removed unused stuff. use krb5_{warn,err}* + + * admin/ank.c: re-organized and abstracted. + + * admin/gettime.c: removed + +Thu Aug 28 00:37:39 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/{get_cred,get_in_tkt}.c: Check for v4 reply. + + * lib/roken/base64.c: Add base64 functions. + + * kdc/connect.c lib/krb5/send_to_kdc.c: Add http support. + +Wed Aug 27 00:29:20 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * include/Makefile.am: Don't make links to built files. + + * admin/kdb_edit.c: Add command to set the database path. + + * lib/hdb: Include version number in database. + +Tue Aug 26 20:14:54 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * admin/ktutil: Merged v4 srvtab conversion. + +Mon Aug 25 23:02:18 1997 Assar Westerlund <assar@sics.se> + + * lib/roken/roken.h: add F_OK + + * lib/gssapi/acquire_creds.c: fix typo + + * configure.in: call AC_TYPE_MODE_T + + * acinclude.m4: Add AC_TYPE_MODE_T + +Sun Aug 24 16:46:53 1997 Assar Westerlund <assar@sics.se> + + * Release 0.0f + +Sun Aug 24 08:06:54 1997 Assar Westerlund <assar@sics.se> + + * appl/popper/pop_pass.c: log poppers + + * kdc/kaserver.c: some more checks + + * kpasswd/kpasswd.c: removed `-p' + + * kuser/kinit.c: removed `-p' + + * lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): If + KDC_ERR_PREUATH_REQUIRED, add preauthentication and try again. + + * lib/krb5/get_in_tkt.c (krb5_get_in_cred): don't print out + krb-error text + + * lib/gssapi/import_name.c (input_name): more names types. + + * admin/load.c (parse_keys): handle the case of an empty salt + + * kdc/kaserver.c: fix up memory deallocation + + * kdc/kaserver.c: quick hack at talking kaserver protocol + + * kdc/kerberos4.c: Make `db-fetch4' global + + * configure.in: add --enable-kaserver + + * kdc/rx.h, kdc/kerberos4.h: new header files + + * lib/krb5/principal.c: fix krb5_build_principal_ext & c:o + +Sun Aug 24 03:52:44 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/{get_in_tkt,mk_safe,mk_priv}.c: Fix some Cray specific + type conflicts. + + * lib/krb5/{get_cred,get_in_tkt}.c: Mask nonce to 32 bits. + + * lib/des/{md4,md5,sha}.c: Now works on Crays. + +Sat Aug 23 18:15:01 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * appl/afsutil/afslog.c: If no cells or files specified, get + tokens for all local cells. Better test for files. + +Thu Aug 21 23:33:38 1997 Assar Westerlund <assar@sics.se> + + * lib/gssapi/v1.c: new file with v1 compatibility functions. + +Thu Aug 21 20:36:13 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/kafs/afskrb5.c: Don't check ticket file for afs ticket. + + * kdc/kerberos4.c: Check database when converting v4 principals. + + * kdc/kerberos5.c: Include kvno in Ticket. + + * lib/krb5/encrypt.c: Add kvno parameter to encrypt_EncryptedData. + + * kuser/klist.c: Print version number of ticket, include more + flags. + +Wed Aug 20 21:26:58 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/kafs/afskrb5.c (get_cred): Check cached afs tickets for + expiration. + +Wed Aug 20 17:40:31 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/recvauth.c (krb5_recvauth): Send a KRB-ERROR iff + there's an error. + + * lib/krb5/sendauth.c (krb5_sendauth): correct the protocol + documentation and process KRB-ERROR's + +Tue Aug 19 20:41:30 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos4.c: Fix memory leak in v4 protocol handler. + +Mon Aug 18 05:15:09 1997 Assar Westerlund <assar@sics.se> + + * lib/gssapi/accept_sec_context.c: Added + `gsskrb5_register_acceptor_identity' + +Sun Aug 17 01:40:20 1997 Assar Westerlund <assar@sics.se> + + * lib/gssapi/accept_sec_context.c (gss_accept_sec_context): don't + always pass server == NULL to krb5_rd_req. + + * lib/gssapi: new files: canonicalize_name.c export_name.c + context_time.c compare_name.c release_cred.c acquire_cred.c + inquire_cred.c, from Luke Howard <lukeh@xedoc.com.au> + + * lib/krb5/config_file.c: Add netinfo support from Luke Howard + <lukeh@xedoc.com.au> + + * lib/editline/sysunix.c: sgtty-support from Luke Howard + <lukeh@xedoc.com.au> + + * lib/krb5/principal.c: krb5_sname_to_principal fix from Luke + Howard <lukeh@xedoc.com.au> + +Sat Aug 16 00:44:47 1997 Assar Westerlund <assar@koi.pdc.kth.se> + + * Release 0.0e + +Sat Aug 16 00:23:46 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * appl/afsutil/afslog.c: Use new libkafs. + + * lib/kafs/afskrb5.c: Get AFS tokens via 524 protocol. + + * lib/krb5/warn.c: Fix format string for *x type. + +Fri Aug 15 22:15:01 1997 Assar Westerlund <assar@sics.se> + + * admin/get.c (get_entry): print more information about the entry + + * lib/des/Makefile.am: build destest, mdtest, des, rpw, speed + + * lib/krb5/config_file.c: new functions `krb5_config_get_time' and + `krb5_config_vget_time'. Use them. + +Fri Aug 15 00:09:37 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * admin/ktutil.c: Keytab manipulation program. + + * lib/krb5/keytab.c: Return sane values from resolve and + start_seq_get. + + * kdc/kerberos5.c: Fix for old clients passing 0 for `no endtime'. + + * lib/45/get_ad_tkt.c: Kerberos 4 get_ad_tkt using + krb524_convert_creds_kdc. + + * lib/krb5/convert_creds.c: Implementation of + krb524_convert_creds_kdc. + + * lib/asn1/k5.asn1: Make kdc-req-body.till OPTIONAL + + * kdc/524.c: A somewhat working 524-protocol module. + + * kdc/kerberos4.c: Add version 4 ticket encoding and encryption + functions. + + * lib/krb5/context.c: Fix kdc_timeout. + + * lib/hdb/{ndbm,db}.c: Free name in close. + + * kdc/kerberos5.c (tgs_check_autenticator): Return error code + +Thu Aug 14 21:29:03 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos5.c (tgs_make_reply): Fix endtime in reply. + + * lib/krb5/store_emem.c: Fix reallocation bug. + +Tue Aug 12 01:29:46 1997 Assar Westerlund <assar@sics.se> + + * appl/telnet/libtelnet/kerberos5.c, appl/popper/pop_init.c: Use + `krb5_sock_to_principal'. Send server parameter to + krb5_rd_req/krb5_recvauth. Set addresses in auth_context. + + * lib/krb5/recvauth.c: Set addresses in auth_context if there + aren't any + + * lib/krb5/auth_context.c: New function + `krb5_auth_con_setaddrs_from_fd' + + * lib/krb5/sock_principal.c: new function + `krb5_sock_to_principal' + + * lib/krb5/time.c: new file with `krb5_timeofday' and + `krb5_us_timeofday'. Use these functions. + + * kuser/klist.c: print KDC offset iff verbose + + * lib/krb5/get_in_tkt.c: implement KDC time offset and use it if + [libdefaults]kdc_timesync is set. + + * lib/krb5/fcache.c: Implement version 4 of the ccache format. + +Mon Aug 11 05:34:43 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_rep.c (krb5_free_ap_rep_enc_part): free all memory + + * lib/krb5/principal.c (krb5_unparse_name): allocate memory + properly + + * kpasswd/kpasswd.c: Use `krb5_change_password' + + * lib/krb5/init_creds_pw.c (init_cred): set realm of server + correctly. + + * lib/krb5/init_creds_pw.c: support changing of password when it + has expired + + * lib/krb5/changepw.c: new file + + * kuser/klist.c: use getarg + + * admin/init.c (init): add `kadmin/changepw' + +Mon Aug 11 04:30:47 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/get_cred.c: Make get_credentials handle cross-realm. + +Mon Aug 11 00:03:24 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/config_file.c: implement support for #-comments + +Sat Aug 9 02:21:46 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/hprop*.c: Add database propagation programs. + + * kdc/connect.c: Max request size. + +Sat Aug 9 00:47:28 1997 Assar Westerlund <assar@sics.se> + + * lib/otp: resurrected from krb4 + + * appl/push: new program for fetching mail with POP. + + * appl/popper/popper.h: new include files. new fields in `POP' + + * appl/popper/pop_pass.c: Implement both v4 and v5. + + * appl/popper/pop_init.c: Implement both v4 and v5. + + * appl/popper/pop_debug.c: use getarg. Talk both v4 and v5 + + * appl/popper: Popper from krb4. + + * configure.in: check for inline and <netinet/tcp.h> generate + files in appl/popper, appl/push, and lib/otp + +Fri Aug 8 05:51:02 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_cred.c: clean-up and try to free memory even when + there're errors + + * lib/krb5/get_cred.c: adapt to new `extract_ticket' + + * lib/krb5/get_in_tkt.c: reorganize. check everything and try to + return memory even if there are errors. + + * kuser/kverify.c: new file + + * lib/krb5/free_host_realm.c: new file + + * lib/krb5/principal.c (krb5_sname_to_principal): implement + different nametypes. Also free memory. + + * lib/krb5/verify_init.c: more functionality + + * lib/krb5/mk_req_ext.c (krb5_mk_req_extended): free the checksum + + * lib/krb5/get_in_tkt.c (extract_ticket): don't copy over the + principals in creds. Should also compare them with that received + from the KDC + + * lib/krb5/cache.c (krb5_cc_gen_new): copy the newly allocated + krb5_ccache + (krb5_cc_destroy): call krb5_cc_close + (krb5_cc_retrieve_cred): delete the unused creds + +Fri Aug 8 02:30:40 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/log.c: Allow better control of destinations of logging + (like passing explicit destinations, and log-functions). + +Fri Aug 8 01:20:39 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_default_principal.c: new file + + * kpasswd/kpasswdd.c: use krb5_log* + +Fri Aug 8 00:37:47 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/init_creds_pw.c: Implement krb5_get_init_creds_keytab. + +Fri Aug 8 00:37:17 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/init_creds_pw.c: Use `krb5_get_default_principal'. + Print password expire information. + + * kdc/config.c: new variable `kdc_warn_pwexpire' + + * kpasswd/kpasswd.c: converted to getarg and get_init_creds + +Thu Aug 7 22:17:09 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/mcache.c: new file + + * admin/gettime.c: new function puttime. Use it. + + * lib/krb5/keyblock.c: Added krb5_free_keyblock and + krb5_copy_keyblock + + * lib/krb5/init_creds_pw.c: more functionality + + * lib/krb5/creds.c: Added krb5_free_creds_contents and + krb5_copy_creds. Changed callers. + + * lib/krb5/config_file.c: new functions krb5_config_get and + krb5_config_vget + + * lib/krb5/cache.c: cleanup added mcache + + * kdc/kerberos5.c: include last-req's of type 6 and 7, if + applicable + +Wed Aug 6 20:38:23 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/log.c: New parameter `log-level'. Default to `SYSLOG'. + +Tue Aug 5 22:53:54 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/verify_init.c, init_creds_pw.c, init_creds.c, + prompter_posix.c: the beginning of an implementation of the cygnus + initial-ticket API. + + * lib/krb5/get_in_tkt_pw.c: make `krb5_password_key_proc' global + + * lib/krb5/get_in_tkt.c (krb5_get_in_cred): new function that is + almost krb5_get_in_tkt but doesn't write the creds to the ccache. + Small fixes in krb5_get_in_tkt + + * lib/krb5/get_addrs.c (krb5_get_all_client_addrs): don't include + loopback. + +Mon Aug 4 20:20:48 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc: Make context global. + +Fri Aug 1 17:23:56 1997 Assar Westerlund <assar@sics.se> + + * Release 0.0d + + * lib/roken/flock.c: new file + + * kuser/kinit.c: check for and print expiry information in the + `kdc_rep' + + * lib/krb5/get_in_tkt.c: Set `ret_as_reply' if != NULL + + * kdc/kerberos5.c: Check the valid times on client and server. + Check the password expiration. + Check the require_preauth flag. + Send an lr_type == 6 with pw_end. + Set key.expiration to min(valid_end, pw_end) + + * lib/hdb/hdb.asn1: new flags `require_preauth' and `change_pw' + + * admin/util.c, admin/load.c: handle the new flags. + +Fri Aug 1 16:56:12 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/hdb: Add some simple locking. + +Sun Jul 27 04:44:31 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/log.c: Add some general logging functions. + + * kdc/kerberos4.c: Add version 4 protocol handler. The requrement + for this to work is that all involved principals has a des key in + the database, and that the client has a version 4 (un-)salted + key. Furthermore krb5_425_conv_principal has to do it's job, as + present it's not very clever. + + * lib/krb5/principal.c: Quick patch to make 425_conv work + somewhat. + + * lib/hdb/hdb.c: Add keytype->key and next key functions. + +Fri Jul 25 17:32:12 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/build_auth.c (krb5_build_authenticator): don't free + `cksum'. It's allocated and freed by the caller + + * lib/krb5/get_cred.c (krb5_get_kdc_cred): Don't free `addresses'. + + * kdc/kerberos5.c (tgs_rep2): make sure we also have an defined + `client' to return as part of the KRB-ERROR + +Thu Jul 24 08:13:59 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos5.c: Unseal keys from database before use. + + * kdc/misc.c: New functions set_master_key, unseal_key and + free_key. + + * lib/roken/getarg.c: Handle `-f arg' correctly. + +Thu Jul 24 01:54:43 1997 Assar Westerlund <assar@sics.se> + + * kuser/kinit.c: implement `-l' aka `--lifetime' + + * lib/roken/parse_units.c, parse_time.c: new files + + * admin/gettime.c (gettime): use `parse_time' + + * kdc/kerberos5.c (as_rep): Use `METHOD-DATA' when sending + KRB5KDC_ERR_PREAUTH_REQUIRED, not PA-DATA. + + * kpasswd/kpasswdd.c: fix freeing bug use sequence numbers set + addresses in auth_context bind one socket per interface. + + * kpasswd/kpasswd.c: use sequence numbers + + * lib/krb5/rd_req.c (krb5_verify_ap_req): do abs when verifying + the timestamps + + * lib/krb5/rd_priv.c (krb5_rd_priv): Fetch the correct session key + from auth_context + + * lib/krb5/mk_priv.c (krb5_mk_priv): Fetch the correct session key + from auth_context + + * lib/krb5/mk_error.c (krb5_mk_error): return an error number and + not a comerr'd number. + + * lib/krb5/get_in_tkt.c (krb5_get_in_tkt): interpret the error + number in KRB-ERROR correctly. + + * lib/krb5/get_cred.c (krb5_get_kdc_cred): interpret the error + number in KRB-ERROR correctly. + + * lib/asn1/k5.asn1: Add `METHOD-DATA' + + * removed some memory leaks. + +Wed Jul 23 07:53:18 1997 Assar Westerlund <assar@sics.se> + + * Release 0.0c + + * lib/krb5/rd_cred.c, get_for_creds.c: new files + + * lib/krb5/get_host_realm.c: try default realm as last chance + + * kpasswd/kpasswdd.c: updated to hdb changes + + * appl/telnet/libtelnet/kerberos5.c: Implement forwarding + + * appl/telnet/libtelnet: removed totally unused files + + * admin/ank.c: fix prompts and generation of random keys + +Wed Jul 23 04:02:32 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * admin/dump.c: Include salt in dump. + + * admin: Mostly updated for new db-format. + + * kdc/kerberos5.c: Update to use new db format. Better checking of + flags and such. More logging. + + * lib/hdb/hdb.c: Use generated encode and decode functions. + + * lib/hdb/hdb.h: Get hdb_entry from ASN.1 generated code. + + * lib/krb5/get_cred.c: Get addresses from krbtgt if there are none + in the reply. + +Sun Jul 20 16:22:30 1997 Assar Westerlund <assar@sics.se> + + * kuser/kinit.c: break if des_read_pw_string() != 0 + + * kpasswd/kpasswdd.c: send a reply + + * kpasswd/kpasswd.c: restructured code. better report on + krb-error break if des_read_pw_string() != 0 + + * kdc/kerberos5.c: Check `require_enc_timestamp' malloc space for + starttime and renew_till + + * appl/telnet/libtelnet/kerberos5.c (kerberos5_is): Send a + keyblock to krb5_verify_chekcsum + +Sun Jul 20 06:35:46 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * Release 0.0b + + * kpasswd/kpasswd.c: Avoid using non-standard struct names. + +Sat Jul 19 19:26:23 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/keytab.c (krb5_kt_get_entry): check return from + `krb5_kt_start_seq_get'. From <map@stacken.kth.se> + +Sat Jul 19 04:07:39 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/asn1/k5.asn1: Update with more pa-data types from + draft-ietf-cat-kerberos-revisions-00.txt + + * admin/load.c: Update to match current db-format. + + * kdc/kerberos5.c (as_rep): Try all valid pa-datas before giving + up. Send back an empty pa-data if the client has the v4 flag set. + + * lib/krb5/get_in_tkt.c: Pass both version5 and version4 salted + pa-data. DTRT if there is any pa-data in the reply. + + * lib/krb5/str2key.c: XOR with some sane value. + + * lib/hdb/hdb.h: Add `version 4 salted key' flag. + + * kuser/kinit.c: Ask for password before calling get_in_tkt. This + makes it possible to call key_proc more than once. + + * kdc/string2key.c: Add flags to output version 5 (DES only), + version 4, and AFS string-to-key of a password. + + * lib/asn1/gen_copy.c: copy_* functions now returns an int (0 or + ENOMEM). + +Fri Jul 18 02:54:58 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_host_realm.c (krb5_get_host_realm): do the + name2name thing + + * kdc/misc.c: check result of hdb_open + + * admin/kdb_edit: updated to new sl + + * lib/sl: sl_func now returns an int. != 0 means to exit. + + * kpasswd/kpasswdd: A crude (but somewhat working) implementation + of `draft-ietf-cat-kerb-chg-password-00.txt' + +Fri Jul 18 00:55:39 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kuser/krenew.c: Crude ticket renewing program. + + * kdc/kerberos5.c: Rewritten flags parsing, it now might work to + get forwarded and renewed tickets. + + * kuser/kinit.c: Add `-r' flag. + + * lib/krb5/get_cred.c: Move most of contents of get_creds to new + function get_kdc_cred, that always contacts the kdc and doesn't + save in the cache. This is a hack. + + * lib/krb5/get_in_tkt.c: Pass starttime and renew_till in request + (a bit kludgy). + + * lib/krb5/mk_req_ext.c: Make an auth_context if none passed in. + + * lib/krb5/send_to_kdc.c: Get timeout from context. + + * lib/krb5/context.c: Add kdc_timeout to context struct. + +Thu Jul 17 20:35:45 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kuser/klist.c: Print start time of ticket if available. + + * lib/krb5/get_host_realm.c: Return error if no realm was found. + +Thu Jul 17 20:28:21 1997 Assar Westerlund <assar@sics.se> + + * kpasswd: non-working kpasswd added + +Thu Jul 17 00:21:22 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * Release 0.0a + + * kdc/main.c: Add -p flag to disable pa-enc-timestamp requirement. + +Wed Jul 16 03:37:41 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/kerberos5.c (tgs_rep2): Free ticket and ap_req. + + * lib/krb5/auth_context.c (krb5_auth_con_free): Free remote + subkey. + + * lib/krb5/principal.c (krb5_free_principal): Check for NULL. + + * lib/krb5/send_to_kdc.c: Check for NULL return from + gethostbyname. + + * lib/krb5/set_default_realm.c: Try to get realm of local host if + no default realm is available. + + * Remove non ASN.1 principal code. + +Wed Jul 16 03:17:30 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kdc/kerberos5.c: Split tgs_rep in smaller functions. Add better + error handing. Do some logging. + + * kdc/log.c: Some simple logging facilities. + + * kdc/misc.c (db_fetch): Take a krb5_principal. + + * kdc/connect.c: Pass address of request to as_rep and + tgs_rep. Send KRB-ERROR. + + * lib/krb5/mk_error.c: Add more fields. + + * lib/krb5/get_cred.c: Print normal error code if no e_text is + available. + +Wed Jul 16 03:07:50 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_in_tkt.c: implement `krb5_init_etype'. + Change encryption type of pa_enc_timestamp to DES-CBC-MD5 + + * lib/krb5/context.c: recognize all encryption types actually + implemented + + * lib/krb5/auth_context.c (krb5_auth_con_init): Change default + encryption type to `DES_CBC_MD5' + + * lib/krb5/read_message.c, write_message.c: new files + +Tue Jul 15 17:14:21 1997 Assar Westerlund <assar@sics.se> + + * lib/asn1: replaced asn1_locl.h by `der_locl.h' and `gen_locl.h'. + + * lib/error/compile_et.awk: generate a prototype for the + `destroy_foo_error_table' function. + +Mon Jul 14 12:24:40 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/krbhst.c (krb5_get_krbhst): Get all kdc's and try also + with `kerberos.REALM' + + * kdc/kerberos5.c, lib/krb5/rd_priv.c, lib/krb5/rd_safe.c: use + `max_skew' + + * lib/krb5/rd_req.c (krb5_verify_ap_req): record authenticator + subkey + + * lib/krb5/build_auth.c (krb5_build_authenticator): always + generate a subkey. + + * lib/krb5/address.c: implement `krb5_address_order' + + * lib/gssapi/import_name.c: Implement `gss_import_name' + + * lib/gssapi/external.c: Use new OID + + * lib/gssapi/encapsulate.c: New functions + `gssapi_krb5_encap_length' and `gssapi_krb5_make_header'. Changed + callers. + + * lib/gssapi/decapsulate.c: New function + `gssaspi_krb5_verify_header'. Changed callers. + + * lib/asn1/gen*.c: Give tags to generated structs. + Use `err' and `asprintf' + + * appl/test/gss_common.c: new file + + * appl/test/gssapi_server.c: removed all krb5 calls + + * appl/telnet/libtelnet/kerberos5.c: Add support for genering and + verifying checksums. Also start using session subkeys. + +Mon Jul 14 12:08:25 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/rd_req.c (krb5_rd_req_with_keyblock): Split up. + +Sun Jul 13 03:07:44 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_safe.c, mk_safe.c: made bug-compatible with MIT + + * lib/krb5/encrypt.c: new functions `DES_encrypt_null_ivec' and + `DES_encrypt_key_ivec' + + * lib/krb5/checksum.c: implement rsa-md4-des and rsa-md5-des + + * kdc/kerberos5.c (tgs_rep): support keyed checksums + + * lib/krb5/creds.c: new file + + * lib/krb5/get_in_tkt.c: better freeing + + * lib/krb5/context.c (krb5_free_context): more freeing + + * lib/krb5/config_file.c: New function `krb5_config_file_free' + + * lib/error/compile_et.awk: Generate a `destroy_' function. + + * kuser/kinit.c, klist.c: Don't leak memory. + +Sun Jul 13 02:46:27 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * kdc/connect.c: Check filedescriptor in select. + + * kdc/kerberos5.c: Remove most of the most common memory leaks. + + * lib/krb5/rd_req.c: Free allocated data. + + * lib/krb5/auth_context.c (krb5_auth_con_free): Free a lot of + fields. + +Sun Jul 13 00:32:16 1997 Assar Westerlund <assar@sics.se> + + * appl/telnet: Conditionalize the krb4-support. + + * configure.in: Test for krb4 + +Sat Jul 12 17:14:12 1997 Assar Westerlund <assar@sics.se> + + * kdc/kerberos5.c: check if the pre-auth was decrypted properly. + set the `pre_authent' flag + + * lib/krb5/get_cred.c, lib/krb5/get_in_tkt.c: generate a random nonce. + + * lib/krb5/encrypt.c: Made `generate_random_block' global. + + * appl/test: Added gssapi_client and gssapi_server. + + * lib/krb5/data.c: Add `krb5_data_zero' + + * appl/test/tcp_client.c: try `mk_safe' and `mk_priv' + + * appl/test/tcp_server.c: try `rd_safe' and `rd_priv' + +Sat Jul 12 16:45:58 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/get_addrs.c: Fix for systems that has sa_len, but + returns zero length from SIOCGIFCONF. + +Sat Jul 12 16:38:34 1997 Assar Westerlund <assar@sics.se> + + * appl/test: new programs + + * lib/krb5/rd_req.c: add address compare + + * lib/krb5/mk_req_ext.c: allow no checksum + + * lib/krb5/keytab.c (krb5_kt_ret_string): 0-terminate string + + * lib/krb5/address.c: fix `krb5_address_compare' + +Sat Jul 12 15:03:16 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/get_addrs.c: Fix ip4 address extraction. + + * kuser/klist.c: Add verbose flag, and split main into smaller + pieces. + + * lib/krb5/fcache.c: Save ticket flags. + + * lib/krb5/get_in_tkt.c (extract_ticket): Extract addresses and + flags. + + * lib/krb5/krb5.h: Add ticket_flags to krb5_creds. + +Sat Jul 12 13:12:48 1997 Assar Westerlund <assar@sics.se> + + * configure.in: Call `AC_KRB_PROG_LN_S' + + * acinclude.m4: Add `AC_KRB_PROG_LN_S' from krb4 + +Sat Jul 12 00:57:01 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/get_in_tkt.c: Use union of krb5_flags and KDCOptions to + pass options. + +Fri Jul 11 15:04:22 1997 Assar Westerlund <assar@sics.se> + + * appl/telnet: telnet & telnetd seems to be working. + + * lib/krb5/config_file.c: Added krb5_config_v?get_list Fixed + krb5_config_vget_next + + * appl/telnet/libtelnet/kerberos5.c: update to current API + +Thu Jul 10 14:54:39 1997 Assar Westerlund <assar@sics.se> + + * appl/telnet/libtelnet/kerberos5.c (kerberos5_status): call + `krb5_kuserok' + + * appl/telnet: Added. + +Thu Jul 10 05:09:25 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/error/compile_et.awk: Remove usage of sub, gsub, and + functions for compatibility with awk. + + * include/bits.c: Must use signed char. + + * lib/krb5/context.c: Move krb5_get_err_text, and krb5_init_ets + here. + + * lib/error/error.c: Replace krb5_get_err_text with new function + com_right. + + * lib/error/compile_et.awk: Avoid using static variables. + + * lib/error/error.c: Don't use krb5_locl.h + + * lib/error/error.h: Move definitions of error_table and + error_list from krb5.h. + + * lib/error: Moved from lib/krb5. + +Wed Jul 9 07:42:04 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/encrypt.c: Temporary hack to avoid des_rand_data. + +Wed Jul 9 06:58:00 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/{rd,mk}_{*}.c: more checking for addresses and stuff + according to pseudocode from 1510 + +Wed Jul 9 06:06:06 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/hdb/hdb.c: Add hdb_etype2key. + + * kdc/kerberos5.c: Check authenticator. Use more general etype + functions. + +Wed Jul 9 03:51:12 1997 Assar Westerlund <assar@sics.se> + + * lib/asn1/k5.asn1: Made all `s_address' OPTIONAL according to + draft-ietf-cat-kerberos-r-00.txt + + * lib/krb5/principal.c (krb5_parse_name): default to local realm + if none given + + * kuser/kinit.c: New option `-p' and prompt + +Wed Jul 9 02:30:06 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/keyblock.c: Keyblock generation functions. + + * lib/krb5/encrypt.c: Use functions from checksum.c. + + * lib/krb5/checksum.c: Move checksum functions here. Add + krb5_cksumsize function. + +Wed Jul 9 01:15:38 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_host_realm.c: implemented + + * lib/krb5/config_file.c: Redid part. New functions: + krb5_config_v?get_next + + * kuser/kdestroy.c: new program + + * kuser/kinit.c: new flag `-f' + + * lib/asn1/k5.asn1: Made HostAddresses = SEQUENCE OF HostAddress + + * acinclude.m4: Added AC_KRB_STRUCT_SOCKADDR_SA_LEN + + * lib/krb5/krb5.h: krb5_addresses == HostAddresses. Changed all + users. + + * lib/krb5/get_addrs.c: figure out all local addresses, possibly + even IPv6! + + * lib/krb5/checksum.c: table-driven checksum + +Mon Jul 7 21:13:28 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/encrypt.c: Make krb5_decrypt use the same struct as + krb5_encrypt. + +Mon Jul 7 11:15:51 1997 Assar Westerlund <assar@sics.se> + + * lib/roken/vsyslog.c: new file + + * lib/krb5/encrypt.c: add des-cbc-md4. + adjust krb5_encrypt and krb5_decrypt to reality + +Mon Jul 7 02:46:31 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/encrypt.c: Implement as a vector of function pointers. + + * lib/krb5/{decrypt,encrypt}.c: Implement des-cbc-crc, and + des-cbc-md5 in separate functions. + + * lib/krb5/krb5.h: Add more checksum and encryption types. + + * lib/krb5/krb5_locl.h: Add etype to krb5_decrypt. + +Sun Jul 6 23:02:59 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/[gs]et_default_realm.c, kuserok.c: new files + + * lib/krb5/config_file.[ch]: new c-based configuration reading + stuff + +Wed Jul 2 23:12:56 1997 Assar Westerlund <assar@sics.se> + + * configure.in: Set WFLAGS if using gcc + +Wed Jul 2 17:47:03 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/asn1/der_put.c (der_put_int): Return size correctly. + + * admin/ank.c: Be compatible with the asn1 principal format. + +Wed Jul 1 23:52:20 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/asn1: Now all decode_* and encode_* functions now take a + final size_t* argument, that they return the size in. Return + values are zero for success, and anything else (such as some + ASN1_* constant) for error. + +Mon Jun 30 06:08:14 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/keytab.c (krb5_kt_add_entry): change open mode to + O_WRONLY | O_APPEND + + * lib/krb5/get_cred.c: removed stale prototype for + `extract_ticket' and corrected call. + + * lib/asn1/gen_length.c (length_type): Make the length functions + for SequenceOf non-destructive + + * admin/ank.c (doit): Fix reading of `y/n'. + +Mon Jun 16 05:41:43 1997 Assar Westerlund <assar@sics.se> + + * lib/gssapi/wrap.c, unwrap.c: do encrypt and add sequence number + + * lib/gssapi/get_mic.c, verify_mic.c: Add sequence number. + + * lib/gssapi/accept_sec_context.c (gss_accept_sec_context): Set + KRB5_AUTH_CONTEXT_DO_SEQUENCE. Verify 8003 checksum. + + * lib/gssapi/8003.c: New file. + + * lib/krb/krb5.h: Define a `krb_authenticator' as an ASN.1 + Authenticator. + + * lib/krb5/auth_context.c: New functions + `krb5_auth_setlocalseqnumber' and `krb5_auth_setremoteseqnumber' + +Tue Jun 10 00:35:54 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5: Preapre for use of some asn1-types. + + * lib/asn1/*.c (copy_*): Constness. + + * lib/krb5/krb5.h: Include asn1.h; krb5_data is now an + octet_string. + + * lib/asn1/der*,gen.c: krb5_data -> octet_string, char * -> + general_string + + * lib/asn1/libasn1.h: Moved stuff from asn1_locl.h that doesn't + have anything to do with asn1_compile. + + * lib/asn1/asn1_locl.h: Remove der.h. Add some prototypes. + +Sun Jun 8 03:51:55 1997 Assar Westerlund <assar@sics.se> + + * kdc/kerberos5.c: Fix PA-ENC-TS-ENC + + * kdc/connect.c(process_request): Set `new' + + * lib/krb5/get_in_tkt.c: Do PA-ENC-TS-ENC the correct way. + + * lib: Added editline,sl,roken. + +Mon Jun 2 00:37:48 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/fcache.c: Move file cache from cache.c. + + * lib/krb5/cache.c: Allow more than one cache type. + +Sun Jun 1 23:45:33 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * admin/extkeytab.c: Merged with kdb_edit. + +Sun Jun 1 23:23:08 1997 Assar Westerlund <assar@sics.se> + + * kdc/kdc.c: more support for ENC-TS-ENC + + * lib/krb5/get_in_tkt.c: redone to enable pre-authentication + +Sun Jun 1 22:45:11 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/hdb/db.c: Merge fetch and store. + + * admin: Merge to one program. + + * lib/krb5/str2key.c: Fill in keytype and length. + +Sun Jun 1 16:31:23 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_safe.c, lib/krb5/rd_priv.c, lib/krb5/mk_rep.c, + lib/krb5/mk_priv.c, lib/krb5/build_auth.c: Some support for + KRB5_AUTH_CONTEXT_DO_SEQUENCE + + * lib/krb5/get_in_tkt.c (get_in_tkt): be prepared to parse an + KRB_ERROR. Some support for PA_ENC_TS_ENC. + + * lib/krb5/auth_context.c: implemented seq_number functions + + * lib/krb5/generate_subkey.c, generate_seq_number.c: new files + + * lib/gssapi/gssapi.h: avoid including <krb5.h> + + * lib/asn1/Makefile.am: SUFFIXES as a variable to make automake + happy + + * kdc/kdc.c: preliminary PREAUTH_ENC_TIMESTAMP + + * configure.in: adapted to automake 1.1p + +Mon May 26 22:26:21 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/principal.c: Add contexts to many functions. + +Thu May 15 20:25:37 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/verify_user.c: First stab at a verify user. + + * lib/auth/sia/sia5.c: SIA module for Kerberos 5. + +Mon Apr 14 00:09:03 1997 Assar Westerlund <assar@sics.se> + + * lib/gssapi: Enough of a gssapi-over-krb5 implementation to be + able to (mostly) run gss-client and gss-server. + + * lib/krb5/keytab.c: implemented krb5_kt_add_entry, + krb5_kt_store_principal, krb5_kt_store_keyblock + + * lib/des/md5.[ch], sha.[ch]: new files + + * lib/asn1/der_get.c (generalizedtime2time): use `timegm' + + * lib/asn1/timegm.c: new file + + * admin/extkeytab.c: new program + + * admin/admin_locl.h: new file + + * admin/Makefile.am: Added extkeytab + + * configure.in: moved config to include + removed timezone garbage + added lib/gssapi and admin + + * Makefile.am: Added admin + +Mon Mar 17 11:34:05 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kdc/kdc.c: Use new copying functions, and free some data. + + * lib/asn1/Makefile.am: Try to not always rebuild generated files. + + * lib/asn1/der_put.c: Add fix_dce(). + + * lib/asn1/der_{get,length,put}.c: Fix include files. + + * lib/asn1/der_free.c: Remove unused functions. + + * lib/asn1/gen.c: Split into gen_encode, gen_decode, gen_free, + gen_length, and gen_copy. + +Sun Mar 16 18:13:52 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/sendauth.c: implemented functionality + + * lib/krb5/rd_rep.c: Use `krb5_decrypt' + + * lib/krb5/cache.c (krb5_cc_get_name): return default if `id' == + NULL + + * lib/krb5/principal.c (krb5_free_principal): added `context' + argument. Changed all callers. + + (krb5_sname_to_principal): new function + + * lib/krb5/auth_context.c (krb5_free_authenticator): add `context' + argument. Changed all callers + + * lib/krb5/{net_write.c,net_read.c,recvauth.c}: new files + + * lib/asn1/gen.c: Fix encoding and decoding of BitStrings + +Fri Mar 14 11:29:00 1997 Assar Westerlund <assar@sics.se> + + * configure.in: look for *dbm? + + * lib/asn1/gen.c: Fix filename in generated files. Check fopens. + Put trailing newline in asn1_files. + +Fri Mar 14 05:06:44 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/get_in_tkt.c: Fix some memory leaks. + + * lib/krb5/krbhst.c: Properly free hostlist. + + * lib/krb5/decrypt.c: CRCs are 32 bits. + +Fri Mar 14 04:39:15 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/asn1/gen.c: Generate one file for each type. + +Fri Mar 14 04:13:47 1997 Assar Westerlund <assar@sics.se> + + * lib/asn1/gen.c: Generate `length_FOO' functions + + * lib/asn1/der_length.c: new file + + * kuser/klist.c: renamed stime -> printable_time to avoid conflict + on HP/UX + +Fri Mar 14 03:37:23 1997 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/hdb/ndbm.c: Return NOENTRY if fetch fails. Don't free + datums. Don't add .db to filename. + +Fri Mar 14 02:49:51 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kdc/dump.c: Database dump program. + + * kdc/ank.c: Trivial database editing program. + + * kdc/{kdc.c, load.c}: Use libhdb. + + * lib/hdb: New database routine library. + + * lib/krb5/error/Makefile.am: Add hdb_err. + +Wed Mar 12 17:41:14 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * kdc/kdc.c: Rewritten AS, and somewhat more working TGS support. + + * lib/asn1/gen.c: Generate free functions. + + * Some specific free functions. + +Wed Mar 12 12:30:13 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/krb5_mk_req_ext.c: new file + + * lib/asn1/gen.c: optimize the case with a simple type + + * lib/krb5/get_cred.c (krb5_get_credentials): Use + `mk_req_extended' and remove old code. + + * lib/krb5/get_in_tkt.c (decrypt_tkt): First try with an + EncASRepPart, then with an EncTGSRepPart. + +Wed Mar 12 08:26:04 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/store_emem.c: New resizable memory storage. + + * lib/krb5/{store.c, store_fd.c, store_mem.c}: Split of store.c + + * lib/krb5/krb5.h: Add free entry to krb5_storage. + + * lib/krb5/decrypt.c: Make keyblock const. + +Tue Mar 11 20:22:17 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/krb5.h: Add EncTicketPart to krb5_ticket. + + * lib/krb5/rd_req.c: Return whole asn.1 ticket in + krb5_ticket->tkt. + + * lib/krb5/get_in_tkt.c: TGS -> AS + + * kuser/kfoo.c: Print error string rather than number. + + * kdc/kdc.c: Some kind of non-working TGS support. + +Mon Mar 10 01:43:22 1997 Assar Westerlund <assar@sics.se> + + * lib/asn1/gen.c: reduced generated code by 1/5 + + * lib/asn1/der_put.c: (der_put_length_and_tag): new function + + * lib/asn1/der_get.c (der_match_tag_and_length): new function + + * lib/asn1/der.h: added prototypes + +Mon Mar 10 01:15:43 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/krb5.h: Include <asn1_err.h>. Add prototype for + krb5_rd_req_with_keyblock. + + * lib/krb5/rd_req.c: Add function krb5_rd_req_with_keyblock that + takes a precomputed keyblock. + + * lib/krb5/get_cred.c: Use krb5_mk_req rather than inlined code. + + * lib/krb5/mk_req.c: Calculate checksum of in_data. + +Sun Mar 9 21:17:58 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/error/compile_et.awk: Add a declaration of struct + error_list, and multiple inclusion block to header files. + +Sun Mar 9 21:01:12 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_req.c: do some checks on times + + * lib/krb/{mk_priv.c, rd_priv.c, sendauth.c, decrypt.c, + address.c}: new files + + * lib/krb5/auth_context.c: more code + + * configure.in: try to figure out timezone + +Sat Mar 8 11:41:07 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/error/error.c: Try strerror if error code wasn't found. + + * lib/krb5/get_in_tkt.c: Remove realm parameter from + krb5_get_salt. + + * lib/krb5/context.c: Initialize error table. + + * kdc: The beginnings of a kdc. + +Sat Mar 8 08:16:28 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_safe.c: new file + + * lib/krb5/checksum.c (krb5_verify_checksum): New function + + * lib/krb5/get_cred.c: use krb5_create_checksum + + * lib/krb5/checksum.c: new file + + * lib/krb5/store.c: no more arithmetic with void* + + * lib/krb5/cache.c: now seems to work again + +Sat Mar 8 06:58:09 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/Makefile.am: Add asn1_glue.c and error/*.c to libkrb5. + + * lib/krb5/get_in_tkt.c: Moved some functions to asn1_glue.c. + + * lib/krb5/asn1_glue.c: Moved some asn1-stuff here. + + * lib/krb5/{cache,keytab}.c: Use new storage functions. + + * lib/krb5/krb5.h: Protypes for new storage functions. + + * lib/krb5/krb5.h: Make krb5_{ret,store}_* functions able to write + data to more than file descriptors. + +Sat Mar 8 01:01:17 1997 Assar Westerlund <assar@sics.se> + + * lib/krb5/encrypt.c: New file. + + * lib/krb5/Makefile.am: More -I + + * configure.in: Test for big endian, random, rand, setitimer + + * lib/asn1/gen.c: perhaps even decodes bitstrings + +Thu Mar 6 19:05:29 1997 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/config_file.y: Better return values on error. + +Sat Feb 8 15:59:56 1997 Assar Westerlund <assar@pdc.kth.se> + + * lib/asn1/parse.y: ifdef HAVE_STRDUP + + * lib/asn1/lex.l: ifdef strdup + brange-dead version of list of special characters to make stupid + lex accept it. + + * lib/asn1/gen.c: A DER integer should really be a `unsigned' + + * lib/asn1/der_put.c: A DER integer should really be a `unsigned' + + * lib/asn1/der_get.c: A DER integer should really be a `unsigned' + + * lib/krb5/error/Makefile.am: It seems "$(SHELL) ./compile_et" is + needed. + + * lib/krb/mk_rep.c, lib/krb/rd_req.c, lib/krb/store.c, + lib/krb/store.h: new files. + + * lib/krb5/keytab.c: now even with some functionality. + + * lib/asn1/gen.c: changed paramater from void * to Foo * + + * lib/asn1/der_get.c (der_get_octet_string): Fixed bug with empty + string. + +Sun Jan 19 06:17:39 1997 Assar Westerlund <assar@pdc.kth.se> + + * lib/krb5/get_cred.c (krb5_get_credentials): Check for creds in + cc before getting new ones. + + * lib/krb5/krb5.h (krb5_free_keyblock): Fix prototype. + + * lib/krb5/build_auth.c (krb5_build_authenticator): It seems the + CRC should be stored LSW first. (?) + + * lib/krb5/auth_context.c: Implement `krb5_auth_con_getkey' and + `krb5_free_keyblock' + + * lib/**/Makefile.am: Rename foo libfoo.a + + * include/Makefile.in: Use test instead of [ + -e does not work with /bin/sh on psoriasis + + * configure.in: Search for awk + create lib/krb/error/compile_et + +Tue Jan 14 03:46:26 1997 Assar Westerlund <assar@pdc.kth.se> + + * lib/krb5/Makefile.am: replaced mit-crc.c by crc.c + +Wed Dec 18 00:53:55 1996 Johan Danielsson <joda@emma.pdc.kth.se> + + * kuser/kinit.c: Guess principal. + + * lib/krb5/error/compile_et.awk: Don't include krb5.h. Fix some + warnings. + + * lib/krb5/error/asn1_err.et: Add ASN.1 error messages. + + * lib/krb5/mk_req.c: Get client from cache. + + * lib/krb5/cache.c: Add better error checking some useful return + values. + + * lib/krb5/krb5.h: Fix krb5_auth_context. + + * lib/asn1/der.h: Make krb5_data compatible with krb5.h + +Tue Dec 17 01:32:36 1996 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/error: Add primitive error library. + +Mon Dec 16 16:30:20 1996 Johan Danielsson <joda@emma.pdc.kth.se> + + * lib/krb5/cache.c: Get correct address type from cache. + + * lib/krb5/krb5.h: Change int16 to int to be compatible with asn1. + diff --git a/crypto/heimdal/ChangeLog.1999 b/crypto/heimdal/ChangeLog.1999 new file mode 100644 index 000000000000..e022b9682465 --- /dev/null +++ b/crypto/heimdal/ChangeLog.1999 @@ -0,0 +1,2194 @@ +1999-12-30 Assar Westerlund <assar@sics.se> + + * configure.in (krb4): use `-ldes' in tests + +1999-12-26 Assar Westerlund <assar@sics.se> + + * lib/hdb/print.c (event2string): handle events without principal. + From Luke Howard <lukeh@PADL.COM> + +1999-12-25 Assar Westerlund <assar@sics.se> + + * Release 0.2j + +Tue Dec 21 18:03:17 1999 Assar Westerlund <assar@sics.se> + + * lib/hdb/Makefile.am (asn1_files): add $(EXEEXT) for cygwin and + related systems + + * lib/asn1/Makefile.am (asn1_files): add $(EXEEXT) for cygwin and + related systems + + * include/Makefile.am (krb5-types.h): add $(EXEEXT) for cygwin and + related systems + +1999-12-20 Assar Westerlund <assar@sics.se> + + * Release 0.2i + +1999-12-20 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): bump version to 6:3:1 + + * lib/krb5/send_to_kdc.c (send_via_proxy): free data + * lib/krb5/send_to_kdc.c (send_via_proxy): new function use + getaddrinfo instead of gethostbyname{,2} + * lib/krb5/get_for_creds.c: use getaddrinfo instead of + getnodebyname{,2} + +1999-12-17 Assar Westerlund <assar@sics.se> + + * Release 0.2h + +1999-12-17 Assar Westerlund <assar@sics.se> + + * Release 0.2g + +1999-12-16 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: bump version to 6:2:1 + + * lib/krb5/principal.c (krb5_sname_to_principal): handle + ai_canonname not being set + * lib/krb5/expand_hostname.c (krb5_expand_hostname): handle + ai_canonname not being set + + * appl/test/uu_server.c: print messages to stderr + * appl/test/tcp_server.c: print messages to stderr + * appl/test/nt_gss_server.c: print messages to stderr + * appl/test/gssapi_server.c: print messages to stderr + + * appl/test/tcp_client.c (proto): remove shadowing `context' + * appl/test/common.c (client_doit): add forgotten ntohs + +1999-12-13 Assar Westerlund <assar@sics.se> + + * configure.in (VERISON): bump to 0.2g-pre + +1999-12-12 Assar Westerlund <assar@sics.se> + + * lib/krb5/principal.c (krb5_425_conv_principal_ext): be more + robust and handle extra dot at the beginning of default_domain + +1999-12-12 Assar Westerlund <assar@sics.se> + + * Release 0.2f + +1999-12-12 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: bump version to 6:1:1 + + * lib/krb5/changepw.c (get_kdc_address): use + `krb5_get_krb_changepw_hst' + + * lib/krb5/krbhst.c (krb5_get_krb_changepw_hst): add + + * lib/krb5/get_host_realm.c: add support for _kerberos.domain + (according to draft-ietf-cat-krb-dns-locate-01.txt) + +1999-12-06 Assar Westerlund <assar@sics.se> + + * Release 0.2e + +1999-12-06 Assar Westerlund <assar@sics.se> + + * lib/krb5/changepw.c (krb5_change_password): use the correct + address + + * lib/krb5/Makefile.am: bump version to 6:0:1 + + * lib/asn1/Makefile.am: bump version to 1:4:0 + +1999-12-04 Assar Westerlund <assar@sics.se> + + * configure.in: move AC_KRB_IPv6 to make sure it's performed + before AC_BROKEN + (el_init): use new feature of AC_FIND_FUNC_NO_LIBS + + * appl/test/uu_client.c: use client_doit + * appl/test/test_locl.h (client_doit): add prototype + * appl/test/tcp_client.c: use client_doit + * appl/test/nt_gss_client.c: use client_doit + * appl/test/gssapi_client.c: use client_doit + * appl/test/common.c (client_doit): move identical code here and + start using getaddrinfo + + * appl/kf/kf.c (doit): rewrite to use getaddrinfo + * kdc/hprop.c: re-write to use getaddrinfo + * lib/krb5/principal.c (krb5_sname_to_principal): use getaddrinfo + * lib/krb5/expand_hostname.c (krb5_expand_hostname): use + getaddrinfo + * lib/krb5/changepw.c: re-write to use getaddrinfo + * lib/krb5/addr_families.c (krb5_parse_address): use getaddrinfo + +1999-12-03 Assar Westerlund <assar@sics.se> + + * configure.in (BROKEN): check for freeaddrinfo, getaddrinfo, + getnameinfo, gai_strerror + (socklen_t): check for + +1999-12-02 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/crypto.c: ARCFOUR_set_key -> RC4_set_key + +1999-11-23 Assar Westerlund <assar@sics.se> + + * lib/krb5/crypto.c (ARCFOUR_string_to_key): change order of bytes + within unicode characters. this should probably be done in some + arbitrarly complex way to do it properly and you would have to + know what character encoding was used for the password and salt + string. + + * lib/krb5/addr_families.c (ipv4_uninteresting): ignore 0.0.0.0 + (INADDR_ANY) + (ipv6_uninteresting): remove unused macro + +1999-11-22 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/krb5.h: rc4->arcfour + + * lib/krb5/crypto.c: rc4->arcfour + +1999-11-17 Assar Westerlund <assar@sics.se> + + * lib/krb5/krb5_locl.h: add <rc4.h> + * lib/krb5/krb5.h (krb5_keytype): add KEYTYPE_RC4 + * lib/krb5/crypto.c: some code for doing RC4/MD5/HMAC which might + not be totally different from some small company up in the + north-west corner of the US + + * lib/krb5/get_addrs.c (find_all_addresses): change code to + actually increment buf_size + +1999-11-14 Assar Westerlund <assar@sics.se> + + * lib/krb5/krb5.h (krb5_context_data): add `scan_interfaces' + * lib/krb5/get_addrs.c (krb5_get_all_client_addrs): make interaces + scanning optional + * lib/krb5/context.c (init_context_from_config_file): set + `scan_interfaces' + + * lib/krb5/Makefile.am (libkrb5_la_SOURCES): add add_et_list.c + * lib/krb5/add_et_list.c (krb5_add_et_list): new function + +1999-11-12 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_default_realm.c (krb5_get_default_realm, + krb5_get_default_realms): set realms if they were unset + * lib/krb5/context.c (init_context_from_config_file): don't + initialize default realms here. it's done lazily instead. + + * lib/krb5/krb5.h (KRB5_TC_*): make constants unsigned + * lib/asn1/gen_glue.c (generate_2int, generate_units): make sure + bit constants are unsigned + * lib/asn1/gen.c (define_type): make length in sequences be + unsigned. + + * configure.in: remove duplicate test for setsockopt test for + struct tm.tm_isdst + + * lib/krb5/get_in_tkt.c (krb5_get_in_cred): generate + preauthentication information if we get back ERR_PREAUTH_REQUIRED + * lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): remove + preauthentication generation code. it's now in krb5_get_in_cred + + * configure.in (AC_BROKEN_SNPRINTF): add strptime check for struct + tm.tm_gmtoff and timezone + +1999-11-11 Johan Danielsson <joda@pdc.kth.se> + + * kdc/main.c: make this work with multi-db + + * kdc/kdc_locl.h: make this work with multi-db + + * kdc/config.c: make this work with multi-db + +1999-11-09 Johan Danielsson <joda@pdc.kth.se> + + * kdc/misc.c: update for multi-database code + + * kdc/main.c: update for multi-database code + + * kdc/kdc_locl.h: update + + * kdc/config.c: allow us to have more than one database + +1999-11-04 Assar Westerlund <assar@sics.se> + + * Release 0.2d + + * lib/krb5/Makefile.am: bump version to 5:0:0 to be safe + (krb5_context_data has changed and some code do (might) access + fields directly) + + * lib/krb5/krb5.h (krb5_context_data): add `etypes_des' + + * lib/krb5/get_cred.c (init_tgs_req): use + krb5_keytype_to_enctypes_default + + * lib/krb5/crypto.c (krb5_keytype_to_enctypes_default): new + function + + * lib/krb5/context.c (set_etypes): new function + (init_context_from_config_file): set both `etypes' and `etypes_des' + +1999-11-02 Assar Westerlund <assar@sics.se> + + * configure.in (VERSION): bump to 0.2d-pre + +1999-10-29 Assar Westerlund <assar@sics.se> + + * lib/krb5/principal.c (krb5_parse_name): check memory allocations + +1999-10-28 Assar Westerlund <assar@sics.se> + + * Release 0.2c + + * lib/krb5/dump_config.c (print_tree): check for empty tree + + * lib/krb5/string-to-key-test.c (tests): update the test cases + with empty principals so that they actually use an empty realm and + not the default. use the correct etype for 3DES + + * lib/krb5/Makefile.am: bump version to 4:1:0 + + * kdc/config.c (configure): more careful with the port string + +1999-10-26 Assar Westerlund <assar@sics.se> + + * Release 0.2b + +1999-10-20 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: bump version to 4:0:0 + (krb524_convert_creds_kdc and potentially some other functions + have changed prototypes) + + * lib/hdb/Makefile.am: bump version to 4:0:1 + + * lib/asn1/Makefile.am: bump version to 1:3:0 + + * configure.in (LIB_roken): add dbopen. getcap in roken + references dbopen and with shared libraries we need to add this + dependency. + + * lib/krb5/verify_krb5_conf.c (main): support speicifying the + configuration file to test on the command line + + * lib/krb5/config_file.c (parse_binding): handle line with no + whitespace before = + (krb5_config_parse_file_debug): set lineno earlier so that we don't + use it unitialized + + * configure.in (AM_INIT_AUTOMAKE): bump to 0.2b-pre opt*: need + more include files for these tests + + * lib/krb5/set_default_realm.c (krb5_set_default_realm): use + krb5_config_get_strings, which means that your configuration file + should look like: + + [libdefaults] + default_realm = realm1 realm2 realm3 + + * lib/krb5/set_default_realm.c (config_binding_to_list): fix + copy-o. From Michal Vocu <michal@karlin.mff.cuni.cz> + + * kdc/config.c (configure): add a missing strdup. From Michal + Vocu <michal@karlin.mff.cuni.cz> + +1999-10-17 Assar Westerlund <assar@sics.se> + + * Release 0.2a + + * configure.in: only test for db.h with using berkeley_db. remember + to link with LIB_tgetent when checking for el_init. add xnlock + + * appl/Makefile.am: add xnlock + + * kdc/kerberos5.c (find_etype): support null keys + + * kdc/kerberos4.c (get_des_key): support null keys + + * lib/krb5/crypto.c (krb5_get_wrapped_length): more correct + calculation + +1999-10-16 Johan Danielsson <joda@pdc.kth.se> + + * kuser/kinit.c (main): pass ccache to krb524_convert_creds_kdc + +1999-10-12 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/crypto.c (krb5_enctype_to_keytype): remove warning + +1999-10-10 Assar Westerlund <assar@sics.se> + + * lib/krb5/mk_req.c (krb5_mk_req): use krb5_free_host_realm + + * lib/krb5/krb5.h (krb5_ccache_data): make `ops' const + + * lib/krb5/crypto.c (krb5_string_to_salttype): new function + + * **/*.[ch]: const-ize + +1999-10-06 Assar Westerlund <assar@sics.se> + + * lib/krb5/creds.c (krb5_compare_creds): const-ify + + * lib/krb5/cache.c: clean-up and comment-up + + * lib/krb5/copy_host_realm.c (krb5_copy_host_realm): copy all the + strings + + * lib/krb5/verify_user.c (krb5_verify_user_lrealm): free the + correct realm part + + * kdc/connect.c (handle_tcp): things work much better when ret is + initialized + +1999-10-03 Assar Westerlund <assar@sics.se> + + * lib/krb5/convert_creds.c (krb524_convert_creds_kdc): look at the + type of the session key + + * lib/krb5/crypto.c (krb5_enctypes_compatible_keys): spell + correctly + + * lib/krb5/creds.c (krb5_compare_creds): fix spelling of + krb5_enctypes_compatible_keys + + * lib/krb5/convert_creds.c (krb524_convert_creds_kdc): get new + credentials from the KDC if the existing one doesn't have a DES + session key. + + * lib/45/get_ad_tkt.c (get_ad_tkt): update to new + krb524_convert_creds_kdc + +1999-10-03 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/keytab_keyfile.c: make krb5_akf_ops const + + * lib/krb5/keytab_memory.c: make krb5_mkt_ops const + + * lib/krb5/keytab_file.c: make krb5_fkt_ops const + +1999-10-01 Assar Westerlund <assar@sics.se> + + * lib/krb5/config_file.c: rewritten to allow error messages + + * lib/krb5/Makefile.am (bin_PROGRAMS): add verify_krb5_conf + (libkrb5_la_SOURCES): add config_file_netinfo.c + + * lib/krb5/verify_krb5_conf.c: new program for verifying that + krb5.conf is corret + + * lib/krb5/config_file_netinfo.c: moved netinfo code here from + config_file.c + +1999-09-28 Assar Westerlund <assar@sics.se> + + * kdc/hpropd.c (dump_krb4): kludge default_realm + + * lib/asn1/check-der.c: add test cases for Generalized time and + make sure we return the correct value + + * lib/asn1/der_put.c: simplify by using der_put_length_and_tag + + * lib/krb5/verify_user.c (krb5_verify_user_lrealm): ariant of + krb5_verify_user that tries in all the local realms + + * lib/krb5/set_default_realm.c: add support for having several + default realms + + * lib/krb5/kuserok.c (krb5_kuserok): use `krb5_get_default_realms' + + * lib/krb5/get_default_realm.c (krb5_get_default_realms): add + + * lib/krb5/krb5.h (krb5_context_data): change `default_realm' to + `default_realms' + + * lib/krb5/context.c: change from `default_realm' to + `default_realms' + + * lib/krb5/aname_to_localname.c (krb5_aname_to_localname): use + krb5_get_default_realms + + * lib/krb5/Makefile.am (libkrb5_la_SOURCES): add copy_host_realm.c + + * lib/krb5/copy_host_realm.c: new file + +1999-09-27 Johan Danielsson <joda@pdc.kth.se> + + * lib/asn1/der_put.c (encode_generalized_time): encode length + + * lib/krb5/recvauth.c: new function `krb5_recvauth_match_version' + that allows more intelligent matching of the application version + +1999-09-26 Assar Westerlund <assar@sics.se> + + * lib/asn1/asn1_print.c: add err.h + + * kdc/config.c (configure): use parse_bytes + + * appl/test/nt_gss_common.c: use the correct header file + +1999-09-24 Johan Danielsson <joda@pdc.kth.se> + + * kuser/klist.c: add a `--cache' flag + + * kuser/kinit.c (main): only get default value for `get_v4_tgt' if + it's explicitly set in krb5.conf + +1999-09-23 Assar Westerlund <assar@sics.se> + + * lib/asn1/asn1_print.c (tag_names); add another univeral tag + + * lib/asn1/der.h: update universal tags + +1999-09-22 Assar Westerlund <assar@sics.se> + + * lib/asn1/asn1_print.c (loop): print length of octet string + +1999-09-21 Johan Danielsson <joda@pdc.kth.se> + + * admin/ktutil.c (kt_get): add `--help' + +1999-09-21 Assar Westerlund <assar@sics.se> + + * kuser/Makefile.am: add kdecode_ticket + + * kuser/kdecode_ticket.c: new debug program + + * appl/test/nt_gss_server.c: new program to test against `Sample * + SSPI Code' in Windows 2000 RC1 SDK. + + * appl/test/Makefile.am: add nt_gss_client and nt_gss_server + + * lib/asn1/der_get.c (decode_general_string): remember to advance + ret over the length-len + + * lib/asn1/Makefile.am: add asn1_print + + * lib/asn1/asn1_print.c: new program for printing DER-structures + + * lib/asn1/der_put.c: make functions more consistent + + * lib/asn1/der_get.c: make functions more consistent + +1999-09-20 Johan Danielsson <joda@pdc.kth.se> + + * kdc/kerberos5.c: be more informative in pa-data error messages + +1999-09-16 Assar Westerlund <assar@sics.se> + + * configure.in: test for strlcpy, strlcat + +1999-09-14 Assar Westerlund <assar@sics.se> + + * lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): return + KRB5_LIBOS_PWDINTR when interrupted + + * lib/krb5/get_in_tkt_pw.c (krb5_password_key_proc): check return + value from des_read_pw_string + + * kuser/kinit.c (main): don't print any error if reading the + password was interrupted + + * kpasswd/kpasswd.c (main): don't print any error if reading the + password was interrupted + + * kdc/string2key.c (main): check the return value from fgets + + * kdc/kstash.c (main): check return value from des_read_pw_string + + * admin/ktutil.c (kt_add): check the return-value from fgets and + overwrite the password for paranoid reasons + + * lib/krb5/keytab_keyfile.c (get_cell_and_realm): only remove the + newline if it's there + +1999-09-13 Assar Westerlund <assar@sics.se> + + * kdc/hpropd.c (main): remove bogus error with `--print'. remove + sysloging of number of principals transferred + + * kdc/hprop.c (ka_convert): set flags correctly for krbtgt/CELL + principals + (main): get rid of bogus opening of hdb database when propagating + ka-server database + +1999-09-12 Assar Westerlund <assar@sics.se> + + * lib/krb5/krb5_locl.h (O_BINARY): add fallback definition + + * lib/krb5/krb5.h (krb5_context_data): add keytab types + + * configure.in: revert back awk test, not worked around in + roken.awk + + * lib/krb5/keytab_krb4.c: remove O_BINARY + + * lib/krb5/keytab_keyfile.c: some support for AFS KeyFile's. From + Love <lha@e.kth.se> + + * lib/krb5/keytab_file.c: remove O_BINARY + + * lib/krb5/keytab.c: move the list of keytab types to the context + + * lib/krb5/fcache.c: remove O_BINARY + + * lib/krb5/context.c (init_context_from_config_file): register all + standard cache and keytab types + (krb5_free_context): free `kt_types' + + * lib/krb5/cache.c (krb5_cc_resolve): move the registration of the + standard types of credential caches to context + + * lib/krb5/Makefile.am (libkrb5_la_SOURCES): add keytab_keyfile.c + +1999-09-10 Assar Westerlund <assar@sics.se> + + * lib/krb5/keytab.c: add comments and clean-up + + * admin/ktutil.c: add `ktutil copy' + + * lib/krb5/keytab_krb4.c: new file + + * lib/krb5/krb5.h (krb5_kt_cursor): add a `data' field + + * lib/krb5/Makefile.am: add keytab_krb4.c + + * lib/krb5/keytab.c: add krb4 and correct some if's + + * admin/srvconvert.c (srvconv): move common code + + * lib/krb5/krb5.h (krb5_fkt_ops, krb5_mkt_ops): new variables + + * lib/krb5/keytab.c: move out file and memory functions + + * lib/krb5/Makefile.am (libkrb5_la_SOURCES): add keytab_file.c, + keytab_memory.c + + * lib/krb5/keytab_memory.c: new file + + * lib/krb5/keytab_file.c: new file + + * kpasswd/kpasswdd.c: move out password quality functions + +1999-09-07 Assar Westerlund <assar@sics.se> + + * lib/hdb/Makefile.am (libhdb_la_SOURCES): add keytab.c. From + Love <lha@e.kth.se> + + * lib/krb5/convert_creds.c (krb524_convert_creds_kdc): check + return value from `krb5_sendto_kdc' + +1999-09-06 Assar Westerlund <assar@sics.se> + + * lib/krb5/send_to_kdc.c (send_and_recv): rename to recv_loop and + remove the sending of data. add a parameter `limit'. let callers + send the date themselves (and preferably with net_write on tcp + sockets) + (send_and_recv_tcp): read first the length field and then only that + many bytes + +1999-09-05 Assar Westerlund <assar@sics.se> + + * kdc/connect.c (handle_tcp): try to print warning `TCP data of + strange type' less often + + * lib/krb5/send_to_kdc.c (send_and_recv): handle EINTR properly. + return on EOF. always free data. check return value from + realloc. + (send_and_recv_tcp, send_and_recv_http): check advertised length + against actual length + +1999-09-01 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: check for sgi capabilities + +1999-08-27 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/get_addrs.c: krb5_get_all_server_addrs shouldn't return + extra addresses + + * kpasswd/kpasswdd.c: use HDB keytabs; change some error messages; + add --realm flag + + * lib/krb5/address.c (krb5_append_addresses): remove duplicates + +1999-08-26 Johan Danielsson <joda@pdc.kth.se> + + * lib/hdb/keytab.c: HDB keytab backend + +1999-08-25 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/keytab.c + (krb5_kt_{start_seq_get,next_entry,end_seq_get}): check for NULL + pointer + +1999-08-24 Johan Danielsson <joda@pdc.kth.se> + + * kpasswd/kpasswdd.c: add `--keytab' flag + +1999-08-23 Assar Westerlund <assar@sics.se> + + * lib/krb5/addr_families.c (IN6_ADDR_V6_TO_V4): use `s6_addr' + instead of the non-standard `s6_addr32'. From Yoshinobu Inoue + <shin@kame.net> by way of the KAME repository + +1999-08-18 Assar Westerlund <assar@sics.se> + + * configure.in (--enable-new-des3-code): remove check for `struct + addrinfo' + + * lib/krb5/crypto.c (etypes): remove NEW_DES3_CODE, enable + des3-cbc-sha1 and keep old-des3-cbc-sha1 for backwards + compatability + + * lib/krb5/krb5.h (krb5_enctype): des3-cbc-sha1 (with key + derivation) just got assigned etype 16 by <bcn@isi.edu>. keep the + old etype at 7. + +1999-08-16 Assar Westerlund <assar@sics.se> + + * lib/krb5/sendauth.c (krb5_sendauth): only look at errno if + krb5_net_read actually returns -1 + + * lib/krb5/recvauth.c (krb5_recvauth): only look at errno if + krb5_net_read actually returns -1 + + * appl/kf/kf.c (proto): don't trust errno if krb5_net_read hasn't + returned -1 + + * appl/test/tcp_server.c (proto): only trust errno if + krb5_net_read actually returns -1 + + * appl/kf/kfd.c (proto): be more careful with the return value + from krb5_net_read + +1999-08-13 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_addrs.c (get_addrs_int): try the different ways + sequentially instead of just one. this helps if your heimdal was + built with v6-support but your kernel doesn't have it, for + example. + +1999-08-12 Assar Westerlund <assar@sics.se> + + * kdc/hpropd.c: add inetd flag. default means try to figure out + if stdin is a socket or not. + + * Makefile.am (ACLOCAL): just use `cf', this variable is only used + when the current directory is $(top_srcdir) anyways and having + $(top_srcdir) there breaks if it's a relative path + +1999-08-09 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: check for setproctitle + +1999-08-05 Assar Westerlund <assar@sics.se> + + * lib/krb5/principal.c (krb5_sname_to_principal): remember to call + freehostent + + * appl/test/tcp_client.c: call freehostent + + * appl/kf/kf.c (doit): call freehostent + + * appl/kf/kf.c: make v6 friendly and simplify + + * appl/kf/kfd.c: make v6 friendly and simplify + + * appl/test/tcp_server.c: simplify by using krb5_err instead of + errx + + * appl/test/tcp_client.c: simplify by using krb5_err instead of + errx + + * appl/test/tcp_server.c: make v6 friendly and simplify + + * appl/test/tcp_client.c: make v6 friendly and simplify + +1999-08-04 Assar Westerlund <assar@sics.se> + + * Release 0.1m + +1999-08-04 Assar Westerlund <assar@sics.se> + + * kuser/kinit.c (main): some more KRB4-conditionalizing + + * lib/krb5/get_in_tkt.c: type correctness + + * lib/krb5/get_for_creds.c (krb5_fwd_tgs_creds): set forwarded in + flags. From Miroslav Ruda <ruda@ics.muni.cz> + + * kuser/kinit.c (main): add config file support for forwardable + and krb4 support. From Miroslav Ruda <ruda@ics.muni.cz> + + * kdc/kerberos5.c (as_rep): add an empty X500-compress string as + transited. + (fix_transited_encoding): check length. + From Miroslav Ruda <ruda@ics.muni.cz> + + * kdc/hpropd.c (dump_krb4): check the realm so that we don't dump + principals in some other realm. From Miroslav Ruda + <ruda@ics.muni.cz> + (main): rename sa_len -> sin_len, sa_lan is a define on some + platforms. + + * appl/kf/kfd.c: add regpag support. From Miroslav Ruda + <ruda@ics.muni.cz> + + * appl/kf/kf.c: add `-G' and forwardable option in krb5.conf. + From Miroslav Ruda <ruda@ics.muni.cz> + + * lib/krb5/config_file.c (parse_list): don't run past end of line + + * appl/test/gss_common.h: new prototypes + + * appl/test/gssapi_client.c: use gss_err instead of abort + + * appl/test/gss_common.c (gss_verr, gss_err): add + +1999-08-03 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am (n_fold_test_LDADD): need to set this + otherwise it doesn't build with shared libraries + + * kdc/hpropd.c: v6-ify + + * kdc/hprop.c: v6-ify + +1999-08-01 Assar Westerlund <assar@sics.se> + + * lib/krb5/mk_req.c (krb5_mk_req): use krb5_expand_hostname + +1999-07-31 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_host_realm.c (krb5_get_host_realm_int): new + function that takes a FQDN + + * lib/krb5/Makefile.am (libkrb5_la_SOURCES): add exapnd_hostname.c + + * lib/krb5/expand_hostname.c: new file + +1999-07-28 Assar Westerlund <assar@sics.se> + + * Release 0.1l + +1999-07-28 Assar Westerlund <assar@sics.se> + + * lib/asn1/Makefile.am: bump version to 1:2:0 + + * lib/krb5/Makefile.am: bump version to 3:1:0 + + * configure.in: more inet_pton to roken + + * lib/krb5/principal.c (krb5_sname_to_principal): use + getipnodebyname + +1999-07-26 Assar Westerlund <assar@sics.se> + + * Release 0.1k + +1999-07-26 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/Makefile.am: bump version number (changed function + signatures) + + * lib/hdb/Makefile.am: bump version number (changes to some + function signatures) + +1999-07-26 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: bump version to 3:0:2 + + * lib/hdb/Makefile.am: bump version to 2:1:0 + + * lib/asn1/Makefile.am: bump version to 1:1:0 + +1999-07-26 Assar Westerlund <assar@sics.se> + + * Release 0.1j + +1999-07-26 Assar Westerlund <assar@sics.se> + + * configure.in: rokenize inet_ntop + + * lib/krb5/store_fd.c: lots of changes from size_t to ssize_t + + * lib/krb5/store_mem.c: lots of changes from size_t to ssize_t + + * lib/krb5/store_emem.c: lots of changes from size_t to ssize_t + + * lib/krb5/store.c: lots of changes from size_t to ssize_t + (krb5_ret_stringz): check return value from realloc + + * lib/krb5/mk_safe.c: some type correctness + + * lib/krb5/mk_priv.c: some type correctness + + * lib/krb5/krb5.h (krb5_storage): change return values of + functions from size_t to ssize_t + +1999-07-24 Assar Westerlund <assar@sics.se> + + * Release 0.1i + + * configure.in (AC_PROG_AWK): disable. mawk seems to mishandle \# + in lib/roken/roken.awk + + * lib/krb5/get_addrs.c (find_all_addresses): try to use SA_LEN to + step over addresses if there's no `sa_lan' field + + * lib/krb5/sock_principal.c (krb5_sock_to_principal): simplify by + using `struct sockaddr_storage' + + * lib/krb5/send_to_kdc.c (krb5_sendto_kdc): simplify by using + `struct sockaddr_storage' + + * lib/krb5/changepw.c (krb5_change_password): simplify by using + `struct sockaddr_storage' + + * lib/krb5/auth_context.c (krb5_auth_con_setaddrs_from_fd): + simplify by using `struct sockaddr_storage' + + * kpasswd/kpasswdd.c (*): simplify by using `struct + sockaddr_storage' + + * kdc/connect.c (*): simplify by using `struct sockaddr_storage' + + * configure.in (sa_family_t): just test for existence + (sockaddr_storage): also specify include file + + * configure.in (AM_INIT_AUTOMAKE): bump version to 0.1i + (sa_family_t): test for + (struct sockaddr_storage): test for + + * kdc/hprop.c (propagate_database): typo, NULL should be + auth_context + + * lib/krb5/get_addrs.c: conditionalize on HAVE_IPV6 instead of + AF_INET6 + + * appl/kf/kf.c (main): use warnx + + * appl/kf/kf.c (proto): remove shadowing context + + * lib/krb5/get_addrs.c (find_all_addresses): try to handle the + case of getting back an `sockaddr_in6' address when sizeof(struct + sockaddr_in6) > sizeof(struct sockaddr) and we have no sa_len to + tell us how large the address is. This obviously doesn't work + with unknown protocol types. + +1999-07-24 Assar Westerlund <assar@sics.se> + + * Release 0.1h + +1999-07-23 Assar Westerlund <assar@sics.se> + + * appl/kf/kfd.c: clean-up and more paranoia + + * etc/services.append: add kf + + * appl/kf/kf.c: rename tk_file to ccache for consistency. clean-up + +1999-07-22 Assar Westerlund <assar@sics.se> + + * lib/krb5/n-fold-test.c (main): print the correct data + + * appl/Makefile.am (SUBDIRS): add kf + + * appl/kf: new program. From Miroslav Ruda <ruda@ics.muni.cz> + + * kdc/hprop.c: declare some variables unconditionally to simplify + things + + * kpasswd/kpasswdd.c: initialize kadm5 connection for every change + (otherwise the modifier in the database doesn't get set) + + * kdc/hpropd.c: clean-up and re-organize + + * kdc/hprop.c: clean-up and re-organize + + * configure.in (SunOS): define to xy for SunOS x.y + +1999-07-19 Assar Westerlund <assar@sics.se> + + * configure.in (AC_BROKEN): test for copyhostent, freehostent, + getipnodebyaddr, getipnodebyname + +1999-07-15 Assar Westerlund <assar@sics.se> + + * lib/asn1/check-der.c: more test cases for integers + + * lib/asn1/der_length.c (length_int): handle the case of the + largest negative integer by not calling abs + +1999-07-14 Assar Westerlund <assar@sics.se> + + * lib/asn1/check-der.c (generic_test): check malloc return value + properly + + * lib/krb5/Makefile.am: add string_to_key_test + + * lib/krb5/prog_setup.c (krb5_program_setup): always initialize + the context + + * lib/krb5/n-fold-test.c (main): return a relevant return value + + * lib/krb5/krbhst.c: do SRV lookups for admin server as well. + some clean-up. + +1999-07-12 Assar Westerlund <assar@sics.se> + + * configure.in: handle not building X programs + +1999-07-06 Assar Westerlund <assar@sics.se> + + * lib/krb5/addr_families.c (ipv6_parse_addr): remove duplicate + variable + (ipv6_sockaddr2port): fix typo + + * etc/services.append: beginning of a file with services + + * lib/krb5/cache.c (krb5_cc_resolve): fall-back to files if + there's no prefix. also clean-up a little bit. + + * kdc/hprop.c (--kaspecials): new flag for handling special KA + server entries. From "Brandon S. Allbery KF8NH" + <allbery@kf8nh.apk.net> + +1999-07-05 Assar Westerlund <assar@sics.se> + + * kdc/connect.c (handle_tcp): make sure we have data before + starting to look for HTTP + + * kdc/connect.c (handle_tcp): always do getpeername, we can't + trust recvfrom to return anything sensible + +1999-07-04 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_in_tkt.c (add_padat): encrypt pre-auth data with + all enctypes + + * kpasswd/kpasswdd.c (change): fetch the salt-type from the entry + + * admin/srvconvert.c (srvconv): better error messages + +1999-07-03 Assar Westerlund <assar@sics.se> + + * lib/krb5/principal.c (unparse_name): error check malloc properly + + * lib/krb5/get_in_tkt.c (krb5_init_etype): error check malloc + properly + + * lib/krb5/crypto.c (*): do some malloc return-value checks + properly + + * lib/hdb/hdb.c (hdb_process_master_key): simplify by using + krb5_data_alloc + + * lib/hdb/hdb.c (hdb_process_master_key): check return value from + malloc + + * lib/asn1/gen_decode.c (decode_type): fix generation of decoding + information for TSequenceOf. + + * kdc/kerberos5.c (get_pa_etype_info): check return value from + malloc + +1999-07-02 Assar Westerlund <assar@sics.se> + + * lib/asn1/der_copy.c (copy_octet_string): don't fail if length == + 0 and malloc returns NULL + +1999-06-29 Assar Westerlund <assar@sics.se> + + * lib/krb5/addr_families.c (ipv6_parse_addr): implement + +1999-06-24 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_cred.c (krb5_rd_cred): compare the sender's address + as an addrport one + + * lib/krb5/krb5.h (KRB5_ADDRESS_ADDRPORT, KRB5_ADDRESS_IPPORT): + add + (krb5_auth_context): add local and remote port + + * lib/krb5/get_for_creds.c (krb5_get_forwarded_creds): get the + local and remote address and add them to the krb-cred packet + + * lib/krb5/auth_context.c: save the local and remove ports in the + auth_context + + * lib/krb5/address.c (krb5_make_addrport): create an address of + type KRB5_ADDRESS_ADDRPORT from (addr, port) + + * lib/krb5/addr_families.c (krb5_sockaddr2port): new function for + grabbing the port number out of the sockaddr + +1999-06-23 Assar Westerlund <assar@sics.se> + + * admin/srvcreate.c (srvcreate): always take the DES-CBC-MD5 key. + increase possible verbosity. + + * lib/krb5/config_file.c (parse_list): handle blank lines at + another place + + * kdc/connect.c (add_port_string): don't return a value + + * lib/kadm5/init_c.c (get_cred_cache): you cannot reuse the cred + cache if the principals are different. close and NULL the old one + so that we create a new one. + + * configure.in: move around cgywin et al + (LIB_kdb): set at the end of krb4-block + (krb4): test for krb_enable_debug and krb_disable_debug + +1999-06-16 Assar Westerlund <assar@sics.se> + + * kuser/kdestroy.c (main): try to destroy v4 ticket even if the + destruction of the v5 one fails + + * lib/krb5/crypto.c (DES3_postproc): new version that does the + right thing + (*): don't put and recover length in 3DES encoding + other small fixes + +1999-06-15 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_default_principal.c: rewrite to use + get_default_username + + * lib/krb5/Makefile.am: add n-fold-test + + * kdc/connect.c: add fallbacks for all lookups by service name + (handle_tcp): break-up and clean-up + +1999-06-09 Assar Westerlund <assar@sics.se> + + * lib/krb5/addr_families.c (ipv6_uninteresting): don't consider + the loopback address as uninteresting + + * lib/krb5/get_addrs.c: new magic flag to get loopback address if + there are no other addresses. + (krb5_get_all_client_addrs): use that flag + +1999-06-04 Assar Westerlund <assar@sics.se> + + * lib/krb5/crypto.c (HMAC_SHA1_DES3_checksum): don't include the + length + (checksum_sha1, checksum_hmac_sha1_des3): blocksize should be 64 + (encrypt_internal_derived): don't include the length and don't + decrease by the checksum size twice + (_get_derived_key): the constant should be 5 bytes + +1999-06-02 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: use KRB_CHECK_X + + * configure.in: check for netinet/ip.h + +1999-05-31 Assar Westerlund <assar@sics.se> + + * kpasswd/kpasswdd.c (setup_passwd_quality_check): conditionalize + on RTLD_NOW + +1999-05-23 Assar Westerlund <assar@sics.se> + + * appl/test/uu_server.c: removed unused stuff + + * appl/test/uu_client.c: removed unused stuff + +1999-05-21 Assar Westerlund <assar@sics.se> + + * kuser/kgetcred.c (main): correct error message + + * lib/krb5/crypto.c (verify_checksum): call (*ct->checksum) + directly, avoiding redundant lookups and memory leaks + + * lib/krb5/auth_context.c (krb5_auth_con_setaddrs_from_fd): free + local and remote addresses + + * lib/krb5/get_default_principal.c (get_logname): also try + $USERNAME + + * lib/asn1/Makefile.am (asn1_files): add $(EXEEXT) + + * lib/krb5/principal.c (USE_RESOLVER): try to define only if we + have a libresolv (currently by checking for res_search) + +1999-05-18 Johan Danielsson <joda@pdc.kth.se> + + * kdc/connect.c (handle_tcp): remove %-escapes in request + +1999-05-14 Assar Westerlund <assar@sics.se> + + * Release 0.1g + + * admin/ktutil.c (kt_remove): -t should be -e + + * configure.in (CHECK_NETINET_IP_AND_TCP): use + + * kdc/hpropd.c: support for dumping to krb4. From Miroslav Ruda + <ruda@ics.muni.cz> + + * admin/ktutil.c (kt_add): new option `--no-salt'. From Miroslav + Ruda <ruda@ics.muni.cz> + + * configure.in: add cygwin and DOS tests replace sendmsg, recvmsg, + and innetgr with roken versions + + * kuser/kgetcred.c: new program + +Tue May 11 14:09:33 1999 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/mcache.c: fix paste-o + +1999-05-10 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: don't use uname + +1999-05-10 Assar Westerlund <assar@sics.se> + + * acconfig.h (KRB_PUT_INT): if we don't have KRB4 use four + arguments :-) + + * appl/test/uu_server.c (setsockopt): cast to get rid of a warning + + * appl/test/tcp_server.c (setsockopt): cast to get rid of a + warning + + * appl/test/tcp_client.c (proto): call krb5_sendauth with ccache + == NULL + + * appl/test/gssapi_server.c (setsockopt): cast to get rid of a + warning + + * lib/krb5/sendauth.c (krb5_sendauth): handle ccache == NULL by + setting the default ccache. + + * configure.in (getsockopt, setsockopt): test for + (AM_INIT_AUTOMAKE): bump version to 0.1g + + * appl/Makefile.am (SUBDIRS): add kx + + * lib/hdb/convert_db.c (main): handle the case of no master key + +1999-05-09 Assar Westerlund <assar@sics.se> + + * Release 0.1f + + * kuser/kinit.c: add --noaddresses + + * lib/krb5/get_in_tkt.c (init_as_req): interpret `addrs' being an + empty sit of list as to not ask for any addresses. + +1999-05-08 Assar Westerlund <assar@sics.se> + + * acconfig.h (_GNU_SOURCE): define this to enable (used) + extensions on glibc-based systems such as linux + +1999-05-03 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_cred.c (get_cred_from_kdc_flags): allocate and free + `*out_creds' properly + + * lib/krb5/creds.c (krb5_compare_creds): just verify that the + keytypes/enctypes are compatible, not that they are the same + + * kuser/kdestroy.c (cache): const-correctness + +1999-05-03 Johan Danielsson <joda@pdc.kth.se> + + * lib/hdb/hdb.c (hdb_set_master_key): initialise master key + version + + * lib/hdb/convert_db.c: add support for upgrading database + versions + + * kdc/misc.c: add flags to fetch + + * kdc/kstash.c: unlink keyfile on failure, chmod to 400 + + * kdc/hpropd.c: add --print option + + * kdc/hprop.c: pass flags to hdb_foreach + + * lib/hdb/convert_db.c: add some flags + + * lib/hdb/Makefile.am: remove extra LDFLAGS, update version to 2; + build prototype headers + + * lib/hdb/hdb_locl.h: update prototypes + + * lib/hdb/print.c: move printable version of entry from kadmin + + * lib/hdb/hdb.c: change hdb_{seal,unseal}_* to check if the key is + sealed or not; add flags to hdb_foreach + + * lib/hdb/ndbm.c: add flags to NDBM_seq, NDBM_firstkey, and + NDBM_nextkey + + * lib/hdb/db.c: add flags to DB_seq, DB_firstkey, and DB_nextkey + + * lib/hdb/common.c: add flags to _hdb_{fetch,store} + + * lib/hdb/hdb.h: add master_key_version to struct hdb, update + prototypes + + * lib/hdb/hdb.asn1: make mkvno optional, update version to 2 + + * configure.in: --enable-netinfo + + * lib/krb5/config_file.c: HAVE_NETINFO_NI_H -> HAVE_NETINFO + + * config.sub: fix for crays + + * config.guess: new version from automake 1.4 + + * config.sub: new version from automake 1.4 + +Wed Apr 28 00:21:17 1999 Assar Westerlund <assar@sics.se> + + * Release 0.1e + + * lib/krb5/mcache.c (mcc_get_next): get the current cursor + correctly + + * acconfig.h: correct definition of KRB_PUT_INT for old krb4 code. + From Ake Sandgren <ake@cs.umu.se> + +1999-04-27 Johan Danielsson <joda@pdc.kth.se> + + * kdc/kerberos5.c: fix arguments to decrypt_ticket + +1999-04-25 Assar Westerlund <assar@sics.se> + + * lib/krb5/mk_req_ext.c (krb5_mk_req_internal): try to handle old + DCE secd's that are not able to handle MD5 checksums by defaulting + to MD4 if the keytype was DES-CBC-CRC + + * lib/krb5/mk_req.c (krb5_mk_req): use auth_context->keytype + + * lib/krb5/krb5.h (krb5_auth_context_data): add `keytype' and + `cksumtype' + + * lib/krb5/get_cred.c (make_pa_tgs_req): remove old kludge for + secd + (init_tgs_req): add all supported enctypes for the keytype in + `in_creds->session.keytype' if it's set + + * lib/krb5/crypto.c (F_PSEUDO): new flag for non-protocol + encryption types + (do_checksum): new function + (verify_checksum): take the checksum to use from the checksum message + and not from the crypto struct + (etypes): add F_PSEUDO flags + (krb5_keytype_to_enctypes): new function + + * lib/krb5/auth_context.c (krb5_auth_con_init): initalize keytype + and cksumtype + (krb5_auth_setcksumtype, krb5_auth_getcksumtype): implement + (krb5_auth_setkeytype, krb5_auth_getkeytype): implement + (krb5_auth_setenctype): comment out, it's rather bogus anyway + +Sun Apr 25 16:55:50 1999 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/krb5_locl.h: fix for stupid aix warnings + + * lib/krb5/fcache.c (erase_file): don't malloc + +Sat Apr 24 18:35:21 1999 Johan Danielsson <joda@pdc.kth.se> + + * kdc/config.c: pass context to krb5_config_file_free + + * kuser/kinit.c: add `--fcache-version' to set cache version to + create + + * kuser/klist.c: print cache version if verbose + + * lib/krb5/transited.c (krb5_domain_x500_decode): don't abort + + * lib/krb5/principal.c: abort -> krb5_abortx + + * lib/krb5/mk_rep.c: abort -> krb5_abortx + + * lib/krb5/config_file.c: abort -> krb5_abortx + + * lib/krb5/context.c (init_context_from_config_file): init + fcache_version; add krb5_{get,set}_fcache_version + + * lib/krb5/keytab.c: add support for reading (and writing?) old + version keytabs + + * lib/krb5/cache.c: add krb5_cc_get_version + + * lib/krb5/fcache.c: add support for reading and writing old + version cache files + + * lib/krb5/store_mem.c (krb5_storage_from_mem): zero flags + + * lib/krb5/store_emem.c (krb5_storage_emem): zero flags + + * lib/krb5/store_fd.c (krb5_storage_from_fd): zero flags + + * lib/krb5/store.c: add flags to change how various fields are + stored, used for old cache version support + + * lib/krb5/krb5.h: add support for reading and writing old version + cache files, and keytabs + +Wed Apr 21 00:09:26 1999 Assar Westerlund <assar@sics.se> + + * configure.in: fix test for readline.h remember to link with + $LIB_tgetent when trying linking with readline + + * lib/krb5/init_creds_pw.c (get_init_creds_common): if start_time + is given, request a postdated ticket. + + * lib/krb5/data.c (krb5_data_free): free data as long as it's not + NULL + +Tue Apr 20 20:18:14 1999 Assar Westerlund <assar@sics.se> + + * kpasswd/Makefile.am (kpasswdd_LDADD): add LIB_dlopen + + * lib/krb5/krb5.h (KRB5_VERIFY_AP_REQ_IGNORE_INVALID): add + + * lib/krb5/rd_req.c (krb5_decrypt_ticket): add `flags` and + KRB5_VERIFY_AP_REQ_IGNORE_INVALID for ignoring that the ticket is + invalid + +Tue Apr 20 12:42:08 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * kpasswd/kpasswdd.c: don't try to load library by default; get + library and function name from krb5.conf + + * kpasswd/sample_passwd_check.c: sample password checking + functions + +Mon Apr 19 22:22:19 1999 Assar Westerlund <assar@sics.se> + + * lib/krb5/store.c (krb5_storage_to_data, krb5_ret_data): use + krb5_data_alloc and be careful with checking allocation and sizes. + + * kuser/klist.c (--tokens): conditionalize on KRB4 + + * kuser/kinit.c (renew_validate): set all flags + (main): fix cut-n-paste error when setting start-time + + * kdc/kerberos5.c (check_tgs_flags): starttime of a validate + ticket should be > than current time + (*): send flags to krb5_verify_ap_req and krb5_decrypt_ticket + + * kuser/kinit.c (renew_validate): use the client realm instead of + the local realm when renewing tickets. + + * lib/krb5/get_for_creds.c (krb5_fwd_tgs_creds): compat function + (krb5_get_forwarded_creds): correct freeing of out_creds + + * kuser/kinit.c (renew_validate): hopefully fix up freeing of + memory + + * configure.in: do all the krb4 tests with "$krb4" != "no" + + * lib/krb5/keyblock.c (krb5_free_keyblock_contents): don't zero + keyvalue if it's NULL. noticed by Ake Sandgren <ake@cs.umu.se> + + * lib/krb5/get_in_tkt.c (add_padata): loop over all enctypes + instead of just taking the first one. fix all callers. From + "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net> + + * kdc/kdc_locl.h (enable_kaserver): declaration + + * kdc/hprop.c (ka_convert): print the failing principal. AFS 3.4a + creates krbtgt.REALMOFCELL as NOTGS+NOSEAL, work around. From + "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net> + + * kdc/hpropd.c (open_socket): stupid cast to get rid of a warning + + * kdc/connect.c (add_standard_ports, process_request): look at + enable_kaserver. From "Brandon S. Allbery KF8NH" + <allbery@kf8nh.apk.net> + + * kdc/config.c: new flag --kaserver and config file option + enable-kaserver. From "Brandon S. Allbery KF8NH" + <allbery@kf8nh.apk.net> + +Mon Apr 19 12:32:04 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * configure.in: check for dlopen, and dlfcn.h + + * kpasswd/kpasswdd.c: add support for dlopen:ing password quality + check library + + * configure.in: add appl/su + +Sun Apr 18 15:46:53 1999 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/cache.c: add krb5_cc_get_type that returns type of a + cache + +Fri Apr 16 17:58:51 1999 Assar Westerlund <assar@sics.se> + + * configure.in: LIB_kdb: -L should be before -lkdb + test for prototype of strsep + +Thu Apr 15 11:34:38 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/krb5/Makefile.am: update version + + * lib/krb5/get_for_creds.c (krb5_get_forwarded_creds): use + ALLOC_SEQ + + * lib/krb5/fcache.c: add some support for reading and writing old + cache formats; + (fcc_store_cred): use krb5_store_creds; (fcc_read_cred): use + krb5_ret_creds + + * lib/krb5/store_mem.c (krb5_storage_from_mem): check malloc, + initialize host_byteorder + + * lib/krb5/store_fd.c (krb5_storage_from_fd): initialize + host_byteorder + + * lib/krb5/store_emem.c (krb5_storage_emem): initialize + host_byteorder + + * lib/krb5/store.c (krb5_storage_set_host_byteorder): add; + (krb5_store_int32,krb5_ret_int32,krb5_store_int16,krb5_ret_int16): + check host_byteorder flag; (krb5_store_creds): add; + (krb5_ret_creds): add + + * lib/krb5/krb5.h (krb5_storage): add `host_byteorder' flag for + storage of numbers + + * lib/krb5/heim_err.et: add `host not found' error + + * kdc/connect.c: don't use data after clearing decriptor + + * lib/krb5/auth_context.c: abort -> krb5_abortx + + * lib/krb5/warn.c: add __attribute__; add *abort functions + + * configure.in: check for __attribute__ + + * kdc/connect.c: log bogus requests + +Tue Apr 13 18:38:05 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/kadm5/create_s.c (kadm5_s_create_principal): create v4 salts + for all DES keys + +1999-04-12 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_cred.c (init_tgs_req): re-structure a little bit + + * lib/krb5/get_cred.c (init_tgs_req): some more error checking + + * lib/krb5/generate_subkey.c (krb5_generate_subkey): check return + value from malloc + +Sun Apr 11 03:47:23 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/krb5/krb5.conf.5: update to reality + + * lib/krb5/krb5_425_conv_principal.3: update to reality + +1999-04-11 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_host_realm.c: handle more than one realm for a host + + * kpasswd/kpasswd.c (main): use krb5_program_setup and + print_version + + * kdc/string2key.c (main): use krb5_program_setup and + print_version + +Sun Apr 11 02:35:58 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/krb5/principal.c (krb5_524_conv_principal): make it actually + work, and check built-in list of host-type first-components + + * lib/krb5/krbhst.c: lookup SRV-records to find a kdc for a realm + + * lib/krb5/context.c: add srv_* flags to context + + * lib/krb5/principal.c: add default v4_name_convert entries + + * lib/krb5/krb5.h: add srv_* flags to context + +Sat Apr 10 22:52:28 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * kadmin/kadmin.c: complain about un-recognised commands + + * admin/ktutil.c: complain about un-recognised commands + +Sat Apr 10 15:41:49 1999 Assar Westerlund <assar@sics.se> + + * kadmin/load.c (doit): fix error message + + * lib/krb5/crypto.c (encrypt_internal): free checksum if lengths + fail to match. + (krb5_get_wrapped_length): new function + + * configure.in: security/pam_modules.h: check for + + * lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): kludge + around `ret_as_reply' semantics by only freeing it when ret == 0 + +Fri Apr 9 20:24:04 1999 Assar Westerlund <assar@sics.se> + + * kuser/klist.c (print_cred_verbose): handle the case of a bad + enctype + + * configure.in: test for more header files + (LIB_roken): set + +Thu Apr 8 15:01:59 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * configure.in: fixes for building w/o krb4 + + * ltmain.sh: update to libtool 1.2d + + * ltconfig: update to libtool 1.2d + +Wed Apr 7 23:37:26 1999 Assar Westerlund <assar@sics.se> + + * kdc/hpropd.c: fix some error messages to be more understandable. + + * kdc/hprop.c (ka_dump): remove unused variables + + * appl/test/tcp_server.c: remove unused variables + + * appl/test/gssapi_server.c: remove unused variables + + * appl/test/gssapi_client.c: remove unused variables + +Wed Apr 7 14:05:15 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/krb5/context.c (krb5_get_err_text): long -> krb5_error_code + + * kuser/klist.c: make it compile w/o krb4 + + * kuser/kdestroy.c: make it compile w/o krb4 + + * admin/ktutil.c: fix {srv,key}2{srv,key}tab confusion; add help + strings + +Mon Apr 5 16:13:46 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * configure.in: test for MIPS ABI; new test_package + +Thu Apr 1 11:00:40 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * include/Makefile.am: clean krb5-private.h + + * Release 0.1d + + * kpasswd/kpasswdd.c (doit): pass context to + krb5_get_all_client_addrs + + * kdc/connect.c (init_sockets): pass context to + krb5_get_all_server_addrs + + * lib/krb5/get_in_tkt.c (init_as_req): pass context to + krb5_get_all_client_addrs + + * lib/krb5/get_cred.c (get_cred_kdc_la): pass context to + krb5_get_all_client_addrs + + * lib/krb5/get_addrs.c (get_addrs_int): add extra host addresses + + * lib/krb5/krb5.h: add support for adding an extra set of + addresses + + * lib/krb5/context.c: add support for adding an extra set of + addresses + + * lib/krb5/addr_families.c: add krb5_parse_address + + * lib/krb5/address.c: krb5_append_addresses + + * lib/krb5/config_file.c (parse_binding): don't zap everything + after first whitespace + + * kuser/kinit.c (renew_validate): don't allocate out + + * lib/krb5/get_for_creds.c (krb5_get_forwarded_creds): don't + allocate out_creds + + * lib/krb5/get_cred.c (get_cred_kdc, get_cred_kdc_la): make + out_creds pointer; + (krb5_get_kdc_cred): allocate out_creds; (get_cred_from_kdc_flags): + free more memory + + * lib/krb5/crypto.c (encrypt_internal): free checksum + + * lib/krb5/convert_creds.c (krb524_convert_creds_kdc): free reply, + and ticket + + * kuser/Makefile.am: remove kfoo + + * lib/Makefile.am: add auth + + * lib/kadm5/iprop.h: getarg.h + + * lib/kadm5/replay_log.c: use getarg + + * lib/kadm5/ipropd_slave.c: use getarg + + * lib/kadm5/ipropd_master.c: use getarg + + * lib/kadm5/dump_log.c: use getarg + + * kpasswd/kpasswdd.c: use getarg + + * Makefile.am.common: make a more working check-local target + + * lib/asn1/main.c: use getargs + +Mon Mar 29 20:19:57 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * kuser/klist.c (print_cred_verbose): use krb5_print_address + + * lib/kadm5/server.c: k_{put,get}_int -> _krb5_{put,get}_int + + * lib/krb5/addr_families.c (krb5_print_address): handle unknown + address types; (ipv6_print_addr): print in 16-bit groups (as it + should) + + * lib/krb5/crc.c: crc_{init_table,update} -> + _krb5_crc_{init_table,update} + + * lib/krb5/crypto.c: k_{put,get}_int -> _krb5_{put,get}_int + crc_{init_table,update} -> _krb5_crc_{init_table,update} + + * lib/krb5/send_to_kdc.c: k_{put,get}_int -> _krb5_{put,get}_int + + * lib/krb5/store.c: k_{put,get}_int -> _krb5_{put,get}_int + + * lib/krb5/krb5_locl.h: include krb5-private.h + + * kdc/connect.c (addr_to_string): use krb5_print_address + + * lib/krb5/addr_families.c (krb5_print_address): int -> size_t + + * lib/krb5/addr_families.c: add support for printing ipv6 + addresses, either with inet_ntop, or ugly for-loop + + * kdc/524.c: check that the ticket came from a valid address; use + the address of the connection as the address to put in the v4 + ticket (if this address is AF_INET) + + * kdc/connect.c: pass addr to do_524 + + * kdc/kdc_locl.h: prototype for do_524 + +Sat Mar 27 17:48:31 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * configure.in: check for OSF C2; bind/bitypes.h, getudbnam, + setlim; check for auth modules; siad.h, getpwnam_r; + lib/auth/Makefile, lib/auth/sia/Makefile + + * lib/krb5/crypto.c: n_fold -> _krb5_n_fold + + * lib/krb5/n-fold.c: n_fold -> _krb5_n_fold + +Thu Mar 25 04:35:21 1999 Assar Westerlund <assar@sics.se> + + * lib/kadm5/set_keys.c (_kadm5_set_keys): free salt when zapping + it + + * lib/kadm5/free.c (kadm5_free_principal_ent): free `key_data' + + * lib/hdb/ndbm.c (NDBM_destroy): clear master key + + * lib/hdb/db.c (DB_destroy): clear master key + (DB_open): check malloc + + * kdc/connect.c (init_sockets): free addresses + + * kadmin/kadmin.c (main): make code more consistent. always free + configuration information. + + * kadmin/init.c (create_random_entry): free the entry + +Wed Mar 24 04:02:03 1999 Assar Westerlund <assar@sics.se> + + * lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): + re-organize the code to always free `kdc_reply' + + * lib/krb5/get_in_tkt.c (krb5_get_in_cred): be more careful about + freeing memory + + * lib/krb5/fcache.c (fcc_destroy): don't call fcc_close + + * lib/krb5/crypto.c (krb5_crypto_destroy): free `crypto' + + * lib/hdb/hdb_locl.h: try db_185.h first in case db.h is a DB 2.0 + header + + * configure.in (db_185.h): check for + + * admin/srvcreate.c: new file. contributed by Daniel Kouril + <kouril@informatics.muni.cz> + + * admin/ktutil.c: srvcreate: new command + + * kuser/klist.c: add support for printing AFS tokens + + * kuser/kdestroy.c: add support for destroying v4 tickets and AFS + tokens. based on code by Love <lha@stacken.kth.se> + + * kuser/Makefile.am (kdestroy_LDADD, klist_LDADD): more libraries + + * configure.in: sys/ioccom.h: test for + + * kuser/klist.c (main): don't print `no ticket file' with --test. + From: Love <lha@e.kth.se> + + * kpasswd/kpasswdd.c (doit): more braces to make gcc happy + + * kdc/connect.c (init_socket): get rid of a stupid warning + + * include/bits.c (my_strupr): cast away some stupid warnings + +Tue Mar 23 14:34:44 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/krb5/get_host_realm.c (krb5_get_host_realm): no infinite + loops, please + +Tue Mar 23 00:00:45 1999 Assar Westerlund <assar@sics.se> + + * lib/kadm5/Makefile.am (install_build_headers): recover from make + rewriting the names of the headers kludge to help solaris make + + * lib/krb5/Makefile.am: kludge to help solaris make + + * lib/hdb/Makefile.am: kludge to help solaris make + + * configure.in (LIB_kdb): make sure there's a -L option in here by + adding $(LIB_krb4) + + * lib/asn1/gen_glue.c (generate_2int, generate_int2): int -> + unsigned + + * configure.in (SunOS): set to a number KRB4, KRB5 conditionals: + remove the `dnl' to work around an automake flaw + +Sun Mar 21 15:08:49 1999 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/get_default_realm.c: char* -> krb5_realm + +Sun Mar 21 14:08:30 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * include/bits.c: <bind/bitypes.h> + + * lib/krb5/Makefile.am: create krb5-private.h + +Sat Mar 20 00:08:59 1999 Assar Westerlund <assar@sics.se> + + * configure.in (gethostname): remove duplicate + +Fri Mar 19 14:48:03 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/hdb/Makefile.am: add version-info + + * lib/gssapi/Makefile.am: add version-info + + * lib/asn1/Makefile.am: use $(x:y=z) make syntax; move check-der + to check_PROGRAMS + + * lib/Makefile.am: add 45 + + * lib/kadm5/Makefile.am: split in client and server libraries + (breaks shared libraries otherwise) + +Thu Mar 18 11:33:30 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * include/kadm5/Makefile.am: clean a lot of header files (since + automake lacks a clean-hook) + + * include/Makefile.am: clean a lot of header files (since automake + lacks a clean-hook) + + * lib/kadm5/Makefile.am: fix build-installation of headers + + * lib/krb5/Makefile.am: remove include_dir hack + + * lib/hdb/Makefile.am: remove include_dir hack + + * lib/asn1/Makefile.am: remove include_dir hack + + * include/Makefile.am: remove include_dir hack + + * doc/whatis.texi: define sub for html + + * configure.in: LIB_kdb, have_err_h, have_fnmatch_h, have_glob_h + + * lib/asn1/Makefile.am: der.h + + * kpasswd/kpasswdd.c: admin.h -> kadm5/admin.h + + * kdc/Makefile.am: remove junk + + * kadmin/Makefile.am: sl.a -> sl.la + + * appl/afsutil/Makefile.am: remove EXTRA_bin_PROGRAMS + + * admin/Makefile.am: sl.a -> sl.la + + * configure.in: condition KRB5; AC_CHECK_XAU + + * Makefile.am: include Makefile.am.common + + * include/kadm5/Makefile.am: include Makefile.am.common; don't + install headers from here + + * include/Makefile.am: include Makefile.am.common; don't install + headers from here + + * doc/Makefile.am: include Makefile.am.common + + * lib/krb5/Makefile.am: include Makefile.am.common + + * lib/kadm5/Makefile.am: include Makefile.am.common + + * lib/hdb/Makefile.am: include Makefile.am.common + + * lib/gssapi/Makefile.am: include Makefile.am.common + + * lib/asn1/Makefile.am: include Makefile.am.common + + * lib/Makefile.am: include Makefile.am.common + + * lib/45/Makefile.am: include Makefile.am.common + + * kuser/Makefile.am: include Makefile.am.common + + * kpasswd/Makefile.am: include Makefile.am.common + + * kdc/Makefile.am: include Makefile.am.common + + * kadmin/Makefile.am: include Makefile.am.common + + * appl/test/Makefile.am: include Makefile.am.common + + * appl/afsutil/Makefile.am: include Makefile.am.common + + * appl/Makefile.am: include Makefile.am.common + + * admin/Makefile.am: include Makefile.am.common + +Wed Mar 17 03:04:38 1999 Assar Westerlund <assar@sics.se> + + * lib/krb5/store.c (krb5_store_stringz): braces fix + + * lib/kadm5/get_s.c (kadm5_s_get_principal): braces fix + + * lib/kadm5/ent_setup.c (_kadm5_setup_entry): braces fix + + * kdc/connect.c (loop): braces fix + + * lib/krb5/config_file.c: cast to unsigned char to make is* happy + + * lib/krb5/log.c (krb5_addlog_dest): more braces to make gcc happy + + * lib/krb5/crypto.c (krb5_verify_checksum): rename C -> cksum to + be consistent + + * kadmin/util.c (timeval2str): more braces to make gcc happy + + * kadmin/load.c: cast in is* to get rid of stupid warning + + * kadmin/dump.c (append_hex): cast in isalnum to get rid of stupid + warning + + * kdc/kaserver.c: malloc checks and fixes + + * lib/krb5/get_host_realm.c (krb5_get_host_realm): include leading + dot (if any) when looking up realms. + +Fri Mar 12 13:57:56 1999 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/get_host_realm.c: add dns support + + * lib/krb5/set_default_realm.c: use krb5_free_host_realm + + * lib/krb5/free_host_realm.c: check for NULL realmlist + + * lib/krb5/context.c: don't print warning if there is no krb5.conf + +Wed Mar 10 19:29:46 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * configure.in: use AC_WFLAGS + +Mon Mar 8 11:49:43 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * Release 0.1c + + * kuser/klist.c: use print_version + + * kuser/kdestroy.c: use print_version + + * kdc/hpropd.c: use print_version + + * kdc/hprop.c: use print_version + + * kdc/config.c: use print_version + + * kadmin/kadmind.c: use print_version + + * kadmin/kadmin.c: use print_version + + * appl/test/common.c: use print_version + + * appl/afsutil/afslog.c: use print_version + +Mon Mar 1 10:49:14 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/krb5/get_addrs.c: SOCKADDR_HAS_SA_LEN -> + HAVE_STRUCT_SOCKADDR_SA_LEN + + * configure.in, acconfig.h, cf/*: update to automake 1.4/autoconf 2.13 + +Sun Feb 28 18:19:20 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/asn1/gen.c: make `BIT STRING's unsigned + + * lib/asn1/{symbol.h,gen.c}: add TUInteger type + + * lib/krb5/verify_user.c (krb5_verify_user): pass prompter to + krb5_get_init_creds_password + + * lib/krb5/fcache.c (fcc_gen_new): implement + +Sat Feb 27 22:41:23 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * doc/install.texi: krb4 is now automatically detected + + * doc/misc.texi: update procedure to set supported encryption + types + + * doc/setup.texi: change some silly wordings + +Sat Feb 27 22:17:30 1999 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/krb5/keytab.c (fkt_remove_entry): make this work + + * admin/ktutil.c: add minimally working `get' command + +Sat Feb 27 19:44:49 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * lib/hdb/convert_db.c: more typos + + * include/Makefile.am: remove EXTRA_DATA (as of autoconf + 2.13/automake 1.4) + + * appl/Makefile.am: OTP_dir + +Fri Feb 26 17:37:00 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * doc/setup.texi: add kadmin section + + * lib/asn1/check-der.c: fix printf warnings + +Thu Feb 25 11:16:49 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * configure.in: -O does not belong in WFLAGS + +Thu Feb 25 11:05:57 1999 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/asn1/der_put.c: fix der_put_int + +Tue Feb 23 20:35:12 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * configure.in: use AC_BROKEN_GLOB + +Mon Feb 22 15:12:44 1999 Johan Danielsson <joda@blubb.pdc.kth.se> + + * configure.in: check for glob + +Mon Feb 22 11:32:42 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * Release 0.1b + +Sat Feb 20 15:48:06 1999 Johan Danielsson <joda@blubb.pdc.kth.se> + + * lib/hdb/convert_db.c: convert DES3 keys to des3-cbc-sha1, and + des3-cbc-md5 + + * lib/krb5/crypto.c (DES3_string_to_key): make this actually do + what the draft said it should + + * lib/hdb/convert_db.c: little program for database conversion + + * lib/hdb/db.c (DB_open): try to open database w/o .db extension + + * lib/hdb/ndbm.c (NDBM_open): add test for database format + + * lib/hdb/db.c (DB_open): add test for database format + + * lib/asn1/gen_glue.c (generate_2int): don't depend on flags being + unsigned + + * lib/hdb/hdb.c: change `hdb_set_master_key' to take an + EncryptionKey, and add a new function `hdb_set_master_keyfile' to + do what `hdb_set_master_key' used to do + + * kdc/kstash.c: add `--convert-file' option to change keytype of + existing master key file + +Fri Feb 19 07:04:14 1999 Assar Westerlund <assar@squid.pdc.kth.se> + + * Release 0.1a + +Sat Feb 13 17:12:53 1999 Assar Westerlund <assar@sics.se> + + * lib/krb5/mk_safe.c (krb5_mk_safe): sizeof(buf) -> buf_size, buf + is now a `u_char *' + + * lib/krb5/get_in_tkt.c (krb5_init_etype): etypes are now `int' + + * lib/krb5/get_host_realm.c (krb5_get_host_realm): constize + orig_host + + (krb5_salttype_to_string): new function (RSA_MD5_DES_verify, + RSA_MD5_DES3_verify): initialize ret + + * lib/gssapi/init_sec_context.c (init_auth): remove unnecessary + gssapi_krb5_init. ask for KEYTYPE_DES credentials + + * kadmin/get.c (print_entry_long): print the keytypes and salts + available for the principal + + * configure.in (WFLAGS): add `-O' to catch unitialized variables + and such + (gethostname, mkstemp, getusershell, inet_aton): more tests + + * lib/hdb/hdb.h: update prototypes + + * configure.in: homogenize broken detection with krb4 + + * lib/kadm5/init_c.c (kadm5_c_init_with_context): remove unused + `error' + + * lib/asn1/Makefile.am (check-der): add + + * lib/asn1/gen.c (define_type): map ASN1 Integer to `int' instead + of `unsigned' + + * lib/asn1/der_length.c (length_unsigned): new function + (length_int): handle signed integers + + * lib/asn1/der_put.c (der_put_unsigned): new function + (der_put_int): handle signed integers + + * lib/asn1/der_get.c (der_get_unsigned): new function + (der_get_int): handle signed integers + + * lib/asn1/der.h: all integer functions take `int' instead of + `unsigned' + + * lib/asn1/lex.l (filename): unused. remove. + + * lib/asn1/check-der.c: new test program for der encoding and + decoding. + +Mon Feb 1 04:09:06 1999 Assar Westerlund <assar@sics.se> + + * lib/krb5/send_to_kdc.c (krb5_sendto_kdc): only call + gethostbyname2 with AF_INET6 if we actually have IPv6. From + "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net> + + * lib/krb5/changepw.c (get_kdc_address): dito + +Sun Jan 31 06:26:36 1999 Assar Westerlund <assar@sics.se> + + * kdc/connect.c (parse_prots): always bind to AF_INET, there are + v6-implementations without support for `mapped V4 addresses'. + From Jun-ichiro itojun Hagino <itojun@kame.net> + +Sat Jan 30 22:38:27 1999 Assar Westerlund <assar@juguete.sics.se> + + * Release 0.0u + +Sat Jan 30 13:43:02 1999 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: explicit rules for *.et files + + * lib/kadm5/init_c.c (get_kadm_ticket): only remove creds if + krb5_get_credentials was succesful. + (get_new_cache): return better error codes and return earlier. + (get_cred_cache): only delete default_client if it's different + from client + (kadm5_c_init_with_context): return a more descriptive error. + + * kdc/kerberos5.c (check_flags): handle NULL client or server + + * lib/krb5/sendauth.c (krb5_sendauth): return the error in + `ret_error' iff != NULL + + * lib/krb5/rd_error.c (krb5_free_error, krb5_free_error_contents): + new functions + + * lib/krb5/mk_req_ext.c (krb5_mk_req_extended): more + type-correctness + + * lib/krb5/krb5.h (krb5_error): typedef to KRB_ERROR + + * lib/krb5/init_creds_pw.c: KRB5_TGS_NAME: use + + * lib/krb5/get_cred.c: KRB5_TGS_NAME: use + + * lib/kafs/afskrb5.c (afslog_uid_int): update to changes + + * lib/kadm5/rename_s.c (kadm5_s_rename_principal): call remove + instead of rename, but shouldn't this just call rename? + + * lib/kadm5/get_s.c (kadm5_s_get_principal): always return an + error if the principal wasn't found. + + * lib/hdb/ndbm.c (NDBM_seq): unseal key + + * lib/hdb/db.c (DB_seq): unseal key + + * lib/asn1/Makefile.am: added explicit rules for asn1_err.[ch] + + * kdc/hprop.c (v4_prop): add krbtgt/THISREALM@OTHERREALM when + finding cross-realm tgts in the v4 database + + * kadmin/mod.c (mod_entry): check the number of arguments. check + that kadm5_get_principal worked. + + * lib/krb5/keytab.c (fkt_remove_entry): remove KRB5_KT_NOTFOUND if + we weren't able to remove it. + + * admin/ktutil.c: less drive-by-deleting. From Love + <lha@e.kth.se> + + * kdc/connect.c (parse_ports): copy the string before mishandling + it with strtok_r + + * kdc/kerberos5.c (tgs_rep2): print the principal with mismatching + kvnos + + * kadmin/kadmind.c (main): convert `debug_port' to network byte + order + + * kadmin/kadmin.c: allow specification of port number. + + * lib/kadm5/kadm5_locl.h (kadm5_client_context): add + `kadmind_port'. + + * lib/kadm5/init_c.c (_kadm5_c_init_context): move up + initalize_kadm5_error_table_r. + allow specification of port number. + + From Love <lha@stacken.kth.se> + + * kuser/klist.c: add option -t | --test + diff --git a/crypto/heimdal/ChangeLog.2000 b/crypto/heimdal/ChangeLog.2000 new file mode 100644 index 000000000000..a1cb687f550e --- /dev/null +++ b/crypto/heimdal/ChangeLog.2000 @@ -0,0 +1,1320 @@ +2000-12-31 Assar Westerlund <assar@sics.se> + + * lib/krb5/test_get_addrs.c (main): handle krb5_init_context + failure consistently + * lib/krb5/string-to-key-test.c (main): handle krb5_init_context + failure consistently + * lib/krb5/prog_setup.c (krb5_program_setup): handle + krb5_init_context failure consistently + * lib/hdb/convert_db.c (main): handle krb5_init_context failure + consistently + * kuser/kverify.c (main): handle krb5_init_context failure + consistently + * kuser/klist.c (main): handle krb5_init_context failure + consistently + * kuser/kinit.c (main): handle krb5_init_context failure + consistently + * kuser/kgetcred.c (main): handle krb5_init_context failure + consistently + * kuser/kdestroy.c (main): handle krb5_init_context failure + consistently + * kuser/kdecode_ticket.c (main): handle krb5_init_context failure + consistently + * kuser/generate-requests.c (generate_requests): handle + krb5_init_context failure consistently + * kpasswd/kpasswd.c (main): handle krb5_init_context failure + consistently + * kpasswd/kpasswd-generator.c (generate_requests): handle + krb5_init_context failure consistently + * kdc/main.c (main): handle krb5_init_context failure consistently + * appl/test/uu_client.c (proto): handle krb5_init_context failure + consistently + * appl/kf/kf.c (main): handle krb5_init_context failure + consistently + * admin/ktutil.c (main): handle krb5_init_context failure + consistently + + * admin/get.c (kt_get): more error checking + +2000-12-29 Assar Westerlund <assar@sics.se> + + * lib/asn1/asn1_print.c (loop): check for length longer than data. + inspired by lha@stacken.kth.se + +2000-12-16 Johan Danielsson <joda@pdc.kth.se> + + * admin/ktutil.8: reflect recent changes + + * admin/copy.c: don't copy an entry that already exists in the + keytab, and warn if the keyblock differs + +2000-12-15 Johan Danielsson <joda@pdc.kth.se> + + * admin/Makefile.am: merge srvconvert and srvcreate with copy + + * admin/copy.c: merge srvconvert and srvcreate with copy + + * lib/krb5/Makefile.am: always build keytab_krb4.c + + * lib/krb5/context.c: always register the krb4 keytab functions + + * lib/krb5/krb5.h: declare krb4_ftk_ops + + * lib/krb5/keytab_krb4.c: We don't really need to include krb.h + here, since we only use the principal size macros, so define these + here. Theoretically someone could have a krb4 system where these + values are != 40, but this is unlikely, and + krb5_524_conv_principal also assume they are 40. + +2000-12-13 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/krb5.h: s/krb5_donot_reply/krb5_donot_replay/ + + * lib/krb5/replay.c: fix query-replace-o from MD5 API change, and + the struct is called krb5_donot_replay + +2000-12-12 Assar Westerlund <assar@sics.se> + + * admin/srvconvert.c (srvconvert): do not use data after free:ing + it + +2000-12-11 Assar Westerlund <assar@sics.se> + + * Release 0.3d + +2000-12-11 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): set version to 14:0:0 + * lib/hdb/Makefile.am (libhdb_la_LDFLAGS): update to 6:3:0 + * lib/krb5/Makefile.am (libkrb5_la_LIBADD): add library + dependencies + +2000-12-10 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/auth_context.c: implement krb5_auth_con_{get,set}rcache + +2000-12-08 Assar Westerlund <assar@sics.se> + + * lib/krb5/krb5.h (krb5_enctype): add ETYPE_DES3_CBC_NONE_IVEC as + a new pseudo-type + + * lib/krb5/crypto.c (DES_AFS3_CMU_string_to_key): always treat + cell names as lower case + (krb5_encrypt_ivec, krb5_decrypt_ivec): new functions that allow an + explicit ivec to be specified. fix all sub-functions. + (DES3_CBC_encrypt_ivec): new function that takes an explicit ivec + +2000-12-06 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/Makefile.am: actually build replay cache code + + * lib/krb5/replay.c: implement krb5_get_server_rcache + + * kpasswd/kpasswdd.c: de-pointerise auth_context parameter to + krb5_mk_rep + + * lib/krb5/recvauth.c: de-pointerise auth_context parameter to + krb5_mk_rep + + * lib/krb5/mk_rep.c: auth_context should not be a pointer + + * lib/krb5/auth_context.c: implement krb5_auth_con_genaddrs, and + make setaddrs_from_fd use that + + * lib/krb5/krb5.h: add some more KRB5_AUTH_CONTEXT_* flags + +2000-12-05 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/Makefile.am: add kerberos.8 manpage + + * lib/krb5/cache.c: check for NULL remove_cred function + + * lib/krb5/fcache.c: pretend that empty files are non-existant + + * lib/krb5/get_addrs.c (find_all_addresses): use getifaddrs, from + Jason Thorpe <thorpej@netbsd.org> + +2000-12-01 Assar Westerlund <assar@sics.se> + + * configure.in: remove configure-time generation of krb5-config + * tools/Makefile.am: add generation of krb5-config at make-time + instead of configure-time + + * tools/krb5-config.in: add --prefix and --exec-prefix + +2000-11-30 Assar Westerlund <assar@sics.se> + + * tools/Makefile.am: add krb5-config.1 + * tools/krb5-config.in: add kadm-client and kadm5-server as + libraries + +2000-11-29 Assar Westerlund <assar@sics.se> + + * tools/krb5-config.in: add --prefix, --exec-prefix and gssapi + +2000-11-29 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: add roken/Makefile here, since it can't live in + rk_ROKEN + +2000-11-16 Assar Westerlund <assar@sics.se> + + * configure.in: use the libtool -rpath, do not rely on ld + understanding -rpath + + * configure.in: fix the -Wl stuff for krb4 linking add some + gratuitous extra options when linking with an existing libdes + +2000-11-15 Assar Westerlund <assar@sics.se> + + * lib/hdb/hdb.c (hdb_next_enctype2key): const-ize a little bit + * lib/Makefile.am (SUBDIRS): try to only build des when needed + * kuser/klist.c: print key versions numbers of v4 tickets in + verbose mode + + * kdc/kerberos5.c (tgs_rep2): adapt to new krb5_verify_ap_req2 + * appl/test/gss_common.c (read_token): remove unused variable + + * configure.in (krb4): add -Wl + (MD4Init et al): look for these in more libraries + (getmsg): only run test if we have the function + (AC_OUTPUT): create tools/krb5-config + + * tools/krb5-config.in: new script for storing flags to use + * Makefile.am (SUBDIRS): add tools + + * lib/krb5/get_cred.c (make_pa_tgs_req): update to new + krb5_mk_req_internal + * lib/krb5/mk_req_ext.c (krb5_mk_req_internal): allow different + usages for the encryption. change callers + * lib/krb5/rd_req.c (decrypt_authenticator): add an encryption + `usage'. also try the old + (and wrong) usage of KRB5_KU_AP_REQ_AUTH for backwards compatibility + (krb5_verify_ap_req2): new function for specifying the usage different + from the default (KRB5_KU_AP_REQ_AUTH) + * lib/krb5/build_auth.c (krb5_build_authenticator): add a `usage' + parameter to permit the generation of authenticators with + different crypto usage + + * lib/krb5/mk_req.c (krb5_mk_req_exact): new function that takes a + krb5_principal + (krb5_mk_req): use krb5_mk_req_exact + + * lib/krb5/mcache.c (mcc_close): free data + (mcc_destroy): don't free data + +2000-11-13 Assar Westerlund <assar@sics.se> + + * lib/hdb/ndbm.c: handle both ndbm.h and gdbm/ndbm.h + * lib/hdb/hdb.c: handle both ndbm.h and gdbm/ndbm.h + +2000-11-12 Johan Danielsson <joda@pdc.kth.se> + + * kdc/hpropd.8: remove extra .Xc + +2000-10-27 Johan Danielsson <joda@pdc.kth.se> + + * kuser/kinit.c: fix v4 fallback lifetime calculation + +2000-10-10 Johan Danielsson <joda@pdc.kth.se> + + * kdc/524.c: fix log messge + +2000-10-08 Assar Westerlund <assar@sics.se> + + * lib/krb5/changepw.c (krb5_change_password): check for fd's being + too large to select on + * kpasswd/kpasswdd.c (add_new_tcp): check for the socket fd being + too large to select on + * kdc/connect.c (add_new_tcp): check for the socket fd being too + large to selct on + * kdc/connect.c (loop): check that the socket fd is not too large + to select on + * lib/krb5/send_to_kdc.c (recv_loop): check `fd' for being too + large to be able to select on + + * kdc/kaserver.c (do_authenticate): check for time skew + +2000-10-01 Assar Westerlund <assar@sics.se> + + * kdc/524.c (set_address): allocate memory for storing addresses + in if the original request had an empty set of addresses + * kdc/524.c (set_address): fix bad return of pointer to automatic + data + + * config.sub: update to version 2000-09-11 (aka 1.181) from + subversions.gnu.org + + * config.guess: update to version 2000-09-05 (aka 1.156) from + subversions.gnu.org plus some minor tweaks + +2000-09-20 Assar Westerlund <assar@juguete.sics.se> + + * Release 0.3c + +2000-09-19 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): bump version to + 13:1:0 + + * lib/hdb/Makefile.am (libhdb_la_LDFLAGS): bump version to 6:2:0 + +2000-09-17 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_req.c (krb5_decrypt_ticket): plug some memory leak + (krb5_rd_req): try not to return an allocated auth_context on error + + * lib/krb5/log.c (krb5_vlog_msg): fix const-ness + +2000-09-10 Assar Westerlund <assar@sics.se> + + * kdc/524.c: re-organize + * kdc/kerberos5.c (tgs_rep2): try to avoid leaking auth_context + * kdc/kerberos4.c (valid_princ): check return value of functions + (encode_v4_ticket): add some const + * kdc/misc.c (db_fetch): check malloc + (free_ent): new function + + * lib/krb5/log.c (krb5_vlog_msg): log just the format string it we + fail to allocate the actual string to log, should at least provide + some hint as to where things went wrong + +2000-09-10 Johan Danielsson <joda@pdc.kth.se> + + * kdc/log.c: use DEFAULT_LOG_DEST + + * kdc/config.c: use _PATH_KDC_CONF + + * kdc/kdc_locl.h: add macro constants for kdc.conf, and kdc.log + +2000-09-09 Assar Westerlund <assar@sics.se> + + * lib/krb5/crypto.c (_key_schedule): re-use an existing schedule + +2000-09-06 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: fix dpagaix test + +2000-09-05 Assar Westerlund <assar@sics.se> + + * configure.in: with_dce -> enable_dce. noticed by Ake Sandgren + <ake@cs.umu.se> + +2000-09-01 Johan Danielsson <joda@pdc.kth.se> + + * kdc/kstash.8: update manual page + + * kdc/kstash.c: fix typo, and remove unused option + + * lib/krb5/kerberos.7: short kerberos intro page + +2000-08-27 Assar Westerlund <assar@sics.se> + + * include/bits.c: add __attribute__ for gcc's pleasure + * lib/hdb/keytab.c: re-write to delay the opening of the database + till it's known which principal is being sought, thereby allowing + the usage of multiple databases, however they need to be specified + in /etc/krb5.conf since all the programs using this keytab do not + read kdc.conf + + * appl/test/test_locl.h (keytab): add + * appl/test/common.c: add --keytab + * lib/krb5/crypto.c: remove trailing commas + (KRB5_KU_USAGE_SEQ): renamed from KRB5_KU_USAGE_MIC + +2000-08-26 Assar Westerlund <assar@sics.se> + + * lib/krb5/send_to_kdc.c (send_via_proxy): handle `http://' at the + beginning of the proxy specification. use getaddrinfo correctly + (krb5_sendto): always return a return code + + * lib/krb5/krb5.h (KRB5_KU_USAGE_MIC): rename to KRB5_KU_USAGE_SEQ + * lib/krb5/auth_context.c (krb5_auth_con_free): handle + auth_context == NULL + +2000-08-23 Assar Westerlund <assar@sics.se> + + * kdc/kerberos5.c (find_type): make sure of always setting + `ret_etype' correctly. clean-up structure some + +2000-08-23 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/mcache.c: implement resolve + +2000-08-18 Assar Westerlund <assar@sics.se> + + * kuser/kdecode_ticket.c: check return value from krb5_crypto_init + * kdc/kerberos5.c, kdc/524.c: check return value from krb5_crypto_init + * lib/krb5/*.c: check return value from krb5_crypto_init + +2000-08-16 Assar Westerlund <assar@sics.se> + + * Release 0.3b + +2000-08-16 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: bump version to 13:0:0 + + * lib/hdb/Makefile.am: set version to 6:1:0 + + * configure.in: do getmsg testing the same way as in krb4 + + * lib/krb5/config_file.c (krb5_config_parse_file_debug): make sure + of closing the file on error + + * lib/krb5/crypto.c (encrypt_internal_derived): free the checksum + after use + + * lib/krb5/warn.c (_warnerr): initialize args to make third, + purify et al happy + +2000-08-13 Assar Westerlund <assar@sics.se> + + * kdc/kerberos5.c: re-write search for keys code. loop over all + supported enctypes in order, looping over all keys of each type, + and picking the one with the v5 default salt preferably + +2000-08-10 Assar Westerlund <assar@sics.se> + + * appl/test/gss_common.c (enet_read): add and use + * lib/krb5/krb5.h (heimdal_version, heimdal_long_version): make + const + + * lib/krb5/mk_req_ext.c (krb5_mk_req_internal): add comment on + checksum type selection + + * lib/krb5/context.c (krb5_init_context): do not leak memory on + failure + (default_etypes): prefer arcfour-hmac-md5 to des-cbc-md5 + + * lib/krb5/principal.c: add fnmatch.h + +2000-08-09 Assar Westerlund <assar@sics.se> + + * configure.in: call AC_PROG_CC and AC_PROG_CPP to make sure later + checks that should require them don't fail + * acconfig.h: add HAVE_UINT17_T + +2000-08-09 Johan Danielsson <joda@pdc.kth.se> + + * kdc/mit_dump.c: handle all sorts of weird MIT salt types + +2000-08-08 Johan Danielsson <joda@pdc.kth.se> + + * doc/setup.texi: port 212 -> 2121 + + * lib/krb5/principal.c: krb5_principal_match + +2000-08-04 Johan Danielsson <joda@pdc.kth.se> + + * lib/asn1/der_get.c: add comment on *why* DCE sometimes used BER + encoding + + * kpasswd/Makefile.am: link with pidfile library + + * kpasswd/kpasswdd.c: write a pid file + + * kpasswd/kpasswd_locl.h: util.h + + * kdc/Makefile.am: link with pidfile library + + * kdc/main.c: write a pid file + + * kdc/headers.h: util.h + +2000-08-04 Assar Westerlund <assar@sics.se> + + * lib/krb5/principal.c (krb5_425_conv_principal_ext): always put + hostnames in lower case + (default_v4_name_convert): add imap + +2000-08-03 Assar Westerlund <assar@sics.se> + + * lib/krb5/crc.c (_krb5_crc_update): const-ize (finally) + +2000-07-31 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: check for uint*_t + * include/bits.c: define uint*_t + +2000-07-29 Assar Westerlund <assar@sics.se> + + * kdc/kerberos5.c (check_tgs_flags): set endtime correctly when + renewing, From Derrick J Brashear <shadow@dementia.org> + +2000-07-28 Assar Westerlund <assar@juguete.sics.se> + + * Release 0.3a + +2000-07-27 Assar Westerlund <assar@sics.se> + + * kdc/hprop.c (dump_database): write an empty message to signal + end of dump + +2000-07-26 Assar Westerlund <assar@sics.se> + + * lib/krb5/changepw.c (krb5_change_password): try to be more + careful when not to resend + + * lib/hdb/db3.c: always create a cursor with db3. From Derrick J + Brashear <shadow@dementia.org> + +2000-07-25 Johan Danielsson <joda@pdc.kth.se> + + * lib/hdb/Makefile.am: bump version to 6:0:0 + + * lib/asn1/Makefile.am: bump version to 3:0:1 + + * lib/krb5/Makefile.am: bump version to 12:0:1 + + * lib/krb5/krb5_config.3: manpage + + * lib/krb5/krb5_appdefault.3: manpage + + * lib/krb5/appdefault.c: implementation of the krb5_appdefault set + of functions + +2000-07-23 Assar Westerlund <assar@sics.se> + + * lib/krb5/init_creds_pw.c (change_password): reset forwardable + and proxiable. copy preauthentication list correctly from + supplied options + + * kdc/hpropd.c (main): check that the ticket was for `hprop/' for + paranoid reasons + + * lib/krb5/sock_principal.c (krb5_sock_to_principal): look in + aliases for the real name + +2000-07-22 Johan Danielsson <joda@pdc.kth.se> + + * doc/setup.texi: say something about starting kadmind from the + command line + +2000-07-22 Assar Westerlund <assar@sics.se> + + * kpasswd/kpasswdd.c: use kadm5_s_chpass_principal_cond instead of + mis-doing it here + + * lib/krb5/changepw.c (krb5_change_password): make timeout 1 + + 2^{0,1,...}. also keep track if we got an old packet back and + then just wait without sending a new packet + * lib/krb5/changepw.c: use a datagram socket and remove the + sequence numbers + * lib/krb5/changepw.c (krb5_change_password): clarify an + expression, avoiding a warning + +2000-07-22 Johan Danielsson <joda@pdc.kth.se> + + * kuser/klist.c: make -a and -n aliases for -v + + * lib/krb5/write_message.c: ws + + * kdc/hprop-common.c: nuke extra definitions of + krb5_read_priv_message et.al + + * lib/krb5/read_message.c (krb5_read_message): return error if EOF + +2000-07-20 Assar Westerlund <assar@sics.se> + + * kpasswd/kpasswd.c: print usage consistently + * kdc/hprop.h (HPROP_KEYTAB): use HDB for the keytab + * kdc/hpropd.c: add --keytab + * kdc/hpropd.c: don't care what principal we recvauth as + + * lib/krb5/get_cred.c: be more careful of not returning creds at + all when an error is returned + * lib/krb5/fcache.c (fcc_gen_new): do mkstemp correctly + +2000-07-19 Johan Danielsson <joda@pdc.kth.se> + + * fix-export: use autoreconf + + * configure.in: remove stuff that belong in roken, and remove some + obsolete constructs + +2000-07-18 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: fix some typos + + * appl/Makefile.am: dceutil*s* + + * missing: update to missing from automake 1.4a + +2000-07-17 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: try to get xlc flags from ibmcxx.cfg use + conditional for X use readline cf macro + + * configure.in: subst AIX compiler flags + +2000-07-15 Johan Danielsson <joda@pdc.kth.se> + + * configure.in: pass sixth parameter to test-package; use some + newer autoconf constructs + + * ltmain.sh: update to libtool 1.3c + + * ltconfig: update to libtool 1.3c + + * configure.in: update this to newer auto*/libtool + + * appl/Makefile.am: use conditional for dce + + * lib/Makefile.am: use conditional for dce + +2000-07-11 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/write_message.c: krb5_write_{priv,save}_message + * lib/krb5/read_message.c: krb5_read_{priv,save}_message + * lib/krb5/convert_creds.c: try port kerberos/88 if no response on + krb524/4444 + + * lib/krb5/convert_creds.c: use krb5_sendto + + * lib/krb5/send_to_kdc.c: add more generic krb5_sendto that send + to a port at arbitrary list of hosts + +2000-07-10 Johan Danielsson <joda@pdc.kth.se> + + * doc/misc.texi: language; say something about kadmin del_enctype + +2000-07-10 Assar Westerlund <assar@sics.se> + + * appl/kf/Makefile.am: actually install + +2000-07-08 Assar Westerlund <assar@sics.se> + + * configure.in (AM_INIT_AUTOMAKE): bump to 0.3a-pre + (AC_ROKEN): roken is now at 10 + + * lib/krb5/string-to-key-test.c: add a arcfour-hmac-md5 test case + * kdc/Makefile.am (INCLUDES): add ../lib/krb5 + * configure.in: update for standalone roken + * lib/Makefile.am (SUBDIRS): make roken conditional + * kdc/hprop.c: update to new hdb_seal_keys_mkey + * lib/hdb/mkey.c (_hdb_unseal_keys_int, _hdb_seal_keys_int): + rename and export them + + * kdc/headers.h: add krb5_locl.h (since we just use some stuff + from there) + +2000-07-08 Johan Danielsson <joda@pdc.kth.se> + + * kuser/klist.1: update for -f and add some more text for -v + + * kuser/klist.c: use rtbl to format cred listing, add -f and -s + + * lib/krb5/crypto.c: fix type in des3-cbc-none + + * lib/hdb/mkey.c: add key usage + + * kdc/kstash.c: remove writing of old keyfile, and treat + --convert-file as just reading and writing the keyfile without + asking for a new key + + * lib/hdb/mkey.c (read_master_encryptionkey): handle old keytype + based files, and convert the key to cfb64 + + * lib/hdb/mkey.c (hdb_read_master_key): set mkey to NULL before + doing anything else + + * lib/krb5/send_to_kdc.c: use krb5_eai_to_heim_errno + + * lib/krb5/get_for_creds.c: use krb5_eai_to_heim_errno + + * lib/krb5/changepw.c: use krb5_eai_to_heim_errno + + * lib/krb5/addr_families.c: use krb5_eai_to_heim_errno + + * lib/krb5/eai_to_heim_errno.c: convert getaddrinfo error codes to + something that can be passed to get_err_text + +2000-07-07 Assar Westerlund <assar@sics.se> + + * lib/hdb/hdb.c (hdb_next_enctype2key): make sure of skipping + `*key' + + * kdc/kerberos4.c (get_des_key): rewrite some, be more careful + +2000-07-06 Assar Westerlund <assar@sics.se> + + * kdc/kerberos5.c (as_rep): be careful as to now overflowing when + calculating the end of lifetime of a ticket. + + * lib/krb5/context.c (default_etypes): add ETYPE_ARCFOUR_HMAC_MD5 + + * lib/hdb/db3.c: only use a cursor when needed, from Derrick J + Brashear <shadow@dementia.org> + + * lib/krb5/crypto.c: introduce the `special' encryption methods + that are not like all other encryption methods and implement + arcfour-hmac-md5 + +2000-07-05 Johan Danielsson <joda@pdc.kth.se> + + * kdc/mit_dump.c: set initial master key version number to 0 + instead of 1; if we lated bump the mkvno we don't risk using the + wrong key to decrypt + + * kdc/hprop.c: only get master key if we're actually going to use + it; enable reading of MIT krb5 dump files + + * kdc/mit_dump.c: read MIT krb5 dump files + + * lib/hdb/mkey.c (read_master_mit): fix this + + * kdc/kstash.c: make this work with the new mkey code + + * lib/hdb/Makefile.am: add mkey.c, and bump version number + + * lib/hdb/hdb.h: rewrite master key handling + + * lib/hdb/mkey.c: rewrite master key handling + + * lib/krb5/crypto.c: add some more pseudo crypto types + + * lib/krb5/krb5.h: change some funny etypes to use negative + numbers, and add some more + +2000-07-04 Assar Westerlund <assar@sics.se> + + * lib/krb5/krbhst.c (get_krbhst): only try SRV lookup if there are + none in the configuration file + +2000-07-02 Assar Westerlund <assar@sics.se> + + * lib/krb5/keytab_keyfile.c (akf_add_entry): remove unused + variable + + * kpasswd/kpasswd-generator.c: new test program + * kpasswd/Makefile.am: add kpasswd-generator + + * include/Makefile.am (CLEANFILES): add rc4.h + + * kuser/generate-requests.c: new test program + * kuser/Makefile.am (noinst_PROGRAMS): add generate-requests + +2000-07-01 Assar Westerlund <assar@sics.se> + + * configure.in: add --enable-dce and related stuff + * appl/Makefile.am (SUBDIRS): add $(APPL_dce) + +2000-06-29 Assar Westerlund <assar@sics.se> + + * kdc/kerberos4.c (get_des_key): fix thinkos/typos + +2000-06-29 Johan Danielsson <joda@pdc.kth.se> + + * admin/purge.c: use parse_time to parse age + + * lib/krb5/log.c (krb5_vlog_msg): use krb5_format_time + + * admin/list.c: add printing of timestamp and key data; some + cleanup + + * lib/krb5/time.c (krb5_format_time): new function to format time + + * lib/krb5/context.c (init_context_from_config_file): init + date_fmt, also do some cleanup + + * lib/krb5/krb5.h: add date_fmt to context + +2000-06-28 Johan Danielsson <joda@pdc.kth.se> + + * kdc/{kerberos4,kaserver,524}.c (get_des_key): change to return + v4 or afs keys if possible + +2000-06-25 Johan Danielsson <joda@pdc.kth.se> + + * kdc/hprop.c (ka_convert): allow using null salt, and treat 0 + pw_expire as never (from Derrick Brashear) + +2000-06-24 Johan Danielsson <joda@pdc.kth.se> + + * kdc/connect.c (add_standard_ports): only listen to port 750 if + serving v4 requests + +2000-06-22 Assar Westerlund <assar@sics.se> + + * lib/asn1/lex.l: fix includes, and lex stuff + * lib/asn1/lex.h (error_message): update prototype + (yylex): add + * lib/asn1/gen_length.c (length_type): fail on malloc error + * lib/asn1/gen_decode.c (decode_type): fail on malloc error + +2000-06-21 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_for_creds.c: be more compatible with MIT code. + From Daniel Kouril <kouril@ics.muni.cz> + * lib/krb5/rd_cred.c: be more compatible with MIT code. From + Daniel Kouril <kouril@ics.muni.cz> + * kdc/kerberos5.c (get_pa_etype_info): do not set salttype if it's + vanilla pw-salt, that keeps win2k happy. also do the malloc check + correctly. From Daniel Kouril <kouril@ics.muni.cz> + +2000-06-21 Johan Danielsson <joda@pdc.kth.se> + + * kdc/hprop.c: add hdb keytabs + +2000-06-20 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/principal.c: back out rev. 1.64 + +2000-06-19 Johan Danielsson <joda@pdc.kth.se> + + * kdc/kerberos5.c: pa_* -> KRB5_PADATA_* + + * kdc/hpropd.c: add realm override flag + + * kdc/v4_dump.c: code for reading krb4 dump files + + * kdc/hprop.c: generalize source database handing, add support for + non-standard local realms (from by Daniel Kouril + <kouril@ics.muni.cz> and Miroslav Ruda <ruda@ics.muni.cz>), and + support for using different ports (requested by the Czechs, but + implemented differently) + + * lib/krb5/get_cred.c: pa_* -> KRB5_PADATA_* + + * lib/krb5/get_in_tkt.c: pa_* -> KRB5_PADATA_* + + * lib/krb5/krb5.h: use some definitions from asn1.h + + * lib/hdb/hdb.asn1: use new import syntax + + * lib/asn1/k5.asn1: use distinguished value integers + + * lib/asn1/gen_length.c: support for distinguished value integers + + * lib/asn1/gen_encode.c: support for distinguished value integers + + * lib/asn1/gen_decode.c: support for distinguished value integers + + * lib/asn1/gen.c: support for distinguished value integers + + * lib/asn1/lex.l: add support for more standards like import + statements + + * lib/asn1/parse.y: add support for more standards like import + statements, and distinguished value integers + +2000-06-11 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_for_creds.c (add_addrs): ignore addresses of + unknown type + * lib/krb5/get_for_creds.c (add_addrs): zero memory before + starting to copy memory + +2000-06-10 Assar Westerlund <assar@sics.se> + + * lib/krb5/test_get_addrs.c: test program for get_addrs + * lib/krb5/get_addrs.c (find_all_addresses): remember to add in + the size of ifr->ifr_name when using SA_LEN. noticed by Ken + Raeburn <raeburn@MIT.EDU> + +2000-06-07 Assar Westerlund <assar@sics.se> + + * configure.in: add db3 detection stuff do not use streamsptys on + HP-UX 11 + * lib/hdb/hdb.h (HDB): add dbc for db3 + * kdc/connect.c (add_standard_ports): also listen on krb524 aka + 4444 + * etc/services.append (krb524): add + * lib/hdb/db3.c: add berkeley db3 interface. contributed by + Derrick J Brashear <shadow@dementia.org> + * lib/hdb/hdb.h (struct HDB): add + +2000-06-07 Johan Danielsson <joda@pdc.kth.se> + + * kdc/524.c: if 524 is not enabled, just generate error reply and + exit + + * kdc/kerberos4.c: if v4 is not enabled, just generate error reply + and exit + + * kdc/connect.c: only listen to port 4444 if 524 is enabled + + * kdc/config.c: add options to enable/disable v4 and 524 requests + +2000-06-06 Johan Danielsson <joda@pdc.kth.se> + + * kdc/524.c: handle non-existant server principals (from Daniel + Kouril) + +2000-06-03 Assar Westerlund <assar@sics.se> + + * admin/ktutil.c: print name when failing to open keytab + + * kuser/kinit.c: try also to fallback to v4 when no KDC is found + +2000-05-28 Assar Westerlund <assar@sics.se> + + * kuser/klist.c: continue even we have no v5 ccache. make showing + your krb4 tickets the default (if build with krb4 support) + * kuser/kinit.c: add a fallback that tries to get a v4 ticket if + built with krb4 support and we got back a version error from the + KDC + +2000-05-23 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/keytab_keyfile.c: make this actually work + +2000-05-19 Assar Westerlund <assar@sics.se> + + * lib/krb5/store_emem.c (emem_store): make it write-compatible + * lib/krb5/store_fd.c (fd_store): make it write-compatible + * lib/krb5/store_mem.c (mem_store): make it write-compatible + * lib/krb5/krb5.h (krb5_storage): make store write-compatible + +2000-05-18 Assar Westerlund <assar@sics.se> + + * configure.in: add stdio.h in dbopen test + +2000-05-16 Assar Westerlund <assar@assaris.sics.se> + + * Release 0.2t + +2000-05-16 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): set version to 11:1:0 + * lib/krb5/fcache.c: fix second lseek + * lib/krb5/principal.c (krb5_524_conv_principal): fix typo + +2000-05-15 Assar Westerlund <assar@sics.se> + + * Release 0.2s + +2000-05-15 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): set version to 11:0:0 + * lib/hdb/Makefile.am (libhdb_la_LDFLAGS): set version to 4:2:1 + * lib/asn1/Makefile.am (libasn1_la_LDFLAGS): bump to 2:0:0 + * lib/krb5/principal.c (krb5_524_conv_principal): comment-ize, and + simplify string copying + +2000-05-12 Assar Westerlund <assar@sics.se> + + * lib/krb5/fcache.c (scrub_file): new function + (erase_file): re-write, use scrub_file + * lib/krb5/krb5.h (KRB5_DEFAULT_CCFILE_ROOT): add + + * configure.in (dbopen): add header files + + * lib/krb5/krb5.h (krb5_key_usage): add some more + * lib/krb5/fcache.c (erase_file): try to detect symlink games. + also call revoke. + * lib/krb5/changepw.c (krb5_change_password): remember to close + the socket on error + + * kdc/main.c (main): also call sigterm on SIGTERM + +2000-05-06 Assar Westerlund <assar@sics.se> + + * lib/krb5/config_file.c (krb5_config_vget_string_default, + krb5_config_get_string_default): add + +2000-04-25 Assar Westerlund <assar@sics.se> + + * lib/krb5/fcache.c (fcc_initialize): just forget about + over-writing the old cred cache. it's too much of a hazzle trying + to do this safely. + +2000-04-11 Assar Westerlund <assar@sics.se> + + * lib/krb5/crypto.c (krb5_get_wrapped_length): rewrite into + different parts for the derived and non-derived cases + * lib/krb5/crypto.c (krb5_get_wrapped_length): the padding should + be done after having added confounder and checksum + +2000-04-09 Assar Westerlund <assar@sics.se> + + * lib/krb5/get_addrs.c (find_all_addresses): apperently solaris + can return EINVAL when the buffer is too small. cope. + * lib/asn1/Makefile.am (gen_files): add asn1_UNSIGNED.x + * lib/asn1/gen_locl.h (filename): add prototype + (init_generate): const-ize + * lib/asn1/gen.c (filename): new function clean-up a little bit. + * lib/asn1/parse.y: be more tolerant in ranges + * lib/asn1/lex.l: count lines correctly. + (error_message): print filename in messages + +2000-04-08 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_safe.c (krb5_rd_safe): increment sequence number + after comparing + * lib/krb5/rd_priv.c (krb5_rd_priv): increment sequence number + after comparing + * lib/krb5/mk_safe.c (krb5_mk_safe): make `tmp_seq' unsigned + * lib/krb5/mk_priv.c (krb5_mk_priv): make `tmp_seq' unsigned + * lib/krb5/generate_seq_number.c (krb5_generate_seq_number): make + `seqno' be unsigned + * lib/krb5/mk_safe.c (krb5_mk_safe): increment local sequence + number after the fact and only increment it if we were successful + * lib/krb5/mk_priv.c (krb5_mk_priv): increment local sequence + number after the fact and only increment it if we were successful + * lib/krb5/krb5.h (krb5_auth_context_data): make sequence number + unsigned + + * lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): + `in_tkt_service' can be NULL + +2000-04-06 Assar Westerlund <assar@sics.se> + + * lib/asn1/parse.y: regonize INTEGER (0..UNIT_MAX). + (DOTDOT): add + * lib/asn1/lex.l (DOTDOT): add + * lib/asn1/k5.asn1 (UNSIGNED): add. use UNSIGNED for all sequence + numbers. + * lib/asn1/gen_length.c (length_type): add TUInteger + * lib/asn1/gen_free.c (free_type): add TUInteger + * lib/asn1/gen_encode.c (encode_type, generate_type_encode): add + TUInteger + * lib/asn1/gen_decode.c (decode_type, generate_type_decode): add + TUInteger + * lib/asn1/gen_copy.c (copy_type): add TUInteger + * lib/asn1/gen.c (define_asn1): add TUInteger + * lib/asn1/der_put.c (encode_unsigned): add + * lib/asn1/der_length.c (length_unsigned): add + * lib/asn1/der_get.c (decode_unsigned): add + * lib/asn1/der.h (decode_unsigned, encode_unsigned, + length_unsigned): add prototypes + + * lib/asn1/k5.asn1: update pre-authentication types + * lib/krb5/krb5_err.et: add some error codes from pkinit + +2000-04-05 Assar Westerlund <assar@sics.se> + + * lib/hdb/hdb.c: add support for hdb methods (aka back-ends). + include ldap. + * lib/hdb/hdb-ldap.c: tweak the ifdef to OPENLDAP + * lib/hdb/Makefile.am: add hdb-ldap.c and openldap + * kdc/Makefile.am, kpasswd/Makefile.am, kadmin/Makefile.am: add + * configure.in: bump version to 0.2s-pre add options and testing + for (open)ldap + +2000-04-04 Assar Westerlund <assar@sics.se> + + * configure.in (krb4): fix the krb_mk_req test + +2000-04-03 Assar Westerlund <assar@sics.se> + + * configure.in (krb4): add test for const arguments to krb_mk_req + * lib/45/mk_req.c (krb_mk_req): conditionalize const-ness of + arguments + +2000-04-03 Assar Westerlund <assar@sics.se> + + * Release 0.2r + +2000-04-03 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: set version to 10:0:0 + * lib/45/mk_req.c (krb_mk_req): const-ize the arguments + +2000-03-30 Assar Westerlund <assar@sics.se> + + * lib/krb5/principal.c (krb5_425_conv_principal_ext): add some + comments. add fall-back on adding the realm name in lower case. + +2000-03-29 Assar Westerlund <assar@sics.se> + + * kdc/connect.c: remember to repoint all descr->sa to _ss after + realloc as this might have moved the memory around. problem + discovered and diagnosed by Brandon S. Allbery + +2000-03-27 Assar Westerlund <assar@sics.se> + + * configure.in: recognize solaris 2.8 + * config.guess, config.sub: update to current version from + :pserver:anoncvs@subversions.gnu.org:/home/cvs + + * lib/krb5/init_creds_pw.c (print_expire): do not assume anything + about the size of time_t, i.e. make it 64-bit happy + +2000-03-13 Assar Westerlund <assar@sics.se> + + * kuser/klist.c: add support for display v4 tickets + +2000-03-11 Assar Westerlund <assar@sics.se> + + * kdc/kaserver.c (do_authenticate, do_getticket): call check_flags + * kdc/kerberos4.c (do_version4): call check_flags. + * kdc/kerberos5.c (check_flags): make global + +2000-03-10 Assar Westerlund <assar@sics.se> + + * lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): evil + hack to avoid recursion + +2000-03-04 Assar Westerlund <assar@sics.se> + + * kuser/kinit.c: add `krb4_get_tickets' per realm. add --anonymous + * lib/krb5/krb5.h (krb5_get_init_creds_opt): add `anonymous' and + KRB5_GET_INIT_CREDS_OPT_ANONYMOUS + * lib/krb5/init_creds_pw.c (get_init_creds_common): set + request_anonymous flag appropriatly + * lib/krb5/init_creds.c (krb5_get_init_creds_opt_set_anonymous): + add + + * lib/krb5/get_in_tkt.c (_krb5_extract_ticket): new parameter to + determine whetever to ignore client name of not. always copy + client name from kdc. fix callers. + + * kdc: add support for anonymous tickets + + * kdc/string2key.8: add man-page for string2key + +2000-03-03 Assar Westerlund <assar@sics.se> + + * kdc/hpropd.c (dump_krb4): get expiration date from `valid_end' + and not `pw_end' + + * kdc/kadb.h (ka_entry): fix name pw_end -> valid_end. add some + more fields + + * kdc/hprop.c (v4_prop): set the `valid_end' from the v4 + expiration date instead of the `pw_expire' + (ka_convert): set `valid_end' from ka expiration data and `pw_expire' + from pw_change + pw_expire + (main): add a default database for ka dumping + +2000-02-28 Assar Westerlund <assar@sics.se> + + * lib/krb5/context.c (init_context_from_config_file): change + rfc2052 default to no. 2782 says that underscore should be used. + +2000-02-24 Assar Westerlund <assar@sics.se> + + * lib/krb5/fcache.c (fcc_initialize, fcc_store_cred): verify that + stores and close succeed + * lib/krb5/store.c (krb5_store_creds): check to see that the + stores are succesful. + +2000-02-23 Assar Westerlund <assar@sics.se> + + * Release 0.2q + +2000-02-22 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: set version to 9:2:0 + + * lib/krb5/expand_hostname.c (krb5_expand_hostname_realms): copy + the correct hostname + + * kdc/connect.c (add_new_tcp): use the correct entries in the + descriptor table + * kdc/connect.c: initialize `descr' uniformly and correctly + +2000-02-20 Assar Westerlund <assar@sics.se> + + * Release 0.2p + +2000-02-19 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: set version to 9:1:0 + + * lib/krb5/expand_hostname.c (krb5_expand_hostname): make sure + that realms is filled in even when getaddrinfo fails or does not + return any canonical name + + * kdc/connect.c (descr): add sockaddr and string representation + (*): re-write to use the above mentioned + +2000-02-16 Assar Westerlund <assar@sics.se> + + * lib/krb5/addr_families.c (krb5_parse_address): use + krb5_sockaddr2address to copy the result from getaddrinfo. + +2000-02-14 Assar Westerlund <assar@sics.se> + + * Release 0.2o + +2000-02-13 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: set version to 9:0:0 + + * kdc/kaserver.c (do_authenticate): return the kvno of the server + and not the client. Thanks to Brandon S. Allbery KF8NH + <allbery@kf8nh.apk.net> and Chaskiel M Grundman + <cg2v@andrew.cmu.edu> for debugging. + + * kdc/kerberos4.c (do_version4): if an tgs-req is received with an + old kvno, return an error reply and write a message in the log. + +2000-02-12 Assar Westerlund <assar@sics.se> + + * appl/test/gssapi_server.c (proto): with `--fork', create a child + and send over/receive creds with export/import_sec_context + * appl/test/gssapi_client.c (proto): with `--fork', create a child + and send over/receive creds with export/import_sec_context + * appl/test/common.c: add `--fork' / `-f' (only used by gssapi) + +2000-02-11 Assar Westerlund <assar@sics.se> + + * kdc/kdc_locl.h: remove keyfile add explicit_addresses + * kdc/connect.c (init_sockets): pay attention to + explicit_addresses some more comments. better error messages. + * kdc/config.c: add some comments. + remove --key-file. + add --addresses. + + * lib/krb5/context.c (krb5_set_extra_addresses): const-ize and use + proper abstraction + +2000-02-07 Johan Danielsson <joda@pdc.kth.se> + + * lib/krb5/changepw.c: use roken_getaddrinfo_hostspec + +2000-02-07 Assar Westerlund <assar@sics.se> + + * Release 0.2n + +2000-02-07 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: set version to 8:0:0 + * lib/krb5/keytab.c (krb5_kt_default_name): use strlcpy + (krb5_kt_add_entry): set timestamp + +2000-02-06 Assar Westerlund <assar@sics.se> + + * lib/krb5/krb5.h: add macros for accessing krb5_realm + * lib/krb5/time.c (krb5_timeofday): use `krb5_timestamp' instead + of `int32_t' + + * lib/krb5/replay.c (checksum_authenticator): update to new API + for md5 + + * lib/krb5/krb5.h: remove des.h, it's not needed and applications + should not have to make sure to find it. + +2000-02-03 Assar Westerlund <assar@sics.se> + + * lib/krb5/rd_req.c (get_key_from_keytab): rename parameter to + `out_key' to avoid conflicting with label. reported by Sean Doran + <smd@ebone.net> + +2000-02-02 Assar Westerlund <assar@sics.se> + + * lib/krb5/expand_hostname.c: remember to lower-case host names. + bug reported by <amu@mit.edu> + + * kdc/kerberos4.c (do_version4): look at check_ticket_addresses + and emulate that by setting krb_ignore_ip_address (not a great + interface but it doesn't seem like the time to go around fixing + libkrb stuff now) + +2000-02-01 Johan Danielsson <joda@pdc.kth.se> + + * kuser/kinit.c: change --noaddresses into --no-addresses + +2000-01-28 Assar Westerlund <assar@sics.se> + + * kpasswd/kpasswd.c (main): make sure the ticket is not + forwardable and not proxiable + +2000-01-26 Assar Westerlund <assar@sics.se> + + * lib/krb5/crypto.c: update to pseudo-standard APIs for + md4,md5,sha. some changes to libdes calls to make them more + portable. + +2000-01-21 Assar Westerlund <assar@sics.se> + + * lib/krb5/verify_init.c (krb5_verify_init_creds): make sure to + clean up the correct creds. + +2000-01-16 Assar Westerlund <assar@sics.se> + + * lib/krb5/principal.c (append_component): change parameter to + `const char *'. check malloc + * lib/krb5/principal.c (append_component, va_ext_princ, va_princ): + const-ize + * lib/krb5/mk_req.c (krb5_mk_req): make `service' and `hostname' + const + * lib/krb5/principal.c (replace_chars): also add space here + * lib/krb5/principal.c: (quotable_chars): add space + +2000-01-12 Assar Westerlund <assar@sics.se> + + * kdc/kerberos4.c (do_version4): check if preauth was required and + bail-out if so since there's no way that could be done in v4. + Return NULL_KEY as an error to the client (which is non-obvious, + but what can you do?) + +2000-01-09 Assar Westerlund <assar@sics.se> + + * lib/krb5/principal.c (krb5_sname_to_principal): use + krb5_expand_hostname_realms + * lib/krb5/mk_req.c (krb5_km_req): use krb5_expand_hostname_realms + * lib/krb5/expand_hostname.c (krb5_expand_hostname_realms): new + variant of krb5_expand_hostname that tries until it expands into + something that's digestable by krb5_get_host_realm, returning also + the result from that function. + +2000-01-08 Assar Westerlund <assar@sics.se> + + * Release 0.2m + +2000-01-08 Assar Westerlund <assar@sics.se> + + * configure.in: replace AC_C_BIGENDIAN with KRB_C_BIGENDIAN + + * lib/krb5/Makefile.am: bump version to 7:1:0 + + * lib/krb5/principal.c (krb5_sname_to_principal): use + krb5_expand_hostname + * lib/krb5/expand_hostname.c (krb5_expand_hostname): handle + ai_canonname being set in any of the addresses returnedby + getaddrinfo. glibc apparently returns the reverse lookup of every + address in ai_canonname. + +2000-01-06 Assar Westerlund <assar@sics.se> + + * Release 0.2l + +2000-01-06 Assar Westerlund <assar@sics.se> + + * lib/krb5/Makefile.am: set version to 7:0:0 + * lib/krb5/principal.c (krb5_sname_to_principal): remove `hp' + + * lib/hdb/Makefile.am: set version to 4:1:1 + + * kdc/hpropd.c (dump_krb4): use `krb5_get_default_realms' + * lib/krb5/get_in_tkt.c (add_padata): change types to make + everything work out + (krb5_get_in_cred): remove const to make types match + * lib/krb5/crypto.c (ARCFOUR_string_to_key): correct signature + * lib/krb5/principal.c (krb5_sname_to_principal): handle not + getting back a canonname + +2000-01-06 Assar Westerlund <assar@sics.se> + + * Release 0.2k + +2000-01-06 Assar Westerlund <assar@sics.se> + + * lib/krb5/send_to_kdc.c (krb5_sendto_kdc): advance colon so that + we actually parse the port number. based on a patch from Leif + Johansson <leifj@it.su.se> + +2000-01-02 Assar Westerlund <assar@sics.se> + + * admin/purge.c: remove all non-current and old entries from a + keytab + + * admin: break up ktutil.c into files + + * admin/ktutil.c (list): support --verbose (also listning time + stamps) + (kt_add, kt_get): set timestamp in newly created entries + (kt_change): add `change' command + + * admin/srvconvert.c (srvconv): set timestamp in newly created + entries + * lib/krb5/keytab_keyfile.c (akf_next_entry): set timetsamp, + always go the a predicatble position on error + * lib/krb5/keytab.c (krb5_kt_copy_entry_contents): copy timestamp + * lib/krb5/keytab_file.c (fkt_add_entry): store timestamp + (fkt_next_entry_int): return timestamp + * lib/krb5/krb5.h (krb5_keytab_entry): add timestamp diff --git a/crypto/heimdal/README b/crypto/heimdal/README new file mode 100644 index 000000000000..f27b67f912b5 --- /dev/null +++ b/crypto/heimdal/README @@ -0,0 +1,19 @@ +$Id: README,v 1.1 2000/07/27 02:33:54 assar Exp $ + +Heimdal is a Kerberos 5 implementation. + +Please see the manual in doc, by default installed in +/usr/heimdal/info/heimdal.info for information on how to install. +There are also briefer man pages for most of the commands. + +Bug reports and bugs are appreciated, see more under Bug reports in +the manual on how we prefer them. + +For more information see the web-page at +<http://www.pdc.kth.se/heimdal/> or the mailing lists: + +heimdal-announce@sics.se low-volume announcement +heimdal-discuss@sics.se high-volume discussion + +send a mail to heimdal-announce-request@sics.se and +heimdal-discuss-request@sics.se respectively to subscribe. diff --git a/crypto/heimdal/appl/kf/kf.1 b/crypto/heimdal/appl/kf/kf.1 new file mode 100644 index 000000000000..27ca59f54e6f --- /dev/null +++ b/crypto/heimdal/appl/kf/kf.1 @@ -0,0 +1,92 @@ +.\" Things to fix: +.\" * correct section, and operating system +.\" * remove Op from mandatory flags +.\" * use better macros for arguments (like .Pa for files) +.\" +.Dd July 2, 2000 +.Dt KF 1 +.Os Heimdal +.Sh NAME +.Nm kf +.Nd +securly forward tickets +.Sh SYNOPSIS +.Nm +.Oo Fl p Ar port \*(Ba Xo +.Fl -port= Ns Ar port Oc +.Xc +.Oo Fl l Ar login \*(Ba Xo +.Fl -login= Ns Ar login Oc +.Xc +.Oo Fl c Ar ccache \*(Ba Xo +.Fl -ccache= Ns Ar ccache Oc +.Xc +.Op Fl F | Fl -forwardable +.Op Fl G | Fl -no-forwardable +.Op Fl h | Fl -help +.Op Fl -version +.Ar host ... +.Sh DESCRIPTION +The +.Nm +program forwards tickets to a remove host through an authenticated +and encrypted stream. Options supported are: +.Bl -tag -width Ds +.It Xo +.Fl p Ar port Ns , +.Fl -port= Ns Ar port +.Xc +port to connect to +.It Xo +.Fl l Ar login Ns , +.Fl -login= Ns Ar login +.Xc +remote login name +.It Xo +.Fl c Ar ccache Ns , +.Fl -ccache= Ns Ar ccache +.Xc +remote cred cache +.It Xo +.Fl F Ns , +.Fl -forwardable +.Xc +forward forwardable credentials +.It Xo +.Fl G Ns , +.Fl -no-forwardable +.Xc +do not forward forwardable credentials +.It Xo +.Fl h Ns , +.Fl -help +.Xc +.It Xo +.Fl -version +.Xc +.El +.Pp +.Nm +is useful when you do not want to enter your password on a remote host +but want to have your tickets one for example afs. +.Pp +In order for +.Nm +to work you will need to acquire your initial ticket with forwardable +flag, ie +.Nm kinit Fl -forwardable . +.Pp +.Nm telnet +is able to forward ticket by itself. +.\".Sh ENVIRONMENT +.\".Sh FILES +.\".Sh EXAMPLES +.\".Sh DIAGNOSTICS +.Sh SEE ALSO +.Xr kfd 8 , +.Xr kinit 1 , +.Xr telnet 1 +.\".Sh STANDARDS +.\".Sh HISTORY +.\".Sh AUTHORS +.\".Sh BUGS diff --git a/crypto/heimdal/appl/kf/kfd.8 b/crypto/heimdal/appl/kf/kfd.8 new file mode 100644 index 000000000000..3fca73bc9cd4 --- /dev/null +++ b/crypto/heimdal/appl/kf/kfd.8 @@ -0,0 +1,59 @@ +.\" Things to fix: +.\" * correct section, and operating system +.\" * remove Op from mandatory flags +.\" * use better macros for arguments (like .Pa for files) +.\" +.Dd July 2, 2000 +.Dt KFD 8 +.Os Heimdal +.Sh NAME +.Nm kfd +.Nd +receive forwarded tickets +.Sh SYNOPSIS +.Nm +.Oo Fl p Ar port \*(Ba Xo +.Fl -port= Ns Ar port Oc +.Xc +.Op Fl i | Fl -inetd +.Oo Fl R Ar regpag \*(Ba Xo +.Fl -regpag= Ns Ar regpag Oc +.Xc +.Op Fl h | Fl -help +.Op Fl -version +.Sh DESCRIPTION +This is the daemon for +.Nm kf . +Supported options: +.Bl -tag -width Ds +.It Xo +.Fl p Ar port Ns , +.Fl -port= Ns Ar port +.Xc +port to listen to +.It Xo +.Fl i Ns , +.Fl -inetd +.Xc +not started from inetd +.It Xo +.Fl R Ar regpag Ns , +.Fl -regpag= Ns Ar regpag +.Xc +path to regpag binary +.El +.\".Sh ENVIRONMENT +.\".Sh FILES +.Sh EXAMPLES +Put the following in +.Pa /etc/inetd.conf : +.Bd -literal +kf stream tcp nowait root /usr/heimdal/libexec/kfd kfd +.Ed +.\".Sh DIAGNOSTICS +.Sh SEE ALSO +.Xr kf 1 +.\".Sh STANDARDS +.\".Sh HISTORY +.\".Sh AUTHORS +.\".Sh BUGS diff --git a/crypto/heimdal/appl/login/env.c b/crypto/heimdal/appl/login/env.c new file mode 100644 index 000000000000..57f68b1c9a6c --- /dev/null +++ b/crypto/heimdal/appl/login/env.c @@ -0,0 +1,98 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "login_locl.h" +RCSID("$Id: env.c,v 1.1 2000/06/28 12:27:38 joda Exp $"); + +/* + * the environment we will send to execle and the shell. + */ + +char **env; +int num_env; + +void +extend_env(char *str) +{ + env = realloc(env, (num_env + 1) * sizeof(*env)); + if(env == NULL) + errx(1, "Out of memory!"); + env[num_env++] = str; +} + +void +add_env(const char *var, const char *value) +{ + int i; + char *str; + asprintf(&str, "%s=%s", var, value); + if(str == NULL) + errx(1, "Out of memory!"); + for(i = 0; i < num_env; i++) + if(strncmp(env[i], var, strlen(var)) == 0 && + env[i][strlen(var)] == '='){ + free(env[i]); + env[i] = str; + return; + } + + extend_env(str); +} + +void +copy_env(void) +{ + char **p; + for(p = environ; *p; p++) + extend_env(*p); +} + +int +login_read_env(const char *file) +{ + char **newenv; + char *p; + int i, j; + + newenv = NULL; + i = read_environment(file, &newenv); + for (j = 0; j < i; j++) { + p = strchr(newenv[j], '='); + *p++ = 0; + add_env(newenv[j], p); + *--p = '='; + free(newenv[j]); + } + free(newenv); + return 0; +} diff --git a/crypto/heimdal/appl/push/pfrom.1 b/crypto/heimdal/appl/push/pfrom.1 new file mode 100644 index 000000000000..c04d1116c19e --- /dev/null +++ b/crypto/heimdal/appl/push/pfrom.1 @@ -0,0 +1,25 @@ +.\" $Id: pfrom.1,v 1.2 2000/11/29 18:26:27 joda Exp $ +.\" +.Dd Mars 4, 2000 +.Dt PFROM 1 +.Os HEIMDAL +.Sh NAME +.Nm pfrom +.Nd +fetch a list of the current mail via POP +.Sh SYNOPSIS +.Nm +.Op Fl 4 | Fl -krb4 +.Op Fl 5 | Fl -krb5 +.Op Fl v | Fl -verbose +.Op Fl c | -count +.Op Fl -header +.Oo Fl p Ar port-spec \*(Ba Xo +.Fl -port= Ns Ar port-spec +.Xc +.Oc +.Sh DESCRIPTION +.Nm +is a script that does push --from. +.Sh SEE ALSO +.Xr push 8 diff --git a/crypto/heimdal/appl/rcp/ChangeLog b/crypto/heimdal/appl/rcp/ChangeLog new file mode 100644 index 000000000000..06850618f1e2 --- /dev/null +++ b/crypto/heimdal/appl/rcp/ChangeLog @@ -0,0 +1,29 @@ +2001-01-29 Assar Westerlund <assar@sics.se> + + * util.c (roundup): add fallback definition + + * rcp.c: remove non-STDC code + * rcp_locl.h: add sys/types.h and sys/wait.h + + * rcp.c: no calls to err with NULL + +2001-01-28 Assar Westerlund <assar@sics.se> + + * rcp_locl.h: add + + * Makefile.am (LDADD): remove unused libraries + +2001-01-27 Assar Westerlund <assar@sics.se> + + * util.c: replace vfork by fork + + * rcp.c: add RCSID S_ISTXT -> S_ISVTX printf sizes of files with + %lu instead of %q (which is not portable) + + * util.c: add RCSID do not use sig_t + * rcp.c: remove __P, use st_mtime et al from struct stat + * extern.h: remove __P + + * initial import of port of bsd rcp changed to use existing rsh, + contributed by Richard Nyberg <rnyberg@it.su.se> + diff --git a/crypto/heimdal/appl/rcp/Makefile.am b/crypto/heimdal/appl/rcp/Makefile.am new file mode 100644 index 000000000000..4ecf7a63b0f6 --- /dev/null +++ b/crypto/heimdal/appl/rcp/Makefile.am @@ -0,0 +1,11 @@ +# $Id: Makefile.am,v 1.2 2001/01/28 22:50:35 assar Exp $ + +include $(top_srcdir)/Makefile.am.common + +INCLUDES += $(INCLUDE_krb4) + +bin_PROGRAMS = rcp + +rcp_SOURCES = rcp.c util.c + +LDADD = $(LIB_roken) diff --git a/crypto/heimdal/appl/rcp/Makefile.in b/crypto/heimdal/appl/rcp/Makefile.in new file mode 100644 index 000000000000..f0ee15107a76 --- /dev/null +++ b/crypto/heimdal/appl/rcp/Makefile.in @@ -0,0 +1,559 @@ +# Makefile.in generated automatically by automake 1.4a from Makefile.am + +# Copyright (C) 1994, 1995-9, 2000 Free Software Foundation, Inc. +# This Makefile.in is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY, to the extent permitted by law; without +# even the implied warranty of MERCHANTABILITY or FITNESS FOR A +# PARTICULAR PURPOSE. + +SHELL = @SHELL@ + +srcdir = @srcdir@ +top_srcdir = @top_srcdir@ +VPATH = @srcdir@ +prefix = @prefix@ +exec_prefix = @exec_prefix@ + +bindir = @bindir@ +sbindir = @sbindir@ +libexecdir = @libexecdir@ +datadir = @datadir@ +sysconfdir = @sysconfdir@ +sharedstatedir = @sharedstatedir@ +localstatedir = @localstatedir@ +libdir = @libdir@ +infodir = @infodir@ +mandir = @mandir@ +includedir = @includedir@ +oldincludedir = /usr/include + +pkgdatadir = $(datadir)/@PACKAGE@ +pkglibdir = $(libdir)/@PACKAGE@ +pkgincludedir = $(includedir)/@PACKAGE@ + +top_builddir = ../.. + +ACLOCAL = @ACLOCAL@ +AUTOCONF = @AUTOCONF@ +AUTOMAKE = @AUTOMAKE@ +AUTOHEADER = @AUTOHEADER@ + +INSTALL = @INSTALL@ +INSTALL_PROGRAM = @INSTALL_PROGRAM@ +INSTALL_DATA = @INSTALL_DATA@ +INSTALL_SCRIPT = @INSTALL_SCRIPT@ +INSTALL_STRIP_FLAG = +transform = @program_transform_name@ + +NORMAL_INSTALL = : +PRE_INSTALL = : +POST_INSTALL = : +NORMAL_UNINSTALL = : +PRE_UNINSTALL = : +POST_UNINSTALL = : + +@SET_MAKE@ +host_alias = @host_alias@ +host_triplet = @host@ +AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@ +AMDEP = @AMDEP@ +AMTAR = @AMTAR@ +AS = @AS@ +AWK = @AWK@ +CANONICAL_HOST = @CANONICAL_HOST@ +CATMAN = @CATMAN@ +CATMANEXT = @CATMANEXT@ +CC = @CC@ +CPP = @CPP@ +CXX = @CXX@ +CXXCPP = @CXXCPP@ +DBLIB = @DBLIB@ +DEPDIR = @DEPDIR@ +DIR_des = @DIR_des@ +DIR_roken = @DIR_roken@ +DLLTOOL = @DLLTOOL@ +EXEEXT = @EXEEXT@ +EXTRA_LIB45 = @EXTRA_LIB45@ +GROFF = @GROFF@ +INCLUDES_roken = @INCLUDES_roken@ +INCLUDE_ = @INCLUDE_@ +LEX = @LEX@ +LIBOBJS = @LIBOBJS@ +LIBTOOL = @LIBTOOL@ +LIB_ = @LIB_@ +LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@ +LIB_des = @LIB_des@ +LIB_des_appl = @LIB_des_appl@ +LIB_kdb = @LIB_kdb@ +LIB_otp = @LIB_otp@ +LIB_roken = @LIB_roken@ +LIB_security = @LIB_security@ +LN_S = @LN_S@ +LTLIBOBJS = @LTLIBOBJS@ +MAKEINFO = @MAKEINFO@ +NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@ +NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@ +NROFF = @NROFF@ +OBJDUMP = @OBJDUMP@ +OBJEXT = @OBJEXT@ +PACKAGE = @PACKAGE@ +RANLIB = @RANLIB@ +STRIP = @STRIP@ +VERSION = @VERSION@ +VOID_RETSIGTYPE = @VOID_RETSIGTYPE@ +WFLAGS = @WFLAGS@ +WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@ +WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@ +YACC = @YACC@ +dpagaix_CFLAGS = @dpagaix_CFLAGS@ +dpagaix_LDADD = @dpagaix_LDADD@ +install_sh = @install_sh@ + +# $Id: Makefile.am,v 1.2 2001/01/28 22:50:35 assar Exp $ + + +# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $ + + +# $Id: Makefile.am.common,v 1.23 2000/12/05 09:11:09 joda Exp $ + + +AUTOMAKE_OPTIONS = foreign no-dependencies + +SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x + +INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken) $(INCLUDE_krb4) + +AM_CFLAGS = $(WFLAGS) + +CP = cp + +COMPILE_ET = $(top_builddir)/lib/com_err/compile_et + +buildinclude = $(top_builddir)/include + +LIB_XauReadAuth = @LIB_XauReadAuth@ +LIB_crypt = @LIB_crypt@ +LIB_dbm_firstkey = @LIB_dbm_firstkey@ +LIB_dbopen = @LIB_dbopen@ +LIB_dlopen = @LIB_dlopen@ +LIB_dn_expand = @LIB_dn_expand@ +LIB_el_init = @LIB_el_init@ +LIB_getattr = @LIB_getattr@ +LIB_gethostbyname = @LIB_gethostbyname@ +LIB_getpwent_r = @LIB_getpwent_r@ +LIB_getpwnam_r = @LIB_getpwnam_r@ +LIB_getsockopt = @LIB_getsockopt@ +LIB_logout = @LIB_logout@ +LIB_logwtmp = @LIB_logwtmp@ +LIB_odm_initialize = @LIB_odm_initialize@ +LIB_pidfile = @LIB_pidfile@ +LIB_readline = @LIB_readline@ +LIB_res_search = @LIB_res_search@ +LIB_setpcred = @LIB_setpcred@ +LIB_setsockopt = @LIB_setsockopt@ +LIB_socket = @LIB_socket@ +LIB_syslog = @LIB_syslog@ +LIB_tgetent = @LIB_tgetent@ + +LIBS = @LIBS@ + +HESIODLIB = @HESIODLIB@ +HESIODINCLUDE = @HESIODINCLUDE@ +INCLUDE_hesiod = @INCLUDE_hesiod@ +LIB_hesiod = @LIB_hesiod@ + +INCLUDE_krb4 = @INCLUDE_krb4@ +LIB_krb4 = @LIB_krb4@ + +INCLUDE_openldap = @INCLUDE_openldap@ +LIB_openldap = @LIB_openldap@ + +INCLUDE_readline = @INCLUDE_readline@ + +LEXLIB = @LEXLIB@ + +NROFF_MAN = groff -mandoc -Tascii + +@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS) + +@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \ +@KRB5_TRUE@ $(top_builddir)/lib/asn1/libasn1.la +@KRB5_TRUE@LIB_gssapi = @KRB5_TRUE@$(top_builddir)/lib/gssapi/libgssapi.la + +CHECK_LOCAL = $(PROGRAMS) + +bin_PROGRAMS = rcp + +rcp_SOURCES = rcp.c util.c + +LDADD = $(LIB_roken) +subdir = appl/rcp +mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs +CONFIG_HEADER = ../../include/config.h +CONFIG_CLEAN_FILES = +bin_PROGRAMS = rcp$(EXEEXT) +PROGRAMS = $(bin_PROGRAMS) + + +DEFS = @DEFS@ -I. -I$(srcdir) -I../../include +CPPFLAGS = @CPPFLAGS@ +LDFLAGS = @LDFLAGS@ +X_CFLAGS = @X_CFLAGS@ +X_LIBS = @X_LIBS@ +X_EXTRA_LIBS = @X_EXTRA_LIBS@ +X_PRE_LIBS = @X_PRE_LIBS@ +am_rcp_OBJECTS = rcp.$(OBJEXT) util.$(OBJEXT) +rcp_OBJECTS = $(am_rcp_OBJECTS) +rcp_LDADD = $(LDADD) +rcp_DEPENDENCIES = +rcp_LDFLAGS = +COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +CFLAGS = @CFLAGS@ +CCLD = $(CC) +LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ +DIST_SOURCES = $(rcp_SOURCES) +depcomp = +DIST_COMMON = ChangeLog Makefile.am Makefile.in + + +DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) + +GZIP_ENV = --best +SOURCES = $(rcp_SOURCES) +OBJECTS = $(am_rcp_OBJECTS) + +all: all-redirect +.SUFFIXES: +.SUFFIXES: .1 .3 .5 .8 .c .cat1 .cat3 .cat5 .cat8 .et .h .lo .o .obj .x +$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4) $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common + cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/rcp/Makefile + +Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status + cd $(top_builddir) \ + && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status + + +mostlyclean-binPROGRAMS: + +clean-binPROGRAMS: + -test -z "$(bin_PROGRAMS)" || rm -f $(bin_PROGRAMS) + +distclean-binPROGRAMS: + +maintainer-clean-binPROGRAMS: + +install-binPROGRAMS: $(bin_PROGRAMS) + @$(NORMAL_INSTALL) + $(mkinstalldirs) $(DESTDIR)$(bindir) + @list='$(bin_PROGRAMS)'; for p in $$list; do \ + if test -f $$p; then \ + f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \ + echo " $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f"; \ + $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f; \ + else :; fi; \ + done + +uninstall-binPROGRAMS: + @$(NORMAL_UNINSTALL) + @list='$(bin_PROGRAMS)'; for p in $$list; do \ + f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \ + echo " rm -f $(DESTDIR)$(bindir)/$$f"; \ + rm -f $(DESTDIR)$(bindir)/$$f; \ + done + +mostlyclean-compile: + -rm -f *.o core *.core + -rm -f *.$(OBJEXT) + +clean-compile: + +distclean-compile: + -rm -f *.tab.c + +maintainer-clean-compile: + +mostlyclean-libtool: + -rm -f *.lo + +clean-libtool: + -rm -rf .libs _libs + +distclean-libtool: + +maintainer-clean-libtool: + +rcp$(EXEEXT): $(rcp_OBJECTS) $(rcp_DEPENDENCIES) + @rm -f rcp$(EXEEXT) + $(LINK) $(rcp_LDFLAGS) $(rcp_OBJECTS) $(rcp_LDADD) $(LIBS) +.c.o: + $(COMPILE) -c $< +.c.obj: + $(COMPILE) -c `cygpath -w $<` +.c.lo: + $(LTCOMPILE) -c -o $@ $< + +tags: TAGS + +ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES) + list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \ + unique=`for i in $$list; do \ + if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ + done | \ + $(AWK) ' { files[$$0] = 1; } \ + END { for (i in files) print i; }'`; \ + mkid -fID $$unique $(LISP) + +TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \ + $(TAGS_FILES) $(LISP) + tags=; \ + here=`pwd`; \ + list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \ + unique=`for i in $$list; do \ + if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ + done | \ + $(AWK) ' { files[$$0] = 1; } \ + END { for (i in files) print i; }'`; \ + test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \ + || etags $(ETAGS_ARGS) $$tags $$unique $(LISP) + +mostlyclean-tags: + +clean-tags: + +distclean-tags: + -rm -f TAGS ID + +maintainer-clean-tags: + +distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir) + +distdir: $(DISTFILES) + @for file in $(DISTFILES); do \ + d=$(srcdir); \ + if test -d $$d/$$file; then \ + cp -pR $$d/$$file $(distdir) \ + || exit 1; \ + else \ + test -f $(distdir)/$$file \ + || cp -p $$d/$$file $(distdir)/$$file \ + || exit 1; \ + fi; \ + done + $(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-hook +info-am: +info: info-am +dvi-am: +dvi: dvi-am +check-am: all-am + $(MAKE) $(AM_MAKEFLAGS) check-local +check: check-am +installcheck-am: +installcheck: installcheck-am +install-exec-am: install-binPROGRAMS + @$(NORMAL_INSTALL) + $(MAKE) $(AM_MAKEFLAGS) install-exec-hook +install-exec: install-exec-am + +install-data-am: install-data-local +install-data: install-data-am + +install-am: all-am + @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am +install: install-am +uninstall-am: uninstall-binPROGRAMS +uninstall: uninstall-am +all-am: Makefile $(PROGRAMS) all-local +all-redirect: all-am +install-strip: + $(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install +installdirs: + $(mkinstalldirs) $(DESTDIR)$(bindir) + + +mostlyclean-generic: + +clean-generic: + +distclean-generic: + -rm -f Makefile $(CONFIG_CLEAN_FILES) + -rm -f config.cache config.log stamp-h stamp-h[0-9]* + +maintainer-clean-generic: + -rm -f Makefile.in +mostlyclean-am: mostlyclean-binPROGRAMS mostlyclean-compile \ + mostlyclean-libtool mostlyclean-tags \ + mostlyclean-generic + +mostlyclean: mostlyclean-am + +clean-am: clean-binPROGRAMS clean-compile clean-libtool clean-tags \ + clean-generic mostlyclean-am + +clean: clean-am + +distclean-am: distclean-binPROGRAMS distclean-compile distclean-libtool \ + distclean-tags distclean-generic clean-am + -rm -f libtool + +distclean: distclean-am + +maintainer-clean-am: maintainer-clean-binPROGRAMS \ + maintainer-clean-compile maintainer-clean-libtool \ + maintainer-clean-tags maintainer-clean-generic \ + distclean-am + @echo "This command is intended for maintainers to use;" + @echo "it deletes files that may require special tools to rebuild." + +maintainer-clean: maintainer-clean-am + +.PHONY: mostlyclean-binPROGRAMS distclean-binPROGRAMS clean-binPROGRAMS \ +maintainer-clean-binPROGRAMS uninstall-binPROGRAMS install-binPROGRAMS \ +mostlyclean-compile distclean-compile clean-compile \ +maintainer-clean-compile mostlyclean-libtool distclean-libtool \ +clean-libtool maintainer-clean-libtool tags mostlyclean-tags \ +distclean-tags clean-tags maintainer-clean-tags distdir info-am info \ +dvi-am dvi check-local check check-am installcheck-am installcheck \ +install-exec-am install-exec install-data-local install-data-am \ +install-data install-am install uninstall-am uninstall all-local \ +all-redirect all-am all install-strip installdirs mostlyclean-generic \ +distclean-generic clean-generic maintainer-clean-generic clean \ +mostlyclean distclean maintainer-clean + + +install-suid-programs: + @foo='$(bin_SUIDS)'; \ + for file in $$foo; do \ + x=$(DESTDIR)$(bindir)/$$file; \ + if chown 0:0 $$x && chmod u+s $$x; then :; else \ + echo "*"; \ + echo "* Failed to install $$x setuid root"; \ + echo "*"; \ + fi; done + +install-exec-hook: install-suid-programs + +install-build-headers:: $(include_HEADERS) $(build_HEADERZ) + @foo='$(include_HEADERS) $(build_HEADERZ)'; \ + for f in $$foo; do \ + f=`basename $$f`; \ + if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \ + else file="$$f"; fi; \ + if cmp -s $$file $(buildinclude)/$$f 2> /dev/null ; then \ + : ; else \ + echo " $(CP) $$file $(buildinclude)/$$f"; \ + $(CP) $$file $(buildinclude)/$$f; \ + fi ; \ + done + +all-local: install-build-headers +#NROFF_MAN = nroff -man +.1.cat1: + $(NROFF_MAN) $< > $@ +.3.cat3: + $(NROFF_MAN) $< > $@ +.5.cat5: + $(NROFF_MAN) $< > $@ +.8.cat8: + $(NROFF_MAN) $< > $@ + +dist-cat1-mans: + @foo='$(man1_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.1) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat3-mans: + @foo='$(man3_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.3) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat5-mans: + @foo='$(man5_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.5) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat8-mans: + @foo='$(man8_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.8) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans + +install-cat-mans: + $(SHELL) $(top_srcdir)/cf/install-catman.sh "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS) + +install-data-local: install-cat-mans + +.et.h: + $(COMPILE_ET) $< +.et.c: + $(COMPILE_ET) $< + +.x.c: + @cmp -s $< $@ 2> /dev/null || cp $< $@ + +check-local:: + @foo='$(CHECK_LOCAL)'; \ + if test "$$foo"; then \ + failed=0; all=0; \ + for i in $$foo; do \ + all=`expr $$all + 1`; \ + if ./$$i --version > /dev/null 2>&1; then \ + echo "PASS: $$i"; \ + else \ + echo "FAIL: $$i"; \ + failed=`expr $$failed + 1`; \ + fi; \ + done; \ + if test "$$failed" -eq 0; then \ + banner="All $$all tests passed"; \ + else \ + banner="$$failed of $$all tests failed"; \ + fi; \ + dashes=`echo "$$banner" | sed s/./=/g`; \ + echo "$$dashes"; \ + echo "$$banner"; \ + echo "$$dashes"; \ + test "$$failed" -eq 0; \ + fi + +# Tell versions [3.59,3.63) of GNU make to not export all variables. +# Otherwise a system limit (for SysV at least) may be exceeded. +.NOEXPORT: diff --git a/crypto/heimdal/appl/rcp/extern.h b/crypto/heimdal/appl/rcp/extern.h new file mode 100644 index 000000000000..a98456d305e2 --- /dev/null +++ b/crypto/heimdal/appl/rcp/extern.h @@ -0,0 +1,51 @@ +/*- + * Copyright (c) 1992, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)extern.h 8.1 (Berkeley) 5/31/93 + * $FreeBSD$ + */ + +typedef struct { + int cnt; + char *buf; +} BUF; + +extern int iamremote; + +BUF *allocbuf (BUF *, int, int); +char *colon (char *); +void lostconn (int); +void nospace (void); +int okname (char *); +void run_err (const char *, ...); +int susystem (char *, int); +void verifydir (char *); diff --git a/crypto/heimdal/appl/rcp/rcp.c b/crypto/heimdal/appl/rcp/rcp.c new file mode 100644 index 000000000000..1c532ad8e500 --- /dev/null +++ b/crypto/heimdal/appl/rcp/rcp.c @@ -0,0 +1,807 @@ +/* + * Copyright (c) 1983, 1990, 1992, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "rcp_locl.h" + +#define RSH_PROGRAM "rsh" +#define OPTIONS "5dfKpP:rtxz" + +struct passwd *pwd; +uid_t userid; +int errs, remin, remout; +int pflag, iamremote, iamrecursive, targetshouldbedirectory; +int doencrypt, noencrypt; +int usebroken, usekrb5; +char *port; + +#define CMDNEEDS 64 +char cmd[CMDNEEDS]; /* must hold "rcp -r -p -d\0" */ + +int response (void); +void rsource (char *, struct stat *); +void sink (int, char *[]); +void source (int, char *[]); +void tolocal (int, char *[]); +void toremote (char *, int, char *[]); +void usage (void); + +int do_cmd(char *host, char *remuser, char *cmd, int *fdin, int *fdout); + +int +main(argc, argv) + int argc; + char *argv[]; +{ + int ch, fflag, tflag; + char *targ; + + fflag = tflag = 0; + while ((ch = getopt(argc, argv, OPTIONS)) != -1) + switch(ch) { /* User-visible flags. */ + case '5': + usekrb5 = 1; + break; + case 'K': + usebroken = 1; + break; + case 'P': + port = optarg; + break; + case 'p': + pflag = 1; + break; + case 'r': + iamrecursive = 1; + break; + case 'x': + doencrypt = 1; + break; + case 'z': + noencrypt = 1; + break; + /* Server options. */ + case 'd': + targetshouldbedirectory = 1; + break; + case 'f': /* "from" */ + iamremote = 1; + fflag = 1; + break; + case 't': /* "to" */ + iamremote = 1; + tflag = 1; + break; + case '?': + default: + usage(); + } + argc -= optind; + argv += optind; + + if ((pwd = getpwuid(userid = getuid())) == NULL) + errx(1, "unknown user %d", (int)userid); + + remin = STDIN_FILENO; /* XXX */ + remout = STDOUT_FILENO; + + if (fflag) { /* Follow "protocol", send data. */ + (void)response(); + (void)setuid(userid); + source(argc, argv); + exit(errs); + } + + if (tflag) { /* Receive data. */ + (void)setuid(userid); + sink(argc, argv); + exit(errs); + } + + if (argc < 2) + usage(); + if (argc > 2) + targetshouldbedirectory = 1; + + remin = remout = -1; + /* Command to be executed on remote system using "rsh". */ + (void) sprintf(cmd, "rcp%s%s%s", iamrecursive ? " -r" : "", + pflag ? " -p" : "", targetshouldbedirectory ? " -d" : ""); + + (void)signal(SIGPIPE, lostconn); + + if ((targ = colon(argv[argc - 1]))) /* Dest is remote host. */ + toremote(targ, argc, argv); + else { + tolocal(argc, argv); /* Dest is local host. */ + if (targetshouldbedirectory) + verifydir(argv[argc - 1]); + } + exit(errs); +} + +void +toremote(targ, argc, argv) + char *targ, *argv[]; + int argc; +{ + int i, len; + char *bp, *host, *src, *suser, *thost, *tuser; + + *targ++ = 0; + if (*targ == 0) + targ = "."; + + if ((thost = strchr(argv[argc - 1], '@'))) { + /* user@host */ + *thost++ = 0; + tuser = argv[argc - 1]; + if (*tuser == '\0') + tuser = NULL; + else if (!okname(tuser)) + exit(1); + } else { + thost = argv[argc - 1]; + tuser = NULL; + } + + for (i = 0; i < argc - 1; i++) { + src = colon(argv[i]); + if (src) { /* remote to remote */ + *src++ = 0; + if (*src == 0) + src = "."; + host = strchr(argv[i], '@'); + len = strlen(_PATH_RSH) + strlen(argv[i]) + + strlen(src) + (tuser ? strlen(tuser) : 0) + + strlen(thost) + strlen(targ) + CMDNEEDS + 20; + if (!(bp = malloc(len))) + err(1, "malloc"); + if (host) { + *host++ = 0; + suser = argv[i]; + if (*suser == '\0') + suser = pwd->pw_name; + else if (!okname(suser)) + continue; + (void)snprintf(bp, len, + "%s %s -l %s -n %s %s '%s%s%s:%s'", + _PATH_RSH, host, suser, cmd, src, + tuser ? tuser : "", tuser ? "@" : "", + thost, targ); + } else + (void)snprintf(bp, len, + "exec %s %s -n %s %s '%s%s%s:%s'", + _PATH_RSH, argv[i], cmd, src, + tuser ? tuser : "", tuser ? "@" : "", + thost, targ); + (void)susystem(bp, userid); + (void)free(bp); + } else { /* local to remote */ + if (remin == -1) { + len = strlen(targ) + CMDNEEDS + 20; + if (!(bp = malloc(len))) + err(1, "malloc"); + (void)snprintf(bp, len, "%s -t %s", cmd, targ); + host = thost; + + if (do_cmd(host, tuser, bp, &remin, &remout) < 0) + exit(1); + + if (response() < 0) + exit(1); + (void)free(bp); + (void)setuid(userid); + } + source(1, argv+i); + } + } +} + +void +tolocal(argc, argv) + int argc; + char *argv[]; +{ + int i, len; + char *bp, *host, *src, *suser; + + for (i = 0; i < argc - 1; i++) { + if (!(src = colon(argv[i]))) { /* Local to local. */ + len = strlen(_PATH_CP) + strlen(argv[i]) + + strlen(argv[argc - 1]) + 20; + if (!(bp = malloc(len))) + err(1, "malloc"); + (void)snprintf(bp, len, "exec %s%s%s %s %s", _PATH_CP, + iamrecursive ? " -PR" : "", pflag ? " -p" : "", + argv[i], argv[argc - 1]); + if (susystem(bp, userid)) + ++errs; + (void)free(bp); + continue; + } + *src++ = 0; + if (*src == 0) + src = "."; + if ((host = strchr(argv[i], '@')) == NULL) { + host = argv[i]; + suser = pwd->pw_name; + } else { + *host++ = 0; + suser = argv[i]; + if (*suser == '\0') + suser = pwd->pw_name; + else if (!okname(suser)) + continue; + } + len = strlen(src) + CMDNEEDS + 20; + if ((bp = malloc(len)) == NULL) + err(1, "malloc"); + (void)snprintf(bp, len, "%s -f %s", cmd, src); + if (do_cmd(host, suser, bp, &remin, &remout) < 0) { + (void)free(bp); + ++errs; + continue; + } + (void)free(bp); + sink(1, argv + argc - 1); + (void)seteuid(0); + (void)close(remin); + remin = remout = -1; + } +} + +void +source(argc, argv) + int argc; + char *argv[]; +{ + struct stat stb; + static BUF buffer; + BUF *bp; + off_t i; + int amt, fd, haderr, indx, result; + char *last, *name, buf[BUFSIZ]; + + for (indx = 0; indx < argc; ++indx) { + name = argv[indx]; + if ((fd = open(name, O_RDONLY, 0)) < 0) + goto syserr; + if (fstat(fd, &stb)) { +syserr: run_err("%s: %s", name, strerror(errno)); + goto next; + } + switch (stb.st_mode & S_IFMT) { + case S_IFREG: + break; + case S_IFDIR: + if (iamrecursive) { + rsource(name, &stb); + goto next; + } + /* FALLTHROUGH */ + default: + run_err("%s: not a regular file", name); + goto next; + } + if ((last = strrchr(name, '/')) == NULL) + last = name; + else + ++last; + if (pflag) { + /* + * Make it compatible with possible future + * versions expecting microseconds. + */ + (void)snprintf(buf, sizeof(buf), "T%ld 0 %ld 0\n", + (long)stb.st_mtime, + (long)stb.st_atime); + (void)write(remout, buf, strlen(buf)); + if (response() < 0) + goto next; + } +#define MODEMASK (S_ISUID|S_ISGID|S_ISVTX|S_IRWXU|S_IRWXG|S_IRWXO) + (void)snprintf(buf, sizeof(buf), "C%04o %lu %s\n", + stb.st_mode & MODEMASK, (unsigned long)stb.st_size, last); + (void)write(remout, buf, strlen(buf)); + if (response() < 0) + goto next; + if ((bp = allocbuf(&buffer, fd, BUFSIZ)) == NULL) { +next: (void)close(fd); + continue; + } + + /* Keep writing after an error so that we stay sync'd up. */ + for (haderr = i = 0; i < stb.st_size; i += bp->cnt) { + amt = bp->cnt; + if (i + amt > stb.st_size) + amt = stb.st_size - i; + if (!haderr) { + result = read(fd, bp->buf, amt); + if (result != amt) + haderr = result >= 0 ? EIO : errno; + } + if (haderr) + (void)write(remout, bp->buf, amt); + else { + result = write(remout, bp->buf, amt); + if (result != amt) + haderr = result >= 0 ? EIO : errno; + } + } + if (close(fd) && !haderr) + haderr = errno; + if (!haderr) + (void)write(remout, "", 1); + else + run_err("%s: %s", name, strerror(haderr)); + (void)response(); + } +} + +void +rsource(name, statp) + char *name; + struct stat *statp; +{ + DIR *dirp; + struct dirent *dp; + char *last, *vect[1], path[MAXPATHLEN]; + + if (!(dirp = opendir(name))) { + run_err("%s: %s", name, strerror(errno)); + return; + } + last = strrchr(name, '/'); + if (last == 0) + last = name; + else + last++; + if (pflag) { + (void)snprintf(path, sizeof(path), "T%ld 0 %ld 0\n", + (long)statp->st_mtime, + (long)statp->st_atime); + (void)write(remout, path, strlen(path)); + if (response() < 0) { + closedir(dirp); + return; + } + } + (void)snprintf(path, sizeof(path), + "D%04o %d %s\n", statp->st_mode & MODEMASK, 0, last); + (void)write(remout, path, strlen(path)); + if (response() < 0) { + closedir(dirp); + return; + } + while ((dp = readdir(dirp))) { + if (dp->d_ino == 0) + continue; + if (!strcmp(dp->d_name, ".") || !strcmp(dp->d_name, "..")) + continue; + if (strlen(name) + 1 + strlen(dp->d_name) >= MAXPATHLEN - 1) { + run_err("%s/%s: name too long", name, dp->d_name); + continue; + } + (void)snprintf(path, sizeof(path), "%s/%s", name, dp->d_name); + vect[0] = path; + source(1, vect); + } + (void)closedir(dirp); + (void)write(remout, "E\n", 2); + (void)response(); +} + +void +sink(argc, argv) + int argc; + char *argv[]; +{ + static BUF buffer; + struct stat stb; + struct timeval tv[2]; + enum { YES, NO, DISPLAYED } wrerr; + BUF *bp; + off_t i, j, size; + int amt, count, exists, first, mask, mode, ofd, omode; + int setimes, targisdir, wrerrno = 0; + char ch, *cp, *np, *targ, *why, *vect[1], buf[BUFSIZ]; + +#define atime tv[0] +#define mtime tv[1] +#define SCREWUP(str) { why = str; goto screwup; } + + setimes = targisdir = 0; + mask = umask(0); + if (!pflag) + (void)umask(mask); + if (argc != 1) { + run_err("ambiguous target"); + exit(1); + } + targ = *argv; + if (targetshouldbedirectory) + verifydir(targ); + (void)write(remout, "", 1); + if (stat(targ, &stb) == 0 && S_ISDIR(stb.st_mode)) + targisdir = 1; + for (first = 1;; first = 0) { + cp = buf; + if (read(remin, cp, 1) <= 0) + return; + if (*cp++ == '\n') + SCREWUP("unexpected <newline>"); + do { + if (read(remin, &ch, sizeof(ch)) != sizeof(ch)) + SCREWUP("lost connection"); + *cp++ = ch; + } while (cp < &buf[BUFSIZ - 1] && ch != '\n'); + *cp = 0; + + if (buf[0] == '\01' || buf[0] == '\02') { + if (iamremote == 0) + (void)write(STDERR_FILENO, + buf + 1, strlen(buf + 1)); + if (buf[0] == '\02') + exit(1); + ++errs; + continue; + } + if (buf[0] == 'E') { + (void)write(remout, "", 1); + return; + } + + if (ch == '\n') + *--cp = 0; + + cp = buf; + if (*cp == 'T') { + setimes++; + cp++; + mtime.tv_sec = strtol(cp, &cp, 10); + if (!cp || *cp++ != ' ') + SCREWUP("mtime.sec not delimited"); + mtime.tv_usec = strtol(cp, &cp, 10); + if (!cp || *cp++ != ' ') + SCREWUP("mtime.usec not delimited"); + atime.tv_sec = strtol(cp, &cp, 10); + if (!cp || *cp++ != ' ') + SCREWUP("atime.sec not delimited"); + atime.tv_usec = strtol(cp, &cp, 10); + if (!cp || *cp++ != '\0') + SCREWUP("atime.usec not delimited"); + (void)write(remout, "", 1); + continue; + } + if (*cp != 'C' && *cp != 'D') { + /* + * Check for the case "rcp remote:foo\* local:bar". + * In this case, the line "No match." can be returned + * by the shell before the rcp command on the remote is + * executed so the ^Aerror_message convention isn't + * followed. + */ + if (first) { + run_err("%s", cp); + exit(1); + } + SCREWUP("expected control record"); + } + mode = 0; + for (++cp; cp < buf + 5; cp++) { + if (*cp < '0' || *cp > '7') + SCREWUP("bad mode"); + mode = (mode << 3) | (*cp - '0'); + } + if (*cp++ != ' ') + SCREWUP("mode not delimited"); + + for (size = 0; isdigit(*cp);) + size = size * 10 + (*cp++ - '0'); + if (*cp++ != ' ') + SCREWUP("size not delimited"); + if (targisdir) { + static char *namebuf; + static int cursize; + size_t need; + + need = strlen(targ) + strlen(cp) + 250; + if (need > cursize) { + if (!(namebuf = malloc(need))) + run_err("%s", strerror(errno)); + } + (void)snprintf(namebuf, need, "%s%s%s", targ, + *targ ? "/" : "", cp); + np = namebuf; + } else + np = targ; + exists = stat(np, &stb) == 0; + if (buf[0] == 'D') { + int mod_flag = pflag; + if (exists) { + if (!S_ISDIR(stb.st_mode)) { + errno = ENOTDIR; + goto bad; + } + if (pflag) + (void)chmod(np, mode); + } else { + /* Handle copying from a read-only directory */ + mod_flag = 1; + if (mkdir(np, mode | S_IRWXU) < 0) + goto bad; + } + vect[0] = np; + sink(1, vect); + if (setimes) { + setimes = 0; + if (utimes(np, tv) < 0) + run_err("%s: set times: %s", + np, strerror(errno)); + } + if (mod_flag) + (void)chmod(np, mode); + continue; + } + omode = mode; + mode |= S_IWRITE; + if ((ofd = open(np, O_WRONLY|O_CREAT, mode)) < 0) { +bad: run_err("%s: %s", np, strerror(errno)); + continue; + } + (void)write(remout, "", 1); + if ((bp = allocbuf(&buffer, ofd, BUFSIZ)) == NULL) { + (void)close(ofd); + continue; + } + cp = bp->buf; + wrerr = NO; + for (count = i = 0; i < size; i += BUFSIZ) { + amt = BUFSIZ; + if (i + amt > size) + amt = size - i; + count += amt; + do { + j = read(remin, cp, amt); + if (j <= 0) { + run_err("%s", j ? strerror(errno) : + "dropped connection"); + exit(1); + } + amt -= j; + cp += j; + } while (amt > 0); + if (count == bp->cnt) { + /* Keep reading so we stay sync'd up. */ + if (wrerr == NO) { + j = write(ofd, bp->buf, count); + if (j != count) { + wrerr = YES; + wrerrno = j >= 0 ? EIO : errno; + } + } + count = 0; + cp = bp->buf; + } + } + if (count != 0 && wrerr == NO && + (j = write(ofd, bp->buf, count)) != count) { + wrerr = YES; + wrerrno = j >= 0 ? EIO : errno; + } + if (ftruncate(ofd, size)) { + run_err("%s: truncate: %s", np, strerror(errno)); + wrerr = DISPLAYED; + } + if (pflag) { + if (exists || omode != mode) + if (fchmod(ofd, omode)) + run_err("%s: set mode: %s", + np, strerror(errno)); + } else { + if (!exists && omode != mode) + if (fchmod(ofd, omode & ~mask)) + run_err("%s: set mode: %s", + np, strerror(errno)); + } + (void)close(ofd); + (void)response(); + if (setimes && wrerr == NO) { + setimes = 0; + if (utimes(np, tv) < 0) { + run_err("%s: set times: %s", + np, strerror(errno)); + wrerr = DISPLAYED; + } + } + switch(wrerr) { + case YES: + run_err("%s: %s", np, strerror(wrerrno)); + break; + case NO: + (void)write(remout, "", 1); + break; + case DISPLAYED: + break; + } + } +screwup: + run_err("protocol error: %s", why); + exit(1); +} + +int +response() +{ + char ch, *cp, resp, rbuf[BUFSIZ]; + + if (read(remin, &resp, sizeof(resp)) != sizeof(resp)) + lostconn(0); + + cp = rbuf; + switch(resp) { + case 0: /* ok */ + return (0); + default: + *cp++ = resp; + /* FALLTHROUGH */ + case 1: /* error, followed by error msg */ + case 2: /* fatal error, "" */ + do { + if (read(remin, &ch, sizeof(ch)) != sizeof(ch)) + lostconn(0); + *cp++ = ch; + } while (cp < &rbuf[BUFSIZ] && ch != '\n'); + + if (!iamremote) + (void)write(STDERR_FILENO, rbuf, cp - rbuf); + ++errs; + if (resp == 1) + return (-1); + exit(1); + } + /* NOTREACHED */ +} + +void +usage() +{ + (void)fprintf(stderr, "%s\n%s\n", + "usage: rcp [-5FKpx] [-P port] f1 f2", + " rcp [-5FKprx] [-P port] f1 ... fn directory"); + exit(1); +} + +#include <stdarg.h> + +void +run_err(const char *fmt, ...) +{ + static FILE *fp; + va_list ap; + va_start(ap, fmt); + + ++errs; + if (fp == NULL && !(fp = fdopen(remout, "w"))) + return; + (void)fprintf(fp, "%c", 0x01); + (void)fprintf(fp, "rcp: "); + (void)vfprintf(fp, fmt, ap); + (void)fprintf(fp, "\n"); + (void)fflush(fp); + + if (!iamremote) + vwarnx(fmt, ap); + + va_end(ap); +} + +/* + * This function executes the given command as the specified user on the + * given host. This returns < 0 if execution fails, and >= 0 otherwise. This + * assigns the input and output file descriptors on success. + * + * If it cannot create necessary pipes it exits with error message. + */ + +int +do_cmd(char *host, char *remuser, char *cmd, int *fdin, int *fdout) +{ + int pin[2], pout[2], reserved[2]; + + /* + * Reserve two descriptors so that the real pipes won't get + * descriptors 0 and 1 because that will screw up dup2 below. + */ + pipe(reserved); + + /* Create a socket pair for communicating with rsh. */ + if (pipe(pin) < 0) { + perror("pipe"); + exit(255); + } + if (pipe(pout) < 0) { + perror("pipe"); + exit(255); + } + + /* Free the reserved descriptors. */ + close(reserved[0]); + close(reserved[1]); + + /* For a child to execute the command on the remote host using rsh. */ + if (fork() == 0) { + char *args[100]; + unsigned int i; + + /* Child. */ + close(pin[1]); + close(pout[0]); + dup2(pin[0], 0); + dup2(pout[1], 1); + close(pin[0]); + close(pout[1]); + + i = 0; + args[i++] = RSH_PROGRAM; + if (usekrb5) + args[i++] = "-5"; + if (usebroken) + args[i++] = "-K"; + if (doencrypt) + args[i++] = "-x"; + if (noencrypt) + args[i++] = "-z"; + if (port != NULL) { + args[i++] = "-p"; + args[i++] = port; + } + if (remuser != NULL) { + args[i++] = "-l"; + args[i++] = remuser; + } + args[i++] = host; + args[i++] = cmd; + args[i++] = NULL; + + execvp(RSH_PROGRAM, args); + perror(RSH_PROGRAM); + exit(1); + } + /* Parent. Close the other side, and return the local side. */ + close(pin[0]); + *fdout = pin[1]; + close(pout[1]); + *fdin = pout[0]; + return 0; +} diff --git a/crypto/heimdal/appl/rcp/rcp_locl.h b/crypto/heimdal/appl/rcp/rcp_locl.h new file mode 100644 index 000000000000..4397c9f461ac --- /dev/null +++ b/crypto/heimdal/appl/rcp/rcp_locl.h @@ -0,0 +1,64 @@ +/* + * Copyright (c) 2001 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: rcp_locl.h,v 1.3 2001/01/29 05:59:24 assar Exp $ */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +#endif + +#include <sys/param.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <sys/time.h> +#include <sys/wait.h> + +#include <ctype.h> +#include <dirent.h> +#include <err.h> +#include <errno.h> +#include <fcntl.h> +#include <pwd.h> +#include <signal.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <string.h> +#include <unistd.h> + +#include <roken.h> + +#include "extern.h" + +#define _PATH_CP "/bin/cp" +#define _PATH_RSH "/usr/bin/rsh" diff --git a/crypto/heimdal/appl/rcp/util.c b/crypto/heimdal/appl/rcp/util.c new file mode 100644 index 000000000000..9d0f6d5ea3a0 --- /dev/null +++ b/crypto/heimdal/appl/rcp/util.c @@ -0,0 +1,165 @@ +/*- + * Copyright (c) 1992, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#if 0 +#ifndef lint +#if 0 +static char sccsid[] = "@(#)util.c 8.2 (Berkeley) 4/2/94"; +#endif +static const char rcsid[] = + "$FreeBSD$"; +#endif /* not lint */ +#endif + +#include "rcp_locl.h" + +RCSID("$Id: util.c,v 1.5 2001/01/29 23:36:37 assar Exp $"); + +char * +colon(cp) + char *cp; +{ + if (*cp == ':') /* Leading colon is part of file name. */ + return (0); + + for (; *cp; ++cp) { + if (*cp == ':') + return (cp); + if (*cp == '/') + return (0); + } + return (0); +} + +void +verifydir(cp) + char *cp; +{ + struct stat stb; + + if (!stat(cp, &stb)) { + if (S_ISDIR(stb.st_mode)) + return; + errno = ENOTDIR; + } + run_err("%s: %s", cp, strerror(errno)); + exit(1); +} + +int +okname(cp0) + char *cp0; +{ + int c; + char *cp; + + cp = cp0; + do { + c = *cp; + if (c & 0200) + goto bad; + if (!isalpha(c) && !isdigit(c) && c != '_' && c != '-') + goto bad; + } while (*++cp); + return (1); + +bad: warnx("%s: invalid user name", cp0); + return (0); +} + +int +susystem(s, userid) + int userid; + char *s; +{ + void (*istat)(int), (*qstat)(int); + int status; + pid_t pid; + + pid = fork(); + switch (pid) { + case -1: + return (127); + + case 0: + (void)setuid(userid); + execl(_PATH_BSHELL, "sh", "-c", s, NULL); + _exit(127); + } + istat = signal(SIGINT, SIG_IGN); + qstat = signal(SIGQUIT, SIG_IGN); + if (waitpid(pid, &status, 0) < 0) + status = -1; + (void)signal(SIGINT, istat); + (void)signal(SIGQUIT, qstat); + return (status); +} + +#ifndef roundup +#define roundup(x, y) ((((x)+((y)-1))/(y))*(y)) +#endif + +BUF * +allocbuf(bp, fd, blksize) + BUF *bp; + int fd, blksize; +{ + struct stat stb; + size_t size; + + if (fstat(fd, &stb) < 0) { + run_err("fstat: %s", strerror(errno)); + return (0); + } + size = roundup(stb.st_blksize, blksize); + if (size == 0) + size = blksize; + if (bp->cnt >= size) + return (bp); + if ((bp->buf = realloc(bp->buf, size)) == NULL) { + bp->cnt = 0; + run_err("%s", strerror(errno)); + return (0); + } + bp->cnt = size; + return (bp); +} + +void +lostconn(signo) + int signo; +{ + if (!iamremote) + warnx("lost connection"); + exit(1); +} diff --git a/crypto/heimdal/cf/aix.m4 b/crypto/heimdal/cf/aix.m4 new file mode 100644 index 000000000000..25aaa2aed62a --- /dev/null +++ b/crypto/heimdal/cf/aix.m4 @@ -0,0 +1,39 @@ +dnl +dnl $Id: aix.m4,v 1.5 2000/11/05 17:15:46 joda Exp $ +dnl + +AC_DEFUN(KRB_AIX,[ +aix=no +case "$host" in +*-*-aix3*) + aix=3 + ;; +*-*-aix4*) + aix=4 + ;; +esac +AM_CONDITIONAL(AIX, test "$aix" != no)dnl +AM_CONDITIONAL(AIX4, test "$aix" = 4) +aix_dynamic_afs=yes +AM_CONDITIONAL(AIX_DYNAMIC_AFS, test "$aix_dynamic_afs" = yes)dnl + +AC_FIND_FUNC_NO_LIBS(dlopen, dl) + +if test "$aix" != no; then + if test "$aix_dynamic_afs" = yes; then + if test "$ac_cv_funclib_dlopen" = yes; then + AIX_EXTRA_KAFS= + elif test "$ac_cv_funclib_dlopen" != no; then + AIX_EXTRA_KAFS="$ac_cv_funclib_dlopen" + else + AIX_EXTRA_KAFS=-lld + fi + else + AIX_EXTRA_KAFS= + fi +fi + +AM_CONDITIONAL(HAVE_DLOPEN, test "$ac_cv_funclib_dlopen" != no)dnl +AC_SUBST(AIX_EXTRA_KAFS)dnl + +])
\ No newline at end of file diff --git a/crypto/heimdal/cf/broken-getnameinfo.m4 b/crypto/heimdal/cf/broken-getnameinfo.m4 new file mode 100644 index 000000000000..da206c04a06e --- /dev/null +++ b/crypto/heimdal/cf/broken-getnameinfo.m4 @@ -0,0 +1,28 @@ +dnl $Id: broken-getnameinfo.m4,v 1.2 2000/12/05 09:09:00 joda Exp $ +dnl +dnl test for broken AIX getnameinfo + +AC_DEFUN(rk_BROKEN_GETNAMEINFO,[ +AC_CACHE_CHECK([if getnameinfo is broken], ac_cv_func_getnameinfo_broken, +AC_TRY_RUN([[#include <stdio.h> +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> +#include <netdb.h> + +int +main(int argc, char **argv) +{ + struct sockaddr_in sin; + char host[256]; + memset(&sin, 0, sizeof(sin)); +#ifdef HAVE_STRUCT_SOCKADDR_SA_LEN + sin.sin_len = sizeof(sin); +#endif + sin.sin_family = AF_INET; + sin.sin_addr.s_addr = 0xffffffff; + sin.sin_port = 0; + return getnameinfo((struct sockaddr*)&sin, sizeof(sin), host, sizeof(host), + NULL, 0, 0); +} +]], ac_cv_func_getnameinfo_broken=no, ac_cv_func_getnameinfo_broken=yes))]) diff --git a/crypto/heimdal/cf/broken-realloc.m4 b/crypto/heimdal/cf/broken-realloc.m4 new file mode 100644 index 000000000000..15692559b2a2 --- /dev/null +++ b/crypto/heimdal/cf/broken-realloc.m4 @@ -0,0 +1,26 @@ +dnl +dnl $Id: broken-realloc.m4,v 1.1 2000/07/15 18:05:36 joda Exp $ +dnl +dnl Test for realloc that doesn't handle NULL as first parameter +dnl +AC_DEFUN(rk_BROKEN_REALLOC, [ +AC_CACHE_CHECK(if realloc if broken, ac_cv_func_realloc_broken, [ +ac_cv_func_realloc_broken=no +AC_TRY_RUN([ +#include <stddef.h> +#include <stdlib.h> + +int main() +{ + return realloc(NULL, 17) == NULL; +} +],:, ac_cv_func_realloc_broken=yes, :) +]) +if test "$ac_cv_func_realloc_broken" = yes ; then + AC_DEFINE(BROKEN_REALLOC, 1, [Define if realloc(NULL) doesn't work.]) +fi +AH_BOTTOM([#ifdef BROKEN_REALLOC +#define realloc(X, Y) isoc_realloc((X), (Y)) +#define isoc_realloc(X, Y) ((X) ? realloc((X), (Y)) : malloc(Y)) +#endif]) +]) diff --git a/crypto/heimdal/cf/broken2.m4 b/crypto/heimdal/cf/broken2.m4 new file mode 100644 index 000000000000..78a3dcbc357e --- /dev/null +++ b/crypto/heimdal/cf/broken2.m4 @@ -0,0 +1,35 @@ +dnl $Id: broken2.m4,v 1.1 2000/12/15 14:27:33 assar Exp $ +dnl +dnl AC_BROKEN but with more arguments + +dnl AC_BROKEN2(func, includes, arguments) +AC_DEFUN(AC_BROKEN2, +[for ac_func in $1 +do +AC_MSG_CHECKING([for $ac_func]) +AC_CACHE_VAL(ac_cv_func_$ac_func, +[AC_TRY_LINK([$2], +[ +/* The GNU C library defines this for functions which it implements + to always fail with ENOSYS. Some functions are actually named + something starting with __ and the normal name is an alias. */ +#if defined (__stub_$1) || defined (__stub___$1) +choke me +#else +$ac_func($3) +#endif +], [eval "ac_cv_func_$ac_func=yes"], [eval "ac_cv_func_$ac_func=no"])]) +if eval "test \"\${ac_cv_func_$ac_func}\" = yes"; then + ac_tr_func=HAVE_[]upcase($ac_func) + AC_DEFINE_UNQUOTED($ac_tr_func) + AC_MSG_RESULT(yes) +else + AC_MSG_RESULT(no) + LIBOBJS[]="$LIBOBJS ${ac_func}.o" +fi +done +if false; then + AC_CHECK_FUNCS($1) +fi +AC_SUBST(LIBOBJS)dnl +]) diff --git a/crypto/heimdal/cf/db.m4 b/crypto/heimdal/cf/db.m4 new file mode 100644 index 000000000000..c147569c51d6 --- /dev/null +++ b/crypto/heimdal/cf/db.m4 @@ -0,0 +1,40 @@ +dnl $Id: db.m4,v 1.1 2000/07/19 11:21:07 joda Exp $ +dnl +dnl tests for various db libraries +dnl +AC_DEFUN([rk_DB],[berkeley_db=db +AC_ARG_WITH(berkeley-db, +[ --without-berkeley-db if you don't want berkeley db],[ +if test "$withval" = no; then + berkeley_db="" +fi +]) +if test "$berkeley_db"; then + AC_CHECK_HEADERS([ \ + db.h \ + db_185.h \ + ]) +fi + +AC_FIND_FUNC_NO_LIBS2(dbopen, $berkeley_db, [ +#include <stdio.h> +#if defined(HAVE_DB_185_H) +#include <db_185.h> +#elif defined(HAVE_DB_H) +#include <db.h> +#endif +],[NULL, 0, 0, 0, NULL]) + +AC_FIND_FUNC_NO_LIBS(dbm_firstkey, $berkeley_db gdbm ndbm) +AC_FIND_FUNC_NO_LIBS(db_create, $berkeley_db) + +DBLIB="$LIB_dbopen" +if test "$LIB_dbopen" != "$LIB_db_create"; then + DBLIB="$DBLIB $LIB_db_create" +fi +if test "$LIB_dbopen" != "$LIB_dbm_firstkey"; then + DBLIB="$DBLIB $LIB_dbm_firstkey" +fi +AC_SUBST(DBLIB)dnl + +]) diff --git a/crypto/heimdal/cf/install-catman.sh b/crypto/heimdal/cf/install-catman.sh new file mode 100755 index 000000000000..c48cc208af5b --- /dev/null +++ b/crypto/heimdal/cf/install-catman.sh @@ -0,0 +1,25 @@ +#!/bin/sh +# +# $Id: install-catman.sh,v 1.1 2000/11/30 01:38:17 joda Exp $ +# +# install preformatted manual pages + +INSTALL_DATA="$1"; shift +mkinstalldirs="$1"; shift +srcdir="$1"; shift +mandir="$1"; shift +suffix="$1"; shift + +for f in "$@"; do + base=`echo "$f" | sed 's/\(.*\)\.\([^.]*\)$/\1/'` + section=`echo "$f" | sed 's/\(.*\)\.\([^.]*\)$/\2/'` + catdir="$mandir/cat$section" + c="$base.cat$section" + if test -f "$srcdir/$c"; then + if test \! -d "$catdir"; then + eval "$mkinstalldirs $catdir" + fi + eval "echo $INSTALL_DATA $srcdir/$c $catdir/$base.$suffix" + eval "$INSTALL_DATA $srcdir/$c $catdir/$base.$suffix" + fi +done diff --git a/crypto/heimdal/cf/krb-irix.m4 b/crypto/heimdal/cf/krb-irix.m4 new file mode 100644 index 000000000000..cdde69c147b0 --- /dev/null +++ b/crypto/heimdal/cf/krb-irix.m4 @@ -0,0 +1,12 @@ +dnl +dnl $Id: krb-irix.m4,v 1.2 2000/12/13 12:48:45 assar Exp $ +dnl + +dnl requires AC_CANONICAL_HOST +AC_DEFUN(KRB_IRIX,[ +irix=no +case "$host_os" in +irix*) irix=yes ;; +esac +AM_CONDITIONAL(IRIX, test "$irix" != no)dnl +]) diff --git a/crypto/heimdal/cf/krb-readline.m4 b/crypto/heimdal/cf/krb-readline.m4 new file mode 100644 index 000000000000..6d0f0b211f5d --- /dev/null +++ b/crypto/heimdal/cf/krb-readline.m4 @@ -0,0 +1,43 @@ +dnl $Id: krb-readline.m4,v 1.2 2000/11/15 00:47:08 assar Exp $ +dnl +dnl Tests for readline functions +dnl + +dnl el_init + +AC_DEFUN(KRB_READLINE,[ +AC_FIND_FUNC_NO_LIBS(el_init, edit, [], [], [$LIB_tgetent]) +if test "$ac_cv_func_el_init" = yes ; then + AC_CACHE_CHECK(for four argument el_init, ac_cv_func_el_init_four,[ + AC_TRY_COMPILE([#include <stdio.h> + #include <histedit.h>], + [el_init("", NULL, NULL, NULL);], + ac_cv_func_el_init_four=yes, + ac_cv_func_el_init_four=no)]) + if test "$ac_cv_func_el_init_four" = yes; then + AC_DEFINE(HAVE_FOUR_VALUED_EL_INIT, 1, [Define if el_init takes four arguments.]) + fi +fi + +dnl readline + +ac_foo=no +if test "$with_readline" = yes; then + : +elif test "$ac_cv_func_readline" = yes; then + : +elif test "$ac_cv_func_el_init" = yes; then + ac_foo=yes + LIB_readline="\$(top_builddir)/lib/editline/libel_compat.la $LIB_el_init" +else + LIB_readline='$(top_builddir)/lib/editline/libeditline.la' +fi +AM_CONDITIONAL(el_compat, test "$ac_foo" = yes) +if test "$readline_libdir"; then + LIB_readline="-rpath $readline_libdir $LIB_readline" +fi +LIB_readline="$LIB_readline \$(LIB_tgetent)" +AC_DEFINE(HAVE_READLINE, 1, + [Define if you have a readline compatible library.])dnl + +])
\ No newline at end of file diff --git a/crypto/heimdal/cf/retsigtype.m4 b/crypto/heimdal/cf/retsigtype.m4 new file mode 100644 index 000000000000..4c3ecbdff017 --- /dev/null +++ b/crypto/heimdal/cf/retsigtype.m4 @@ -0,0 +1,18 @@ +dnl +dnl $Id: retsigtype.m4,v 1.1 2000/07/15 18:05:56 joda Exp $ +dnl +dnl Figure out return type of signal handlers, and define SIGRETURN macro +dnl that can be used to return from one +dnl +AC_DEFUN(rk_RETSIGTYPE,[ +AC_TYPE_SIGNAL +if test "$ac_cv_type_signal" = "void" ; then + AC_DEFINE(VOID_RETSIGTYPE, 1, [Define if signal handlers return void.]) +fi +AC_SUBST(VOID_RETSIGTYPE) +AH_BOTTOM([#ifdef VOID_RETSIGTYPE +#define SIGRETURN(x) return +#else +#define SIGRETURN(x) return (RETSIGTYPE)(x) +#endif]) +])
\ No newline at end of file diff --git a/crypto/heimdal/cf/roken-frag.m4 b/crypto/heimdal/cf/roken-frag.m4 new file mode 100644 index 000000000000..c6b552e6e059 --- /dev/null +++ b/crypto/heimdal/cf/roken-frag.m4 @@ -0,0 +1,586 @@ +dnl $Id: roken-frag.m4,v 1.19 2000/12/15 14:29:54 assar Exp $ +dnl +dnl some code to get roken working +dnl +dnl rk_ROKEN(subdir) +dnl +AC_DEFUN(rk_ROKEN, [ + +AC_REQUIRE([rk_CONFIG_HEADER]) + +DIR_roken=roken +LIB_roken='$(top_builddir)/$1/libroken.la' +INCLUDES_roken='-I$(top_builddir)/$1 -I$(top_srcdir)/$1' + +dnl Checks for programs +AC_REQUIRE([AC_PROG_CC]) +AC_REQUIRE([AC_PROG_AWK]) +AC_REQUIRE([AC_OBJEXT]) +AC_REQUIRE([AC_EXEEXT]) +AC_REQUIRE([AC_PROG_LIBTOOL]) + +AC_REQUIRE([AC_MIPS_ABI]) + +dnl C characteristics + +AC_REQUIRE([AC_C___ATTRIBUTE__]) +AC_REQUIRE([AC_C_INLINE]) +AC_REQUIRE([AC_C_CONST]) +AC_WFLAGS(-Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs) + +AC_REQUIRE([rk_DB]) + +dnl C types + +AC_REQUIRE([AC_TYPE_SIZE_T]) +AC_CHECK_TYPE_EXTRA(ssize_t, int, [#include <unistd.h>]) +AC_REQUIRE([AC_TYPE_PID_T]) +AC_REQUIRE([AC_TYPE_UID_T]) +AC_HAVE_TYPE([long long]) + +AC_REQUIRE([rk_RETSIGTYPE]) + +dnl Checks for header files. +AC_REQUIRE([AC_HEADER_STDC]) +AC_REQUIRE([AC_HEADER_TIME]) + +AC_CHECK_HEADERS([\ + arpa/inet.h \ + arpa/nameser.h \ + config.h \ + crypt.h \ + dbm.h \ + db.h \ + dirent.h \ + errno.h \ + err.h \ + fcntl.h \ + gdbm/ndbm.h \ + grp.h \ + ifaddrs.h \ + ndbm.h \ + net/if.h \ + netdb.h \ + netinet/in.h \ + netinet/in6.h \ + netinet/in_systm.h \ + netinet6/in6.h \ + netinet6/in6_var.h \ + paths.h \ + pwd.h \ + resolv.h \ + rpcsvc/dbm.h \ + rpcsvc/ypclnt.h \ + shadow.h \ + sys/ioctl.h \ + sys/param.h \ + sys/proc.h \ + sys/resource.h \ + sys/socket.h \ + sys/sockio.h \ + sys/stat.h \ + sys/sysctl.h \ + sys/time.h \ + sys/tty.h \ + sys/types.h \ + sys/uio.h \ + sys/utsname.h \ + sys/wait.h \ + syslog.h \ + termios.h \ + unistd.h \ + userconf.h \ + usersec.h \ + util.h \ + vis.h \ + winsock.h \ +]) + +AC_REQUIRE([CHECK_NETINET_IP_AND_TCP]) + +AM_CONDITIONAL(have_err_h, test "$ac_cv_header_err_h" = yes) +AM_CONDITIONAL(have_fnmatch_h, test "$ac_cv_header_fnmatch_h" = yes) +AM_CONDITIONAL(have_ifaddrs_h, test "$ac_cv_header_ifaddrs_h" = yes) +AM_CONDITIONAL(have_vis_h, test "$ac_cv_header_vis_h" = yes) + +dnl Check for functions and libraries + +AC_KRB_IPV6 + +AC_FIND_FUNC(socket, socket) +AC_FIND_FUNC(gethostbyname, nsl) +AC_FIND_FUNC(syslog, syslog) +AC_FIND_FUNC(gethostbyname2, inet6 ip6) + +AC_FIND_FUNC(res_search, resolv, +[ +#include <stdio.h> +#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif +#ifdef HAVE_ARPA_NAMESER_H +#include <arpa/nameser.h> +#endif +#ifdef HAVE_RESOLV_H +#include <resolv.h> +#endif +], +[0,0,0,0,0]) + +AC_FIND_FUNC(dn_expand, resolv, +[ +#include <stdio.h> +#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif +#ifdef HAVE_ARPA_NAMESER_H +#include <arpa/nameser.h> +#endif +#ifdef HAVE_RESOLV_H +#include <resolv.h> +#endif +], +[0,0,0,0,0]) + +AC_BROKEN_SNPRINTF +AC_BROKEN_VSNPRINTF + +AC_BROKEN_GLOB +if test "$ac_cv_func_glob_working" != yes; then + LIBOBJS="$LIBOBJS glob.o" +fi +AM_CONDITIONAL(have_glob_h, test "$ac_cv_func_glob_working" = yes) + + +AC_CHECK_FUNCS([ \ + asnprintf \ + asprintf \ + cgetent \ + getconfattr \ + getrlimit \ + getspnam \ + strsvis \ + strunvis \ + strvis \ + strvisx \ + svis \ + sysconf \ + sysctl \ + uname \ + unvis \ + vasnprintf \ + vasprintf \ + vis \ +]) + +if test "$ac_cv_func_cgetent" = no; then + LIBOBJS="$LIBOBJS getcap.o" +fi + +AC_REQUIRE([AC_FUNC_GETLOGIN]) + +AC_FIND_FUNC_NO_LIBS(getsockopt,, +[#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif], +[0,0,0,0,0]) +AC_FIND_FUNC_NO_LIBS(setsockopt,, +[#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif], +[0,0,0,0,0]) + +AC_FIND_IF_NOT_BROKEN(hstrerror, resolv, +[#ifdef HAVE_NETDB_H +#include <netdb.h> +#endif], +17) +if test "$ac_cv_func_hstrerror" = yes; then +AC_NEED_PROTO([ +#ifdef HAVE_NETDB_H +#include <netdb.h> +#endif], +hstrerror) +fi + +dnl sigh, wish this could be done in a loop +if test "$ac_cv_func_asprintf" = yes; then +AC_NEED_PROTO([ +#include <stdio.h> +#include <string.h>], +asprintf)dnl +fi +if test "$ac_cv_func_vasprintf" = yes; then +AC_NEED_PROTO([ +#include <stdio.h> +#include <string.h>], +vasprintf)dnl +fi +if test "$ac_cv_func_asnprintf" = yes; then +AC_NEED_PROTO([ +#include <stdio.h> +#include <string.h>], +asnprintf)dnl +fi +if test "$ac_cv_func_vasnprintf" = yes; then +AC_NEED_PROTO([ +#include <stdio.h> +#include <string.h>], +vasnprintf)dnl +fi + +AC_FIND_FUNC_NO_LIBS(pidfile,util, +[#ifdef HAVE_UTIL_H +#include <util.h> +#endif],0) + +AC_BROKEN([ \ + chown \ + copyhostent \ + daemon \ + err \ + errx \ + fchown \ + flock \ + fnmatch \ + freeaddrinfo \ + freehostent \ + gai_strerror \ + getaddrinfo \ + getcwd \ + getdtablesize \ + getegid \ + geteuid \ + getgid \ + gethostname \ + getifaddrs \ + getipnodebyaddr \ + getipnodebyname \ + getnameinfo \ + getopt \ + gettimeofday \ + getuid \ + getusershell \ + initgroups \ + innetgr \ + iruserok \ + lstat \ + memmove \ + mkstemp \ + putenv \ + rcmd \ + readv \ + recvmsg \ + sendmsg \ + setegid \ + setenv \ + seteuid \ + strcasecmp \ + strdup \ + strerror \ + strftime \ + strlcat \ + strlcpy \ + strlwr \ + strncasecmp \ + strndup \ + strnlen \ + strptime \ + strsep \ + strsep_copy \ + strtok_r \ + strupr \ + swab \ + unsetenv \ + verr \ + verrx \ + vsyslog \ + vwarn \ + vwarnx \ + warn \ + warnx \ + writev \ +]) + +AC_BROKEN2(inet_aton, +[#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif +#ifdef HAVE_ARPA_INET_H +#include <arpa/inet.h> +#endif], +[0,0]) + +AC_BROKEN2(inet_ntop, +[#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif +#ifdef HAVE_ARPA_INET_H +#include <arpa/inet.h> +#endif], +[0, 0, 0, 0]) + +AC_BROKEN2(inet_pton, +[#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif +#ifdef HAVE_ARPA_INET_H +#include <arpa/inet.h> +#endif], +[0,0,0]) + +dnl +dnl Check for sa_len in struct sockaddr, +dnl needs to come before the getnameinfo test +dnl +AC_HAVE_STRUCT_FIELD(struct sockaddr, sa_len, [#include <sys/types.h> +#include <sys/socket.h>]) + +if test "$ac_cv_func_getnameinfo" = "yes"; then + rk_BROKEN_GETNAMEINFO + if test "$ac_cv_func_getnameinfo_broken" = yes; then + LIBOBJS="$LIBOBJS getnameinfo.o" + fi +fi + +AC_NEED_PROTO([#include <stdlib.h>], setenv) +AC_NEED_PROTO([#include <stdlib.h>], unsetenv) +AC_NEED_PROTO([#include <unistd.h>], gethostname) +AC_NEED_PROTO([#include <unistd.h>], mkstemp) +AC_NEED_PROTO([#include <unistd.h>], getusershell) + +AC_NEED_PROTO([ +#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif +#ifdef HAVE_ARPA_INET_H +#include <arpa/inet.h> +#endif], +inet_aton) + +AC_FIND_FUNC_NO_LIBS(crypt, crypt)dnl + +AC_REQUIRE([rk_BROKEN_REALLOC])dnl + +dnl AC_KRB_FUNC_GETCWD_BROKEN + +dnl +dnl Checks for prototypes and declarations +dnl + +AC_PROTO_COMPAT([ +#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif +#ifdef HAVE_ARPA_INET_H +#include <arpa/inet.h> +#endif +#ifdef HAVE_NETDB_H +#include <netdb.h> +#endif +], +gethostbyname, struct hostent *gethostbyname(const char *)) + +AC_PROTO_COMPAT([ +#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif +#ifdef HAVE_ARPA_INET_H +#include <arpa/inet.h> +#endif +#ifdef HAVE_NETDB_H +#include <netdb.h> +#endif +], +gethostbyaddr, struct hostent *gethostbyaddr(const void *, size_t, int)) + +AC_PROTO_COMPAT([ +#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif +#ifdef HAVE_ARPA_INET_H +#include <arpa/inet.h> +#endif +#ifdef HAVE_NETDB_H +#include <netdb.h> +#endif +], +getservbyname, struct servent *getservbyname(const char *, const char *)) + +AC_PROTO_COMPAT([ +#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif +], +getsockname, int getsockname(int, struct sockaddr*, socklen_t*)) + +AC_PROTO_COMPAT([ +#ifdef HAVE_SYSLOG_H +#include <syslog.h> +#endif +], +openlog, void openlog(const char *, int, int)) + +AC_NEED_PROTO([ +#ifdef HAVE_CRYPT_H +#include <crypt.h> +#endif +#ifdef HAVE_UNISTD_H +#include <unistd.h> +#endif +], +crypt) + +AC_NEED_PROTO([ +#include <string.h> +], +strtok_r) + +AC_NEED_PROTO([ +#include <string.h> +], +strsep) + +dnl variables + +rk_CHECK_VAR(h_errno, +[#ifdef HAVE_SYS_TYPES_H +#include <sys/types.h> +#endif +#ifdef HAVE_NETDB_H +#include <netdb.h> +#endif]) + +rk_CHECK_VAR(h_errlist, +[#ifdef HAVE_NETDB_H +#include <netdb.h> +#endif]) + +rk_CHECK_VAR(h_nerr, +[#ifdef HAVE_NETDB_H +#include <netdb.h> +#endif]) + +rk_CHECK_VAR([__progname], +[#ifdef HAVE_ERR_H +#include <err.h> +#endif]) + +AC_CHECK_DECLARATION([#include <stdlib.h> +#ifdef HAVE_UNISTD_H +#include <unistd.h> +#endif], optarg) +AC_CHECK_DECLARATION([#include <stdlib.h> +#ifdef HAVE_UNISTD_H +#include <unistd.h> +#endif], optind) +AC_CHECK_DECLARATION([#include <stdlib.h> +#ifdef HAVE_UNISTD_H +#include <unistd.h> +#endif], opterr) +AC_CHECK_DECLARATION([#include <stdlib.h> +#ifdef HAVE_UNISTD_H +#include <unistd.h> +#endif], optopt) + +AC_CHECK_DECLARATION([#include <stdlib.h>], environ) + +dnl +dnl Check for fields in struct tm +dnl + +AC_HAVE_STRUCT_FIELD(struct tm, tm_gmtoff, [#include <time.h>]) +AC_HAVE_STRUCT_FIELD(struct tm, tm_zone, [#include <time.h>]) + +dnl +dnl or do we have a variable `timezone' ? +dnl + +rk_CHECK_VAR(timezone,[#include <time.h>]) + +AC_HAVE_TYPE([sa_family_t],[#include <sys/socket.h>]) +AC_HAVE_TYPE([socklen_t],[#include <sys/socket.h>]) +AC_HAVE_TYPE([struct sockaddr], [#include <sys/socket.h>]) +AC_HAVE_TYPE([struct sockaddr_storage], [#include <sys/socket.h>]) +AC_HAVE_TYPE([struct addrinfo], [#include <netdb.h>]) +AC_HAVE_TYPE([struct ifaddrs], [#include <ifaddrs.h>]) + +dnl +dnl Check for struct winsize +dnl + +AC_KRB_STRUCT_WINSIZE + +dnl +dnl Check for struct spwd +dnl + +AC_KRB_STRUCT_SPWD + +dnl won't work with automake +dnl moved to AC_OUTPUT in configure.in +dnl AC_CONFIG_FILES($1/Makefile) + +LIB_roken="${LIB_roken} \$(LIB_crypt) \$(LIB_dbopen)" + +AC_SUBST(DIR_roken)dnl +AC_SUBST(LIB_roken)dnl +AC_SUBST(INCLUDES_roken)dnl +])
\ No newline at end of file diff --git a/crypto/heimdal/cf/roken.m4 b/crypto/heimdal/cf/roken.m4 new file mode 100644 index 000000000000..f5a867846c39 --- /dev/null +++ b/crypto/heimdal/cf/roken.m4 @@ -0,0 +1,64 @@ +dnl $Id: roken.m4,v 1.2 2000/07/08 15:50:34 assar Exp $ +dnl +dnl try to look for an installed roken library with sufficient stuff +dnl +dnl set LIB_roken to the what we should link with +dnl set DIR_roken to if the directory should be built +dnl set CPPFLAGS_roken to stuff to add to CPPFLAGS + +dnl AC_ROKEN(version,directory-to-try,roken-dir,fallback-library,fallback-cppflags) +AC_DEFUN(AC_ROKEN, [ + +AC_ARG_WITH(roken, +[ --with-roken=dir use the roken library in dir], +[if test "$withval" = "no"; then + AC_MSG_ERROR(roken is required) +fi]) + +save_CPPFLAGS="${CPPFLAGS}" + +case $with_roken in +yes|"") + dirs="$2" ;; +*) + dirs="$with_roken" ;; +esac + +roken_installed=no + +for i in $dirs; do + +AC_MSG_CHECKING(for roken in $i) + +CPPFLAGS="-I$i/include ${CPPFLAGS}" + +AC_TRY_CPP( +[#include <roken.h> +#if ROKEN_VERSION < $1 +#error old roken version, should be $1 +fail +#endif +],[roken_installed=yes; break]) + +AC_MSG_RESULT($roken_installed) + +done + +CPPFLAGS="$save_CPPFLAGS" + +if test "$roken_installed" != "yes"; then + DIR_roken="roken" + LIB_roken='$4' + CPPFLAGS_roken='$5' + AC_CONFIG_SUBDIRS(lib/roken) +else + LIB_roken="$i/lib/libroken.la" + CPPFLAGS_roken="-I$i/include" +fi + +LIB_roken="${LIB_roken} \$(LIB_crypt) \$(LIB_dbopen)" + +AC_SUBST(LIB_roken)dnl +AC_SUBST(DIR_roken)dnl +AC_SUBST(CPPFLAGS_roken)dnl +]) diff --git a/crypto/heimdal/doc/migration.texi b/crypto/heimdal/doc/migration.texi new file mode 100644 index 000000000000..90deed775335 --- /dev/null +++ b/crypto/heimdal/doc/migration.texi @@ -0,0 +1,43 @@ +@c $Id: migration.texi,v 1.2 2001/01/28 22:03:36 assar Exp $ + +@node Migration, Windows 2000 compatability, Kerberos 4 issues, Top +@chapter Migration + +@section General issues + +When migrating from a Kerberos 4 KDC. + +@section Order in what to do things: + +@itemize @bullet + +@item Convert the database, check all principals that hprop complains +about. + +@samp{hprop -n --source=<NNN>| hpropd -n} + +Replace <NNN> with whatever source you have, like krb4-db or krb4-dump. + +@item Run a Kerberos 5 slave for a while. + +@c XXX Add you slave first to your kdc list in you kdc. + +@item Figure out if it does everything you want it to. + +Make sure that all things that you use works for you. + +@item Let a small number of controlled users use Kerberos 5 tools. + +Find a sample population of your users and check what programs they use, +you can also check the kdc-log to check what ticket are checked out. + +@item Burn the bridge and change the master. +@item Let all users use the Kerberos 5 tools by default. +@item Turn off services that do not need Kerberos 4 authentication. + +Things that might be hard to get away is old programs with support for +Kerberos 4. Example applications are old Eudora installations using +KPOP, and Zephyr. Eudora can use the Kerberos 4 kerberos in the Heimdal +kdc. + +@end itemize diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt new file mode 100644 index 000000000000..85d745684b2a --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on July 17, 2000. diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt new file mode 100644 index 000000000000..202d44e8639c --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt @@ -0,0 +1,587 @@ +CAT working group M. Swift +Internet Draft J. Brezak +Document: draft-brezak-win2k-krb-rc4-hmac-03.txt Microsoft +Category: Informational June 2000 + + + The Windows 2000 RC4-HMAC Kerberos encryption type + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. Internet-Drafts are + draft documents valid for a maximum of six months and may be + updated, replaced, or obsoleted by other documents at any time. It + is inappropriate to use Internet- Drafts as reference material or to + cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + The Windows 2000 implementation of Kerberos introduces a new + encryption type based on the RC4 encryption algorithm and using an + MD5 HMAC for checksum. This is offered as an alternative to using + the existing DES based encryption types. + + The RC4-HMAC encryption types are used to ease upgrade of existing + Windows NT environments, provide strong crypto (128-bit key + lengths), and provide exportable (meet United States government + export restriction requirements) encryption. + + The Windows 2000 implementation of Kerberos contains new encryption + and checksum types for two reasons: for export reasons early in the + development process, 56 bit DES encryption could not be exported, + and because upon upgrade from Windows NT 4.0 to Windows 2000, + accounts will not have the appropriate DES keying material to do the + standard DES encryption. Furthermore, 3DES is not available for + export, and there was a desire to use a single flavor of encryption + in the product for both US and international products. + + As a result, there are two new encryption types and one new checksum + type introduced in Windows 2000. + + +2. Conventions used in this document + + + +Swift Category - Informational 1 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + +3. Key Generation + + On upgrade from existing Windows NT domains, the user accounts would + not have a DES based key available to enable the use of DES base + encryption types specified in RFC 1510. The key used for RC4-HMAC is + the same as the existing Windows NT key (NT Password Hash) for + compatibility reasons. Once the account password is changed, the DES + based keys are created and maintained. Once the DES keys are + available DES based encryption types can be used with Kerberos. + + The RC4-HMAC String to key function is defined as follow: + + String2Key(password) + + K = MD4(UNICODE(password)) + + The RC4-HMAC keys are generated by using the Windows UNICODE version + of the password. Each Windows UNICODE character is encoded in + little-endian format of 2 octets each. Then performing an MD4 [6] + hash operation on just the UNICODE characters of the password (not + including the terminating zero octets). + + For an account with a password of "foo", this String2Key("foo") will + return: + + 0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, + 0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc + +4. Basic Operations + + The MD5 HMAC function is defined in [3]. It is used in this + encryption type for checksum operations. Refer to [3] for details on + its operation. In this document this function is referred to as + HMAC(Key, Data) returning the checksum using the specified key on + the data. + + The basic MD5 hash operation is used in this encryption type and + defined in [7]. In this document this function is referred to as + MD5(Data) returning the checksum of the data. + + RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A + compatible cipher is described in [8]. In this document the function + is referred to as RC4(Key, Data) returning the encrypted data using + the specified key on the data. + + These encryption types use key derivation as defined in [9] (RFC- + 1510BIS) in Section titled "Key Derivation". With each message, the + message type (T) is used as a component of the keying material. This + summarizes the different key derivation values used in the various + +Swift Category - Informational 2 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + operations. Note that these differ from the key derivations used in + other Kerberos encryption types. + + T = 1 for TS-ENC-TS in the AS-Request + T = 8 for the AS-Reply + T = 7 for the Authenticator in the TGS-Request + T = 8 for the TGS-Reply + T = 2 for the Server Ticket in the AP-Request + T = 11 for the Authenticator in the AP-Request + T = 12 for the Server returned AP-Reply + T = 15 in the generation of checksum for the MIC token + T = 0 in the generation of sequence number for the MIC token + T = 13 in the generation of checksum for the WRAP token + T = 0 in the generation of sequence number for the WRAP token + T = 0 in the generation of encrypted data for the WRAPPED token + + All strings in this document are ASCII unless otherwise specified. + The lengths of ASCII encoded character strings include the trailing + terminator character (0). + + The concat(a,b,c,...) function will return the logical concatenation + (left to right) of the values of the arguments. + + The nonce(n) function returns a pseudo-random number of "n" octets. + +5. Checksum Types + + There is one checksum type used in this encryption type. The + Kerberos constant for this type is: + #define KERB_CHECKSUM_HMAC_MD5 (-138) + + The function is defined as follows: + + K - is the Key + T - the message type, encoded as a little-endian four byte integer + + CHKSUM(K, T, data) + + Ksign = HMAC(K, "signaturekey") //includes zero octet at end + tmp = MD5(concat(T, data)) + CHKSUM = HMAC(Ksign, tmp) + + +6. Encryption Types + + There are two encryption types used in these encryption types. The + Kerberos constants for these types are: + #define KERB_ETYPE_RC4_HMAC 23 + #define KERB_ETYPE_RC4_HMAC_EXP 24 + + The basic encryption function is defined as follow: + + T = the message type, encoded as a little-endian four byte integer. + +Swift Category - Informational 3 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + BYTE L40[14] = "fortybits"; + BYTE SK = "signaturekey"; + + ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 10 + 4, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + add_8_random_bytes(data, data_len, conf_plus_data); + HMAC (K2, conf_plus_data, 8 + data_len, checksum); + HMAC (K1, checksum, 16, K3); + RC4(K3, conf_plus_data, 8 + data_len, edata + 16); + memcpy (edata, checksum, 16); + edata_len = 16 + 8 + data_len; + } + + DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + HMAC (K1, edata, 16, K3); // checksum is at edata + RC4(K3, edata + 16, edata_len - 16, edata + 16); + data_len = edata_len - 16 - 8; + memcpy (data, edata + 16 + 8, data_len); + + // verify generated and received checksums + HMAC (K2, edata + 16, edata_len - 16, checksum); + if (memcmp(edata, checksum, 16) != 0) + printf("CHECKSUM ERROR !!!!!!\n"); + } + + The header field on the encrypted data in KDC messages is: + + typedef struct _RC4_MDx_HEADER { + UCHAR Checksum[16]; + UCHAR Confounder[8]; + } RC4_MDx_HEADER, *PRC4_MDx_HEADER; + + The KDC message is encrypted using the ENCRYPT function not + including the Checksum in the RC4_MDx_HEADER. + + +Swift Category - Informational 4 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + +7. Key Strength Negotiation + + A Kerberos client and server can negotiate over key length if they + are using mutual authentication. If the client is unable to perform + full strength encryption, it may propose a key in the "subkey" field + of the authenticator, using a weaker encryption type. The server + must then either return the same key or suggest its own key in the + subkey field of the AP reply message. The key used to encrypt data + is derived from the key returned by the server. If the client is + able to perform strong encryption but the server is not, it may + propose a subkey in the AP reply without first being sent a subkey + in the authenticator. + +8. GSSAPI Kerberos V5 Mechanism Type + +8.1 Mechanism Specific Changes + + The GSSAPI per-message tokens also require new checksum and + encryption types. The GSS-API per-message tokens must be changed to + support these new encryption types (See [5] Section 1.2.2). The + sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption + is: + Byte 4..5 SEAL_ALG 0x10 0x00 - RC4 + + The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: + Byte 2..3 SGN ALG 0x11 0x00 - HMAC + + The only support quality of protection is: + #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 + + In addition, when using an RC4 based encryption type, the sequence + number is sent in big-endian rather than little-endian order. + + The Windows 2000 implementation also defines new GSSAPI flags in the + initial token passed when initializing a security context. These + flags are passed in the checksum field of the authenticator (See [5] + Section 1.1.1). + + GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s + implementation of DCE RPC, which initially expected three legs of + authentication. Setting this flag causes an extra AP reply to be + sent from the client back to the server after receiving the server’s + AP reply. In addition, the context negotiation tokens do not have + GSSAPI framing - they are raw AP message and do not include object + identifiers. + #define GSS_C_DCE_STYLE 0x1000 + + + +Swift Category - Informational 5 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the + server that it should only allow the server application to identify + the client by name and ID, but not to impersonate the client. + #define GSS_C_IDENTIFY_FLAG 0x2000 + + GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the + client wants to be informed of extended error information. In + particular, Windows 2000 status codes may be returned in the data + field of a Kerberos error message. This allows the client to + understand a server failure more precisely. In addition, the server + may return errors to the client that are normally handled at the + application layer in the server, in order to let the client try to + recover. After receiving an error message, the client may attempt to + resubmit an AP request. + #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 + + These flags are only used if a client is aware of these conventions + when using the SSPI on the Windows platform, they are not generally + used by default. + + When NetBIOS addresses are used in the GSSAPI, they are identified + by the GSS_C_AF_NETBIOS value. This value is defined as: + #define GSS_C_AF_NETBIOS 0x14 + NetBios addresses are 16-octet addresses typically composed of 1 to
th
15 characters, trailing blank (ascii char 20) filled, with a 16 + octet of 0x0. + +8.2 GSSAPI Checksum Type + + The GSSAPI checksum type and algorithm is defined in Section 5. Only + the first 8 octets of the checksum are used. The resulting checksum + is stored in the SGN_CKSUM field (See [5] Section 1.2) for + GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). + + MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, + MIC_seq, MIC_checksum) + { + HMAC (K, SK, 13, K4); + T = 15; + memcpy (T_plus_hdr_plus_msg + 00, &T, 4); + memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8); + // 0101 1100 FFFFFFFF + memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); + MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); + HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); + memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K5); + }else{ + HMAC (K, &T, 4, K5); + +Swift Category - Informational 6 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + } + if (fRC4_EXP) memset(K5+7, 0xAB, 9); + HMAC(K5, MIT_checksum, 8, K6); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K6, seq_plus_direction, 8, MIC_seq); + } + +8.3 GSSAPI Encryption Types + + There are two encryption types for GSSAPI message tokens, one that + is 128 bits in strength, and one that is 56 bits in strength as + defined in Section 6. + + All padding is rounded up to 1 byte. One byte is needed to say that + there is 1 byte of padding. The DES based mechanism type uses 8 byte + padding. See [5] Section 1.2.2.3. + + The encryption mechanism used for GSS wrap based messages is as + follow: + + + WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, + WRAP_seq, WRAP_checksum, edata, edata_len) + { + HMAC (K, SK, 13, K7); + T = 13; + PAD = 1; + memcpy (T_hdr_conf_msg_pad + 00, &T, 4); + memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 + FFFFFFFF + memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); + memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); + MD5 (T_hdr_conf_msg_pad, + 4 + 8 + 8 + msg_len + 1, + MD5_of_T_hdr_conf_msg_pad); + HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); + memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 + bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K8); + }else{ + HMAC (K, &T, 4, K8); + } + if (fRC4_EXP) memset(K8+7, 0xAB, 9); + HMAC(K8, WRAP_checksum, 8, K9); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + +Swift Category - Informational 7 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K9, seq_plus_direction, 8, WRAP_seq); + + for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte + of key with 0xF0 + T = 0; + if (fRC4_EXP){ + *(DWORD *)(L40+10) = T; + HMAC(K10, L40, 14, K11); + memset(K11+7, 0xAB, 9); + }else{ + HMAC(K10, &T, 4, K11); + } + HMAC(K11, seq_num, 4, K12); + RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, + edata); /* skip T & hdr */ + edata_len = 8 + msg_len + 1; // conf + msg_len + pad + } + + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + +9. Security Considerations + + Care must be taken in implementing this encryption type because it + uses a stream cipher. If a different IV isn’t used in each direction + when using a session key, the encryption is weak. By using the + sequence number as an IV, this is avoided. + +10. Acknowledgements + + We would like to thank Salil Dangi for the valuable input in + refining the descriptions of the functions and review input. + +11. References + + 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + 3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, February 1997 + + 4 Kohl, J., Neuman, C., "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993 + + + +Swift Category - Informational 8 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + 5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, + June 1996 + + 6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April + 1992 + + 7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April + 1992 + + 8 Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption + Algorithm", Work in Progress. + + 9 RC4 is a proprietary encryption algorithm available under license + from RSA Data Security Inc. For licensing information, contact: + + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + 10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- + 04.txt, June 25, 1999 + + +12. Author's Addresses + + Mike Swift + Dept. of Computer Science + Sieg Hall + University of Washington + Seattle, WA 98105 + Email: mikesw@cs.washington.edu + + John Brezak + Microsoft + One Microsoft Way + Redmond, Washington + Email: jbrezak@microsoft.com + + + + + + + + + + + + + + + +Swift Category - Informational 9 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + +13. Full Copyright Statement + + "Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and + furnished to others, and derivative works that comment on or + otherwise explain it or assist in its implementation may be + prepared, copied, published and distributed, in whole or in + part, without restriction of any kind, provided that the above + copyright notice and this paragraph are included on all such + copies and derivative works. However, this document itself may + not be modified in any way, such as by removing the copyright + notice or references to the Internet Society or other Internet + organizations, except as needed for the purpose of developing + Internet standards in which case the procedures for copyrights + defined in the Internet Standards process must be followed, or + as required to translate it into languages other than English. + + The limited permissions granted above are perpetual and will + not be revoked by the Internet Society or its successors or + assigns. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Swift Category - Informational 10 + diff --git a/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt b/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt new file mode 100644 index 000000000000..89e64524c475 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt @@ -0,0 +1,1594 @@ + +DHC Working Group Ken Hornstein +INTERNET-DRAFT NRL +Category: Standards Track Ted Lemon +<draft-hornstein-dhc-kerbauth-02.txt> Internet Engines, Inc. +20 February 2000 Bernard Aboba +Expires: September 1, 2000 Microsoft + Jonathan Trostle + Cisco Systems + + DHCP Authentication Via Kerberos V + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other groups +may also distribute working documents as Internet- Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference material +or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +The distribution of this memo is unlimited. + +1. Copyright Notice + +Copyright (C) The Internet Society (2000). All Rights Reserved. + +2. Abstract + +The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for +host configuration. In some circumstances, it is useful for the DHCP +client and server to be able to mutually authenticate as well as to +guarantee the integrity of DHCP packets in transit. This document +describes how Kerberos V may be used in order to allow a DHCP client and +server to mutually authenticate as well as to protect the integrity of +the DHCP exchange. The protocol described in this document is capable of +handling both intra-realm and inter-realm authentication. + + + + + + +Hornstein, et al. Standards Track [Page 1] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +3. Introduction + +The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for +host configuration. In some circumstances, it is useful for the DHCP +client and server to be able to mutually authenticate as well as to +guarantee the integrity of DHCP packets in transit. This document +describes how Kerberos V may be used in order to allow a DHCP client and +server to mutually authenticate as well as to protect the integrity of +the DHCP exchange. The protocol described in this document is capable +of handling both intra-realm and inter-realm authentication. + +3.1. Terminology + +This document uses the following terms: + +DHCP client + A DHCP client or "client" is an Internet host using DHCP to + obtain configuration parameters such as a network address. + +DHCP server + A DHCP server or "server" is an Internet host that returns + configuration parameters to DHCP clients. + +Home KDC The KDC corresponding to the DHCP client's realm. + +Local KDC The KDC corresponding to the DHCP server's realm. + +3.2. Requirements language + +In this document, the key words "MAY", "MUST, "MUST NOT", "optional", +"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as +described in [1]. + +4. Protocol overview + +In DHCP authentication via Kerberos V, DHCP clients and servers utilize +a Kerberos session key in order to compute a message integrity check +value included within the DHCP authentication option. The message +integrity check serves to authenticate as well as integrity protect the +messages, while remaining compatible with the operation of a DHCP relay. +Replay protection is also provided by a replay counter within the +authentication option, as described in [3]. + +Each server maintains a list of session keys and identifiers for +clients, so that the server can retrieve the session key and identifier +used by a client to which the server has provided previous configuration +information. Each server MUST save the replay counter from the previous +authenticated message. To avoid replay attacks, the server MUST discard + + + +Hornstein, et al. Standards Track [Page 2] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +any incoming message whose replay counter is not strictly greater than +the replay counter from the previous message. + +DHCP authentication, described in [3], must work within the existing +DHCP state machine described in [4]. For a client in INIT state, this +means that the client must obtain a valid TGT, as well as a session key, +within the two round-trips provided by the +DHCPDISCOVER/OFFER/REQUEST/ACK sequence. + +In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP +server within the DHCPDISCOVER message. The DHCP server then completes +the AS_REQ using the IP address to be assigned to the client, and +submits this to the client's home KDC in order to obtain a TGT on the +client's behalf. Once the home KDC responds with an AS_REP, the DHCP +server extracts the client TGT and submits this along with its own TGT +to the home KDC, in order to obtain a user-to-user ticket to the DHCP +client. The AS_REP as well as the AP_REQ are included by the DHCP server +in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain +a home realm TGT and TGT session key, using the latter to decrypt the +user-to-user ticket to obtain the user-to-user session key. It is the +user-to-user session key that is used to authenticate and integrity +protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly, +this same session key is used to compute the integrity attribute in the +server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3]. + +In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit +the home realm TGT in the DHCPREQUEST, along with authenticating and +integrity protecting the message using an integrity attribute within the +authentication option. The integrity attribute is computed using the +existing session key. The DHCP server can then return a renewed user- +to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST +message from a client in INIT-REBOOT state can only be validated by +servers that used the same session key to compute the integrity +attribute in their DHCPOFFER messages. + +Other servers will discard the DHCPREQUEST messages. Thus, only servers +that used the user-to-user session key selected by the client will be +able to determine that their offered configuration information was not +selected, returning the offered network address to the server's pool of +available addresses. The servers that cannot validate the DHCPREQUEST +message will eventually return their offered network addresses to their +pool of available addresses as described in section 3.1 of the DHCP +specification [4]. + +When sending a DHCPINFORM, there are two possible procedures. If the +client knows the DHCP server it will be interacting with, then it can +obtain a ticket to the DHCP server from the local realm KDC. This will +require obtaining a TGT to its home realm, as well as possibly a cross- + + + +Hornstein, et al. Standards Track [Page 3] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +realm TGT to the local realm if the local and home realms differ. Once +the DHCP client has a local realm TGT, it can then request a DHCP server +ticket in a TGS_REQ. The DHCP client can then include AP_REQ and +integrity attributes within the DHCPINFORM. The integrity attribute is +computed as described in [3], using the session key obtained from the +TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated +using the same session key. + +If the DHCP client does not know the DHCP server it is interacting with +then it will not be able to obtain a ticket to it and a different +procedure is needed. In this case, the client will include in the +DHCPINFORM an authentication option with a ticket attribute containing +its home realm TGT. The DHCP server will then use this TGT in order to +request a user-to-user ticket from the home KDC in a TGS_REQ. The DHCP +server will return the user-to-user ticket and will authenticate and +integrity protect the DHCPACK/DHCPNAK message. This is accomplished by +including AP_REQ and integrity attributes within the authentication +option included with the DHCPACK/DHCPNAK messages. + +In order to support the DHCP client's ability to authenticate the DHCP +server in the case where the server name is unknown, the Kerberos +principal name for the DHCP server must be of type KRB_NT_SRV_HST with +the service name component equal to 'dhcp'. For example, the DHCP server +principal name for the host srv.foo.org would be of the form +dhcp/srv.foo.org. The client MUST validate that the DHCP server +principal name has the above format. This convention requires that the +administrator ensure that non-DHCP server principals do not have names +that match the above format. + +4.1. Authentication Option Format + +A summary of the authentication option format for DHCP authentication +via Kerberos V is shown below. The fields are transmitted from left to +right. + +0 1 2 3 +0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Code | Length | Protocol | Algorithm | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Global Replay Counter | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Global Replay Counter | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attributes... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Code + + + +Hornstein, et al. Standards Track [Page 4] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + TBD - DHCP Authentication + +Length + + The length field is a single octet and indicates the length of the + Protocol, Algorith, and Authentication Information fields. Octets + outside the range of the length field should be ignored on reception. + +Protocol + + TBD - DHCP Kerberos V authentication + +Algorithm + + The algorithm field is a single octet and defines the specific + algorithm to be used for computation of the authentication option. + Values for the field are as follows: + + 0 - reserved + 1 - HMAC-MD5 + 2 - HMAC-SHA + 3 - 255 reserved + +Global Replay Counter + + As described in [3], the global replay counter field is 8 octets in + length. It MUST be set to the value of a monotonically increasing + counter. Using a counter value such as the current time of day (e.g., + an NTP-format timestamp [10]) can reduce the danger of replay + attacks. + +Attributes + + The attributes field consists of type-length-value attributes of the + following format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Reserved | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Type + The type field is a single octet and is defined as follows: + + 0 - Integrity check + + + +Hornstein, et al. Standards Track [Page 5] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + 1 - TICKET + 2 - Authenticator + 3 - EncTicketPart + 10 - AS_REQ + 11 - AS_REP + 12 - TGS_REQ + 13 - TGS_REP + 14 - AP_REQ + 15 - AP_REP + 20 - KRB_SAFE + 21 - KRB_PRIV + 22 - KRB_CRED + 25 - EncASRepPart + 26 - EncTGSRepPart + 27 - EncAPRepPart + 28 - EncKrbPrvPart + 29 - EncKrbCredPart + 30 - KRB_ERROR + + Note that the values of the Type field are the same as in the + Kerberos MSG-TYPE field. As a result, no new number spaces are + created for IANA administration. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hornstein, et al. Standards Track [Page 6] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + The following attribute types are allowed within the following + messages: + + DISCOVER OFFER REQUEST DECLINE # Attribute + -------------------------------------------------------- + 0 1 1 1 0 Integrity check + 0 0 0-1 0 1 Ticket + 1 0 0 0 10 AS_REQ + 0 1 0 0 11 AS_REP + 0 1 0 0 14 AP_REQ + 0 0-1 0 0 30 KRB_ERROR + + RELEASE ACK NAK INFORM INFORM # Attribute + w/known w/unknown + server server + --------------------------------------------------------------- + 1 1 1 1 0 0 Integrity check + 0 0 0 0 1 1 Ticket + 0 0 0 0 0 10 AS_REQ + 0 0 0 0 0 11 AS_REP + 0 0-1 0 1 0 14 AP_REQ + 0 0 0-1 0 0 30 KRB_ERROR + +4.2. Client behavior + +The following section, which incorporates material from [3], describes +client behavior in detail. + +4.2.1. INIT state + +When in INIT state, the client behaves as follows: + + +[1] As described in [3], the client MUST include the authentication + request option in its DHCPDISCOVER message along with option 61 + [11] to identify itself uniquely to the server. An AS_REQ attribute + MUST be included within the authentication request option. This + (incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags + and MAY include pre-authentication data (PADATA) if the client + knows what PADATA its home KDC will require. The ADDRESSES field in + the AS_REQ will be ommitted since the client does not yet know its + IP address. The ETYPE field will be set to an encryption type that + the client can accept. + +[2] The client MUST validate DHCPOFFER messages that include an + authentication option. Messages including an authentication option + with a KRB_ERROR attribute and no integrity attribute are treated + as though they are unauthenticated. More typically, authentication + + + +Hornstein, et al. Standards Track [Page 7] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + options within the DHCPOFFER message will include AS_REP, AP_REQ, + and integrity attributes. To validate the authentication option, + the client decrypts the enc-part of the AS_REP in order to obtain + the TGT session key. This is used to decrypt the enc-part of the + AP_REQ in order to obtain the user-to-user session key. The user- + to-user session key is then used to compute the message integrity + check as described in [3], and the computed value is compared to + the value within the integrity attribute. The client MUST discard + any messages which fail to pass validation and MAY log the + validation failure. + + As described in [3], the client selects one DHCPOFFER message as + its selected configuration. If none of the DHCPOFFER messages + received by the client include an authentication option, the client + MAY choose an unauthenticated message as its selected + configuration. DHCPOFFER messages including an authentication + option with a KRB_ERROR attribute and no integrity attribute are + treated as though they are unauthenticated. The client SHOULD be + configurable to accept or reject unauthenticated DHCPOFFER + messages. + +[3] The client replies with a DHCPREQUEST message that MUST include an + authentication option. The authentication option MUST include an + integrity attribute, computed as described in [3], using the user + to user session key recovered in step 2. + +[4] As noted in [3], the client MUST validate a DHCPACK message from + the server that includes an authentication option. DHCPACK or + DHCPNAK messages including an authentication option with a + KRB_ERROR attribute and no integrity attribute are treated as + though they are unauthenticated. The client MUST silently discard + the DHCPACK if the message fails to pass validation and MAY log the + validation failure. If the DHCPACK fails to pass validation, the + client MUST revert to the INIT state and return to step 1. The + client MAY choose to remember which server replied with an invalid + DHCPACK message and discard subsequent messages from that server. + +4.2.2. INIT-REBOOT state + +When in INIT-REBOOT state, if the user-to-user ticket is still valid, +the client MUST re-use the session key from the DHCP server user-to-user +ticket in its DHCPREQUEST message. This is used to generate the +integrity attribute contained within the authentication option, as +described in [3]. In the DHCPREQUEST, the DHCP client also includes its +home realm TGT in a ticket attribute in the authentication option in +order to assist the DHCP server in renewing the user-to-user ticket. To +ensure that the user-to-user ticket remains valid throughout the DHCP +lease period so that the renewal process can proceed, the Kerberos + + + +Hornstein, et al. Standards Track [Page 8] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +ticket lifetime SHOULD be set to exceed the DHCP lease time. If the +user-to-user ticket is expired, then the client MUST return to the INIT +state. + +The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages +if no authenticated messages were received. DHCPACK/DHCPNAK messages +with an authentication option containing a KRB_ERROR attribute and no +integrity attribute are treated as though they are unauthenticated. The +client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK +messages as specified in section 3.2 of the DHCP specification [4]. + +4.2.3. RENEWING state + +When in RENEWING state, the DHCP client can be assumed to have a valid +IP address, as well as a TGT to the home realm, a user-to-user ticket +provided by the DHCP server, and a session key with the DHCP server, all +obtained during the original DHCP conversation. If the user-to-user +ticket is still valid, the client MUST re-use the session key from the +user-to-user ticket in its DHCPREQUEST message to generate the integrity +attribute contained within the authentication option. + +Since the DHCP client can renew the TGT to the home realm, it is +possible for it to continue to hold a valid home realm TGT. However, +since the DHCP client did not obtain the user-to-user ticket on its own, +it will need to rely on the DHCP server to renew this ticket. In the +DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket +attribute in the authentication option in order to assist the DHCP +server in renewing the user-to-user ticket. + +If the DHCP server user-to-user ticket is expired, then the client MUST +return to INIT state. To ensure that the user-to-user ticket remains +valid throughout the DHCP lease period so that the renewal process can +proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP +lease time. If client receives no DHCPACK messages or none of the +DHCPACK messages pass validation, the client behaves as if it had not +received a DHCPACK message in section 4.4.5 of the DHCP specification +[4]. + +4.2.4. REBINDING state + +When in REBINDING state, the DHCP client can be assumed to have a valid +IP address, as well as a TGT to the home realm, a user-to-user ticket +and a session key with the DHCP server, all obtained during the original +DHCP conversation. If the user-to-user ticket is still valid, the +client MUST re-use the session key from the user-to-user ticket in its +DHCPREQUEST message to generate the integrity attribute contained within +the authentication option, as described in [3]. + + + + +Hornstein, et al. Standards Track [Page 9] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +Since the DHCP client can renew the TGT to the home realm, it is +possible for it to continue to hold a valid home realm TGT. However, +since the DHCP client did not obtain the user-to-user ticket on its own, +it will need to rely on the DHCP server to renew this ticket. In the +DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket +attribute in the authentication option in order to assist the DHCP +server in renewing the user-to-user ticket. + +If the user-to-user ticket is expired, then the client MUST return to +INIT state. To ensure that the user-to-user ticket remains valid +throughout the DHCP lease period so that the renewal process can +proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP +lease time. If client receives no DHCPACK messages or none of the +DHCPACK messages pass validation, the client behaves as if it had not +received a DHCPACK message in section 4.4.5 of the DHCP specification +[4]. + +4.2.5. DHCPRELEASE message + +Clients sending a DHCPRELEASE MUST include an authentication option. The +authentication option MUST include an integrity attribute, computed as +described in [3], using the user to user session key. + +4.2.6. DHCPDECLINE message + +Clients sending a DHCPDECLINE MUST include an authentication option. The +authentication option MUST include an integrity attribute, computed as +described in [3], using the user to user session key. + +4.2.7. DHCPINFORM message + +Since the client already has some configuration information, it can be +assumed that it has the ability to obtain a home or local realm TGT +prior to sending the DHCPINFORM. + +If the DHCP client knows which DHCP server it will be interacting with, +then it SHOULD include an authentication option containing AP_REQ and +integrity attributes within the DHCPINFORM. The DHCP client first +requests a TGT to the local realm via an AS_REQ and then using the TGT +returned in the AS_REP to request a ticket to the DHCP server from the +local KDC in a TGS_REQ. The session key obtained from the TGS_REP will +be used to generate the integrity attribute as described in [3]. + +If the DHCP client does not know what DHCP server it will be talking to, +then it cannot obtain a ticket to the DHCP server. In this case, the +DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an +authentication option including a ticket attribute only. The ticket +attribute includes a TGT for the home realm. The client MUST validate + + + +Hornstein, et al. Standards Track [Page 10] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +that the DHCP server name in the received Kerberos AP_REQ message is of +the form dhcp/.... as described in section 4. + +The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages +if no authenticated messages were received. DHCPACK/DHCPNAK messages +with an authentication option containing a KRB_ERROR attribute and no +integrity attribute are treated as though they are unauthenticated. The +client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK +messages as specified in section 3.2 of the DHCP specification [4]. + +4.3. Server behavior + +This section, which relies on material from [3], describes the behavior +of a server in response to client messages. + +4.3.1. After receiving a DHCPDISCOVER message + +For installations where IP addresses are required within tickets, the +DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field +based on the IP address that it will include in the DHCPOFFER. The DHCP +server sends the AS_REQ to the home KDC with the FORWARDABLE flag set. +The home KDC then replies to the DHCP server with an AS_REP. The DHCP +server extracts the client TGT from the AS_REP and forms a TGS_REQ, +which it sends to the home KDC. + +If the DHCP server and client are in different realms, then the DHCP +server will need to obtain a TGT to the home realm from the KDC of its +own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the +DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag +set and includes the client home realm TGT in the ADDITIONAL-TICKETS +field, thus requesting a user-to ticket to the DHCP client. The home +KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user +ticket is encrypted in the client's home realm TGT session key. + +In order to recover the user-to-user session key, the DHCP server +decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP +server uses the session key that it shares with the home realm, obtained +in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to +the home realm. + +The DHCP server then sends a DHCPOFFER to the client, including AS_REP, +AP_REQ and integrity attributes within the authentication option. The +AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the +home KDC. The AP_REQ attribute includes an AP_REQ constructed by the +DHCP server based on the TGS_REP sent to it by the home KDC. The server +also includes an integrity attribute generated as specified in [3] from +the user-to-user session key. The server MUST record the user-to-user +session key selected for the client and use that session key for + + + +Hornstein, et al. Standards Track [Page 11] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +validating subsequent messages with the client. + +4.3.2. After receiving a DHCPREQUEST message + +The DHCP server uses the user-to-user session key in order to validate +the integrity attribute contained within the authentication option, +using the method specified in [3]. If the message fails to pass +validation, it MUST discard the message and MAY choose to log the +validation failure. + +If the message passes the validation procedure, the server responds as +described in [4], including an integrity attribute computed as specified +in [3] within the DHCPACK or DHCPNAK message. + +If the authentication option included within the DHCPREQUEST message +contains a ticket attribute then the DHCP server will use the home realm +TGT included in the ticket attribute in order to renew the user-to-user +ticket, which it returns in an AP_REQ attribute within the DHCPACK. +DHCPACK or DHCPNAK messages then include an integrity attribute +generated as specified in [3], using the new user-to-user session key +included within the AP_REQ. + +4.3.3. After receiving a DHCPINFORM message + +The server MAY choose to accept unauthenticated DHCPINFORM messages, or +only accept authenticated DHCPINFORM messages based on a site policy. + +When a client includes an authentication option in a DHCPINFORM message, +the server MUST respond with an authenticated DHCPACK or DHCPNAK +message. If the DHCPINFORM message includes an authentication option +including AP_REQ and integrity attributes, the DHCP server decrypts the +AP_REQ attribute and then recovers the session key. The DHCP server than +validates the integrity attribute included in the authentication option +using the session key. If the integrity attribute is invalid then the +DHCP server MUST silently discard the DHCPINFORM message. + +If the authentication option only includes a ticket attribute and no +integrity or AP_REQ attributes, then the DHCP server should assume that +the client needs the server to obtain a user-to-user ticket from the +home realm KDC. In this case, the DHCP server includes the client home +realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC. +It then receives a user-to-user ticket from the home realm KDC in a +TGS_REP. The DHCP server will then include AP_REQ and integrity +attributes within the DHCPACK/DHCPNAK. + +If the client does not include an authentication option in the +DHCPINFORM, the server can either respond with an unauthenticated +DHCPACK message, or a DHCPNAK if the server does not accept + + + +Hornstein, et al. Standards Track [Page 12] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +unauthenticated clients. + +4.3.4. After receiving a DHCPRELEASE message + +The DHCP server uses the session key in order to validate the integrity +attribute contained within the authentication option, using the method +specified in [3]. If the message fails to pass validation, it MUST +discard the message and MAY choose to log the validation failure. + +If the message passes the validation procedure, the server responds as +described in [4], marking the client's network address as not allocated. + +4.3.5. After receiving a DHCPDECLINE message + +The DHCP server uses the session key in order to validate the integrity +attribute contained within the authentication option, using the method +specified in [3]. If the message fails to pass validation, it MUST +discard the message and MAY choose to log the validation failure. + +If the message passes the validation procedure, the server proceeds as +described in [4]. + +4.4. Error handling + +When an error condition occurs during a Kerberos exchange, Kerberos +error messages can be returned by either side. These Kerberos error +messages MAY be logged by the receiving and sending parties. + +In some cases, it may be possible for these error messages to be +included within the authentication option via the KRB_ERROR attribute. +However, in most cases, errors will result in messages being silently +discarded and so no response will be returned. + +For example, if the home KDC returns a KRB_ERROR in response to the +AS_REQ submitted by the DHCP server on the client's behalf, then the +DHCP server will conclude that the DHCPDISCOVER was not authentic, and +will silently discard it. + +However, if the AS_REQ included PADATA and the home KDC responds with an +AS_REP, then the DHCP server can conclude that the client is authentic. +If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by +the home KDC in the TGS_REP, then the fault may lie with the DHCP server +rather than with the client. In this case, the DHCP server MAY choose to +return a KRB_ERROR within the authentication option included in the +DHCPOFFER. The client will then treat this as an unauthenticated +DHCPOFFER. + + + + + +Hornstein, et al. Standards Track [Page 13] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +Similarly, if the integrity attribute contained in the DHCPOFFER proves +invalid, the client will silently discard the DHCPOFFER and instead +accept an offer from another server if one is available. If the +integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then +the client behaves as if it did not receive a DHCPACK/DHCPNAK. + +When in INIT-REBOOT, REBINDING or RENEWING state, the client will +include a ticket attribute and integrity attribute within the +authentication option of the DHCPREQUEST, in order to assist the DHCP +server in renewing the user-to-user ticket. If the integrity attribute +is invalid, then the DHCP server MUST silently discard the DHCPREQUEST. + +However, if the integrity attribute is successfully validated by the +DHCP server, but the home realm TGT included in the ticket attribute is +invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in +response to its TGS_REQ to the home KDC. In this case, the DHCP server +MAY respond with a DHCPNAK including a KRB_ERROR attribute and no +integrity attribute within the authentication option. This will force +the client back to the INIT state, where it can receive a valid home +realm TGT. + +Where the client included PADATA in the AS_REQ attribute of the +authentication option within the DHCPDISCOVER and the AS_REQ was +successfully validated by the KDC, the DHCP server will conclude that +the DHCP client is authentic. In this case if the client successfully +validates the integrity attribute in the DHCPOFFER, but the server does +not validate the integrity attribute in the client's DHCPREQUEST, the +server MAY choose to respond with an authenticated DHCPNAK containing a +KRB_ERROR attribute. + +4.5. PKINIT issues + +When public key authentication is supported with Kerberos as described +in [8], the client certificate and a signature accompany the initial +request in the preauthentication fields. As a result, it is conceivable +that the incomplete AS_REQ included in the DHCPDISCOVER packet may +exceed the size of a single DHCP option, or even the MTU size. As noted +in [4], a single option may be as large as 255 octets. If the value to +be passed is larger than this the client concatenates together the +values of multiple instances of the same option. + +4.6. Examples + +4.6.1. INIT state + +In the intra-realm case where the DHCP Kerberos mutual authentication is +successful, the conversation will appear as follows: + + + + +Hornstein, et al. Standards Track [Page 14] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + (Integrity) -> + <- DHCPACK + (Integrity) + +In the case where the KDC returns a KRB_ERROR in response to the AS_REQ, +the server will silently discard the DHCPDISCOVER and the conversation +will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ) -> + AS_REQ -> + <- KRB_ERROR + +In the inter-realm case where the DHCP Kerberos mutual authentication is +successful, the conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +DHCPDISCOVER +(Incomplete + AS_REQ) -> + AS_REQ -> + <- AS_REP + TGS_REQ -> + (cross realm, + for home + KDC) + + + +Hornstein, et al. Standards Track [Page 15] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + <- TGS_REP + + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + (Integrity) -> + <- DHCPACK + (Integrity) + +In the case where the client includes PADATA in the AS_REQ attribute +within the authentication option of the DHCPDISCOVER and the KDC returns +an error-free AS_REP indicating successful validation of the PADATA, the +DHCP server will conclude that the DHCP client is authentic. If the KDC +then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault +that lies with the DHCP server, the server MAY choose not to silently +discard the DHCPDISCOVER. Instead it MAY respond with a DHCPOFFER +including a KRB_ERROR attribute within the authentication option. The +client will then treat this as an unauthenticated DHCPOFFER. The +conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ + w/PADATA) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- KRB_ERROR + <- DHCPOFFER, + (KRB_ERROR) +DHCPREQUEST -> + <- DHCPACK + +In the intra-realm case where the client included PADATA in the AS_REQ +attribute of the authentication option and the AS_REQ was successfully +validated by the KDC, the DHCP server will conclude that the DHCP client +is authentic. In this case if the client successfully validates the +integrity attribute in the DHCPOFFER, but the server does not validate +the integrity attribute in the client's DHCPREQUEST, the server MAY + + + +Hornstein, et al. Standards Track [Page 16] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +choose to respond with an authenticated DHCPNAK containing a KRB_ERROR +attribute. The conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ + w/PADATA) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + (Integrity) -> + <- DHCNAK + (KRB_ERROR, + Integrity) +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +In the intra-realm case where the DHCP client cannot validate the +integrity attribute in the DHCPOFFER, the client silently discards the +DHCPOFFER. The conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + + + +Hornstein, et al. Standards Track [Page 17] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + [To another server] + (Integrity) -> + +In the intra-realm case where the DHCP client cannot validate the +integrity attribute in the DHCPACK, the client reverts to INIT state. +The conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER +(Incomplete + AS_REQ) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + (Integrity) -> + <- DHCPACK + (Integrity) +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +4.6.2. INIT-REBOOT, RENEWING or REBINDING + +In the intra-realm or inter-realm case where the original user-to-user +ticket is still valid, and the DHCP server still has a valid TGT to the +home realm, the conversation will appear as follows: + + DHCP DHCP Home + Client Server KDC +-------------- ------------- --------- + +DHCPREQUEST + (TGT, + Integrity) -> + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPACK + (AP_REQ, + + + +Hornstein, et al. Standards Track [Page 18] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + Integrity) + +In the intra-realm or inter-realm case where the DHCP server validates +the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in +response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to +silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK +to the client instead, using the user-to-user session key previously +established with the client. The conversation appears as follows: + + DHCP DHCP Home + Client Server KDC +-------------- ------------- --------- + +DHCPREQUEST + (TGT, + Integrity) -> + TGS_REQ + U-2-U -> + <- KRB_ERROR + <- DHCPNAK + (KRB_ERROR, + Integrity) +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +In the intra-realm or inter-realm case where the DHCP server cannot +validate the integrity attribute in the DHCPREQUEST, the DHCP server +MUST silently discard the DHCPREQUEST and the conversation will appear +as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- + +DHCPREQUEST + (TGT, + Integrity) -> + Silent discard +[Sequence repeats + until timeout] + +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +In the intra-realm or inter-realm case where the original user-to-user +ticket is still valid, the server validates the integrity attribute in + + + +Hornstein, et al. Standards Track [Page 19] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +the DHCPREQUEST, but the client fails to validate the integrity +attribute in the DHCPACK, the client will silently discard the DHCPACK. +The conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- + +DHCPREQUEST + (TGT, + Integrity) -> + + <- DHCPACK + (AP_REQ, + Integrity) +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +4.6.3. DHCPINFORM (with known DHCP server) + +In the case where the DHCP client knows the DHCP server it will be +interacting with, the DHCP client will obtain a ticket to the DHCP +server and will include AP_REQ and integrity attributes within the +DHCPINFORM. + +Where the DHCP Kerberos mutual authentication is successful, the +conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +AS_REQ -> + <- AS_REP +TGS_REQ -> + <- TGS_REP +DHCPINFORM + (AP_REQ, + Integrity) -> + <- DHCPACK + (Integrity) + +In the inter-realm case where the DHCP Kerberos mutual authentication is +successful, the conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- + + + +Hornstein, et al. Standards Track [Page 20] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +AS_REQ -> + <- AS_REP +TGS_REQ -> + <- TGS_REP +TGS_REQ -> + <- TGS_REP +DHCPINFORM + (AP_REQ, + Integrity) -> + <- DHCPACK + (Integrity) + +In the inter-realm case where the DHCP server fails to validate the +integrity attribute in the DHCPINFORM, the server MUST silently discard +the DHCPINFORM. The conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +TGS_REQ -> + <- TGS_REP +TGS_REQ -> + <- TGS_REP +DHCPINFORM + (AP_REQ, + Integrity) -> + <- DHCPACK + (Integrity) +DHCPINFORM + (AP_REQ, + Integrity) -> + +In the inter-realm case where the DHCP client fails to validate the +integrity attribute in the DHCPACK, the client MUST silently discard the +DHCPACK. The conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +TGS_REQ -> + <- TGS_REP +TGS_REQ -> + <- TGS_REP +DHCPINFORM + + + +Hornstein, et al. Standards Track [Page 21] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + (AP_REQ, + Integrity) -> + +4.6.4. DHCPINFORM (with unknown DHCP server) + +In the case where the DHCP client does not know the DHCP server it will +be interacting with, the DHCP client will only include a ticket +attribute within the DHCPINFORM. Thus the DHCP server will not be able +to validate the authentication option. + +Where the DHCP client is able to validate the DHCPACK and no error +occur, the onversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +AS_REQ -> + <- AS_REP +DHCPINFORM + (Ticket) -> + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPACK + (AP_REQ, + Integrity) + +In the inter-realm case where the DHCP server needs to obtain a TGT to +the home realm, and where the client successfully validates the DHCPACK, +the conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +DHCPINFORM + (Ticket) -> + AS_REQ -> + <- AS_REP + TGS_REQ -> + (cross realm, + for home + KDC) + <- TGS_REP + + TGS_REQ + U-2-U -> + + + +Hornstein, et al. Standards Track [Page 22] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + <- TGS_REP + <- DHCPACK + (AP_REQ, + Integrity) + +In the inter-realm case where the local KDC returns a KRB_ERROR in +response to the TGS_REQ from the DHCP server, the DHCP server MAY return +a KRB_ERROR within the DHCP authentication option included in a DHCPNAK. +The conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +DHCPINFORM + (Ticket) -> + AS_REQ -> + <- AS_REP + TGS_REQ -> + (cross realm, + for home + KDC) + <- KRB_ERROR + <- DHCPNAK + (KRB_ERROR) + + +In the inter-realm case where the DHCP client fails to validate the +integrity attribute in the DHCPACK, the client MUST silently discard the +DHCPACK. The conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +DHCPINFORM + (Ticket) -> + AS_REQ -> + <- AS_REP + TGS_REQ -> + (cross realm, + for home + KDC) + <- TGS_REP + + TGS_REQ + + + +Hornstein, et al. Standards Track [Page 23] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + U-2-U -> + <- TGS_REP + <- DHCPACK + (AP_REQ, + Integrity) +DHCPINFORM + (Ticket) -> + +5. References + + +[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +[2] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service + (V5)", RFC 1510, September 1993. + +[3] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", + Internet draft (work in progress), draft-ietf-dhc- + authentication-11.txt, June 1999. + +[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March + 1997. + +[5] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + +[6] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. + +[7] Jain, V., Congdon, P., Roese, J., "Network Port Authentication", + IEEE 802.1 PAR submission, June 1999. + +[8] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, + J., Trostle, J., "Public Key Cryptography for Initial + Authentication in Kerberos", Internet draft (work in progress), + draft-ietf-cat-kerberos-pk-init-09.txt, June 1999. + +[9] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B., + Medvinsky, A., Hur, M., "Public Key Cryptography for Cross-Realm + Authentication in Kerberos", Internet draft (work in progress), + draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999. + +[10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March + 1992. + +[11] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft + (work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt, + November 1998. + + + +Hornstein, et al. Standards Track [Page 24] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +6. Security Considerations + +DHCP authentication, described in [3], addresses the following threats: + + Modification of messages + Rogue servers + Unauthorized clients + +This section describes how DHCP authentication via Kerberos V addresses +each of these threats. + +6.1. Client security + +As noted in [3], it may be desirable to ensure that IP addresses are +only allocated to authorized clients. This can serve to protect against +denial of service attacks. To address this issue it is necessary for +DHCP client messages to be authenticated. In order to guard against +message modification, it is also necessary for DHCP client messages to +be integrity protected. + +Note that this protocol does not make use of KRB_SAFE, so as to allow +modification of mutable fields by the DHCP relay. Replay protection is +therefore provided within the DHCP authentication option itself. + +In DHCP authentication via Kerberos V the DHCP client will authenticate, +integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and +DHCPRELEASE messages using a user-to-user session key obtained by the +DHCP server from the home KDC. If the DHCP client knows the DHCP server +it will be interacting with, then the DHCP client MAY also authenticate, +integrity and replay-protect the DHCPINFORM message using a session key +obtained from the local realm KDC for the DHCP server it expects to +converse with. + +Since the client has not yet obtained a session key, DHCPDISCOVER +packets cannot be authenticated using the session key. However, the +client MAY include pre-authentication data in the PADATA field included +in the DHCPDISCOVER packet. Since the PADATA will then be used by the +DHCP server to request a ticket on the client's behalf, the DHCP server +will learn from the AS_REP whether the PADATA was acceptable or not. +Therefore in this case, the DHCPDISCOVER will be authenticated but not +integrity protected. + +Where the DHCP client does not know the DHCP server it will be +interacting with ahead of time, the DHCPINFORM message will not be +authenticated, integrity or replay protected. + +Note that snooping of PADATA and TGTs on the wire may provide an +attacker with a means of mounting a dictionary attack, since these items + + + +Hornstein, et al. Standards Track [Page 25] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +are typically encrypted with a key derived from the user's password. +Thus use of strong passwords and/or pre-authentication methods utilizing +strong cryptography (see [8]) are recommended. + +6.2. Network access control + +DHCP authentication has been proposed as a method of limiting access to +network media that are not physically secured such as wireless LANs and +ports in college residence halls. However, it is not particularly well +suited to this purpose since even if address allocation is denied an +inauthentic client may use a statically assigned IP address instead, or +may attempt to access the network using non-IP protocols. As a result, +other methods, described in [6]-[7], have been proposed for controlling +access to wireless media and switched LANs. + +6.3. Server security + +As noted in [3], it may be desirable to protect against rogue DHCP +servers put on the network either intentionally or by accident. To +address this issue it is necessary for DHCP server messages to be +authenticated. In order to guard against message modification, it is +also necessary for DHCP server messages to be integrity protected. +Replay protection is also provided within the DHCP authentication +option. + +All messages sent by the DHCP server are authenticated and integrity and +replaly protected using a session key. This includes the DHCPOFFER, +DHCPACK, and DHCPNAK messages. The session key is used to compute the +DHCP authentication option, which is verified by the client. + +In order to provide protection against rogue servers it is necessary to +prevent rogue servers from obtaining the credentials necessary to act as +a DHCP server. As noted in Section 4, the Kerberos principal name for +the DHCP server must be of type KRB_NT_SRV_HST with the service name +component equal to 'dhcp'. The client MUST validate that the DHCP server +principal name has the above format. This convention requires that the +administrator ensure that non-DHCP server principals do not have names +that match the above format. + +7. IANA Considerations + +This draft does not create any new number spaces for IANA +administration. + +8. Acknowledgements + +The authors would like to acknowledge Ralph Droms and William Arbaugh, +authors of the DHCP authentication draft [3]. This draft incorporates + + + +Hornstein, et al. Standards Track [Page 26] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +material from their work; however, any mistakes in this document are +solely the responsibility of the authors. + +9. Authors' Addresses + +Ken Hornstein +US Naval Research Laboratory +Bldg A-49, Room 2 +4555 Overlook Avenue +Washington DC 20375 USA + +Phone: +1 (202) 404-4765 +EMail: kenh@cmf.nrl.navy.mil + +Ted Lemon +Internet Engines, Inc. +950 Charter Street +Redwood City, CA 94063 + +Phone: +1 (650) 779 6031 +Email: mellon@iengines.net + +Bernard Aboba +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + +Phone: +1 (425) 936-6605 +EMail: bernarda@microsoft.com + +Jonathan Trostle +170 W. Tasman Dr. +San Jose, CA 95134, U.S.A. + +Email: jtrostle@cisco.com +Phone: +1 (408) 527-6201 + + +10. Intellectual Property Statement + +The IETF takes no position regarding the validity or scope of any +intellectual property or other rights that might be claimed to pertain +to the implementation or use of the technology described in this +document or the extent to which any license under such rights might or +might not be available; neither does it represent that it has made any +effort to identify any such rights. Information on the IETF's +procedures with respect to rights in standards-track and standards- +related documentation can be found in BCP-11. Copies of claims of + + + +Hornstein, et al. Standards Track [Page 27] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +rights made available for publication and any assurances of licenses to +be made available, or the result of an attempt made to obtain a general +license or permission for the use of such proprietary rights by +implementors or users of this specification can be obtained from the +IETF Secretariat. + +The IETF invites any interested party to bring to its attention any +copyrights, patents or patent applications, or other proprietary rights +which may cover technology that may be required to practice this +standard. Please address the information to the IETF Executive +Director. + +11. Full Copyright Statement + +Copyright (C) The Internet Society (2000). All Rights Reserved. +This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it or +assist in its implmentation may be prepared, copied, published and +distributed, in whole or in part, without restriction of any kind, +provided that the above copyright notice and this paragraph are included +on all such copies and derivative works. However, this document itself +may not be modified in any way, such as by removing the copyright notice +or references to the Internet Society or other Internet organizations, +except as needed for the purpose of developing Internet standards in +which case the procedures for copyrights defined in the Internet +Standards process must be followed, or as required to translate it into +languages other than English. The limited permissions granted above are +perpetual and will not be revoked by the Internet Society or its +successors or assigns. This document and the information contained +herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE +INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE +INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +12. Expiration Date + +This memo is filed as <draft-hornstein-dhc-kerbauth-02.txt>, and +expires October 1, 2000. + + + + + + + + + + + + +Hornstein, et al. Standards Track [Page 28] + + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt new file mode 100644 index 000000000000..208d057f24c8 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt @@ -0,0 +1,301 @@ +INTERNET-DRAFT Mike Swift +draft-ietf-cat-iakerb-04.txt Microsoft +Updates: RFC 1510 Jonathan Trostle +July 2000 Cisco Systems + + + Initial Authentication and Pass Through Authentication + Using Kerberos V5 and the GSS-API (IAKERB) + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance + with all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This draft expires on January 31st, 2001. + + +1. Abstract + + This document defines an extension to the Kerberos protocol + specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC + 1964 [2]) that enables a client to obtain Kerberos tickets for + services where: + + (1) The client knows its principal name and password, but not + its realm name (applicable in the situation where a user is already + on the network but needs to authenticate to an ISP, and the user + does not know his ISP realm name). + (2) The client is able to obtain the IP address of the service in + a realm which it wants to send a request to, but is otherwise unable + to locate or communicate with a KDC in the service realm or one of + the intermediate realms. (One example would be a dial up user who + does not have direct IP connectivity). + (3) The client does not know the realm name of the service. + + +2. Motivation + + When authenticating using Kerberos V5, clients obtain tickets from + a KDC and present them to services. This method of operation works + + well in many situations, but is not always applicable since it + requires the client to know its own realm, the realm of the target + service, the names of the KDC's, and to be able to connect to the + KDC's. + + This document defines an extension to the Kerberos protocol + specification (RFC 1510) [1] that enables a client to obtain + Kerberos tickets for services where: + + (1) The client knows its principal name and password, but not + its realm name (applicable in the situation where a user is already + on the network but needs to authenticate to an ISP, and the user + does not know his ISP realm name). + (2) The client is able to obtain the IP address of the service in + a realm which it wants to send a request to, but is otherwise unable + to locate or communicate with a KDC in the service realm or one of + the intermediate realms. (One example would be a dial up user who + does not have direct IP connectivity). + (3) The client does not know the realm name of the service. + + In this proposal, the client sends KDC request messages directly + to application servers if one of the above failure cases develops. + The application server acts as a proxy, forwarding messages back + and forth between the client and various KDC's (see Figure 1). + + + Client <---------> App Server <----------> KDC + proxies + + + Figure 1: IAKERB proxying + + + In the case where the client has sent a TGS_REQ message to the + application server without a realm name in the request, the + application server will forward an error message to the client + with its realm name in the e-data field of the error message. + The client will attempt to proceed using conventional Kerberos. + +3. When Clients Should Use IAKERB + + We list several, but possibly not all, cases where the client + should use IAKERB. In general, the existing Kerberos paradigm + where clients contact the KDC to obtain service tickets should + be preserved where possible. + + (a) AS_REQ cases: + + (i) The client is unable to locate the user's KDC or the KDC's + in the user's realm are not responding, or + (ii) The user has not entered a name which can be converted + into a realm name (and the realm name cannot be derived from + a certificate). + + (b) TGS_REQ cases: + + (i) the client determines that the KDC(s) in either an + intermediate realm or the service realm are not responding or + + the client is unable to locate a KDC, + + (ii) the client is not able to generate the application server + realm name. + + +4. GSSAPI Encapsulation + + The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the + mechanism proposed by SPNEGO for negotiating protocol variations, is: + {iso(1) member-body(2) United States(840) mit(113554) infosys(1) + gssapi(2) krb5(2) initialauth(4)} + + The AS request, AS reply, TGS request, and TGS reply messages are all + encapsulated using the format defined by RFC1964 [2]. This consists + of the GSS-API token framing defined in appendix B of RFC1508 [3]: + + InitialContextToken ::= + [APPLICATION 0] IMPLICIT SEQUENCE { + thisMech MechType + -- MechType is OBJECT IDENTIFIER + -- representing "Kerberos V5" + innerContextToken ANY DEFINED BY thisMech + -- contents mechanism-specific; + -- ASN.1 usage within innerContextToken + -- is not required + } + + The innerContextToken consists of a 2-byte TOK_ID field (defined + below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, + KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field + shall be one of the following values, to denote that the message is + either a request to the KDC or a response from the KDC. + + Message TOK_ID + KRB-KDC-REQ 00 03 + KRB-KDC-REP 01 03 + + +5. The Protocol + + a. The user supplies a password (AS_REQ): Here the Kerberos client + will send an AS_REQ message to the application server if it cannot + locate a KDC for the user's realm, or such KDC's do not respond, + or the user does not enter a name from which the client can derive + the user's realm name. The client sets the realm field of the + request equal to its own realm if the realm name is known, + otherwise the realm length is set to 0. Upon receipt of the AS_REQ + message, the application server checks if the client has included + a realm. + + If the realm was not included in the original request, the + application server must determine the realm and add it to the + AS_REQ message before forwarding it. If the application server + cannot determine the client realm, it returns the + KRB_AP_ERR_REALM_REQUIRED error-code in an error message to + the client: + + KRB_AP_ERR_REALM_REQUIRED 77 + + The error message can be sent in response to either an AS_REQ + message, or in response to a TGS_REQ message, in which case the + realm and principal name of the application server are placed + into the realm and sname fields respectively, of the KRB-ERROR + message. In the AS_REQ case, once the realm is filled in, the + application server forwards the request to a KDC in the user's + realm. It will retry the request if necessary, and forward the + KDC response back to the client. + + At the time the user enters a username and password, the client + should create a new credential with an INTERNAL NAME [3] that can + be used as an input into the GSS_Acquire_cred function call. + + This functionality is useful when there is no trust relationship + between the user's logon realm and the target realm (Figure 2). + + + User Realm KDC + / + / + / + / 2,3 + 1,4 / + Client<-------------->App Server + + + 1 Client sends AS_REQ to App Server + 2 App server forwards AS_REQ to User Realm KDC + 3 App server receives AS_REP from User Realm KDC + 4 App server sends AS_REP back to Client + + + Figure 2: IAKERB AS_REQ + + + + b. The user does not supply a password (TGS_REQ): The user includes a + TGT targetted at the user's realm, or an intermediate realm, in a + TGS_REQ message. The TGS_REQ message is sent to the application + server. + + If the client has included the realm name in the TGS request, then + the application server will forward the request to a KDC in the + request TGT srealm. It will forward the response back to the client. + + If the client has not included the realm name in the TGS request, + then the application server will return its realm name and principal + name to the client using the KRB_AP_ERR_REALM_REQUIRED error + described above. Sending a TGS_REQ message to the application server + without a realm name in the request, followed by a TGS request using + the returned realm name and then sending an AP request with a mutual + authentication flag should be subject to a local policy decision + (see security considerations below). Using the returned server + principal name in a TGS request followed by sending an AP request + message using the received ticket MUST NOT set any mutual + authentication flags. + + +6. Addresses in Tickets + + In IAKERB, the machine sending requests to the KDC is the server and + not the client. As a result, the client should not include its + addresses in any KDC requests for two reasons. First, the KDC may + reject the forwarded request as being from the wrong client. Second, + in the case of initial authentication for a dial-up client, the client + machine may not yet possess a network address. Hence, as allowed by + RFC1510 [1], the addresses field of the AS and TGS requests should be + blank and the caddr field of the ticket should similarly be left blank. + + +7. Combining IAKERB with Other Kerberos Extensions + + This protocol is usable with other proposed Kerberos extensions such as + PKINIT (Public Key Cryptography for Initial Authentication in Kerberos + [4]). In such cases, the messages which would normally be sent to the + KDC by the GSS runtime are instead sent by the client application to the + server, which then forwards them to a KDC. + + +8. Security Considerations + + A principal is identified by its principal name and realm. A client + that sends a TGS request to an application server without the request + realm name will only be able to mutually authenticate the server + up to its principal name. Thus when requesting mutual authentication, + it is preferable if clients can either determine the server realm name + beforehand, or apply some policy checks to the realm name obtained from + the returned error message. + + +9. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5). Request for Comments 1510. + + [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request + for Comments 1964 + + [3] J. Linn. Generic Security Service Application Program Interface. + Request for Comments 1508 + + [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, + J. Trostle, Public Key Cryptography for Initial Authentication in + Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos- + pkinit-10.txt. + + +10. This draft expires on January 31st, 2001. + + +11. Authors' Addresses + + Michael Swift + Microsoft + One Microsoft Way + Redmond, Washington, 98052, U.S.A. + Email: mikesw@microsoft.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134, U.S.A. + Email: jtrostle@cisco.com + Phone: (408) 527-6201 diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt new file mode 100644 index 000000000000..b3ec336b6513 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt @@ -0,0 +1,174 @@ +INTERNET-DRAFT Jonathan Trostle +draft-ietf-cat-kerberos-extra-tgt-02.txt Cisco Systems +Updates: RFC 1510 Michael M. Swift +expires January 30, 2000 University of WA + + + Extension to Kerberos V5 For Additional Initial Encryption + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance + with all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + This document defines an extension to the Kerberos protocol + specification (RFC 1510) [1] to enable a preauthentication field in + the AS_REQ message to carry a ticket granting ticket. The session + key from this ticket granting ticket will be used to + cryptographically strengthen the initial exchange in either the + conventional Kerberos V5 case or in the case the user stores their + encrypted private key on the KDC [2]. + + +2. Motivation + + In Kerberos V5, the initial exchange with the KDC consists of the + AS_REQ and AS_REP messages. For users, the encrypted part of the + AS_REP message is encrypted in a key derived from a password. + Although a password policy may be in place to prevent dictionary + attacks, brute force attacks may still be a concern due to + insufficient key length. + + This draft specifies an extension to the Kerberos V5 protocol to + allow a ticket granting ticket to be included in an AS_REQ message + preauthentication field. The session key from this ticket granting + ticket will be used to cryptographically strengthen the initial + + exchange in either the conventional Kerberos V5 case or in the case + the user stores their encrypted private key on the KDC [2]. The + session key from the ticket granting ticket is combined with the + user password key (key K2 in the encrypted private key on KDC + option) using HMAC to obtain a new triple des key that is used in + place of the user key in the initial exchange. The ticket granting + ticket could be obtained by the workstation using its host key. + +3. The Extension + + The following new preauthentication type is proposed: + + PA-EXTRA-TGT 22 + + The preauthentication-data field contains a ticket granting ticket + encoded as an ASN.1 octet string. The server realm of the ticket + granting ticket must be equal to the realm in the KDC-REQ-BODY of + the AS_REQ message. In the absence of a trust relationship, the + local Kerberos client should send the AS_REQ message without this + extension. + + In the conventional (non-pkinit) case, we require the RFC 1510 + PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message. + If neither it or the PA-PK-KEY-REQ preauthentication field is + included in the AS_REQ message, the KDC will reply with a + KDC_ERR_PREAUTH_FAILED error message. + + We propose the following new etypes: + + des3-cbc-md5-xor 16 + des3-cbc-sha1-xor 17 + + The encryption key is obtained by: + + (1) Obtaining an output M from the HMAC-SHA1 function [3] using + the user password key (the key K2 in the encrypted private + key on KDC option of pkinit) as the text and the triple des + session key as the K input in HMAC: + + M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1. + + The session key from the accompanying ticket granting ticket + must be a triple des key when one of the triple des xor + encryption types is used. + (2) Concatenate the output M (20 bytes) with the first 8 non-parity + bits of the triple-des ticket granting ticket session key to + get 168 bits that will be used for the new triple-des encryption + key. + (3) Set the parity bits of the resulting key. + + The resulting triple des key is used to encrypt the timestamp + for the PA-ENC-TIMESTAMP preauthentication value (or in the + encrypted private key on KDC option of pkinit, it is used in + place of the key K2 to both sign in the PA-PK-KEY-REQ and for + encryption in the PA-PK-KEY-REP preauthentication types). + + If the KDC decrypts the encrypted timestamp and it is not within + the appropriate clock skew period, the KDC will reply with the + KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if + the above ticket granting ticket fails to decrypt properly, or if + it is not a valid ticket. + + The KDC will create the shared triple des key from the ticket + granting ticket session key and the user password key (the key K2 + in the encrypted private key on KDC case) using HMAC as specified + above and use it to validate the AS_REQ message and then to + encrypt the encrypted part of the AS_REP message (use it in place + of the key K2 for encryption in the PA-PK-KEY-REP preauthentication + field). + + Local workstation policy will determine the exact behaviour of + the Kerberos client with respect to the extension protocol. For + example, the client should consult policy to decide when to use + use the extension. This policy could be dependent on the user + identity, or whether the workstation is in the same realm as the + user. One possibility is for the workstation logon to fail if + the extension is not used. Another possibility is for the KDC + to set a flag in tickets issued when this extension is used. + + A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a + preauthentication field containing a ticket granting ticket, + a randomly generated subkey encrypted in the session key from + the ticket, and a timestamp structure encrypted in the user + password and then the randomly generated subkey was proposed. + Some advantages of the current proposal are that the KDC has two + fewer decryptions to perform per request and the client does not + have to generate a random key. + +4. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5). Request for Comments 1510. + + [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle. + Public Key Cryptography for Initial Authentication in Kerberos. + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerberos-pkinit-08.txt + + [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for + Message Authentication. Request for Comments 2104. + + [4] J. Pato. Using Pre-authentication to Avoid Password Guessing + Attacks. OSF DCE SIG Request for Comments 26.0. + +5. Acknowledgement: We thank Ken Hornstein for some helpful comments. + +6. Expires January 30, 2000. + +7. Authors' Addresses + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134, U.S.A. + + Email: jtrostle@cisco.com + Phone: (408) 527-6201 + + Michael Swift + Email: mikesw@cs.washington.edu diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt new file mode 100644 index 000000000000..d09a2ded5bc5 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000. diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt new file mode 100644 index 000000000000..1ab2b03e079d --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt @@ -0,0 +1,523 @@ + +INTERNET-DRAFT Matthew Hur +draft-ietf-cat-kerberos-pk-cross-06.txt CyberSafe Corporation +Updates: RFC 1510 Brian Tung +expires October 10, 2000 Tatyana Ryutov + Clifford Neuman + Gene Tsudik + ISI + Ari Medvinsky + Keen.com + Bill Sommerfeld + Hewlett-Packard + + + Public Key Cryptography for Cross-Realm Authentication in Kerberos + + +0. Status Of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may + also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as ``work in + progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + + To learn the current status of any Internet-Draft, please check + the ``1id-abstracts.txt'' listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-cross-06.txt, and expires May 15, 1999. + Please send comments to the authors. + + +1. Abstract + + This document defines extensions to the Kerberos protocol + specification [1] to provide a method for using public key + cryptography to enable cross-realm authentication. The methods + defined here specify the way in which message exchanges are to be + used to transport cross-realm secret keys protected by encryption + under public keys certified as belonging to KDCs. + + +2. Introduction + + The Kerberos authentication protocol [2] can leverage the + advantages provided by public key cryptography. PKINIT [3] + describes the use of public key cryptography in the initial + authentication exchange in Kerberos. PKTAPP [4] describes how an + application service can essentially issue a kerberos ticket to + itself after utilizing public key cryptography for authentication. + Another informational document species the use of public key + crypography for anonymous authentication in Kerberos [5]. This + specification describes the use of public key crpytography in cross- + realm authentication. + + Without the use of public key cryptography, administrators must + maintain separate keys for every realm which wishes to exchange + authentication information with another realm (which implies n(n-1) + keys), or they must utilize a hierachichal arrangement of realms, + which may complicate the trust model by requiring evaluation of + transited realms. + + Even with the multi-hop cross-realm authentication, there must be + some way to locate the path by which separate realms are to be + transited. The current method, which makes use of the DNS-like + realm names typical to Kerberos, requires trust of the intermediate + KDCs. + + PKCROSS utilizes a public key infrastructure (PKI) [6] to simplify + the administrative burden of maintaining cross-realm keys. Such + usage leverages a PKI for a non-centrally-administratable environment + (namely, inter-realm). Thus, a shared key for cross-realm + authentication can be established for a set period of time, and a + remote realm is able to issue policy information that is returned to + itself when a client requests cross-realm authentication. Such policy + information may be in the form of restrictions [7]. Furthermore, + these methods are transparent to the client; therefore, only the KDCs + need to be modified to use them. In this way, we take advantage of + the the distributed trust management capabilities of public key + crypography while maintaining the advantages of localized trust + management provided by Kerberos. + + + Although this specification utilizes the protocol specfied in the + PKINIT specification, it is not necessary to implement client + changes in order to make use of the changes in this document. + + +3. Objectives + + The objectives of this specification are as follows: + + 1. Simplify the administration required to establish Kerberos + cross-realm keys. + + 2. Avoid modification of clients and application servers. + + 3. Allow remote KDC to control its policy on cross-realm + keys shared between KDCs, and on cross-realm tickets + presented by clients. + + 4. Remove any need for KDCs to maintain state about keys + shared with other KDCs. + + 5. Leverage the work done for PKINIT to provide the public key + protocol for establishing symmetric cross realm keys. + + +4. Definitions + + The following notation is used throughout this specification: + KDC_l ........... local KDC + KDC_r ........... remote KDC + XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the + local KDC + TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the + client for presentation to the remote KDC + + This specification defines the following new types to be added to the + Kerberos specification: + PKCROSS kdc-options field in the AS_REQ is bit 9 + TE-TYPE-PKCROSS-KDC 2 + TE-TYPE-PKCROSS-CLIENT 3 + + This specification defines the following ASN.1 type for conveying + policy information: + CrossRealmTktData ::= SEQUENCE OF TypedData + + This specification defines the following types for policy information + conveyed in CrossRealmTktData: + PLC_LIFETIME 1 + PLC_SET_TKT_FLAGS 2 + PLC_NOSET_TKT_FLAGS 3 + + TicketExtensions are defined per the Kerberos specification [8]: + TicketExtensions ::= SEQUENCE OF TypedData + Where + TypedData ::= SEQUENCE { + data-type[0] INTEGER, + data-value[1] OCTET STRING OPTIONAL + } + + +5. Protocol Specification + + We assume that the client has already obtained a TGT. To perform + cross-realm authentication, the client does exactly what it does + with ordinary (i.e. non-public-key-enabled) Kerberos; the only + changes are in the KDC; although the ticket which the client + forwards to the remote realm may be changed. This is acceptable + since the client treats the ticket as opaque. + + +5.1. Overview of Protocol + + The basic operation of the PKCROSS protocol is as follows: + + 1. The client submits a request to the local KDC for + credentials for the remote realm. This is just a typical + cross realm request that may occur with or without PKCROSS. + + 2. The local KDC submits a PKINIT request to the remote KDC to + obtain a "special" PKCROSS ticket. This is a standard + PKINIT request, except that PKCROSS flag (bit 9) is set in + the kdc-options field in the AS_REQ. + + 3. The remote KDC responds as per PKINIT, except that + the ticket contains a TicketExtension, which contains + policy information such as lifetime of cross realm tickets + issued by KDC_l to a client. The local KDC must reflect + this policy information in the credentials it forwards to + the client. Call this ticket XTKT_(l,r) to indicate that + this ticket is used to authenticate the local KDC to the + remote KDC. + + 4. The local KDC passes a ticket, TGT_(c,r) (the cross realm + TGT between the client and remote KDC), to the client. + This ticket contains in its TicketExtension field the + ticket, XTKT_(l,r), which contains the cross-realm key. + The TGT_(c,r) ticket is encrypted using the key sealed in + XTKT_(l,r). (The TicketExtension field is not encrypted.) + The local KDC may optionally include another TicketExtension + type that indicates the hostname and/or IP address for the + remote KDC. + + 5. The client submits the request directly to the remote + KDC, as before. + + 6. The remote KDC extracts XTKT_(l,r) from the TicketExtension + in order to decrypt the encrypted part of TGT_(c,r). + + -------------------------------------------------------------------- + + Client Local KDC (KDC_l) Remote KDC (KDC_r) + ------ ----------------- ------------------ + Normal Kerberos + request for + cross-realm + ticket for KDC_r + ----------------------> + + PKINIT request for + XTKT(l,r) - PKCROSS flag + set in the AS-REQ + * -------------------------> + + PKINIT reply with + XTKT_(l,r) and + policy info in + ticket extension + <-------------------------- * + + Normal Kerberos reply + with TGT_(c,r) and + XTKT(l,r) in ticket + extension + <--------------------------------- + + Normal Kerberos + cross-realm TGS-REQ + for remote + application + service with + TGT_(c,r) and + XTKT(l,r) in ticket + extension + -------------------------------------------------> + + Normal Kerberos + cross-realm + TGS-REP + <--------------------------------------------------------------- + + * Note that the KDC to KDC messages occur only periodically, since + the local KDC caches the XTKT_(l,r). + -------------------------------------------------------------------- + + + Sections 5.2 through 5.4 describe in detail steps 2 through 4 + above. Section 5.6 describes the conditions under which steps + 2 and 3 may be skipped. + + Note that the mechanism presented above requires infrequent KDC to + KDC communication (as dictated by policy - this is discussed + later). Without such an exchange, there are the following issues: + 1) KDC_l would have to issue a ticket with the expectation that + KDC_r will accept it. + 2) In the message that the client sends to KDC_r, KDC_l would have + to authenticate KDC_r with credentials that KDC_r trusts. + 3) There is no way for KDC_r to convey policy information to KDC_l. + 4) If, based on local policy, KDC_r does not accept a ticket from + KDC_l, then the client gets stuck in the middle. To address such + an issue would require modifications to standard client + processing behavior. + Therefore, the infreqeunt use of KDC to KDC communication assures + that inter-realm KDC keys may be established in accordance with local + policies and that clients may continue to operate without + modification. + + +5.2. Local KDC's Request to Remote KDC + + When the local KDC receives a request for cross-realm authentication, + it first checks its ticket cache to see if it has a valid PKCROSS + ticket, XTKT_(l,r). If it has a valid XTKT_(l,r), then it does not + need to send a request to the remote KDC (see section 5.5). + + If the local KDC does not have a valid XTKT_(l,r), it sends a + request to the remote KDC in order to establish a cross realm key and + obtain the XTKT_(l,r). This request is in fact a PKINIT request as + described in the PKINIT specification; i.e., it consists of an AS-REQ + with a PA-PK-AS-REQ included as a preauthentication field. Note, + that the AS-REQ MUST have the PKCROSS flag (bit 9) set in the + kdc_options field of the AS-REQ. Otherwise, this exchange exactly + follows the description given in the PKINIT specification. In + addition, the naming + + +5.3. Remote KDC's Response to Local KDC + + When the remote KDC receives the PKINIT/PKCROSS request from the + local KDC, it sends back a PKINIT response as described in + the PKINIT specification with the following exception: the encrypted + part of the Kerberos ticket is not encrypted with the krbtgt key; + instead, it is encrypted with the ticket granting server's PKCROSS + key. This key, rather than the krbtgt key, is used because it + encrypts a ticket used for verifying a cross realm request rather + than for issuing an application service ticket. Note that, as a + matter of policy, the session key for the XTKT_(l,r) MAY be of + greater strength than that of a session key for a normal PKINIT + reply, since the XTKT_(l,r) SHOULD be much longer lived than a + normal application service ticket. + + In addition, the remote KDC SHOULD include policy information in the + XTKT_(l,r). This policy information would then be reflected in the + cross-realm TGT, TGT_(c,r). Otherwise, the policy for TGT_(c,r) + would be dictated by KDC_l rather than by KDC_r. The local KDC MAY + enforce a more restrictive local policy when creating a cross-realm + ticket, TGT_(c,r). For example, KDC_r may dictate a lifetime + policy of eight hours, but KDC_l may create TKT_(c,r) with a + lifetime of four hours, as dictated by local policy. Also, the + remote KDC MAY include other information about itself along with the + PKCROSS ticket. These items are further discussed in section 6 + below. + + +5.4. Local KDC's Response to Client + + Upon receipt of the PKINIT/CROSS response from the remote KDC, + the local KDC formulates a response to the client. This reply + is constructed exactly as in the Kerberos specification, except + for the following: + + A) The local KDC places XTKT_(l,r) in the TicketExtension field of + the client's cross-realm, ticket, TGT_(c,r), for the remote realm. + Where + data-type equals 3 for TE-TYPE-PKCROSS-CLIENT + data-value is ASN.1 encoding of XTKT_(l,r) + + B) The local KDC adds the name of its CA to the transited field of + TGT_(c,r). + + +5.5 Remote KDC's Processing of Client Request + + When the remote KDC, KDC_r, receives a cross-realm ticket, + TGT_(c,r), and it detects that the ticket contains a ticket + extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt + the ticket, XTKT_(l,r), that is encoded in the ticket extension. + KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r). KDC_r + then uses the key obtained from XTKT_(l,r) in order to decrypt the + cross-realm ticket, TGT_(c,r). + + KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in + compliance with any policy information contained in XTKT_(l,r) (see + section 6). If the TGT_(c,r) is not in compliance with policy, then + the KDC_r responds to the client with a KRB-ERROR message of type + KDC_ERR_POLICY. + + +5.6. Short-Circuiting the KDC-to-KDC Exchange + + As we described earlier, the KDC to KDC exchange is required only + for establishing a symmetric, inter-realm key. Once this key is + established (via the PKINIT exchange), no KDC to KDC communication + is required until that key needs to be renewed. This section + describes the circumstances under which the KDC to KDC exchange + described in Sections 5.2 and 5.3 may be skipped. + + The local KDC has a known lifetime for TGT_(c,r). This lifetime may + be determined by policy information included in XTKT_(l,r), and/or + it may be determined by local KDC policy. If the local KDC already + has a ticket XTKT(l,r), and the start time plus the lifetime for + TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then + the local KDC may skip the exchange with the remote KDC, and issue a + cross-realm ticket to the client as described in Section 5.4. + + Since the remote KDC may change its PKCROSS key (referred to in + Section 5.2) while there are PKCROSS tickets still active, it SHOULD + cache the old PKCROSS keys until the last issued PKCROSS ticket + expires. Otherwise, the remote KDC will respond to a client with a + KRB-ERROR message of type KDC_ERR_TGT_REVOKED. + + +6. Extensions for the PKCROSS Ticket + + As stated in section 5.3, the remote KDC SHOULD include policy + information in XTKT_(l,r). This policy information is contained in + a TicketExtension, as defined by the Kerberos specification, and the + authorization data of the ticket will contain an authorization + record of type AD-IN-Ticket-Extensions. The TicketExtension defined + for use by PKCROSS is TE-TYPE-PKCROSS-KDC. + Where + data-type equals 2 for TE-TYPE-PKCROSS-KDC + data-value is ASN.1 encoding of CrossRealmTktData + + CrossRealmTktData ::= SEQUENCE OF TypedData + + + ------------------------------------------------------------------ + CrossRealmTktData types and the corresponding data are interpreted + as follows: + + ASN.1 data + type value interpretation encoding + ---------------- ----- -------------- ---------- + PLC_LIFETIME 1 lifetime (in seconds) INTEGER + for TGT_(c,r) + - cross-realm tickets + issued for clients by + TGT_l + + PLC_SET_TKT_FLAGS 2 TicketFlags that must BITSTRING + be set + - format defined by + Kerberos specification + + PLC_NOSET_TKT_FLAGS 3 TicketFlags that must BITSTRING + not be set + - format defined by + Kerberos specification + + Further types may be added to this table. + ------------------------------------------------------------------ + + +7. Usage of Certificates + + In the cases of PKINIT and PKCROSS, the trust in a certification + authority is equivalent to Kerberos cross realm trust. For this + reason, an implementation MAY choose to use the same KDC certificate + when the KDC is acting in any of the following three roles: + 1) KDC is authenticating clients via PKINIT + 2) KDC is authenticating another KDC for PKCROSS + 3) KDC is the client in a PKCROSS exchange with another KDC + + Note that per PKINIT, the KDC X.509 certificate (the server in a + PKINIT exchange) MUST contain the principal name of the KDC in the + subjectAltName field. + + +8. Transport Issues + + Because the messages between the KDCs involve PKINIT exchanges, and + PKINIT recommends TCP as a transport mechanism (due to the length of + the messages and the likelihood that they will fragment), the same + recommendation for TCP applies to PKCROSS as well. + + +9. Security Considerations + + Since PKCROSS utilizes PKINIT, it is subject to the same security + considerations as PKINIT. Administrators should assure adherence + to security policy - for example, this affects the PKCROSS policies + for cross realm key lifetime and for policy propogation from the + PKCROSS ticket, issued from a remote KDC to a local KDC, to + cross realm tickets that are issued by a local KDC to a client. + + +10. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray + J. Trostle. Public Key Cryptography for Initial Authentication + in Kerberos. + draft-ietf-cat-kerberos-pk-init-11.txt + + [4] A. Medvinsky, M. Hur, S. Medvinsky, B. Clifford Neuman. Public + Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf- + cat-pktapp-02.txt + + [5] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. draft-ietf-cat-kerberos-anoncred-01.txt + + [6] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [7] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [8] C.Neuman, J. Kohl, T. Ts'o. The Kerberos Network Authentication + Service (V5). draft-ietf-cat-kerberos-revisions-05.txt + + +11. Authors' Addresses + + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road + Issaquah WA 98027-5378 + Phone: +1 425 391 6000 + E-mail: matt.hur@cybersafe.com + + Brian Tung + Tatyana Ryutov + Clifford Neuman + Gene Tsudik + USC/Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey, CA 90292-6695 + Phone: +1 310 822 1511 + E-Mail: {brian, tryutov, bcn, gts}@isi.edu + + Ari Medvinsky + Keen.com + 2480 Sand Hill Road, Suite 200 + Menlo Park, CA 94025 + Phone +1 650 289 3134 + E-mail: ari@keen.com + + Bill Sommerfeld + Hewlett Packard + 300 Apollo Drive + Chelmsford MA 01824 + Phone: +1 508 436 4352 + E-Mail: sommerfeld@apollo.hp.com + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt new file mode 100644 index 000000000000..9b0e76adad98 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt @@ -0,0 +1,1059 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-11.txt Clifford Neuman +Updates: RFC 1510 USC/ISI +expires September 15, 2000 Matthew Hur + CyberSafe Corporation + Ari Medvinsky + Keen.com, Inc. + Sasha Medvinsky + Motorola + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-11.txt, and expires September 15, + 2000. Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in + combination with digital signature keys as the primary, required + mechanism. It also allows for the use of RSA keys and/or (static) + Diffie-Hellman certificates. Note in particular that PKINIT supports + the use of separate signature and encryption keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends an AS-REQ message to the KDC as before, except that if that + user is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + Note that PKINIT does not require the use of certificates. A KDC + may store the public key of a principal as part of that principal's + record. In this scenario, the KDC is the trusted party that vouches + for the principal (as in a standard, non-cross realm, Kerberos + environment). Thus, for any principal, the KDC may maintain a + secret key, a public key, or both. + + The PKINIT specification may also be used as a building block for + other specifications. PKCROSS [3] utilizes PKINIT for establishing + the inter-realm key and associated inter-realm policy to be applied + in issuing cross realm service tickets. As specified in [4], + anonymous Kerberos tickets can be issued by applying a NULL + signature in combination with Diffie-Hellman in the PKINIT exchange. + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is described in PKTAPP [5] and is based on + concepts introduced in [6, 7]. For direct client-to-server + authentication, the client uses PKINIT to authenticate to the end + server (instead of a central KDC), which then issues a ticket for + itself. This approach has an advantage over TLS [8] in that the + server does not need to save state (cache session keys). + Furthermore, an additional benefit is that Kerberos tickets can + facilitate delegation (see [9]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510 is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_KDC_NAME_MISMATCH 76 + + We utilize the following typed data for errors: + + TD-PKINIT-CMS-CERTIFICATES 101 + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + We utilize the following encryption types (which map directly to + OIDs): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS#1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + + These mappings are provided so that a client may send the + appropriate enctypes in the AS-REQ message in order to indicate + support for the corresponding OIDs (for performing PKINIT). + + In many cases, PKINIT requires the encoding of the X.500 name of a + certificate authority as a Realm. When such a name appears as + a realm it will be represented using the "other" form of the realm + name as specified in the naming constraints section of RFC1510. + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + <nametype> + ":" + <string> + + where nametype is "X500-RFC2253" and string is the result of doing + an RFC2253 encoding of the distinguished name, i.e. + + "X500-RFC2253:" + RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + function returing a readable UTF encoding of an X.500 name, as + defined by RFC 2253 [14] (part of LDAPv3 [18]). + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, in cases where the KDC does not provide a specific + policy based mapping from the X.500 name or X.509 Version 3 + SubjectAltName extension in the user's certificate to a Kerberos + principal name, PKINIT requires the direct encoding of the X.500 + name as a PrincipalName. In this case, the name-type of the + principal name shall be set to KRB_NT-X500-PRINCIPAL. This new + name type is defined in RFC 1510 as: + + KRB_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. When this name type is used, the principal's + realm shall be set to the certificate authority's distinguished + name using the X500-RFC2253 realm name format described earlier in + this section + + RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: + + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + For the purposes of encoding an X.500 name as a Kerberos name for + use in Kerberos structures, the name-string shall be encoded as a + single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL, + as noted above. All Kerberos names must conform to validity + requirements as given in RFC 1510. Note that name mapping may be + required or optional, based on policy. + + We also define the following similar ASN.1 structure: + + CertPrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF UTF8String + } + + When a Kerberos PrincipalName is to be placed within an X.509 data + structure, the CertPrincipalName structure is to be used, with the + name-string encoded as a single UTF8String. The name-type should be + as identified in the original PrincipalName structure. The mapping + between the GeneralString and UTF8String formats can be found in + [19]. + + The following rules relate to the the matching of PrincipalNames (or + corresponding CertPrincipalNames) with regard to the PKI name + constraints for CAs as laid out in RFC 2459 [15]. In order to be + regarded as a match (for permitted and excluded name trees), the + following must be satisfied. + + 1. If the constraint is given as a user plus realm name, or + as a user plus instance plus realm name (as specified in + RFC 1510), the realm name must be valid (see 2.a-d below) + and the match must be exact, byte for byte. + + 2. If the constraint is given only as a realm name, matching + depends on the type of the realm: + + a. If the realm contains a colon (':') before any equal + sign ('='), it is treated as a realm of type Other, + and must match exactly, byte for byte. + + b. Otherwise, if the realm contains an equal sign, it + is treated as an X.500 name. In order to match, every + component in the constraint MUST be in the principal + name, and have the same value. For example, 'C=US' + matches 'C=US/O=ISI' but not 'C=UK'. + + c. Otherwise, if the realm name conforms to rules regarding + the format of DNS names, it is considered a realm name of + type Domain. The constraint may be given as a realm + name 'FOO.BAR', which matches any PrincipalName within + the realm 'FOO.BAR' but not those in subrealms such as + 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' + matches PrincipalNames in subrealms of the form + 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. + + d. Otherwise, the realm name is invalid and does not match + under any conditions. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys for RSA + keys. + + In the case of Diffie-Hellman, the key shall be produced from the + agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + The following signature algorithm identifiers specified in [11] and + in [15] shall be used with PKINIT: + + id-dsa-with-sha1 (DSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + sha-1WithRSAEncryption (RSA with SHA1) + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + The following algorithm identifier shall be used within the + SubjectPublicKeyInfo data structure: dhpublicnumber + + This identifier and the associated algorithm parameters are + specified in RFC 2459 [15]. + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption (RSA encryption, PKCS#1 v1.5) + id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) + + Both of the above RSA encryption schemes are specified in [16]. + Currently, only PKCS#1 v1.5 is specified by CMS [11], although the + CMS specification says that it will likely include PKCS#1 v2.0 in + the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext + vulnerability discovered in PKCS#1 v1.5.) + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure in the PKINIT Reply, for encrypting the reply key with the + temporary key: + des-ede3-cbc (3-key 3-DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + The full definition of the above algorithm identifiers and their + corresponding parameters (an IV for block chaining) is provided in + the CMS specification [11]. + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + +3.2.1. Client Request + + Public keys may be signed by some certification authority (CA), or + they may be maintained by the KDC in which case the KDC is the + trusted authority. Note that the latter mode does not require the + use of certificates. + + The initial authentication request is sent as per RFC 1510, except + that a preauthentication field containing data signed by the user's + private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedData + -- Defined in CMS [11]; + -- AuthPack (below) defines the + -- data that is signed. + trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, + -- This is a list of CAs that the + -- client trusts and that certify + -- KDCs. + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- As defined in CMS [11]; + -- specifies a particular KDC + -- certificate if the client + -- already has it. + encryptionCert [3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. + } + + TrustedCas ::= CHOICE { + principalName [0] KerberosName, + -- as defined below + caName [1] Name + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial [2] IssuerAndSerialNumber + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts + } + + Usage of SignedData: + + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. The following describes how to fill in the fields of + this data: + + 1. The encapContentInfo field must contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + + a. The eContentType field shall contain the OID value for + pkdata: iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) pkdata (1) + + b. The eContent field is data of the type AuthPack (below). + + 2. The signerInfos field contains the signature of AuthPack. + + 3. The Certificates field, when non-empty, contains the client's + certificate chain. If present, the KDC uses the public key + from the client's certificate to verify the signature in the + request. Note that the client may pass different certificate + chains that are used for signing or for encrypting. Thus, + the KDC may utilize a different client certificate for + signature verification than the one it uses to encrypt the + reply to the client. For example, the client may place a + Diffie-Hellman certificate in this field in order to convey + its static Diffie Hellman certificate to the KDC to enable + static-ephemeral Diffie-Hellman mode for the reply; in this + case, the client does NOT place its public value in the + AuthPack (defined below). As another example, the client may + place an RSA encryption certificate in this field. However, + there must always be (at least) a signature certificate. + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + -- (ephemeral-ephemeral only) + } + + PKAuthenticator ::= SEQUENCE { + kdcName [0] PrincipalName, + kdcRealm [1] Realm, + cusec [2] INTEGER, + -- for replay prevention as in RFC1510 + ctime [3] KerberosTime, + -- for replay prevention as in RFC1510 + nonce [4] INTEGER + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [10] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm ALGORITHM.&id, + parameters ALGORITHM.&type + } -- as specified by the X.509 recommendation [10] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-data, which + is defined in RFC 1510 revisions as a SEQUENCE of TypedData: + + TypedData ::= SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING, + } -- per Kerberos RFC 1510 revisions + + where: + data-type = TD-PKINIT-CMS-CERTIFICATES = 101 + data-value = CertificateSet // as specified by CMS [11] + + The PKAuthenticator carries information to foil replay attacks, and + to bind the request and response. The PKAuthenticator is signed + with the client's signature key. + +3.2.2. KDC Response + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If the client's certificate chain contains no certificate signed by + a CA trusted by the KDC, then the KDC sends back an error message + of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data + is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) + whose data-value is an OCTET STRING which is the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 + + If while verifying a certificate chain the KDC determines that the + signature on one of the certificates in the CertificateSet from + the signedAuthPack fails verification, then the KDC returns an + error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying + e-data is a SEQUENCE of one TypedData (with type + TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING + which is the DER encoding of the index into the CertificateSet + ordered as sent by the client. + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + + The KDC may also check whether any of the certificates in the + client's chain has been revoked. If one of the certificates has + been revoked, then the KDC returns an error of type + KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that + the certificate's revocation status is unknown or not + available, then if required by policy, the KDC returns the + appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three + cases, the affected certificate is identified by the accompanying + e-data, which contains a CertificateIndex as described for + KDC_ERR_INVALID_CERTIFICATE. + + If the certificate chain can be verified, but the name of the + client in the certificate does not match the client's name in the + request, then the KDC returns an error of type + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data + field in this case. + + Finally, if the certificate chain is verified, but the KDC's name + or realm as given in the PKAuthenticator does not match the KDC's + actual principal name, then the KDC returns an error of type + KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again + a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or + TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET + STRING whose data-value is the DER encoding of a PrincipalName or + Realm as defined in RFC 1510 revisions. + + Even if all succeeds, the KDC may--for policy reasons--decide not + to trust the client. In this case, the KDC returns an error message + of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is + the presence or absence of an Enhanced Key Usage (EKU) OID within + the certificate extensions. The rules regarding acceptability of + an EKU sequence (or the absence of any sequence) are a matter of + local policy. For the benefit of implementers, we define a PKINIT + EKU OID as the following: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains the SubjectAltName extention + and the local KDC policy defines a mapping from the + SubjectAltName to a Kerberos name, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + mapping as necessary (e.g., as per RFC 2253 for X.500 + names). In this case the realm in the ticket shall be the + name of the certifier that issued the user's certificate. + + Note that a principal name may be carried in the subject alt name + field of a certificate. This name may be mapped to a principal + record in a security database based on local policy, for example + the subject alt name may be kerberos/principal@realm format. In + this case the realm name is not that of the CA but that of the + local realm doing the mapping (or some realm name chosen by that + realm). + + If a non-KDC X.509 certificate contains the principal name within + the subjectAltName version 3 extension , that name may utilize + KerberosName as defined below, or, in the case of an S/MIME + certificate [17], may utilize the email address. If the KDC + is presented with an S/MIME certificate, then the email address + within subjectAltName will be interpreted as a principal and realm + separated by the "@" sign, or as a name that needs to be + canonicalized. If the resulting name does not correspond to a + registered principal name, then the principal name is formed as + defined in section 3.1. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by the client's CA (if in the + middle of a CA key roll-over, use the KDC cert issued under same + CA key as user cert used to verify request). + 3. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + The KDC encrypts the reply not with the user's long-term key, but + with the Diffie Hellman derived key or a random key generated + for this particular response which is carried in the padata field of + the TGS-REP message. + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Hellman key exchange (if the + -- client public value was present in the + -- request). + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack [1] EnvelopedData, + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + Usage of SignedData: + + When the Diffie-Hellman option is used, dhSignedData in + PA-PK-AS-REP provides authenticated Diffie-Hellman parameters + of the KDC. The reply key used to encrypt part of the KDC reply + message is derived from the Diffie-Hellman exchange: + + 1. Both the KDC and the client calculate a secret value + (g^ab mod p), where a is the client's private exponent and + b is the KDC's private exponent. + + 2. Both the KDC and the client take the first N bits of this + secret value and convert it into a reply key. N depends on + the reply key type. + + 3. If the reply key is DES, N=64 bits, where some of the bits + are replaced with parity bits, according to FIPS PUB 74. + + 4. If the reply key is (3-key) 3-DES, N=192 bits, where some + of the bits are replaced with parity bits, according to + FIPS PUB 74. + + 5. The encapContentInfo field must contain the KdcDHKeyInfo as + defined below. + + a. The eContentType field shall contain the OID value for + pkdata: iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) pkdata (1) + + b. The eContent field is data of the type KdcDHKeyInfo + (below). + + 6. The certificates field must contain the certificates + necessary for the client to establish trust in the KDC's + certificate based on the list of trusted certifiers sent by + the client in the PA-PK-AS-REQ. This field may be empty if + the client did not send to the KDC a list of trusted + certifiers (the trustedCertifiers field was empty, meaning + that the client already possesses the KDC's certificate). + + 7. The signerInfos field is a SET that must contain at least + one member, since it contains the actual signature. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + nonce [0] INTEGER, + -- binds responce to the request + subjectPublicKey [2] BIT STRING + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + } + + Usage of EnvelopedData: + + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. It contains a temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + + 1. The originatorInfo field is not required, since that + information may be presented in the signedData structure + that is encrypted within the encryptedContentInfo field. + + 2. The optional unprotectedAttrs field is not required for + PKINIT. + + 3. The recipientInfos field is a SET which must contain exactly + one member of the KeyTransRecipientInfo type for encryption + with an RSA public key. + + a. The encryptedKey field (in KeyTransRecipientInfo) + contains the temporary key which is encrypted with the + PKINIT client's public key. + + 4. The encryptedContentInfo field contains the signed and + encrypted reply key. + + a. The contentType field shall contain the OID value for + id-signedData: iso (1) member-body (2) us (840) + rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) + + b. The encryptedContent field is encrypted data of the CMS + type signedData as specified below. + + i. The encapContentInfo field must contains the + ReplyKeyPack. + + * The eContentType field shall contain the OID value + for pkdata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkdata (1) + + * The eContent field is data of the type ReplyKeyPack + (below). + + ii. The certificates field must contain the certificates + necessary for the client to establish trust in the + KDC's certificate based on the list of trusted + certifiers sent by the client in the PA-PK-AS-REQ. + This field may be empty if the client did not send + to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the + client already possesses the KDC's certificate). + + iii. The signerInfos field is a SET that must contain at + least one member, since it contains the actual + signature. + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + Since each certifier in the certification path of a user's + certificate is equivalent to a separate Kerberos realm, the name + of each certifier in the certificate chain must be added to the + transited field of the ticket. The format of these realm names is + defined in Section 3.1 of this document. If applicable, the + transit-policy-checked flag should be set in the issued ticket. + + The KDC's certificate(s) must bind the public key(s) of the KDC to + a name derivable from the name of the realm for that KDC. X.509 + certificates shall contain the principal name of the KDC + (defined in section 8.2 of RFC 1510) as the SubjectAltName version + 3 extension. Below is the definition of this version 3 extension, + as specified by the X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] OtherName, + ... + } + + OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value [0] EXPLICIT ANY DEFINED BY type-id + } + + For the purpose of specifying a Kerberos principal name, the value + in OtherName shall be a KerberosName as defined in RFC 1510, but with + the PrincipalName replaced by CertPrincipalName as mentioned in + Section 3.1: + + KerberosName ::= SEQUENCE { + realm [0] Realm, + principalName [1] CertPrincipalName -- defined above + } + + This specific syntax is identified within subjectAltName by setting + the type-id in OtherName to krb5PrincipalName, where (from the + Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + + (This specification may also be used to specify a Kerberos name + within the user's certificate.) The KDC's certificate may be signed + directly by a CA, or there may be intermediaries if the server resides + within a large organization, or it may be unsigned if the client + indicates possession (and trust) of the KDC's certificate. + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. The client uses this + random key to decrypt the main reply, and subsequently proceeds as + described in RFC 1510. + +3.2.3. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + * Diffie-Hellman public/private key pairs + * utilizing Diffie-Hellman ephemeral-ephemeral mode + * SHA1 digest and DSA for signatures + * 3-key triple DES keys derived from the Diffie-Hellman Exchange + * 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + who use public key authentication. However, if these users are + registered with the KDC, it is recommended that the database record + for these users be modified to an additional flag in the attributes + field to indicate that the user should authenticate using PKINIT. + If this flag is set and a request message does not contain the + PKINIT preauthentication field, then the KDC sends back as error of + type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication + field of type PA-PK-AS-REQ must be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in the + limited capacity of self-signing their certificates, but one of the + additional benefits is to align Kerberos authentication with a global + public key infrastructure. Anyone using PKINIT in this way must be + aware of how the certification infrastructure they are linking to + works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, + A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm + Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt + + [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt + + [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman. + Public Key Utilizing Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-02.txt + + [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [9] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [10] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [11] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-13.txt, April 1999, approved for publication + as RFC. + + [12] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public + Key Infrastructure, Certificate and CRL Profile, January 1999. + Request for Comments 2459. + + [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography + Specifications, October 1998. Request for Comments 2437. + + [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME + Version 2 Certificate Handling, March 1998. Request for + Comments 2312. + + [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access + Protocol (v3), December 1997. Request for Comments 2251. + + [19] ITU-T (formerly CCITT) Information Processing Systems - Open + Systems Interconnection - Specification of Abstract Syntax Notation + One (ASN.1) Rec. X.680 ISO/IEC 8824-1 + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires September 15, 2000. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road + Issaquah WA 98027-5378 + Phone: +1 425 391 6000 + E-mail: matt.hur@cybersafe.com + + Ari Medvinsky + Keen.com, Inc. + 150 Independence Drive + Menlo Park CA 94025 + Phone: +1 650 289 3134 + E-mail: ari@keen.com + + Sasha Medvinsky + Motorola + 6450 Sequence Drive + San Diego, CA 92121 + Phone +1 619 404 2825 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt new file mode 100644 index 000000000000..b1e596836eb8 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt @@ -0,0 +1,1080 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-12.txt Clifford Neuman +Updates: RFC 1510 USC/ISI +expires January 15, 2001 Matthew Hur + CyberSafe Corporation + Ari Medvinsky + Keen.com, Inc. + Sasha Medvinsky + Motorola + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-11.txt, and expires January 15, + 2001. Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in + combination with digital signature keys as the primary, required + mechanism. It also allows for the use of RSA keys and/or (static) + Diffie-Hellman certificates. Note in particular that PKINIT supports + the use of separate signature and encryption keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends an AS-REQ message to the KDC as before, except that if that + user is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + Note that PKINIT does not require the use of certificates. A KDC + may store the public key of a principal as part of that principal's + record. In this scenario, the KDC is the trusted party that vouches + for the principal (as in a standard, non-cross realm, Kerberos + environment). Thus, for any principal, the KDC may maintain a + secret key, a public key, or both. + + The PKINIT specification may also be used as a building block for + other specifications. PKCROSS [3] utilizes PKINIT for establishing + the inter-realm key and associated inter-realm policy to be applied + in issuing cross realm service tickets. As specified in [4], + anonymous Kerberos tickets can be issued by applying a NULL + signature in combination with Diffie-Hellman in the PKINIT exchange. + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is described in PKTAPP [5] and is based on + concepts introduced in [6, 7]. For direct client-to-server + authentication, the client uses PKINIT to authenticate to the end + server (instead of a central KDC), which then issues a ticket for + itself. This approach has an advantage over TLS [8] in that the + server does not need to save state (cache session keys). + Furthermore, an additional benefit is that Kerberos tickets can + facilitate delegation (see [9]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510 is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_KDC_NAME_MISMATCH 76 + + We utilize the following typed data for errors: + + TD-PKINIT-CMS-CERTIFICATES 101 + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + We utilize the following encryption types (which map directly to + OIDs): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS#1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + + These mappings are provided so that a client may send the + appropriate enctypes in the AS-REQ message in order to indicate + support for the corresponding OIDs (for performing PKINIT). + + In many cases, PKINIT requires the encoding of the X.500 name of a + certificate authority as a Realm. When such a name appears as + a realm it will be represented using the "other" form of the realm + name as specified in the naming constraints section of RFC1510. + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + <nametype> + ":" + <string> + + where nametype is "X500-RFC2253" and string is the result of doing + an RFC2253 encoding of the distinguished name, i.e. + + "X500-RFC2253:" + RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + function returing a readable UTF encoding of an X.500 name, as + defined by RFC 2253 [14] (part of LDAPv3 [18]). + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, in cases where the KDC does not provide a specific + policy based mapping from the X.500 name or X.509 Version 3 + SubjectAltName extension in the user's certificate to a Kerberos + principal name, PKINIT requires the direct encoding of the X.500 + name as a PrincipalName. In this case, the name-type of the + principal name shall be set to KRB_NT-X500-PRINCIPAL. This new + name type is defined in RFC 1510 as: + + KRB_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. When this name type is used, the principal's + realm shall be set to the certificate authority's distinguished + name using the X500-RFC2253 realm name format described earlier in + this section + + RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: + + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + For the purposes of encoding an X.500 name as a Kerberos name for + use in Kerberos structures, the name-string shall be encoded as a + single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL, + as noted above. All Kerberos names must conform to validity + requirements as given in RFC 1510. Note that name mapping may be + required or optional, based on policy. + + We also define the following similar ASN.1 structure: + + CertPrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF UTF8String + } + + When a Kerberos PrincipalName is to be placed within an X.509 data + structure, the CertPrincipalName structure is to be used, with the + name-string encoded as a single UTF8String. The name-type should be + as identified in the original PrincipalName structure. The mapping + between the GeneralString and UTF8String formats can be found in + [19]. + + The following rules relate to the the matching of PrincipalNames (or + corresponding CertPrincipalNames) with regard to the PKI name + constraints for CAs as laid out in RFC 2459 [15]. In order to be + regarded as a match (for permitted and excluded name trees), the + following must be satisfied. + + 1. If the constraint is given as a user plus realm name, or + as a user plus instance plus realm name (as specified in + RFC 1510), the realm name must be valid (see 2.a-d below) + and the match must be exact, byte for byte. + + 2. If the constraint is given only as a realm name, matching + depends on the type of the realm: + + a. If the realm contains a colon (':') before any equal + sign ('='), it is treated as a realm of type Other, + and must match exactly, byte for byte. + + b. Otherwise, if the realm contains an equal sign, it + is treated as an X.500 name. In order to match, every + component in the constraint MUST be in the principal + name, and have the same value. For example, 'C=US' + matches 'C=US/O=ISI' but not 'C=UK'. + + c. Otherwise, if the realm name conforms to rules regarding + the format of DNS names, it is considered a realm name of + type Domain. The constraint may be given as a realm + name 'FOO.BAR', which matches any PrincipalName within + the realm 'FOO.BAR' but not those in subrealms such as + 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' + matches PrincipalNames in subrealms of the form + 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. + + d. Otherwise, the realm name is invalid and does not match + under any conditions. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys for RSA + keys. + + In the case of Diffie-Hellman, the key shall be produced from the + agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + The following signature algorithm identifiers specified in [11] and + in [15] shall be used with PKINIT: + + id-dsa-with-sha1 (DSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + sha-1WithRSAEncryption (RSA with SHA1) + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + The following algorithm identifier shall be used within the + SubjectPublicKeyInfo data structure: dhpublicnumber + + This identifier and the associated algorithm parameters are + specified in RFC 2459 [15]. + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption (RSA encryption, PKCS#1 v1.5) + id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) + + Both of the above RSA encryption schemes are specified in [16]. + Currently, only PKCS#1 v1.5 is specified by CMS [11], although the + CMS specification says that it will likely include PKCS#1 v2.0 in + the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext + vulnerability discovered in PKCS#1 v1.5.) + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure in the PKINIT Reply, for encrypting the reply key with the + temporary key: + des-ede3-cbc (3-key 3-DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + The full definition of the above algorithm identifiers and their + corresponding parameters (an IV for block chaining) is provided in + the CMS specification [11]. + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + +3.2.1. Client Request + + Public keys may be signed by some certification authority (CA), or + they may be maintained by the KDC in which case the KDC is the + trusted authority. Note that the latter mode does not require the + use of certificates. + + The initial authentication request is sent as per RFC 1510, except + that a preauthentication field containing data signed by the user's + private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedData + -- Defined in CMS [11]; + -- AuthPack (below) defines the + -- data that is signed. + trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, + -- This is a list of CAs that the + -- client trusts and that certify + -- KDCs. + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- As defined in CMS [11]; + -- specifies a particular KDC + -- certificate if the client + -- already has it. + encryptionCert [3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. + } + + TrustedCas ::= CHOICE { + principalName [0] KerberosName, + -- as defined below + caName [1] Name + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial [2] IssuerAndSerialNumber + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts + } + + Usage of SignedData: + + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. The following describes how to fill in the fields of + this data: + + 1. The encapContentInfo field must contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + + a. The eContentType field shall contain the OID value for + pkauthdata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkauthdata (1) + + b. The eContent field is data of the type AuthPack (below). + + 2. The signerInfos field contains the signature of AuthPack. + + 3. The Certificates field, when non-empty, contains the client's + certificate chain. If present, the KDC uses the public key + from the client's certificate to verify the signature in the + request. Note that the client may pass different certificate + chains that are used for signing or for encrypting. Thus, + the KDC may utilize a different client certificate for + signature verification than the one it uses to encrypt the + reply to the client. For example, the client may place a + Diffie-Hellman certificate in this field in order to convey + its static Diffie Hellman certificate to the KDC to enable + static-ephemeral Diffie-Hellman mode for the reply; in this + case, the client does NOT place its public value in the + AuthPack (defined below). As another example, the client may + place an RSA encryption certificate in this field. However, + there must always be (at least) a signature certificate. + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + -- (ephemeral-ephemeral only) + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER, + -- for replay prevention as in RFC1510 + ctime [1] KerberosTime, + -- for replay prevention as in RFC1510 + nonce [2] INTEGER, + pachecksum [3] Checksum + -- Checksum over KDC-REQ-BODY + -- Defined by Kerberos spec + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [10] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm OBJECT IDENTIFIER, + -- for dhKeyAgreement, this is + -- { iso (1) member-body (2) US (840) + -- rsadsi (113459) pkcs (1) 3 1 } + -- from PKCS #3 [20] + parameters ANY DEFINED by algorithm OPTIONAL + -- for dhKeyAgreement, this is + -- DHParameter + } -- as specified by the X.509 recommendation [10] + + DHParameter ::= SEQUENCE { + prime INTEGER, + -- p + base INTEGER, + -- g + privateValueLength INTEGER OPTIONAL + -- l + } -- as defined in PKCS #3 [20] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-data, which + is defined in RFC 1510 revisions as a SEQUENCE of TypedData: + + TypedData ::= SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING, + } -- per Kerberos RFC 1510 revisions + + where: + data-type = TD-PKINIT-CMS-CERTIFICATES = 101 + data-value = CertificateSet // as specified by CMS [11] + + The PKAuthenticator carries information to foil replay attacks, to + bind the pre-authentication data to the KDC-REQ-BODY, and to bind the + request and response. The PKAuthenticator is signed with the client's + signature key. + +3.2.2. KDC Response + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If the client's certificate chain contains no certificate signed by + a CA trusted by the KDC, then the KDC sends back an error message + of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data + is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) + whose data-value is an OCTET STRING which is the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 + + If while verifying a certificate chain the KDC determines that the + signature on one of the certificates in the CertificateSet from + the signedAuthPack fails verification, then the KDC returns an + error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying + e-data is a SEQUENCE of one TypedData (with type + TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING + which is the DER encoding of the index into the CertificateSet + ordered as sent by the client. + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + + The KDC may also check whether any of the certificates in the + client's chain has been revoked. If one of the certificates has + been revoked, then the KDC returns an error of type + KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that + the certificate's revocation status is unknown or not + available, then if required by policy, the KDC returns the + appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three + cases, the affected certificate is identified by the accompanying + e-data, which contains a CertificateIndex as described for + KDC_ERR_INVALID_CERTIFICATE. + + If the certificate chain can be verified, but the name of the + client in the certificate does not match the client's name in the + request, then the KDC returns an error of type + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data + field in this case. + + Finally, if the certificate chain is verified, but the KDC's name + or realm as given in the PKAuthenticator does not match the KDC's + actual principal name, then the KDC returns an error of type + KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again + a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or + TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET + STRING whose data-value is the DER encoding of a PrincipalName or + Realm as defined in RFC 1510 revisions. + + Even if all succeeds, the KDC may--for policy reasons--decide not + to trust the client. In this case, the KDC returns an error message + of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is + the presence or absence of an Enhanced Key Usage (EKU) OID within + the certificate extensions. The rules regarding acceptability of + an EKU sequence (or the absence of any sequence) are a matter of + local policy. For the benefit of implementers, we define a PKINIT + EKU OID as the following: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains the SubjectAltName extention + and the local KDC policy defines a mapping from the + SubjectAltName to a Kerberos name, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + mapping as necessary (e.g., as per RFC 2253 for X.500 + names). In this case the realm in the ticket shall be the + name of the certifier that issued the user's certificate. + + Note that a principal name may be carried in the subject alt name + field of a certificate. This name may be mapped to a principal + record in a security database based on local policy, for example + the subject alt name may be kerberos/principal@realm format. In + this case the realm name is not that of the CA but that of the + local realm doing the mapping (or some realm name chosen by that + realm). + + If a non-KDC X.509 certificate contains the principal name within + the subjectAltName version 3 extension , that name may utilize + KerberosName as defined below, or, in the case of an S/MIME + certificate [17], may utilize the email address. If the KDC + is presented with an S/MIME certificate, then the email address + within subjectAltName will be interpreted as a principal and realm + separated by the "@" sign, or as a name that needs to be + canonicalized. If the resulting name does not correspond to a + registered principal name, then the principal name is formed as + defined in section 3.1. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by the client's CA (if in the + middle of a CA key roll-over, use the KDC cert issued under same + CA key as user cert used to verify request). + 3. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + The KDC encrypts the reply not with the user's long-term key, but + with the Diffie Hellman derived key or a random key generated + for this particular response which is carried in the padata field of + the TGS-REP message. + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Hellman key exchange (if the + -- client public value was present in the + -- request). + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack [1] EnvelopedData, + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + Usage of SignedData: + + When the Diffie-Hellman option is used, dhSignedData in + PA-PK-AS-REP provides authenticated Diffie-Hellman parameters + of the KDC. The reply key used to encrypt part of the KDC reply + message is derived from the Diffie-Hellman exchange: + + 1. Both the KDC and the client calculate a secret value + (g^ab mod p), where a is the client's private exponent and + b is the KDC's private exponent. + + 2. Both the KDC and the client take the first N bits of this + secret value and convert it into a reply key. N depends on + the reply key type. + + 3. If the reply key is DES, N=64 bits, where some of the bits + are replaced with parity bits, according to FIPS PUB 74. + + 4. If the reply key is (3-key) 3-DES, N=192 bits, where some + of the bits are replaced with parity bits, according to + FIPS PUB 74. + + 5. The encapContentInfo field must contain the KdcDHKeyInfo as + defined below. + + a. The eContentType field shall contain the OID value for + pkdhkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) + + b. The eContent field is data of the type KdcDHKeyInfo + (below). + + 6. The certificates field must contain the certificates + necessary for the client to establish trust in the KDC's + certificate based on the list of trusted certifiers sent by + the client in the PA-PK-AS-REQ. This field may be empty if + the client did not send to the KDC a list of trusted + certifiers (the trustedCertifiers field was empty, meaning + that the client already possesses the KDC's certificate). + + 7. The signerInfos field is a SET that must contain at least + one member, since it contains the actual signature. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + nonce [0] INTEGER, + -- binds responce to the request + subjectPublicKey [2] BIT STRING + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + } + + Usage of EnvelopedData: + + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. It contains a temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + + 1. The originatorInfo field is not required, since that + information may be presented in the signedData structure + that is encrypted within the encryptedContentInfo field. + + 2. The optional unprotectedAttrs field is not required for + PKINIT. + + 3. The recipientInfos field is a SET which must contain exactly + one member of the KeyTransRecipientInfo type for encryption + with an RSA public key. + + a. The encryptedKey field (in KeyTransRecipientInfo) + contains the temporary key which is encrypted with the + PKINIT client's public key. + + 4. The encryptedContentInfo field contains the signed and + encrypted reply key. + + a. The contentType field shall contain the OID value for + id-signedData: iso (1) member-body (2) us (840) + rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) + + b. The encryptedContent field is encrypted data of the CMS + type signedData as specified below. + + i. The encapContentInfo field must contains the + ReplyKeyPack. + + * The eContentType field shall contain the OID value + for pkrkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) + + * The eContent field is data of the type ReplyKeyPack + (below). + + ii. The certificates field must contain the certificates + necessary for the client to establish trust in the + KDC's certificate based on the list of trusted + certifiers sent by the client in the PA-PK-AS-REQ. + This field may be empty if the client did not send + to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the + client already possesses the KDC's certificate). + + iii. The signerInfos field is a SET that must contain at + least one member, since it contains the actual + signature. + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + Since each certifier in the certification path of a user's + certificate is equivalent to a separate Kerberos realm, the name + of each certifier in the certificate chain must be added to the + transited field of the ticket. The format of these realm names is + defined in Section 3.1 of this document. If applicable, the + transit-policy-checked flag should be set in the issued ticket. + + The KDC's certificate(s) must bind the public key(s) of the KDC to + a name derivable from the name of the realm for that KDC. X.509 + certificates shall contain the principal name of the KDC + (defined in section 8.2 of RFC 1510) as the SubjectAltName version + 3 extension. Below is the definition of this version 3 extension, + as specified by the X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] OtherName, + ... + } + + OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value [0] EXPLICIT ANY DEFINED BY type-id + } + + For the purpose of specifying a Kerberos principal name, the value + in OtherName shall be a KerberosName as defined in RFC 1510, but with + the PrincipalName replaced by CertPrincipalName as mentioned in + Section 3.1: + + KerberosName ::= SEQUENCE { + realm [0] Realm, + principalName [1] CertPrincipalName -- defined above + } + + This specific syntax is identified within subjectAltName by setting + the type-id in OtherName to krb5PrincipalName, where (from the + Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + + (This specification may also be used to specify a Kerberos name + within the user's certificate.) The KDC's certificate may be signed + directly by a CA, or there may be intermediaries if the server resides + within a large organization, or it may be unsigned if the client + indicates possession (and trust) of the KDC's certificate. + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. The client uses this + random key to decrypt the main reply, and subsequently proceeds as + described in RFC 1510. + +3.2.3. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + * Diffie-Hellman public/private key pairs + * utilizing Diffie-Hellman ephemeral-ephemeral mode + * SHA1 digest and DSA for signatures + * SHA1 digest also for the Checksum in the PKAuthenticator + * 3-key triple DES keys derived from the Diffie-Hellman Exchange + * 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + who use public key authentication. However, if these users are + registered with the KDC, it is recommended that the database record + for these users be modified to an additional flag in the attributes + field to indicate that the user should authenticate using PKINIT. + If this flag is set and a request message does not contain the + PKINIT preauthentication field, then the KDC sends back as error of + type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication + field of type PA-PK-AS-REQ must be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in the + limited capacity of self-signing their certificates, but one of the + additional benefits is to align Kerberos authentication with a global + public key infrastructure. Anyone using PKINIT in this way must be + aware of how the certification infrastructure they are linking to + works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, + A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm + Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt + + [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt + + [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman. + Public Key Utilizing Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-02.txt + + [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [9] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [10] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [11] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-13.txt, April 1999, approved for publication + as RFC. + + [12] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public + Key Infrastructure, Certificate and CRL Profile, January 1999. + Request for Comments 2459. + + [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography + Specifications, October 1998. Request for Comments 2437. + + [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME + Version 2 Certificate Handling, March 1998. Request for + Comments 2312. + + [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access + Protocol (v3), December 1997. Request for Comments 2251. + + [19] ITU-T (formerly CCITT) Information Processing Systems - Open + Systems Interconnection - Specification of Abstract Syntax Notation + One (ASN.1) Rec. X.680 ISO/IEC 8824-1 + + [20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA + Laboratories Technical Note, Version 1.4, Revised November 1, 1993. + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires January 15, 2001. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road + Issaquah WA 98027-5378 + Phone: +1 425 391 6000 + E-mail: matt.hur@cybersafe.com + + Ari Medvinsky + Keen.com, Inc. + 150 Independence Drive + Menlo Park CA 94025 + Phone: +1 650 289 3134 + E-mail: ari@keen.com + + Sasha Medvinsky + Motorola + 6450 Sequence Drive + San Diego, CA 92121 + +1 858 404 2367 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt new file mode 100644 index 000000000000..6581dd5810a5 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt @@ -0,0 +1,378 @@ +INTERNET-DRAFT Ari Medvinsky +draft-ietf-cat-kerberos-pk-tapp-03.txt Keen.com, Inc. +Expires January 14, 2001 Matthew Hur +Informational CyberSafe Corporation + Sasha Medvinsky + Motorola + Clifford Neuman + USC/ISI + +Public Key Utilizing Tickets for Application Servers (PKTAPP) + + +0. Status Of this Memo + +This document is an Internet-Draft and is in full conformance with +all provisions of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), +its areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six +months and may be updated, replaced, or obsoleted by other +documents at any time. It is inappropriate to use Internet-Drafts +as reference material or to cite them other than as "work in +progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +To learn the current status of any Internet-Draft, please check +the "1id-abstracts.txt" listing contained in the Internet-Drafts +Shadow Directories on ftp.ietf.org (US East Coast), +nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or +munnari.oz.au (Pacific Rim). + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30, +2000. Please send comments to the authors. + +1. Abstract + +Public key based Kerberos for Distributed Authentication[1], (PKDA) +proposed by Sirbu & Chuang, describes PK based authentication that +eliminates the use of a centralized key distribution center while +retaining the advantages of Kerberos tickets. This draft describes how, +without any modification, the PKINIT specification[2] may be used to +implement the ideas introduced in PKDA. The benefit is that only a +single PK Kerberos extension is needed to address the goals of PKINIT & +PKDA. + + + +2. Introduction + +With the proliferation of public key cryptography, a number of public +key extensions to Kerberos have been proposed to provide +interoperability with the PK infrastructure and to improve the Kerberos +authentication system [4]. Among these are PKINIT[2] (under development +in the CAT working group) and more recently PKDA [1] proposed by Sirbu & +Chuang of CMU. One of the principal goals of PKINIT is to provide for +interoperability between a PK infrastructure and Kerberos. Using +PKINIT, a user can authenticate to the KDC via a public key certificate. +A ticket granting ticket (TGT), returned by the KDC, enables a PK user +to obtain tickets and authenticate to kerberized services. The PKDA +proposal goes a step further. It supports direct client to server +authentication, eliminating the need for an online key distribution +center. In this draft, we describe how, without any modification, the +PKINIT protocol may be applied to achieve the goals of PKDA. For direct +client to server authentication, the client will use PKINIT to +authenticate to the end server (instead of a central KDC), which then, +will issue a ticket for itself. The benefit of this proposal, is that a +single PK extension to Kerberos can addresses the goals of PKINIT and +PKDA. + + +3. PKDA background + +The PKDA proposal provides direct client to server authentication, thus +eliminating the need for an online key distribution center. A client +and server take part in an initial PK based authentication exchange, +with an added caveat that the server acts as a Kerberos ticket granting +service and issues a traditional Kerberos ticket for itself. In +subsequent communication, the client makes use of the Kerberos ticket, +thus eliminating the need for public key operations on the server. This +approach has an advantage over SSL in that the server does not need to +save state (cache session keys). Furthermore, an additional benefit, is +that Kerberos tickets can facilitate delegation (see Neuman[3]). + +Below is a brief overview of the PKDA protocol. For a more detailed +description see [1]. + +SCERT_REQ: Client to Server +The client requests a certificate from the server. If the serverÆs +certificate is cached locally, SCERT_REQ and SCERT_REP are omitted. + +SCERT_REP: Server to Client +The server returns its certificate to the client. + +PKTGS_REQ: Client to Server +The client sends a request for a service ticket to the server. To +authenticate the request, the client signs, among other fields, a time +stamp and a newly generated symmetric key . The time stamp is used to +foil replay attacks; the symmetric key is used by the server to secure +the PKTGS_REP message. +The client provides a certificate in the request (the certificate +enables the server to verify the validity of the clientÆs signature) and +seals it along with the signed information using the serverÆs public +key. + + +PKTGS_REP: Server to Client +The server returns a service ticket (which it issued for itself) along +with the session key for the ticket. The session key is protected by +the client-generated key from the PKTGS_REQ message. + +AP_REQ: Client to Server +After the above exchange, the client can proceed in a normal fashion, +using the conventional Kerberos ticket in an AP_REQ message. + + +4. PKINIT background + +One of the principal goals of PKINIT is to provide for interoperability +between a public key infrastructure and Kerberos. Using a public key +certificate, a client can authenticate to the KDC and receive a TGT +which enables the client to obtain service tickets to kerberized +services.. In PKINIT, the AS-REQ and AS-REP messages remain the same; +new preauthentication data types are used to conduct the PK exchange. +Client and server certificates are exchanged via the preauthentication +data. Thus, the exchange of certificates , PK authentication, and +delivery of a TGT can occur in two messages. + +Below is a brief overview of the PKINIT protocol. For a more detailed +description see [2]. + +PreAuthentication data of AS-REQ: Client to Server +The client sends a list of trusted certifiers, a signed PK +authenticator, and its certificate. The PK authenticator, based on the +Kerberos authenticator, contains the name of the KDC, a timestamp, and a +nonce. + +PreAuthentication data of AS-REP: Server to Client +The server responds with its certificate and the key used for decrypting +the encrypted part of the AS-REQ. This key is encrypted with the +clientÆs public key. + +AP_REQ: Client to Server +After the above exchange, the client can proceed in a normal fashion, +using the conventional Kerberos ticket in an AP_REQ message. + + +5. Application of PKINIT to achieve equivalence to PKDA + +While PKINIT is normally used to retrieve a ticket granting ticket +(TGT), it may also be used to request an end service ticket. When used +in this fashion, PKINIT is functionally equivalent to PKDA. We +introduce the concept of a local ticket granting server (LTGS) to +illustrate how PKINIT may be used for issuing end service tickets based +on public key authentication. It is important to note that the LTGS may +be built into an application server, or it may be a stand-alone server +used for issuing tickets within a well-defined realm, such as a single +machine. We will discuss both of these options. + + +5.1. The LTGS + +The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT +preauthentication data. When a client submits an AS-REQ to the LTGS, it +specifies an application server, in order to receive an end service +ticket instead of a TGT. + + +5.1.1. The LTGS as a standalone server + +The LTGS may run as a separate process that serves applications which +reside on the same machine. This serves to consolidate administrative +functions and provide an easier migration path for a heterogeneous +environment consisting of both public key and Kerberos. The LTGS would +use one well-known port (port #88 - same as the KDC) for all message +traffic and would share a symmetric with each service. After the client +receives a service ticket, it then contacts the application server +directly. This approach is similar to the one suggested by Sirbu , et +al [1]. + +5.1.1.1. Ticket Policy for PKTAPP Clients + +It is desirable for the LTGS to have access to a PKTAPP client ticket +policy. This policy will contain information for each client, such as +the maximum lifetime of a ticket, whether or not a ticket can be +forwardable, etc. PKTAPP clients, however, use the PKINIT protocol for +authentication and are not required to be registered as Kerberos +principals. + +As one possible solution, each public key Certification Authority could +be registered in a secure database, along with the ticket policy +information for all PKTAPP clients that are certified by this +Certification Authority. + +5.1.1.2. LTGS as a Kerberos Principal + +Since the LTGS serves only PKTAPP clients and returns only end service +tickets for other services, it does not require a Kerberos service key +or a Kerberos principal identity. It is therefore not necessary for the +LTGS to even be registered as a Kerberos principal. + +The LTGS still requires public key credentials for the PKINIT exchange, +and it may be desired to have some global restrictions on the Kerberos +tickets that it can issue. It is recommended (but not required) that +this information be associated with a Kerberos principal entry for the +LTGS. + + +5.1.1.3. Kerberos Principal Database + +Since the LTGS issues tickets for Kerberos services, it will require +access to a Kerberos principal database containing entries for at least +the end services. Each entry must contain a service key and may also +contain restrictions on the service tickets that are issued to clients. +It is recommended that (for ease of administration) this principal +database be centrally administered and distributed (replicated) to all +hosts where an LTGS may be running. + +In the case that there are other clients that do not support PKINIT +protocol, but still need access to the same Kerberos services, this +principal database will also require entries for Kerberos clients and +for the TGS entries. + +5.1.2. The LTGS as part of an application server + +The LTGS may be combined with an application server. This accomplishes +direct client to application server authentication; however, it requires +that applications be modified to process AS-REQ and AS-REP messages. +The LTGS would communicate over the port assigned to the application +server or over the well known Kerberos port for that particular +application. + +5.1.2.2. Ticket Policy for PKTAPP Clients + +Application servers normally do not have access to a distributed +principal database. Therefore, they will have to find another means of +keeping track of the ticket policy information for PKTAPP clients. It is +recommended that this ticket policy be kept in a directory service (such +as LDAP). + +It is critical, however, that both read and write access to this ticket +policy is restricted with strong authentication and encryption to only +the correct application server. An unauthorized party should not have +the authority to modify the ticket policy. Disclosing the ticket policy +to a 3rd party may aid an adversary in determining the best way to +compromise the network. + +It is just as critical for the application server to authenticate the +directory service. Otherwise an adversary could use a man-in-the-middle +attack to substitute a false ticket policy with a false directory +service. + +5.1.2.3. LTGS Credentials + +Each LTGS (combined with an application service) will require public key +credentials in order to use the PKINIT protocol. These credentials can +be stored in a single file that is both encrypted with a password- +derived symmetric key and also secured by an operating system. This +symmetric key may be stashed somewhere on the machine for convenience, +although such practice potentially weakens the overall system security +and is strongly discouraged. + +For added security, it is recommended that the LTGS private keys are +stored inside a temper-resistant hardware module that requires a pin +code for access. + + +5.1.2.4. Compatibility With Standard Kerberos + +Even though an application server is combined with the LTGS, for +backward compatibility it should still accept service tickets that have +been issued by the KDC. This will allow Kerberos clients that do not +support PKTAPP to authenticate to the same application server (with the +help of a KDC). + +5.1.3. Cross-Realm Authentication + +According to the PKINIT draft, the client's realm is the X.500 name of +the Certification Authority that issued the client certificate. A +Kerberos application service will be in a standard Kerberos realm, which +implies that the LTGS will need to issue cross-realm end service +tickets. This is the only case, where cross-realm end service tickets +are issued. In a standard Kerberos model, a client first acquires a +cross-realm TGT, and then gets an end service ticket from the KDC that +is in the same realm as the application service. + +6. Protocol differences between PKINIT and PKDA + +Both PKINIT and PKDA will accomplish the same goal of issuing end +service tickets, based on initial public key authentication. A PKINIT- +based implementation and a PKDA implementation would be functionally +equivalent. The primary differences are that 1)PKDA requires the client +to create the symmetric key while PKINIT requires the server to create +the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes +in four messages. + +7. Summary + +The PKINIT protocol can be used, without modification to facilitate +client to server authentication without the use of a central KDC. The +approach described in this draft (and originally proposed in PKDA[1]) +is essentially a public key authentication protocol that retains the +advantages of Kerberos tickets. + +Given that PKINIT has progressed through the CAT working group of the +IETF, with plans for non-commercial distribution (via MITÆs v5 Kerberos) +as well as commercial support, it is worthwhile to provide PKDA +functionality, under the PKINIT umbrella. + +8. Security Considerations + +PKTAPP is based on the PKINIT protocol and all security considerations +already listed in [2] apply here. + +When the LTGS is implemented as part of each application server, the +secure storage of its public key credentials and of its ticket policy +are both a concern. The respective security considerations are already +covered in sections 5.1.2.3 and 5.1.2.2 of this document. + + +9. Bibliography + +[1] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using +Public Key Cryptography. Symposium On Network and Distributed System +Security, 1997. + +[2] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, +J. Trostle. Public Key Cryptography for Initial Authentication in +Kerberos. Internet Draft, October 1999. +(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt) + +[3] C. Neuman, Proxy-Based Authorization and Accounting for +Distributed Systems. In Proceedings of the 13th International +Conference on Distributed Computing Systems, May 1993. + +[4] J. Kohl, C. Neuman. The Kerberos Network Authentication Service +(V5). Request for Comments 1510. + +10. Expiration Date + +This draft expires April 24, 2000. + +11. Authors + +Ari Medvinsky +Keen.com, Inc. +150 Independence Dr. +Menlo Park, CA 94025 +Phone +1 650 289 3134 +E-mail: ari@keen.com + +Matthew Hur +CyberSafe Corporation +1605 NW Sammamish Road +Issaquah, WA 98027-5378 +Phone: +1 425 391 6000 +E-mail: matt.hur@cybersafe.com + +Alexander Medvinsky +Motorola +6450 Sequence Dr. +San Diego, CA 92121 +Phone: +1 858 404 2367 +E-mail: smedvinsky@gi.com + +Clifford Neuman +USC Information Sciences Institute +4676 Admiralty Way Suite 1001 +Marina del Rey CA 90292-6695 +Phone: +1 310 822 1511 +E-mail: bcn@isi.edu diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt new file mode 100644 index 000000000000..15921248c117 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt @@ -0,0 +1,6866 @@ +INTERNET-DRAFT Clifford Neuman + John Kohl + Theodore Ts'o + March 10, 2000 + Expires September 10, 2000 + +The Kerberos Network Authentication Service (V5) +draft-ietf-cat-kerberos-revisions-05.txt + +STATUS OF THIS MEMO + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC 2026. Internet-Drafts are working documents +of the Internet Engineering Task Force (IETF), its areas, and its working +groups. Note that other groups may also distribute working documents as +Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months and +may be updated, replaced, or obsoleted by other documents at any time. It is +inappropriate to use Internet-Drafts as reference material or to cite them +other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +To learn the current status of any Internet-Draft, please check the +"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow +Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), +ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-revisions-05.txt, and expires September 10, 2000. +Please send comments to: krb-protocol@MIT.EDU + +ABSTRACT + +This document provides an overview and specification of Version 5 of the +Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol +and its intended use that require more detailed or clearer explanation than +was provided in RFC1510. This document is intended to provide a detailed +description of the protocol, suitable for implementation, together with +descriptions of the appropriate use of protocol messages and fields within +those messages. + +This document is not intended to describe Kerberos to the end user, system +administrator, or application developer. Higher level papers describing +Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], +are available elsewhere. + +OVERVIEW + +This INTERNET-DRAFT describes the concepts and model upon which the Kerberos +network authentication system is based. It also specifies Version 5 of the +Kerberos protocol. + +The motivations, goals, assumptions, and rationale behind most design +decisions are treated cursorily; they are more fully described in a paper + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +available in IEEE communications [NT94] and earlier in the Kerberos portion +of the Athena Technical Plan [MNSS87]. The protocols have been a proposed +standard and are being considered for advancement for draft standard through +the IETF standard process. Comments are encouraged on the presentation, but +only minor refinements to the protocol as implemented or extensions that fit +within current protocol framework will be considered at this time. + +Requests for addition to an electronic mailing list for discussion of +Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. +This mailing list is gatewayed onto the Usenet as the group +comp.protocols.kerberos. Requests for further information, including +documents and code availability, may be sent to info-kerberos@MIT.EDU. + +BACKGROUND + +The Kerberos model is based in part on Needham and Schroeder's trusted +third-party authentication protocol [NS78] and on modifications suggested by +Denning and Sacco [DS81]. The original design and implementation of Kerberos +Versions 1 through 4 was the work of two former Project Athena staff +members, Steve Miller of Digital Equipment Corporation and Clifford Neuman +(now at the Information Sciences Institute of the University of Southern +California), along with Jerome Saltzer, Technical Director of Project +Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members +of Project Athena have also contributed to the work on Kerberos. + +Version 5 of the Kerberos protocol (described in this document) has evolved +from Version 4 based on new requirements and desires for features not +available in Version 4. The design of Version 5 of the Kerberos protocol was +led by Clifford Neuman and John Kohl with much input from the community. The +development of the MIT reference implementation was led at MIT by John Kohl +and Theodore T'so, with help and contributed code from many others. Since +RFC1510 was issued, extensions and revisions to the protocol have been +proposed by many individuals. Some of these proposals are reflected in this +document. Where such changes involved significant effort, the document cites +the contribution of the proposer. + +Reference implementations of both version 4 and version 5 of Kerberos are +publicly available and commercial implementations have been developed and +are widely used. Details on the differences between Kerberos Versions 4 and +5 can be found in [KNT92]. + +1. Introduction + +Kerberos provides a means of verifying the identities of principals, (e.g. a +workstation user or a network server) on an open (unprotected) network. This +is accomplished without relying on assertions by the host operating system, +without basing trust on host addresses, without requiring physical security +of all the hosts on the network, and under the assumption that packets +traveling along the network can be read, modified, and inserted at will[1]. +Kerberos performs authentication under these conditions as a trusted +third-party authentication service by using conventional (shared secret key +[2] cryptography. Kerberos extensions have been proposed and implemented +that provide for the use of public key cryptography during certain phases of +the authentication protocol. These extensions provide for authentication of +users registered with public key certification authorities, and allow the +system to provide certain benefits of public key cryptography in situations +where they are needed. + +The basic Kerberos authentication process proceeds as follows: A client + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +sends a request to the authentication server (AS) requesting 'credentials' +for a given server. The AS responds with these credentials, encrypted in the +client's key. The credentials consist of 1) a 'ticket' for the server and 2) +a temporary encryption key (often called a "session key"). The client +transmits the ticket (which contains the client's identity and a copy of the +session key, all encrypted in the server's key) to the server. The session +key (now shared by the client and server) is used to authenticate the +client, and may optionally be used to authenticate the server. It may also +be used to encrypt further communication between the two parties or to +exchange a separate sub-session key to be used to encrypt further +communication. + +Implementation of the basic protocol consists of one or more authentication +servers running on physically secure hosts. The authentication servers +maintain a database of principals (i.e., users and servers) and their secret +keys. Code libraries provide encryption and implement the Kerberos protocol. +In order to add authentication to its transactions, a typical network +application adds one or two calls to the Kerberos library directly or +through the Generic Security Services Application Programming Interface, +GSSAPI, described in separate document. These calls result in the +transmission of the necessary messages to achieve authentication. + +The Kerberos protocol consists of several sub-protocols (or exchanges). +There are two basic methods by which a client can ask a Kerberos server for +credentials. In the first approach, the client sends a cleartext request for +a ticket for the desired server to the AS. The reply is sent encrypted in +the client's secret key. Usually this request is for a ticket-granting +ticket (TGT) which can later be used with the ticket-granting server (TGS). +In the second method, the client sends a request to the TGS. The client uses +the TGT to authenticate itself to the TGS in the same manner as if it were +contacting any other application server that requires Kerberos +authentication. The reply is encrypted in the session key from the TGT. +Though the protocol specification describes the AS and the TGS as separate +servers, they are implemented in practice as different protocol entry points +within a single Kerberos server. + +Once obtained, credentials may be used to verify the identity of the +principals in a transaction, to ensure the integrity of messages exchanged +between them, or to preserve privacy of the messages. The application is +free to choose whatever protection may be necessary. + +To verify the identities of the principals in a transaction, the client +transmits the ticket to the application server. Since the ticket is sent "in +the clear" (parts of it are encrypted, but this encryption doesn't thwart +replay) and might be intercepted and reused by an attacker, additional +information is sent to prove that the message originated with the principal +to whom the ticket was issued. This information (called the authenticator) +is encrypted in the session key, and includes a timestamp. The timestamp +proves that the message was recently generated and is not a replay. +Encrypting the authenticator in the session key proves that it was generated +by a party possessing the session key. Since no one except the requesting +principal and the server know the session key (it is never sent over the +network in the clear) this guarantees the identity of the client. + +The integrity of the messages exchanged between principals can also be +guaranteed using the session key (passed in the ticket and contained in the +credentials). This approach provides detection of both replay attacks and +message stream modification attacks. It is accomplished by generating and +transmitting a collision-proof checksum (elsewhere called a hash or digest + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +function) of the client's message, keyed with the session key. Privacy and +integrity of the messages exchanged between principals can be secured by +encrypting the data to be passed using the session key contained in the +ticket or the subsession key found in the authenticator. + +The authentication exchanges mentioned above require read-only access to the +Kerberos database. Sometimes, however, the entries in the database must be +modified, such as when adding new principals or changing a principal's key. +This is done using a protocol between a client and a third Kerberos server, +the Kerberos Administration Server (KADM). There is also a protocol for +maintaining multiple copies of the Kerberos database. Neither of these +protocols are described in this document. + +1.1. Cross-Realm Operation + +The Kerberos protocol is designed to operate across organizational +boundaries. A client in one organization can be authenticated to a server in +another. Each organization wishing to run a Kerberos server establishes its +own 'realm'. The name of the realm in which a client is registered is part +of the client's name, and can be used by the end-service to decide whether +to honor a request. + +By establishing 'inter-realm' keys, the administrators of two realms can +allow a client authenticated in the local realm to prove its identity to +servers in other realms[3]. The exchange of inter-realm keys (a separate key +may be used for each direction) registers the ticket-granting service of +each realm as a principal in the other realm. A client is then able to +obtain a ticket-granting ticket for the remote realm's ticket-granting +service from its local realm. When that ticket-granting ticket is used, the +remote ticket-granting service uses the inter-realm key (which usually +differs from its own normal TGS key) to decrypt the ticket-granting ticket, +and is thus certain that it was issued by the client's own TGS. Tickets +issued by the remote ticket-granting service will indicate to the +end-service that the client was authenticated from another realm. + +A realm is said to communicate with another realm if the two realms share an +inter-realm key, or if the local realm shares an inter-realm key with an +intermediate realm that communicates with the remote realm. An +authentication path is the sequence of intermediate realms that are +transited in communicating from one realm to another. + +Realms are typically organized hierarchically. Each realm shares a key with +its parent and a different key with each child. If an inter-realm key is not +directly shared by two realms, the hierarchical organization allows an +authentication path to be easily constructed. If a hierarchical organization +is not used, it may be necessary to consult a database in order to construct +an authentication path between realms. + +Although realms are typically hierarchical, intermediate realms may be +bypassed to achieve cross-realm authentication through alternate +authentication paths (these might be established to make communication +between two realms more efficient). It is important for the end-service to +know which realms were transited when deciding how much faith to place in +the authentication process. To facilitate this decision, a field in each +ticket contains the names of the realms that were involved in authenticating +the client. + +The application server is ultimately responsible for accepting or rejecting +authentication and should check the transited field. The application server + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +may choose to rely on the KDC for the application server's realm to check +the transited field. The application server's KDC will set the +TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate +realms may also check the transited field as they issue +ticket-granting-tickets for other realms, but they are encouraged not to do +so. A client may request that the KDC's not check the transited field by +setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not +required to honor this flag. + +1.2. Authorization + +As an authentication service, Kerberos provides a means of verifying the +identity of principals on a network. Authentication is usually useful +primarily as a first step in the process of authorization, determining +whether a client may use a service, which objects the client is allowed to +access, and the type of access allowed for each. Kerberos does not, by +itself, provide authorization. Possession of a client ticket for a service +provides only for authentication of the client to that service, and in the +absence of a separate authorization procedure, it should not be considered +by an application as authorizing the use of that service. + +Such separate authorization methods may be implemented as application +specific access control functions and may be based on files such as the +application server, or on separately issued authorization credentials such +as those based on proxies [Neu93], or on other authorization services. +Separately authenticated authorization credentials may be embedded in a +tickets authorization data when encapsulated by the kdc-issued authorization +data element. + +Applications should not be modified to accept the mere issuance of a service +ticket by the Kerberos server (even by a modified Kerberos server) as +granting authority to use the service, since such applications may become +vulnerable to the bypass of this authorization check in an environment if +they interoperate with other KDCs or where other options for application +authentication (e.g. the PKTAPP proposal) are provided. + +1.3. Environmental assumptions + +Kerberos imposes a few assumptions on the environment in which it can +properly function: + + * 'Denial of service' attacks are not solved with Kerberos. There are + places in these protocols where an intruder can prevent an application + from participating in the proper authentication steps. Detection and + solution of such attacks (some of which can appear to be nnot-uncommon + 'normal' failure modes for the system) is usually best left to the + human administrators and users. + * Principals must keep their secret keys secret. If an intruder somehow + steals a principal's key, it will be able to masquerade as that + principal or impersonate any server to the legitimate principal. + * 'Password guessing' attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to successfully + mount an offline dictionary attack by repeatedly attempting to decrypt, + with successive entries from a dictionary, messages obtained which are + encrypted under a key derived from the user's password. + * Each host on the network must have a clock which is 'loosely + synchronized' to the time of the other hosts; this synchronization is + used to reduce the bookkeeping needs of application servers when they + do replay detection. The degree of "looseness" can be configured on a + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + per-server basis, but is typically on the order of 5 minutes. If the + clocks are synchronized over the network, the clock synchronization + protocol must itself be secured from network attackers. + * Principal identifiers are not recycled on a short-term basis. A typical + mode of access control will use access control lists (ACLs) to grant + permissions to particular principals. If a stale ACL entry remains for + a deleted principal and the principal identifier is reused, the new + principal will inherit rights specified in the stale ACL entry. By not + re-using principal identifiers, the danger of inadvertent access is + removed. + +1.4. Glossary of terms + +Below is a list of terms used throughout this document. + +Authentication + Verifying the claimed identity of a principal. +Authentication header + A record containing a Ticket and an Authenticator to be presented to a + server as part of the authentication process. +Authentication path + A sequence of intermediate realms transited in the authentication + process when communicating from one realm to another. +Authenticator + A record containing information that can be shown to have been recently + generated using the session key known only by the client and server. +Authorization + The process of determining whether a client may use a service, which + objects the client is allowed to access, and the type of access allowed + for each. +Capability + A token that grants the bearer permission to access an object or + service. In Kerberos, this might be a ticket whose use is restricted by + the contents of the authorization data field, but which lists no + network addresses, together with the session key necessary to use the + ticket. +Ciphertext + The output of an encryption function. Encryption transforms plaintext + into ciphertext. +Client + A process that makes use of a network service on behalf of a user. Note + that in some cases a Server may itself be a client of some other server + (e.g. a print server may be a client of a file server). +Credentials + A ticket plus the secret session key necessary to successfully use that + ticket in an authentication exchange. +KDC + Key Distribution Center, a network service that supplies tickets and + temporary session keys; or an instance of that service or the host on + which it runs. The KDC services both initial ticket and ticket-granting + ticket requests. The initial ticket portion is sometimes referred to as + the Authentication Server (or service). The ticket-granting ticket + portion is sometimes referred to as the ticket-granting server (or + service). +Kerberos + Aside from the 3-headed dog guarding Hades, the name given to Project + Athena's authentication service, the protocol used by that service, or + the code used to implement the authentication service. +Plaintext + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The input to an encryption function or the output of a decryption + function. Decryption transforms ciphertext into plaintext. +Principal + A uniquely named client or server instance that participates in a + network communication. +Principal identifier + The name used to uniquely identify each different principal. +Seal + To encipher a record containing several fields in such a way that the + fields cannot be individually replaced without either knowledge of the + encryption key or leaving evidence of tampering. +Secret key + An encryption key shared by a principal and the KDC, distributed + outside the bounds of the system, with a long lifetime. In the case of + a human user's principal, the secret key is derived from a password. +Server + A particular Principal which provides a resource to network clients. + The server is sometimes refered to as the Application Server. +Service + A resource provided to network clients; often provided by more than one + server (for example, remote file service). +Session key + A temporary encryption key used between two principals, with a lifetime + limited to the duration of a single login "session". +Sub-session key + A temporary encryption key used between two principals, selected and + exchanged by the principals using the session key, and with a lifetime + limited to the duration of a single association. +Ticket + A record that helps a client authenticate itself to a server; it + contains the client's identity, a session key, a timestamp, and other + information, all sealed using the server's secret key. It only serves + to authenticate a client when presented along with a fresh + Authenticator. + +2. Ticket flag uses and requests + +Each Kerberos ticket contains a set of flags which are used to indicate +various attributes of that ticket. Most flags may be requested by a client +when the ticket is obtained; some are automatically turned on and off by a +Kerberos server as required. The following sections explain what the various +flags mean, and gives examples of reasons to use such a flag. + +2.1. Initial and pre-authenticated tickets + +The INITIAL flag indicates that a ticket was issued using the AS protocol +and not issued based on a ticket-granting ticket. Application servers that +want to require the demonstrated knowledge of a client's secret key (e.g. a +password-changing program) can insist that this flag be set in any tickets +they accept, and thus be assured that the client's key was recently +presented to the application client. + +The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the +initial authentication, regardless of whether the current ticket was issued +directly (in which case INITIAL will also be set) or issued on the basis of +a ticket-granting ticket (in which case the INITIAL flag is clear, but the +PRE-AUTHENT and HW-AUTHENT flags are carried forward from the +ticket-granting ticket). + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +2.2. Invalid tickets + +The INVALID flag indicates that a ticket is invalid. Application servers +must reject tickets which have this flag set. A postdated ticket will +usually be issued in this form. Invalid tickets must be validated by the KDC +before use, by presenting them to the KDC in a TGS request with the VALIDATE +option specified. The KDC will only validate tickets after their starttime +has passed. The validation is required so that postdated tickets which have +been stolen before their starttime can be rendered permanently invalid +(through a hot-list mechanism) (see section 3.3.3.1). + +2.3. Renewable tickets + +Applications may desire to hold tickets which can be valid for long periods +of time. However, this can expose their credentials to potential theft for +equally long periods, and those stolen credentials would be valid until the +expiration time of the ticket(s). Simply using short-lived tickets and +obtaining new ones periodically would require the client to have long-term +access to its secret key, an even greater risk. Renewable tickets can be +used to mitigate the consequences of theft. Renewable tickets have two +"expiration times": the first is when the current instance of the ticket +expires, and the second is the latest permissible value for an individual +expiration time. An application client must periodically (i.e. before it +expires) present a renewable ticket to the KDC, with the RENEW option set in +the KDC request. The KDC will issue a new ticket with a new session key and +a later expiration time. All other fields of the ticket are left unmodified +by the renewal process. When the latest permissible expiration time arrives, +the ticket expires permanently. At each renewal, the KDC may consult a +hot-list to determine if the ticket had been reported stolen since its last +renewal; it will refuse to renew such stolen tickets, and thus the usable +lifetime of stolen tickets is reduced. + +The RENEWABLE flag in a ticket is normally only interpreted by the +ticket-granting service (discussed below in section 3.3). It can usually be +ignored by application servers. However, some particularly careful +application servers may wish to disallow renewable tickets. + +If a renewable ticket is not renewed by its expiration time, the KDC will +not renew the ticket. The RENEWABLE flag is reset by default, but a client +may request it be set by setting the RENEWABLE option in the KRB_AS_REQ +message. If it is set, then the renew-till field in the ticket contains the +time after which the ticket may not be renewed. + +2.4. Postdated tickets + +Applications may occasionally need to obtain tickets for use much later, +e.g. a batch submission system would need tickets to be valid at the time +the batch job is serviced. However, it is dangerous to hold valid tickets in +a batch queue, since they will be on-line longer and more prone to theft. +Postdated tickets provide a way to obtain these tickets from the KDC at job +submission time, but to leave them "dormant" until they are activated and +validated by a further request of the KDC. If a ticket theft were reported +in the interim, the KDC would refuse to validate the ticket, and the thief +would be foiled. + +The MAY-POSTDATE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. This flag +must be set in a ticket-granting ticket in order to issue a postdated ticket +based on the presented ticket. It is reset by default; it may be requested + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. +This flag does not allow a client to obtain a postdated ticket-granting +ticket; postdated ticket-granting tickets can only by obtained by requesting +the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a +postdated ticket will be the remaining life of the ticket-granting ticket at +the time of the request, unless the RENEWABLE option is also set, in which +case it can be the full life (endtime-starttime) of the ticket-granting +ticket. The KDC may limit how far in the future a ticket may be postdated. + +The POSTDATED flag indicates that a ticket has been postdated. The +application server can check the authtime field in the ticket to see when +the original authentication occurred. Some services may choose to reject +postdated tickets, or they may only accept them within a certain period +after the original authentication. When the KDC issues a POSTDATED ticket, +it will also be marked as INVALID, so that the application client must +present the ticket to the KDC to be validated before use. + +2.5. Proxiable and proxy tickets + +At times it may be necessary for a principal to allow a service to perform +an operation on its behalf. The service must be able to take on the identity +of the client, but only for a particular purpose. A principal can allow a +service to take on the principal's identity for a particular purpose by +granting it a proxy. + +The process of granting a proxy using the proxy and proxiable flags is used +to provide credentials for use with specific services. Though conceptually +also a proxy, user's wishing to delegate their identity for ANY purpose must +use the ticket forwarding mechanism described in the next section to forward +a ticket granting ticket. + +The PROXIABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. When set, +this flag tells the ticket-granting server that it is OK to issue a new +ticket (but not a ticket-granting ticket) with a different network address +based on this ticket. This flag is set if requested by the client on initial +authentication. By default, the client will request that it be set when +requesting a ticket granting ticket, and reset when requesting any other +ticket. + +This flag allows a client to pass a proxy to a server to perform a remote +request on its behalf, e.g. a print service client can give the print server +a proxy to access the client's files on a particular file server in order to +satisfy a print request. + +In order to complicate the use of stolen credentials, Kerberos tickets are +usually valid from only those network addresses specifically included in the +ticket[4]. When granting a proxy, the client must specify the new network +address from which the proxy is to be used, or indicate that the proxy is to +be issued for use from any address. + +The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. +Application servers may check this flag and at their option they may require +additional authentication from the agent presenting the proxy in order to +provide an audit trail. + +2.6. Forwardable tickets + +Authentication forwarding is an instance of a proxy where the service is + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +granted complete use of the client's identity. An example where it might be +used is when a user logs in to a remote system and wants authentication to +work from that system as if the login were local. + +The FORWARDABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. The +FORWARDABLE flag has an interpretation similar to that of the PROXIABLE +flag, except ticket-granting tickets may also be issued with different +network addresses. This flag is reset by default, but users may request that +it be set by setting the FORWARDABLE option in the AS request when they +request their initial ticket- granting ticket. + +This flag allows for authentication forwarding without requiring the user to +enter a password again. If the flag is not set, then authentication +forwarding is not permitted, but the same result can still be achieved if +the user engages in the AS exchange specifying the requested network +addresses and supplies a password. + +The FORWARDED flag is set by the TGS when a client presents a ticket with +the FORWARDABLE flag set and requests a forwarded ticket by specifying the +FORWARDED KDC option and supplying a set of addresses for the new ticket. It +is also set in all tickets issued based on tickets with the FORWARDED flag +set. Application servers may choose to process FORWARDED tickets differently +than non-FORWARDED tickets. + +2.7. Other KDC options + +There are two additional options which may be set in a client's request of +the KDC. The RENEWABLE-OK option indicates that the client will accept a +renewable ticket if a ticket with the requested life cannot otherwise be +provided. If a ticket with the requested life cannot be provided, then the +KDC may issue a renewable ticket with a renew-till equal to the the +requested endtime. The value of the renew-till field may still be adjusted +by site-determined limits or limits imposed by the individual principal or +server. + +The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. +It indicates that the ticket to be issued for the end server is to be +encrypted in the session key from the a additional second ticket-granting +ticket provided with the request. See section 3.3.3 for specific details. + +3. Message Exchanges + +The following sections describe the interactions between network clients and +servers and the messages involved in those exchanges. + +3.1. The Authentication Service Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_AS_REQ 5.4.1 + 2. Kerberos to client KRB_AS_REP or 5.4.2 + KRB_ERROR 5.9.1 + +The Authentication Service (AS) Exchange between the client and the Kerberos +Authentication Server is initiated by a client when it wishes to obtain +authentication credentials for a given server but currently holds no +credentials. In its basic form, the client's secret key is used for +encryption and decryption. This exchange is typically used at the initiation + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +of a login session to obtain credentials for a Ticket-Granting Server which +will subsequently be used to obtain credentials for other servers (see +section 3.3) without requiring further use of the client's secret key. This +exchange is also used to request credentials for services which must not be +mediated through the Ticket-Granting Service, but rather require a +principal's secret key, such as the password-changing service[5]. This +exchange does not by itself provide any assurance of the the identity of the +user[6]. + +The exchange consists of two messages: KRB_AS_REQ from the client to +Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these +messages are described in sections 5.4.1, 5.4.2, and 5.9.1. + +In the request, the client sends (in cleartext) its own identity and the +identity of the server for which it is requesting credentials. The response, +KRB_AS_REP, contains a ticket for the client to present to the server, and a +session key that will be shared by the client and the server. The session +key and additional information are encrypted in the client's secret key. The +KRB_AS_REP message contains information which can be used to detect replays, +and to associate it with the message to which it replies. Various errors can +occur; these are indicated by an error response (KRB_ERROR) instead of the +KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR +message contains information which can be used to associate it with the +message to which it replies. The lack of encryption in the KRB_ERROR message +precludes the ability to detect replays, fabrications, or modifications of +such messages. + +Without preautentication, the authentication server does not know whether +the client is actually the principal named in the request. It simply sends a +reply without knowing or caring whether they are the same. This is +acceptable because nobody but the principal whose identity was given in the +request will be able to use the reply. Its critical information is encrypted +in that principal's key. The initial request supports an optional field that +can be used to pass additional information that might be needed for the +initial exchange. This field may be used for preauthentication as described +in section [hl<>]. + +3.1.1. Generation of KRB_AS_REQ message + +The client may specify a number of options in the initial request. Among +these options are whether pre-authentication is to be performed; whether the +requested ticket is to be renewable, proxiable, or forwardable; whether it +should be postdated or allow postdating of derivative tickets; and whether a +renewable ticket will be accepted in lieu of a non-renewable ticket if the +requested ticket expiration date cannot be satisfied by a non-renewable +ticket (due to configuration constraints; see section 4). See section A.1 +for pseudocode. + +The client prepares the KRB_AS_REQ message and sends it to the KDC. + +3.1.2. Receipt of KRB_AS_REQ message + +If all goes well, processing the KRB_AS_REQ message will result in the +creation of a ticket for the client to present to the server. The format for +the ticket is described in section 5.3.1. The contents of the ticket are +determined as follows. + +3.1.3. Generation of KRB_AS_REP message + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +The authentication server looks up the client and server principals named in +the KRB_AS_REQ in its database, extracting their respective keys. If +required, the server pre-authenticates the request, and if the +pre-authentication check fails, an error message with the code +KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the +requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP +is returned. Otherwise it generates a 'random' session key[7]. + +If there are multiple encryption keys registered for a client in the +Kerberos database (or if the key registered supports multiple encryption +types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype field from the AS +request is used by the KDC to select the encryption method to be used for +encrypting the response to the client. If there is more than one supported, +strong encryption type in the etype list, the first valid etype for which an +encryption key is available is used. The encryption method used to respond +to a TGS request is taken from the keytype of the session key found in the +ticket granting ticket. [***I will change the example keytypes to be 3DES +based examples 7/14***] + +When the etype field is present in a KDC request, whether an AS or TGS +request, the KDC will attempt to assign the type of the random session key +from the list of methods in the etype field. The KDC will select the +appropriate type using the list of methods provided together with +information from the Kerberos database indicating acceptable encryption +methods for the application server. The KDC will not issue tickets with a +weak session key encryption type. + +If the requested start time is absent, indicates a time in the past, or is +within the window of acceptable clock skew for the KDC and the POSTDATE +option has not been specified, then the start time of the ticket is set to +the authentication server's current time. If it indicates a time in the +future beyond the acceptable clock skew, but the POSTDATED option has not +been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise +the requested start time is checked against the policy of the local realm +(the administrator might decide to prohibit certain types or ranges of +postdated tickets), and if acceptable, the ticket's start time is set as +requested and the INVALID flag is set in the new ticket. The postdated +ticket must be validated before use by presenting it to the KDC after the +start time has been reached. + +The expiration time of the ticket will be set to the minimum of the +following: + + * The expiration time (endtime) requested in the KRB_AS_REQ message. + * The ticket's start time plus the maximum allowable lifetime associated + with the client principal (the authentication server's database + includes a maximum ticket lifetime field in each principal's record; + see section 4). + * The ticket's start time plus the maximum allowable lifetime associated + with the server principal. + * The ticket's start time plus the maximum lifetime set by the policy of + the local realm. + +If the requested expiration time minus the start time (as determined above) +is less than a site-determined minimum lifetime, an error message with code +KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the +ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' +option was requested, then the 'RENEWABLE' flag is set in the new ticket, +and the renew-till value is set as if the 'RENEWABLE' option were requested + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +(the field and option names are described fully in section 5.4.1). + +If the RENEWABLE option has been requested or if the RENEWABLE-OK option has +been set and a renewable ticket is to be issued, then the renew-till field +is set to the minimum of: + + * Its requested value. + * The start time of the ticket plus the minimum of the two maximum + renewable lifetimes associated with the principals' database entries. + * The start time of the ticket plus the maximum renewable lifetime set by + the policy of the local realm. + +The flags field of the new ticket will have the following options set if +they have been requested and if the policy of the local realm allows: +FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new +ticket is post-dated (the start time is in the future), its INVALID flag +will also be set. + +If all of the above succeed, the server formats a KRB_AS_REP message (see +section 5.4.2), copying the addresses in the request into the caddr of the +response, placing any required pre-authentication data into the padata of +the response, and encrypts the ciphertext part in the client's key using the +requested encryption method, and sends it to the client. See section A.2 for +pseudocode. + +3.1.4. Generation of KRB_ERROR message + +Several errors can occur, and the Authentication Server responds by +returning an error message, KRB_ERROR, to the client, with the error-code +and e-text fields set to appropriate values. The error message contents and +details are described in Section 5.9.1. + +3.1.5. Receipt of KRB_AS_REP message + +If the reply message type is KRB_AS_REP, then the client verifies that the +cname and crealm fields in the cleartext portion of the reply match what it +requested. If any padata fields are present, they may be used to derive the +proper secret key to decrypt the message. The client decrypts the encrypted +part of the response using its secret key, verifies that the nonce in the +encrypted part matches the nonce it supplied in its request (to detect +replays). It also verifies that the sname and srealm in the response match +those in the request (or are otherwise expected values), and that the host +address field is also correct. It then stores the ticket, session key, start +and expiration times, and other information for later use. The +key-expiration field from the encrypted part of the response may be checked +to notify the user of impending key expiration (the client program could +then suggest remedial action, such as a password change). See section A.3 +for pseudocode. + +Proper decryption of the KRB_AS_REP message is not sufficient to verify the +identity of the user; the user and an attacker could cooperate to generate a +KRB_AS_REP format message which decrypts properly but is not from the proper +KDC. If the host wishes to verify the identity of the user, it must require +the user to present application credentials which can be verified using a +securely-stored secret key for the host. If those credentials can be +verified, then the identity of the user can be assured. + +3.1.6. Receipt of KRB_ERROR message + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +If the reply message type is KRB_ERROR, then the client interprets it as an +error and performs whatever application-specific tasks are necessary to +recover. + +3.2. The Client/Server Authentication Exchange + + Summary +Message direction Message type Section +Client to Application server KRB_AP_REQ 5.5.1 +[optional] Application server to client KRB_AP_REP or 5.5.2 + KRB_ERROR 5.9.1 + +The client/server authentication (CS) exchange is used by network +applications to authenticate the client to the server and vice versa. The +client must have already acquired credentials for the server using the AS or +TGS exchange. + +3.2.1. The KRB_AP_REQ message + +The KRB_AP_REQ contains authentication information which should be part of +the first message in an authenticated transaction. It contains a ticket, an +authenticator, and some additional bookkeeping information (see section +5.5.1 for the exact format). The ticket by itself is insufficient to +authenticate a client, since tickets are passed across the network in +cleartext[DS90], so the authenticator is used to prevent invalid replay of +tickets by proving to the server that the client knows the session key of +the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is +referred to elsewhere as the 'authentication header.' + +3.2.2. Generation of a KRB_AP_REQ message + +When a client wishes to initiate authentication to a server, it obtains +(either through a credentials cache, the AS exchange, or the TGS exchange) a +ticket and session key for the desired service. The client may re-use any +tickets it holds until they expire. To use a ticket the client constructs a +new Authenticator from the the system time, its name, and optionally an +application specific checksum, an initial sequence number to be used in +KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in +negotiations for a session key unique to this particular session. +Authenticators may not be re-used and will be rejected if replayed to a +server[LGDSR87]. If a sequence number is to be included, it should be +randomly chosen so that even after many messages have been exchanged it is +not likely to collide with other sequence numbers in use. + +The client may indicate a requirement of mutual authentication or the use of +a session-key based ticket by setting the appropriate flag(s) in the +ap-options field of the message. + +The Authenticator is encrypted in the session key and combined with the +ticket to form the KRB_AP_REQ message which is then sent to the end server +along with any additional application-specific information. See section A.9 +for pseudocode. + +3.2.3. Receipt of KRB_AP_REQ message + +Authentication is based on the server's current time of day (clocks must be +loosely synchronized), the authenticator, and the ticket. Several errors are +possible. If an error occurs, the server is expected to reply to the client +with a KRB_ERROR message. This message may be encapsulated in the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +application protocol if its 'raw' form is not acceptable to the protocol. +The format of error messages is described in section 5.9.1. + +The algorithm for verifying authentication information is as follows. If the +message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE +error. If the key version indicated by the Ticket in the KRB_AP_REQ is not +one the server can use (e.g., it indicates an old key, and the server no +longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is +returned. If the USE-SESSION-KEY flag is set in the ap-options field, it +indicates to the server that the ticket is encrypted in the session key from +the server's ticket-granting ticket rather than its secret key[10]. Since it +is possible for the server to be registered in multiple realms, with +different keys in each, the srealm field in the unencrypted portion of the +ticket in the KRB_AP_REQ is used to specify which secret key the server +should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is +returned if the server doesn't have the proper key to decipher the ticket. + +The ticket is decrypted using the version of the server's key specified by +the ticket. If the decryption routines detect a modification of the ticket +(each encryption system must provide safeguards to detect modified +ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned +(chances are good that different keys were used to encrypt and decrypt). + +The authenticator is decrypted using the session key extracted from the +decrypted ticket. If decryption shows it to have been modified, the +KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client +from the ticket are compared against the same fields in the authenticator. +If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might +not match, for example, if the wrong session key was used to encrypt the +authenticator). The addresses in the ticket (if any) are then searched for +an address matching the operating-system reported address of the client. If +no match is found or the server insists on ticket addresses but none are +present in the ticket, the KRB_AP_ERR_BADADDR error is returned. + +If the local (server) time and the client time in the authenticator differ +by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW +error is returned. If the server name, along with the client name, time and +microsecond fields from the Authenticator match any recently-seen such +tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must +remember any authenticator presented within the allowable clock skew, so +that a replay attempt is guaranteed to fail. If a server loses track of any +authenticator presented within the allowable clock skew, it must reject all +requests until the clock skew interval has passed. This assures that any +lost or re-played authenticators will fall outside the allowable clock skew +and can no longer be successfully replayed (If this is not done, an attacker +could conceivably record the ticket and authenticator sent over the network +to a server, then disable the client's host, pose as the disabled host, and +replay the ticket and authenticator to subvert the authentication.). If a +sequence number is provided in the authenticator, the server saves it for +later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is +present, the server either saves it for later use or uses it to help +generate its own choice for a subkey to be returned in a KRB_AP_REP message. + +The server computes the age of the ticket: local (server) time minus the +start time inside the Ticket. If the start time is later than the current +time by more than the allowable clock skew or if the INVALID flag is set in +the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the +current time is later than end time by more than the allowable clock skew, +the KRB_AP_ERR_TKT_EXPIRED error is returned. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + +If all these checks succeed without an error, the server is assured that the +client possesses the credentials of the principal named in the ticket and +thus, the client has been authenticated to the server. See section A.10 for +pseudocode. + +Passing these checks provides only authentication of the named principal; it +does not imply authorization to use the named service. Applications must +make a separate authorization decisions based upon the authenticated name of +the user, the requested operation, local acces control information such as +that contained in a .k5login or .k5users file, and possibly a separate +distributed authorization service. + +3.2.4. Generation of a KRB_AP_REP message + +Typically, a client's request will include both the authentication +information and its initial request in the same message, and the server need +not explicitly reply to the KRB_AP_REQ. However, if mutual authentication +(not only authenticating the client to the server, but also the server to +the client) is being performed, the KRB_AP_REQ message will have +MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is +required in response. As with the error message, this message may be +encapsulated in the application protocol if its "raw" form is not acceptable +to the application's protocol. The timestamp and microsecond field used in +the reply must be the client's timestamp and microsecond field (as provided +in the authenticator)[12]. If a sequence number is to be included, it should +be randomly chosen as described above for the authenticator. A subkey may be +included if the server desires to negotiate a different subkey. The +KRB_AP_REP message is encrypted in the session key extracted from the +ticket. See section A.11 for pseudocode. + +3.2.5. Receipt of KRB_AP_REP message + +If a KRB_AP_REP message is returned, the client uses the session key from +the credentials obtained for the server[13] to decrypt the message, and +verifies that the timestamp and microsecond fields match those in the +Authenticator it sent to the server. If they match, then the client is +assured that the server is genuine. The sequence number and subkey (if +present) are retained for later use. See section A.12 for pseudocode. + +3.2.6. Using the encryption key + +After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server +share an encryption key which can be used by the application. The 'true +session key' to be used for KRB_PRIV, KRB_SAFE, or other +application-specific uses may be chosen by the application based on the +subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases, +the use of this session key will be implicit in the protocol; in others the +method of use must be chosen from several alternatives. We leave the +protocol negotiations of how to use the key (e.g. selecting an encryption or +checksum type) to the application programmer; the Kerberos protocol does not +constrain the implementation options, but an example of how this might be +done follows. + +One way that an application may choose to negotiate a key to be used for +subequent integrity and privacy protection is for the client to propose a +key in the subkey field of the authenticator. The server can then choose a +key using the proposed key from the client as input, returning the new +subkey in the subkey field of the application reply. This key could then be + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +used for subsequent communication. To make this example more concrete, if +the encryption method in use required a 56 bit key, and for whatever reason, +one of the parties was prevented from using a key with more than 40 unknown +bits, this method would allow the the party which is prevented from using +more than 40 bits to either propose (if the client) an initial key with a +known quantity for 16 of those bits, or to mask 16 of the bits (if the +server) with the known quantity. The application implementor is warned, +however, that this is only an example, and that an analysis of the +particular crytosystem to be used, and the reasons for limiting the key +length, must be made before deciding whether it is acceptable to mask bits +of the key. + +With both the one-way and mutual authentication exchanges, the peers should +take care not to send sensitive information to each other without proper +assurances. In particular, applications that require privacy or integrity +should use the KRB_AP_REP response from the server to client to assure both +client and server of their peer's identity. If an application protocol +requires privacy of its messages, it can use the KRB_PRIV message (section +3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. + +3.3. The Ticket-Granting Service (TGS) Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_TGS_REQ 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 5.4.2 + KRB_ERROR 5.9.1 + +The TGS exchange between a client and the Kerberos Ticket-Granting Server is +initiated by a client when it wishes to obtain authentication credentials +for a given server (which might be registered in a remote realm), when it +wishes to renew or validate an existing ticket, or when it wishes to obtain +a proxy ticket. In the first case, the client must already have acquired a +ticket for the Ticket-Granting Service using the AS exchange (the +ticket-granting ticket is usually obtained when a client initially +authenticates to the system, such as when a user logs in). The message +format for the TGS exchange is almost identical to that for the AS exchange. +The primary difference is that encryption and decryption in the TGS exchange +does not take place under the client's key. Instead, the session key from +the ticket-granting ticket or renewable ticket, or sub-session key from an +Authenticator is used. As is the case for all application servers, expired +tickets are not accepted by the TGS, so once a renewable or ticket-granting +ticket expires, the client must use a separate exchange to obtain valid +tickets. + +The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the +client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or +KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the +client plus a request for credentials. The authentication information +consists of the authentication header (KRB_AP_REQ) which includes the +client's previously obtained ticket-granting, renewable, or invalid ticket. +In the ticket-granting ticket and proxy cases, the request may include one +or more of: a list of network addresses, a collection of typed authorization +data to be sealed in the ticket for authorization use by the application +server, or additional tickets (the use of which are described later). The +TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the +session key from the ticket-granting ticket or renewable ticket, or if +present, in the sub-session key from the Authenticator (part of the +authentication header). The KRB_ERROR message contains an error code and + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +text explaining what went wrong. The KRB_ERROR message is not encrypted. The +KRB_TGS_REP message contains information which can be used to detect +replays, and to associate it with the message to which it replies. The +KRB_ERROR message also contains information which can be used to associate +it with the message to which it replies, but the lack of encryption in the +KRB_ERROR message precludes the ability to detect replays or fabrications of +such messages. + +3.3.1. Generation of KRB_TGS_REQ message + +Before sending a request to the ticket-granting service, the client must +determine in which realm the application server is registered[15]. If the +client does not already possess a ticket-granting ticket for the appropriate +realm, then one must be obtained. This is first attempted by requesting a +ticket-granting ticket for the destination realm from a Kerberos server for +which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ +message recursively). The Kerberos server may return a TGT for the desired +realm in which case one can proceed. Alternatively, the Kerberos server may +return a TGT for a realm which is 'closer' to the desired realm (further +along the standard hierarchical path), in which case this step must be +repeated with a Kerberos server in the realm specified in the returned TGT. +If neither are returned, then the request must be retried with a Kerberos +server for a realm higher in the hierarchy. This request will itself require +a ticket-granting ticket for the higher realm which must be obtained by +recursively applying these directions. + +Once the client obtains a ticket-granting ticket for the appropriate realm, +it determines which Kerberos servers serve that realm, and contacts one. The +list might be obtained through a configuration file or network service or it +may be generated from the name of the realm; as long as the secret keys +exchanged by realms are kept secret, only denial of service results from +using a false Kerberos server. + +As in the AS exchange, the client may specify a number of options in the +KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing +an authentication header as an element of the padata field, and including +the same fields as used in the KRB_AS_REQ message along with several +optional fields: the enc-authorization-data field for application server use +and additional tickets required by some options. + +In preparing the authentication header, the client can select a sub-session +key under which the response from the Kerberos server will be encrypted[16]. +If the sub-session key is not specified, the session key from the +ticket-granting ticket will be used. If the enc-authorization-data is +present, it must be encrypted in the sub-session key, if present, from the +authenticator portion of the authentication header, or if not present, using +the session key from the ticket-granting ticket. + +Once prepared, the message is sent to a Kerberos server for the destination +realm. See section A.5 for pseudocode. + +3.3.2. Receipt of KRB_TGS_REQ message + +The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ +message, but there are many additional checks to be performed. First, the +Kerberos server must determine which server the accompanying ticket is for +and it must select the appropriate key to decrypt it. For a normal +KRB_TGS_REQ message, it will be for the ticket granting service, and the +TGS's key will be used. If the TGT was issued by another realm, then the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +appropriate inter-realm key must be used. If the accompanying ticket is not +a ticket granting ticket for the current realm, but is for an application +server in the current realm, the RENEW, VALIDATE, or PROXY options are +specified in the request, and the server for which a ticket is requested is +the server named in the accompanying ticket, then the KDC will decrypt the +ticket in the authentication header using the key of the server for which it +was issued. If no ticket can be found in the padata field, the +KDC_ERR_PADATA_TYPE_NOSUPP error is returned. + +Once the accompanying ticket has been decrypted, the user-supplied checksum +in the Authenticator must be verified against the contents of the request, +and the message rejected if the checksums do not match (with an error code +of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not +collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the +checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is +returned. If the authorization-data are present, they are decrypted using +the sub-session key from the Authenticator. + +If any of the decryptions indicate failed integrity checks, the +KRB_AP_ERR_BAD_INTEGRITY error is returned. + +3.3.3. Generation of KRB_TGS_REP message + +The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), +but with its type field set to KRB_TGS_REP. The detailed specification is in +section 5.4.2. + +The response will include a ticket for the requested server. The Kerberos +database is queried to retrieve the record for the requested server +(including the key with which the ticket will be encrypted). If the request +is for a ticket granting ticket for a remote realm, and if no key is shared +with the requested realm, then the Kerberos server will select the realm +"closest" to the requested realm with which it does share a key, and use +that realm instead. This is the only case where the response from the KDC +will be for a different server than that requested by the client. + +By default, the address field, the client's name and realm, the list of +transited realms, the time of initial authentication, the expiration time, +and the authorization data of the newly-issued ticket will be copied from +the ticket-granting ticket (TGT) or renewable ticket. If the transited field +needs to be updated, but the transited type is not supported, the +KDC_ERR_TRTYPE_NOSUPP error is returned. + +If the request specifies an endtime, then the endtime of the new ticket is +set to the minimum of (a) that request, (b) the endtime from the TGT, and +(c) the starttime of the TGT plus the minimum of the maximum life for the +application server and the maximum life for the local realm (the maximum +life for the requesting principal was already applied when the TGT was +issued). If the new ticket is to be a renewal, then the endtime above is +replaced by the minimum of (a) the value of the renew_till field of the +ticket and (b) the starttime for the new ticket plus the life +(endtime-starttime) of the old ticket. + +If the FORWARDED option has been requested, then the resulting ticket will +contain the addresses specified by the client. This option will only be +honored if the FORWARDABLE flag is set in the TGT. The PROXY option is +similar; the resulting ticket will contain the addresses specified by the +client. It will be honored only if the PROXIABLE flag in the TGT is set. The +PROXY option will not be honored on requests for additional ticket-granting + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +tickets. + +If the requested start time is absent, indicates a time in the past, or is +within the window of acceptable clock skew for the KDC and the POSTDATE +option has not been specified, then the start time of the ticket is set to +the authentication server's current time. If it indicates a time in the +future beyond the acceptable clock skew, but the POSTDATED option has not +been specified or the MAY-POSTDATE flag is not set in the TGT, then the +error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting +ticket has the MAY-POSTDATE flag set, then the resulting ticket will be +postdated and the requested starttime is checked against the policy of the +local realm. If acceptable, the ticket's start time is set as requested, and +the INVALID flag is set. The postdated ticket must be validated before use +by presenting it to the KDC after the starttime has been reached. However, +in no case may the starttime, endtime, or renew-till time of a newly-issued +postdated ticket extend beyond the renew-till time of the ticket-granting +ticket. + +If the ENC-TKT-IN-SKEY option has been specified and an additional ticket +has been included in the request, the KDC will decrypt the additional ticket +using the key for the server to which the additional ticket was issued and +verify that it is a ticket-granting ticket. If the name of the requested +server is missing from the request, the name of the client in the additional +ticket will be used. Otherwise the name of the requested server will be +compared to the name of the client in the additional ticket and if +different, the request will be rejected. If the request succeeds, the +session key from the additional ticket will be used to encrypt the new +ticket that is issued instead of using the key of the server for which the +new ticket will be used[17]. + +If the name of the server in the ticket that is presented to the KDC as part +of the authentication header is not that of the ticket-granting server +itself, the server is registered in the realm of the KDC, and the RENEW +option is requested, then the KDC will verify that the RENEWABLE flag is set +in the ticket, that the INVALID flag is not set in the ticket, and that the +renew_till time is still in the future. If the VALIDATE option is rqeuested, +the KDC will check that the starttime has passed and the INVALID flag is +set. If the PROXY option is requested, then the KDC will check that the +PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket +passes the hotlist check described in the next paragraph, the KDC will issue +the appropriate new ticket. + +3.3.3.1. Checking for revoked tickets + +Whenever a request is made to the ticket-granting server, the presented +ticket(s) is(are) checked against a hot-list of tickets which have been +canceled. This hot-list might be implemented by storing a range of issue +timestamps for 'suspect tickets'; if a presented ticket had an authtime in +that range, it would be rejected. In this way, a stolen ticket-granting +ticket or renewable ticket cannot be used to gain additional tickets +(renewals or otherwise) once the theft has been reported. Any normal ticket +obtained before it was reported stolen will still be valid (because they +require no interaction with the KDC), but only until their normal expiration +time. + +The ciphertext part of the response in the KRB_TGS_REP message is encrypted +in the sub-session key from the Authenticator, if present, or the session +key key from the ticket-granting ticket. It is not encrypted using the +client's secret key. Furthermore, the client's key's expiration date and the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +key version number fields are left out since these values are stored along +with the client's database record, and that record is not needed to satisfy +a request based on a ticket-granting ticket. See section A.6 for pseudocode. + +3.3.3.2. Encoding the transited field + +If the identity of the server in the TGT that is presented to the KDC as +part of the authentication header is that of the ticket-granting service, +but the TGT was issued from another realm, the KDC will look up the +inter-realm key shared with that realm and use that key to decrypt the +ticket. If the ticket is valid, then the KDC will honor the request, subject +to the constraints outlined above in the section describing the AS exchange. +The realm part of the client's identity will be taken from the +ticket-granting ticket. The name of the realm that issued the +ticket-granting ticket will be added to the transited field of the ticket to +be issued. This is accomplished by reading the transited field from the +ticket-granting ticket (which is treated as an unordered set of realm +names), adding the new realm to the set, then constructing and writing out +its encoded (shorthand) form (this may involve a rearrangement of the +existing encoding). + +Note that the ticket-granting service does not add the name of its own +realm. Instead, its responsibility is to add the name of the previous realm. +This prevents a malicious Kerberos server from intentionally leaving out its +own name (it could, however, omit other realms' names). + +The names of neither the local realm nor the principal's realm are to be +included in the transited field. They appear elsewhere in the ticket and +both are known to have taken part in authenticating the principal. Since the +endpoints are not included, both local and single-hop inter-realm +authentication result in a transited field that is empty. + +Because the name of each realm transited is added to this field, it might +potentially be very long. To decrease the length of this field, its contents +are encoded. The initially supported encoding is optimized for the normal +case of inter-realm communication: a hierarchical arrangement of realms +using either domain or X.500 style realm names. This encoding (called +DOMAIN-X500-COMPRESS) is now described. + +Realm names in the transited field are separated by a ",". The ",", "\", +trailing "."s, and leading spaces (" ") are special characters, and if they +are part of a realm name, they must be quoted in the transited field by +preced- ing them with a "\". + +A realm name ending with a "." is interpreted as being prepended to the +previous realm. For example, we can encode traversal of EDU, MIT.EDU, +ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: + + "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". + +Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they +would not be included in this field, and we would have: + + "EDU,MIT.,WASHINGTON.EDU" + +A realm name beginning with a "/" is interpreted as being appended to the +previous realm[18]. If it is to stand by itself, then it should be preceded +by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, +/COM/HP, /COM, and /COM/DEC as: + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + "/COM,/HP,/APOLLO, /COM/DEC". + +Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they +they would not be included in this field, and we would have: + + "/COM,/HP" + +A null subfield preceding or following a "," indicates that all realms +between the previous realm and the next realm have been traversed[19]. Thus, +"," means that all realms along the path between the client and the server +have been traversed. ",EDU, /COM," means that that all realms from the +client's realm up to EDU (in a domain style hierarchy) have been traversed, +and that everything from /COM down to the server's realm in an X.500 style +has also been traversed. This could occur if the EDU realm in one hierarchy +shares an inter-realm key directly with the /COM realm in another hierarchy. + +3.3.4. Receipt of KRB_TGS_REP message + +When the KRB_TGS_REP is received by the client, it is processed in the same +manner as the KRB_AS_REP processing described above. The primary difference +is that the ciphertext part of the response must be decrypted using the +session key from the ticket-granting ticket rather than the client's secret +key. See section A.7 for pseudocode. + +3.4. The KRB_SAFE Exchange + +The KRB_SAFE message may be used by clients requiring the ability to detect +modifications of messages they exchange. It achieves this by including a +keyed collision-proof checksum of the user data and some control +information. The checksum is keyed with an encryption key (usually the last +key negotiated via subkeys, or the session key if no negotiation has +occured). + +3.4.1. Generation of a KRB_SAFE message + +When an application wishes to send a KRB_SAFE message, it collects its data +and the appropriate control information and computes a checksum over them. +The checksum algorithm should be a keyed one-way hash function (such as the +RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC), +generated using the sub-session key if present, or the session key. +Different algorithms may be selected by changing the checksum type in the +message. Unkeyed or non-collision-proof checksums are not suitable for this +use. + +The control information for the KRB_SAFE message includes both a timestamp +and a sequence number. The designer of an application using the KRB_SAFE +message must choose at least one of the two mechanisms. This choice should +be based on the needs of the application protocol. + +Sequence numbers are useful when all messages sent will be received by one's +peer. Connection state is presently required to maintain the session key, so +maintaining the next sequence number should not present an additional +problem. + +If the application protocol is expected to tolerate lost messages without +them being resent, the use of the timestamp is the appropriate replay +detection mechanism. Using timestamps is also the appropriate mechanism for +multi-cast protocols where all of one's peers share a common sub-session + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +key, but some messages will be sent to a subset of one's peers. + +After computing the checksum, the client then transmits the information and +checksum to the recipient in the message format specified in section 5.6.1. + +3.4.2. Receipt of KRB_SAFE message + +When an application receives a KRB_SAFE message, it verifies it as follows. +If any error occurs, an error code is reported for use by the application. + +The message is first checked by verifying that the protocol version and type +fields match the current version and KRB_SAFE, respectively. A mismatch +generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The +application verifies that the checksum used is a collision-proof keyed +checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If +the sender's address was included in the control information, the recipient +verifies that the operating system's report of the sender's address matches +the sender's address in the message, and (if a recipient address is +specified or the recipient requires an address) that one of the recipient's +addresses appears as the recipient's address in the message. A failed match +for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and +usec and/or the sequence number fields are checked. If timestamp and usec +are expected and not present, or they are present but not current, the +KRB_AP_ERR_SKEW error is generated. If the server name, along with the +client name, time and microsecond fields from the Authenticator match any +recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT +error is generated. If an incorrect sequence number is included, or a +sequence number is expected but not present, the KRB_AP_ERR_BADORDER error +is generated. If neither a time-stamp and usec or a sequence number is +present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is +computed over the data and control information, and if it doesn't match the +received checksum, a KRB_AP_ERR_MODIFIED error is generated. + +If all the checks succeed, the application is assured that the message was +generated by its peer and was not modi- fied in transit. + +3.5. The KRB_PRIV Exchange + +The KRB_PRIV message may be used by clients requiring confidentiality and +the ability to detect modifications of exchanged messages. It achieves this +by encrypting the messages and adding control information. + +3.5.1. Generation of a KRB_PRIV message + +When an application wishes to send a KRB_PRIV message, it collects its data +and the appropriate control information (specified in section 5.7.1) and +encrypts them under an encryption key (usually the last key negotiated via +subkeys, or the session key if no negotiation has occured). As part of the +control information, the client must choose to use either a timestamp or a +sequence number (or both); see the discussion in section 3.4.1 for +guidelines on which to use. After the user data and control information are +encrypted, the client transmits the ciphertext and some 'envelope' +information to the recipient. + +3.5.2. Receipt of KRB_PRIV message + +When an application receives a KRB_PRIV message, it verifies it as follows. +If any error occurs, an error code is reported for use by the application. + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +The message is first checked by verifying that the protocol version and type +fields match the current version and KRB_PRIV, respectively. A mismatch +generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The +application then decrypts the ciphertext and processes the resultant +plaintext. If decryption shows the data to have been modified, a +KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was +included in the control information, the recipient verifies that the +operating system's report of the sender's address matches the sender's +address in the message, and (if a recipient address is specified or the +recipient requires an address) that one of the recipient's addresses appears +as the recipient's address in the message. A failed match for either case +generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the +sequence number fields are checked. If timestamp and usec are expected and +not present, or they are present but not current, the KRB_AP_ERR_SKEW error +is generated. If the server name, along with the client name, time and +microsecond fields from the Authenticator match any recently-seen such +tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence +number is included, or a sequence number is expected but not present, the +KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or +a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. + +If all the checks succeed, the application can assume the message was +generated by its peer, and was securely transmitted (without intruders able +to see the unencrypted contents). + +3.6. The KRB_CRED Exchange + +The KRB_CRED message may be used by clients requiring the ability to send +Kerberos credentials from one host to another. It achieves this by sending +the tickets together with encrypted data containing the session keys and +other information associated with the tickets. + +3.6.1. Generation of a KRB_CRED message + +When an application wishes to send a KRB_CRED message it first (using the +KRB_TGS exchange) obtains credentials to be sent to the remote host. It then +constructs a KRB_CRED message using the ticket or tickets so obtained, +placing the session key needed to use each ticket in the key field of the +corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED +message. + +Other information associated with each ticket and obtained during the +KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in +the encrypted part of the KRB_CRED message. The current time and, if +specifically required by the application the nonce, s-address, and r-address +fields, are placed in the encrypted part of the KRB_CRED message which is +then encrypted under an encryption key previosuly exchanged in the KRB_AP +exchange (usually the last key negotiated via subkeys, or the session key if +no negotiation has occured). + +3.6.2. Receipt of KRB_CRED message + +When an application receives a KRB_CRED message, it verifies it. If any +error occurs, an error code is reported for use by the application. The +message is verified by checking that the protocol version and type fields +match the current version and KRB_CRED, respectively. A mismatch generates a +KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then +decrypts the ciphertext and processes the resultant plaintext. If decryption +shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +generated. + +If present or required, the recipient verifies that the operating system's +report of the sender's address matches the sender's address in the message, +and that one of the recipient's addresses appears as the recipient's address +in the message. A failed match for either case generates a +KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field +if required) are checked next. If the timestamp and usec are not present, or +they are present but not current, the KRB_AP_ERR_SKEW error is generated. + +If all the checks succeed, the application stores each of the new tickets in +its ticket cache together with the session key and other information in the +corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED +message. + +4. The Kerberos Database + +The Kerberos server must have access to a database containing the principal +identifiers and secret keys of principals to be authenticated[21]. + +4.1. Database contents + +A database entry should contain at least the following fields: + +Field Value + +name Principal's identifier +key Principal's secret key +p_kvno Principal's key version +max_life Maximum lifetime for Tickets +max_renewable_life Maximum total lifetime for renewable Tickets + +The name field is an encoding of the principal's identifier. The key field +contains an encryption key. This key is the principal's secret key. (The key +can be encrypted before storage under a Kerberos "master key" to protect it +in case the database is compromised but the master key is not. In that case, +an extra field must be added to indicate the master key version used, see +below.) The p_kvno field is the key version number of the principal's secret +key. The max_life field contains the maximum allowable lifetime (endtime - +starttime) for any Ticket issued for this principal. The max_renewable_life +field contains the maximum allowable total lifetime for any renewable Ticket +issued for this principal. (See section 3.1 for a description of how these +lifetimes are used in determining the lifetime of a given Ticket.) + +A server may provide KDC service to several realms, as long as the database +representation provides a mechanism to distinguish between principal records +with identifiers which differ only in the realm name. + +When an application server's key changes, if the change is routine (i.e. not +the result of disclosure of the old key), the old key should be retained by +the server until all tickets that had been issued using that key have +expired. Because of this, it is possible for several keys to be active for a +single principal. Ciphertext encrypted in a principal's key is always tagged +with the version of the key that was used for encryption, to help the +recipient find the proper key for decryption. + +When more than one key is active for a particular principal, the principal +will have more than one record in the Kerberos database. The keys and key +version numbers will differ between the records (the rest of the fields may + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +or may not be the same). Whenever Kerberos issues a ticket, or responds to a +request for initial authentication, the most recent key (known by the +Kerberos server) will be used for encryption. This is the key with the +highest key version number. + +4.2. Additional fields + +Project Athena's KDC implementation uses additional fields in its database: + +Field Value + +K_kvno Kerberos' key version +expiration Expiration date for entry +attributes Bit field of attributes +mod_date Timestamp of last modification +mod_name Modifying principal's identifier + +The K_kvno field indicates the key version of the Kerberos master key under +which the principal's secret key is encrypted. + +After an entry's expiration date has passed, the KDC will return an error to +any client attempting to gain tickets as or for the principal. (A database +may want to maintain two expiration dates: one for the principal, and one +for the principal's current key. This allows password aging to work +independently of the principal's expiration date. However, due to the +limited space in the responses, the KDC must combine the key expiration and +principal expiration date into a single value called 'key_exp', which is +used as a hint to the user to take administrative action.) + +The attributes field is a bitfield used to govern the operations involving +the principal. This field might be useful in conjunction with user +registration procedures, for site-specific policy implementations (Project +Athena currently uses it for their user registration process controlled by +the system-wide database service, Moira [LGDSR87]), to identify whether a +principal can play the role of a client or server or both, to note whether a +server is appropriate trusted to recieve credentials delegated by a client, +or to identify the 'string to key' conversion algorithm used for a +principal's key[22]. Other bits are used to indicate that certain ticket +options should not be allowed in tickets encrypted under a principal's key +(one bit each): Disallow issuing postdated tickets, disallow issuing +forwardable tickets, disallow issuing tickets based on TGT authentication, +disallow issuing renewable tickets, disallow issuing proxiable tickets, and +disallow issuing tickets for which the principal is the server. + +The mod_date field contains the time of last modification of the entry, and +the mod_name field contains the name of the principal which last modified +the entry. + +4.3. Frequently Changing Fields + +Some KDC implementations may wish to maintain the last time that a request +was made by a particular principal. Information that might be maintained +includes the time of the last request, the time of the last request for a +ticket-granting ticket, the time of the last use of a ticket-granting +ticket, or other times. This information can then be returned to the user in +the last-req field (see section 5.2). + +Other frequently changing information that can be maintained is the latest +expiration time for any tickets that have been issued using each key. This + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +field would be used to indicate how long old keys must remain valid to allow +the continued use of outstanding tickets. + +4.4. Site Constants + +The KDC implementation should have the following configurable constants or +options, to allow an administrator to make and enforce policy decisions: + + * The minimum supported lifetime (used to determine whether the + KDC_ERR_NEVER_VALID error should be returned). This constant should + reflect reasonable expectations of round-trip time to the KDC, + encryption/decryption time, and processing time by the client and + target server, and it should allow for a minimum 'useful' lifetime. + * The maximum allowable total (renewable) lifetime of a ticket + (renew_till - starttime). + * The maximum allowable lifetime of a ticket (endtime - starttime). + * Whether to allow the issue of tickets with empty address fields + (including the ability to specify that such tickets may only be issued + if the request specifies some authorization_data). + * Whether proxiable, forwardable, renewable or post-datable tickets are + to be issued. + +5. Message Specifications + +The following sections describe the exact contents and encoding of protocol +messages and objects. The ASN.1 base definitions are presented in the first +subsection. The remaining subsections specify the protocol objects (tickets +and authenticators) and messages. Specification of encryption and checksum +techniques, and the fields related to them, appear in section 6. + +Optional field in ASN.1 sequences + +For optional integer value and date fields in ASN.1 sequences where a +default value has been specified, certain default values will not be allowed +in the encoding because these values will always be represented through +defaulting by the absence of the optional field. For example, one will not +send a microsecond zero value because one must make sure that there is only +one way to encode this value. + +Additional fields in ASN.1 sequences + +Implementations receiving Kerberos messages with additional fields present +in ASN.1 sequences should carry the those fields through, unmodified, when +the message is forwarded. Implementations should not drop such fields if the +sequence is reencoded. + +5.1. ASN.1 Distinguished Encoding Representation + +All uses of ASN.1 in Kerberos shall use the Distinguished Encoding +Representation of the data elements as described in the X.509 specification, +section 8.7 [X509-88]. + +5.3. ASN.1 Base Definitions + +The following ASN.1 base definitions are used in the rest of this section. +Note that since the underscore character (_) is not permitted in ASN.1 +names, the hyphen (-) is used in its place for the purposes of ASN.1 names. + +Realm ::= GeneralString + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString +} + +Kerberos realms are encoded as GeneralStrings. Realms shall not contain a +character with the code 0 (the ASCII NUL). Most realms will usually consist +of several components separated by periods (.), in the style of Internet +Domain Names, or separated by slashes (/) in the style of X.500 names. +Acceptable forms for realm names are specified in section 7. A PrincipalName +is a typed sequence of components consisting of the following sub-fields: + +name-type + This field specifies the type of name that follows. Pre-defined values + for this field are specified in section 7.2. The name-type should be + treated as a hint. Ignoring the name type, no two names can be the same + (i.e. at least one of the components, or the realm, must be different). + This constraint may be eliminated in the future. +name-string + This field encodes a sequence of components that form a name, each + component encoded as a GeneralString. Taken together, a PrincipalName + and a Realm form a principal identifier. Most PrincipalNames will have + only a few components (typically one or two). + +KerberosTime ::= GeneralizedTime + -- Specifying UTC time zone (Z) + +The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding +shall specify the UTC time zone (Z) and shall not include any fractional +portions of the seconds. It further shall not include any separators. +Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm +on 6 November 1985 is 19851106210627Z. + +HostAddress ::= SEQUENCE { + addr-type[0] INTEGER, + address[1] OCTET STRING +} + +HostAddresses ::= SEQUENCE OF HostAddress + +The host adddress encodings consists of two fields: + +addr-type + This field specifies the type of address that follows. Pre-defined + values for this field are specified in section 8.1. +address + This field encodes a single address of type addr-type. + +The two forms differ slightly. HostAddress contains exactly one address; +HostAddresses contains a sequence of possibly many addresses. + +AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type[0] INTEGER, + ad-data[1] OCTET STRING +} + +ad-data + This field contains authorization data to be interpreted according to + the value of the corresponding ad-type field. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +ad-type + This field specifies the format for the ad-data subfield. All negative + values are reserved for local use. Non-negative values are reserved for + registered use. + +Each sequence of type and data is refered to as an authorization element. +Elements may be application specific, however, there is a common set of +recursive elements that should be understood by all implementations. These +elements contain other elements embedded within them, and the interpretation +of the encapsulating element determines which of the embedded elements must +be interpreted, and which may be ignored. Definitions for these common +elements may be found in Appendix B. + +TicketExtensions ::= SEQUENCE OF SEQUENCE { + te-type[0] INTEGER, + te-data[1] OCTET STRING +} + + + +te-data + This field contains opaque data that must be caried with the ticket to + support extensions to the Kerberos protocol including but not limited + to some forms of inter-realm key exchange and plaintext authorization + data. See appendix C for some common uses of this field. +te-type + This field specifies the format for the te-data subfield. All negative + values are reserved for local use. Non-negative values are reserved for + registered use. + +APOptions ::= BIT STRING + -- reserved(0), + -- use-session-key(1), + -- mutual-required(2) + +TicketFlags ::= BIT STRING + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- may-postdate(5), + -- postdated(6), + -- invalid(7), + -- renewable(8), + -- initial(9), + -- pre-authent(10), + -- hw-authent(11), + -- transited-policy-checked(12), + -- ok-as-delegate(13) + +KDCOptions ::= BIT STRING + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- allow-postdate(5), + -- postdated(6), + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + -- unused7(7), + -- renewable(8), + -- unused9(9), + -- unused10(10), + -- unused11(11), + -- unused12(12), + -- unused13(13), + -- disable-transited-check(26), + -- renewable-ok(27), + -- enc-tkt-in-skey(28), + -- renew(30), + -- validate(31) + +ASN.1 Bit strings have a length and a value. When used in Kerberos for the +APOptions, TicketFlags, and KDCOptions, the length of the bit string on +generated values should be the smallest number of bits needed to include the +highest order bit that is set (1), but in no case less than 32 bits. The +ASN.1 representation of the bit strings uses unnamed bits, with the meaning +of the individual bits defined by the comments in the specification above. +Implementations should accept values of bit strings of any length and treat +the value of flags corresponding to bits beyond the end of the bit string as +if the bit were reset (0). Comparison of bit strings of different length +should treat the smaller string as if it were padded with zeros beyond the +high order bits to the length of the longer string[23]. + +LastReq ::= SEQUENCE OF SEQUENCE { + lr-type[0] INTEGER, + lr-value[1] KerberosTime +} + +lr-type + This field indicates how the following lr-value field is to be + interpreted. Negative values indicate that the information pertains + only to the responding server. Non-negative values pertain to all + servers for the realm. If the lr-type field is zero (0), then no + information is conveyed by the lr-value subfield. If the absolute value + of the lr-type field is one (1), then the lr-value subfield is the time + of last initial request for a TGT. If it is two (2), then the lr-value + subfield is the time of last initial request. If it is three (3), then + the lr-value subfield is the time of issue for the newest + ticket-granting ticket used. If it is four (4), then the lr-value + subfield is the time of the last renewal. If it is five (5), then the + lr-value subfield is the time of last request (of any type). If it is + (6), then the lr-value subfield is the time when the password will + expire. +lr-value + This field contains the time of the last request. the time must be + interpreted according to the contents of the accompanying lr-type + subfield. + +See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, +EncryptionKey, EncryptionType, and KeyType. + +5.3. Tickets and Authenticators + +This section describes the format and encryption parameters for tickets and +authenticators. When a ticket or authenticator is included in a protocol +message it is treated as an opaque object. + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +5.3.1. Tickets + +A ticket is a record that helps a client authenticate to a service. A Ticket +contains the following information: + +Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno[0] INTEGER, + realm[1] Realm, + sname[2] PrincipalName, + enc-part[3] EncryptedData, + extensions[4] TicketExtensions OPTIONAL +} + +-- Encrypted part of ticket +EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags[0] TicketFlags, + key[1] EncryptionKey, + crealm[2] Realm, + cname[3] PrincipalName, + transited[4] TransitedEncoding, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + caddr[9] HostAddresses OPTIONAL, + authorization-data[10] AuthorizationData OPTIONAL +} +-- encoded Transited field +TransitedEncoding ::= SEQUENCE { + tr-type[0] INTEGER, -- must be registered + contents[1] OCTET STRING +} + +The encoding of EncTicketPart is encrypted in the key shared by Kerberos and +the end server (the server's secret key). See section 6 for the format of +the ciphertext. + +tkt-vno + This field specifies the version number for the ticket format. This + document describes version number 5. +realm + This field specifies the realm that issued a ticket. It also serves to + identify the realm part of the server's principal identifier. Since a + Kerberos server can only issue tickets for servers within its realm, + the two will always be identical. +sname + This field specifies all components of the name part of the server's + identity, including those parts that identify a specific instance of a + service. +enc-part + This field holds the encrypted encoding of the EncTicketPart sequence. +extensions + This optional field contains a sequence of extentions that may be used + to carry information that must be carried with the ticket to support + several extensions, including but not limited to plaintext + authorization data, tokens for exchanging inter-realm keys, and other + information that must be associated with a ticket for use by the + application server. See Appendix C for definitions of some common + extensions. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + Note that some older versions of Kerberos did not support this field. + Because this is an optional field it will not break older clients, but + older clients might strip this field from the ticket before sending it + to the application server. This limits the usefulness of this ticket + field to environments where the ticket will not be parsed and + reconstructed by these older Kerberos clients. + + If it is known that the client will strip this field from the ticket, + as an interim measure the KDC may append this field to the end of the + enc-part of the ticket and append a traler indicating the lenght of the + appended extensions field. (this paragraph is open for discussion, + including the form of the traler). +flags + This field indicates which of various options were used or requested + when the ticket was issued. It is a bit-field, where the selected + options are indicated by the bit being set (1), and the unselected + options and reserved fields being reset (0). Bit 0 is the most + significant bit. The encoding of the bits is specified in section 5.2. + The flags are described in more detail above in section 2. The meanings + of the flags are: + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + field. + + 1 FORWARDABLE + The FORWARDABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. When set, this + flag tells the ticket-granting server + that it is OK to issue a new ticket- + granting ticket with a different network + address based on the presented ticket. + + 2 FORWARDED + When set, this flag indicates that the + ticket has either been forwarded or was + issued based on authentication involving + a forwarded ticket-granting ticket. + + 3 PROXIABLE + The PROXIABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. The PROXIABLE + flag has an interpretation identical to + that of the FORWARDABLE flag, except + that the PROXIABLE flag tells the + ticket-granting server that only non- + ticket-granting tickets may be issued + with different network addresses. + + 4 PROXY + When set, this flag indicates that a + ticket is a proxy. + + 5 MAY-POSTDATE + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The MAY-POSTDATE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. This flag tells + the ticket-granting server that a post- + dated ticket may be issued based on this + ticket-granting ticket. + + 6 POSTDATED + This flag indicates that this ticket has + been postdated. The end-service can + check the authtime field to see when the + original authentication occurred. + + 7 INVALID + This flag indicates that a ticket is + invalid, and it must be validated by the + KDC before use. Application servers + must reject tickets which have this flag + set. + + 8 RENEWABLE + The RENEWABLE flag is normally only + interpreted by the TGS, and can usually + be ignored by end servers (some particu- + larly careful servers may wish to disal- + low renewable tickets). A renewable + ticket can be used to obtain a replace- + ment ticket that expires at a later + date. + + 9 INITIAL + This flag indicates that this ticket was + issued using the AS protocol, and not + issued based on a ticket-granting + ticket. + + 10 PRE-AUTHENT + This flag indicates that during initial + authentication, the client was authenti- + cated by the KDC before a ticket was + issued. The strength of the pre- + authentication method is not indicated, + but is acceptable to the KDC. + + 11 HW-AUTHENT + This flag indicates that the protocol + employed for initial authentication + required the use of hardware expected to + be possessed solely by the named client. + The hardware authentication method is + selected by the KDC and the strength of + the method is not indicated. + + 12 TRANSITED This flag indicates that the KDC for the + POLICY-CHECKED realm has checked the transited field + against a realm defined policy for + trusted certifiers. If this flag is + reset (0), then the application server + must check the transited field itself, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + and if unable to do so it must reject + the authentication. If the flag is set + (1) then the application server may skip + its own validation of the transited + field, relying on the validation + performed by the KDC. At its option the + application server may still apply its + own validation based on a separate + policy for acceptance. + + 13 OK-AS-DELEGATE This flag indicates that the server (not + the client) specified in the ticket has + been determined by policy of the realm + to be a suitable recipient of + delegation. A client can use the + presence of this flag to help it make a + decision whether to delegate credentials + (either grant a proxy or a forwarded + ticket granting ticket) to this server. + The client is free to ignore the value + of this flag. When setting this flag, + an administrator should consider the + Security and placement of the server on + which the service will run, as well as + whether the service requires the use of + delegated credentials. + + 14 ANONYMOUS + This flag indicates that the principal + named in the ticket is a generic princi- + pal for the realm and does not identify + the individual using the ticket. The + purpose of the ticket is only to + securely distribute a session key, and + not to identify the user. Subsequent + requests using the same ticket and ses- + sion may be considered as originating + from the same user, but requests with + the same username but a different ticket + are likely to originate from different + users. + + 15-31 RESERVED + Reserved for future use. + +key + This field exists in the ticket and the KDC response and is used to + pass the session key from Kerberos to the application server and the + client. The field's encoding is described in section 6.2. +crealm + This field contains the name of the realm in which the client is + registered and in which initial authentication took place. +cname + This field contains the name part of the client's principal identifier. +transited + This field lists the names of the Kerberos realms that took part in + authenticating the user to whom this ticket was issued. It does not + specify the order in which the realms were transited. See section + 3.3.3.2 for details on how this field encodes the traversed realms. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + When the names of CA's are to be embedded inthe transited field (as + specified for some extentions to the protocol), the X.500 names of the + CA's should be mapped into items in the transited field using the + mapping defined by RFC2253. +authtime + This field indicates the time of initial authentication for the named + principal. It is the time of issue for the original ticket on which + this ticket is based. It is included in the ticket to provide + additional information to the end service, and to provide the necessary + information for implementation of a `hot list' service at the KDC. An + end service that is particularly paranoid could refuse to accept + tickets for which the initial authentication occurred "too far" in the + past. This field is also returned as part of the response from the KDC. + When returned as part of the response to initial authentication + (KRB_AS_REP), this is the current time on the Kerberos server[24]. +starttime + This field in the ticket specifies the time after which the ticket is + valid. Together with endtime, this field specifies the life of the + ticket. If it is absent from the ticket, its value should be treated as + that of the authtime field. +endtime + This field contains the time after which the ticket will not be honored + (its expiration time). Note that individual services may place their + own limits on the life of a ticket and may reject tickets which have + not yet expired. As such, this is really an upper bound on the + expiration time for the ticket. +renew-till + This field is only present in tickets that have the RENEWABLE flag set + in the flags field. It indicates the maximum endtime that may be + included in a renewal. It can be thought of as the absolute expiration + time for the ticket, including all renewals. +caddr + This field in a ticket contains zero (if omitted) or more (if present) + host addresses. These are the addresses from which the ticket can be + used. If there are no addresses, the ticket can be used from any + location. The decision by the KDC to issue or by the end server to + accept zero-address tickets is a policy decision and is left to the + Kerberos and end-service administrators; they may refuse to issue or + accept such tickets. The suggested and default policy, however, is that + such tickets will only be issued or accepted when additional + information that can be used to restrict the use of the ticket is + included in the authorization_data field. Such a ticket is a + capability. + + Network addresses are included in the ticket to make it harder for an + attacker to use stolen credentials. Because the session key is not sent + over the network in cleartext, credentials can't be stolen simply by + listening to the network; an attacker has to gain access to the session + key (perhaps through operating system security breaches or a careless + user's unattended session) to make use of stolen tickets. + + It is important to note that the network address from which a + connection is received cannot be reliably determined. Even if it could + be, an attacker who has compromised the client's workstation could use + the credentials from there. Including the network addresses only makes + it more difficult, not impossible, for an attacker to walk off with + stolen credentials and then use them from a "safe" location. +authorization-data + The authorization-data field is used to pass authorization data from + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + the principal on whose behalf a ticket was issued to the application + service. If no authorization data is included, this field will be left + out. Experience has shown that the name of this field is confusing, and + that a better name for this field would be restrictions. Unfortunately, + it is not possible to change the name of this field at this time. + + This field contains restrictions on any authority obtained on the basis + of authentication using the ticket. It is possible for any principal in + posession of credentials to add entries to the authorization data field + since these entries further restrict what can be done with the ticket. + Such additions can be made by specifying the additional entries when a + new ticket is obtained during the TGS exchange, or they may be added + during chained delegation using the authorization data field of the + authenticator. + + Because entries may be added to this field by the holder of + credentials, except when an entry is separately authenticated by + encapulation in the kdc-issued element, it is not allowable for the + presence of an entry in the authorization data field of a ticket to + amplify the priveleges one would obtain from using a ticket. + + The data in this field may be specific to the end service; the field + will contain the names of service specific objects, and the rights to + those objects. The format for this field is described in section 5.2. + Although Kerberos is not concerned with the format of the contents of + the sub-fields, it does carry type information (ad-type). + + By using the authorization_data field, a principal is able to issue a + proxy that is valid for a specific purpose. For example, a client + wishing to print a file can obtain a file server proxy to be passed to + the print server. By specifying the name of the file in the + authorization_data field, the file server knows that the print server + can only use the client's rights when accessing the particular file to + be printed. + + A separate service providing authorization or certifying group + membership may be built using the authorization-data field. In this + case, the entity granting authorization (not the authorized entity), + may obtain a ticket in its own name (e.g. the ticket is issued in the + name of a privelege server), and this entity adds restrictions on its + own authority and delegates the restricted authority through a proxy to + the client. The client would then present this authorization credential + to the application server separately from the authentication exchange. + Alternatively, such authorization credentials may be embedded in the + ticket authenticating the authorized entity, when the authorization is + separately authenticated using the kdc-issued authorization data + element (see B.4). + + Similarly, if one specifies the authorization-data field of a proxy and + leaves the host addresses blank, the resulting ticket and session key + can be treated as a capability. See [Neu93] for some suggested uses of + this field. + + The authorization-data field is optional and does not have to be + included in a ticket. + +5.3.2. Authenticators + +An authenticator is a record sent with a ticket to a server to certify the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +client's knowledge of the encryption key in the ticket, to help the server +detect replays, and to help choose a "true session key" to use with the +particular session. The encoding is encrypted in the ticket's session key +shared by the client and the server: + +-- Unencrypted authenticator +Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno[0] INTEGER, + crealm[1] Realm, + cname[2] PrincipalName, + cksum[3] Checksum OPTIONAL, + cusec[4] INTEGER, + ctime[5] KerberosTime, + subkey[6] EncryptionKey OPTIONAL, + seq-number[7] INTEGER OPTIONAL, + authorization-data[8] AuthorizationData OPTIONAL +} + + +authenticator-vno + This field specifies the version number for the format of the + authenticator. This document specifies version 5. +crealm and cname + These fields are the same as those described for the ticket in section + 5.3.1. +cksum + This field contains a checksum of the the applica- tion data that + accompanies the KRB_AP_REQ. +cusec + This field contains the microsecond part of the client's timestamp. Its + value (before encryption) ranges from 0 to 999999. It often appears + along with ctime. The two fields are used together to specify a + reasonably accurate timestamp. +ctime + This field contains the current time on the client's host. +subkey + This field contains the client's choice for an encryption key which is + to be used to protect this specific application session. Unless an + application specifies otherwise, if this field is left out the session + key from the ticket will be used. +seq-number + This optional field includes the initial sequence number to be used by + the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to + detect replays (It may also be used by application specific messages). + When included in the authenticator this field specifies the initial + sequence number for messages from the client to the server. When + included in the AP-REP message, the initial sequence number is that for + messages from the server to the client. When used in KRB_PRIV or + KRB_SAFE messages, it is incremented by one after each message is sent. + Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to + zero following the value 2^32 - 1. + + For sequence numbers to adequately support the detection of replays + they should be non-repeating, even across connection boundaries. The + initial sequence number should be random and uniformly distributed + across the full space of possible sequence numbers, so that it cannot + be guessed by an attacker and so that it and the successive sequence + numbers do not repeat other sequences. +authorization-data + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + This field is the same as described for the ticket in section 5.3.1. It + is optional and will only appear when additional restrictions are to be + placed on the use of a ticket, beyond those carried in the ticket + itself. + +5.4. Specifications for the AS and TGS exchanges + +This section specifies the format of the messages used in the exchange +between the client and the Kerberos server. The format of possible error +messages appears in section 5.9.1. + +5.4.1. KRB_KDC_REQ definition + +The KRB_KDC_REQ message has no type of its own. Instead, its type is one of +KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial +ticket or an additional ticket. In either case, the message is sent from the +client to the Authentication Server to request credentials for a service. + +The message fields are: + +AS-REQ ::= [APPLICATION 10] KDC-REQ +TGS-REQ ::= [APPLICATION 12] KDC-REQ + +KDC-REQ ::= SEQUENCE { + pvno[1] INTEGER, + msg-type[2] INTEGER, + padata[3] SEQUENCE OF PA-DATA OPTIONAL, + req-body[4] KDC-REQ-BODY +} + +PA-DATA ::= SEQUENCE { + padata-type[1] INTEGER, + padata-value[2] OCTET STRING, + -- might be encoded AP-REQ +} + +KDC-REQ-BODY ::= SEQUENCE { + kdc-options[0] KDCOptions, + cname[1] PrincipalName OPTIONAL, + -- Used only in AS-REQ + realm[2] Realm, -- Server's realm + -- Also client's in AS-REQ + sname[3] PrincipalName OPTIONAL, + from[4] KerberosTime OPTIONAL, + till[5] KerberosTime OPTIONAL, + rtime[6] KerberosTime OPTIONAL, + nonce[7] INTEGER, + etype[8] SEQUENCE OF INTEGER, + -- EncryptionType, + -- in preference order + addresses[9] HostAddresses OPTIONAL, + enc-authorization-data[10] EncryptedData OPTIONAL, + -- Encrypted AuthorizationData + -- encoding + additional-tickets[11] SEQUENCE OF Ticket OPTIONAL +} + +The fields in this message are: + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +pvno + This field is included in each message, and specifies the protocol + version number. This document specifies protocol version 5. +msg-type + This field indicates the type of a protocol message. It will almost + always be the same as the application identifier associated with a + message. It is included to make the identifier more readily accessible + to the application. For the KDC-REQ message, this type will be + KRB_AS_REQ or KRB_TGS_REQ. +padata + The padata (pre-authentication data) field contains a sequence of + authentication information which may be needed before credentials can + be issued or decrypted. In the case of requests for additional tickets + (KRB_TGS_REQ), this field will include an element with padata-type of + PA-TGS-REQ and data of an authentication header (ticket-granting ticket + and authenticator). The checksum in the authenticator (which must be + collision-proof) is to be computed over the KDC-REQ-BODY encoding. In + most requests for initial authentication (KRB_AS_REQ) and most replies + (KDC-REP), the padata field will be left out. + + This field may also contain information needed by certain extensions to + the Kerberos protocol. For example, it might be used to initially + verify the identity of a client before any response is returned. This + is accomplished with a padata field with padata-type equal to + PA-ENC-TIMESTAMP and padata-value defined as follows: + + padata-type ::= PA-ENC-TIMESTAMP + padata-value ::= EncryptedData -- PA-ENC-TS-ENC + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp[0] KerberosTime, -- client's time + pausec[1] INTEGER OPTIONAL + } + + with patimestamp containing the client's time and pausec containing the + microseconds which may be omitted if a client will not generate more + than one request per second. The ciphertext (padata-value) consists of + the PA-ENC-TS-ENC sequence, encrypted using the client's secret key. + + [use-specified-kvno item is here for discussion and may be removed] It + may also be used by the client to specify the version of a key that is + being used for accompanying preauthentication, and/or which should be + used to encrypt the reply from the KDC. + + PA-USE-SPECIFIED-KVNO ::= Integer + + The KDC should only accept and abide by the value of the + use-specified-kvno preauthentication data field when the specified key + is still valid and until use of a new key is confirmed. This situation + is likely to occur primarily during the period during which an updated + key is propagating to other KDC's in a realm. + + The padata field can also contain information needed to help the KDC or + the client select the key needed for generating or decrypting the + response. This form of the padata is useful for supporting the use of + certain token cards with Kerberos. The details of such extensions are + specified in separate documents. See [Pat92] for additional uses of + this field. +padata-type + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The padata-type element of the padata field indicates the way that the + padata-value element is to be interpreted. Negative values of + padata-type are reserved for unregistered use; non-negative values are + used for a registered interpretation of the element type. +req-body + This field is a placeholder delimiting the extent of the remaining + fields. If a checksum is to be calculated over the request, it is + calculated over an encoding of the KDC-REQ-BODY sequence which is + enclosed within the req-body field. +kdc-options + This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the + KDC and indicates the flags that the client wants set on the tickets as + well as other information that is to modify the behavior of the KDC. + Where appropriate, the name of an option may be the same as the flag + that is set by that option. Although in most case, the bit in the + options field will be the same as that in the flags field, this is not + guaranteed, so it is not acceptable to simply copy the options field to + the flags field. There are various checks that must be made before + honoring an option anyway. + + The kdc_options field is a bit-field, where the selected options are + indicated by the bit being set (1), and the unselected options and + reserved fields being reset (0). The encoding of the bits is specified + in section 5.2. The options are described in more detail above in + section 2. The meanings of the options are: + + Bit(s) Name Description + 0 RESERVED + Reserved for future expansion of this + field. + + 1 FORWARDABLE + The FORWARDABLE option indicates that + the ticket to be issued is to have its + forwardable flag set. It may only be + set on the initial request, or in a sub- + sequent request if the ticket-granting + ticket on which it is based is also for- + wardable. + + 2 FORWARDED + The FORWARDED option is only specified + in a request to the ticket-granting + server and will only be honored if the + ticket-granting ticket in the request + has its FORWARDABLE bit set. This + option indicates that this is a request + for forwarding. The address(es) of the + host from which the resulting ticket is + to be valid are included in the + addresses field of the request. + + 3 PROXIABLE + The PROXIABLE option indicates that the + ticket to be issued is to have its prox- + iable flag set. It may only be set on + the initial request, or in a subsequent + request if the ticket-granting ticket on + which it is based is also proxiable. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + 4 PROXY + The PROXY option indicates that this is + a request for a proxy. This option will + only be honored if the ticket-granting + ticket in the request has its PROXIABLE + bit set. The address(es) of the host + from which the resulting ticket is to be + valid are included in the addresses + field of the request. + + 5 ALLOW-POSTDATE + The ALLOW-POSTDATE option indicates that + the ticket to be issued is to have its + MAY-POSTDATE flag set. It may only be + set on the initial request, or in a sub- + sequent request if the ticket-granting + ticket on which it is based also has its + MAY-POSTDATE flag set. + + 6 POSTDATED + The POSTDATED option indicates that this + is a request for a postdated ticket. + This option will only be honored if the + ticket-granting ticket on which it is + based has its MAY-POSTDATE flag set. + The resulting ticket will also have its + INVALID flag set, and that flag may be + reset by a subsequent request to the KDC + after the starttime in the ticket has + been reached. + + 7 UNUSED + This option is presently unused. + + 8 RENEWABLE + The RENEWABLE option indicates that the + ticket to be issued is to have its + RENEWABLE flag set. It may only be set + on the initial request, or when the + ticket-granting ticket on which the + request is based is also renewable. If + this option is requested, then the rtime + field in the request contains the + desired absolute expiration time for the + ticket. + + 9-13 UNUSED + These options are presently unused. + + 14 REQUEST-ANONYMOUS + The REQUEST-ANONYMOUS option indicates + that the ticket to be issued is not to + identify the user to which it was + issued. Instead, the principal identif- + ier is to be generic, as specified by + the policy of the realm (e.g. usually + anonymous@realm). The purpose of the + ticket is only to securely distribute a + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + session key, and not to identify the + user. The ANONYMOUS flag on the ticket + to be returned should be set. If the + local realms policy does not permit + anonymous credentials, the request is to + be rejected. + + 15-25 RESERVED + Reserved for future use. + + 26 DISABLE-TRANSITED-CHECK + By default the KDC will check the + transited field of a ticket-granting- + ticket against the policy of the local + realm before it will issue derivative + tickets based on the ticket granting + ticket. If this flag is set in the + request, checking of the transited field + is disabled. Tickets issued without the + performance of this check will be noted + by the reset (0) value of the + TRANSITED-POLICY-CHECKED flag, + indicating to the application server + that the tranisted field must be checked + locally. KDC's are encouraged but not + required to honor the + DISABLE-TRANSITED-CHECK option. + + 27 RENEWABLE-OK + The RENEWABLE-OK option indicates that a + renewable ticket will be acceptable if a + ticket with the requested life cannot + otherwise be provided. If a ticket with + the requested life cannot be provided, + then a renewable ticket may be issued + with a renew-till equal to the the + requested endtime. The value of the + renew-till field may still be limited by + local limits, or limits selected by the + individual principal or server. + + 28 ENC-TKT-IN-SKEY + This option is used only by the ticket- + granting service. The ENC-TKT-IN-SKEY + option indicates that the ticket for the + end server is to be encrypted in the + session key from the additional ticket- + granting ticket provided. + + 29 RESERVED + Reserved for future use. + + 30 RENEW + This option is used only by the ticket- + granting service. The RENEW option + indicates that the present request is + for a renewal. The ticket provided is + encrypted in the secret key for the + server on which it is valid. This + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + option will only be honored if the + ticket to be renewed has its RENEWABLE + flag set and if the time in its renew- + till field has not passed. The ticket + to be renewed is passed in the padata + field as part of the authentication + header. + + 31 VALIDATE + This option is used only by the ticket- + granting service. The VALIDATE option + indicates that the request is to vali- + date a postdated ticket. It will only + be honored if the ticket presented is + postdated, presently has its INVALID + flag set, and would be otherwise usable + at this time. A ticket cannot be vali- + dated before its starttime. The ticket + presented for validation is encrypted in + the key of the server for which it is + valid and is passed in the padata field + as part of the authentication header. + +cname and sname + These fields are the same as those described for the ticket in section + 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is + specified. If absent, the name of the server is taken from the name of + the client in the ticket passed as additional-tickets. +enc-authorization-data + The enc-authorization-data, if present (and it can only be present in + the TGS_REQ form), is an encoding of the desired authorization-data + encrypted under the sub-session key if present in the Authenticator, or + alternatively from the session key in the ticket-granting ticket, both + from the padata field in the KRB_AP_REQ. +realm + This field specifies the realm part of the server's principal + identifier. In the AS exchange, this is also the realm part of the + client's principal identifier. +from + This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket + requests when the requested ticket is to be postdated. It specifies the + desired start time for the requested ticket. If this field is omitted + then the KDC should use the current time instead. +till + This field contains the expiration date requested by the client in a + ticket request. It is optional and if omitted the requested ticket is + to have the maximum endtime permitted according to KDC policy for the + parties to the authentication exchange as limited by expiration date of + the ticket granting ticket or other preauthentication credentials. +rtime + This field is the requested renew-till time sent from a client to the + KDC in a ticket request. It is optional. +nonce + This field is part of the KDC request and response. It it intended to + hold a random number generated by the client. If the same number is + included in the encrypted response from the KDC, it provides evidence + that the response is fresh and has not been replayed by an attacker. + Nonces must never be re-used. Ideally, it should be generated randomly, + but if the correct time is known, it may suffice[25]. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +etype + This field specifies the desired encryption algorithm to be used in the + response. +addresses + This field is included in the initial request for tickets, and + optionally included in requests for additional tickets from the + ticket-granting server. It specifies the addresses from which the + requested ticket is to be valid. Normally it includes the addresses for + the client's host. If a proxy is requested, this field will contain + other addresses. The contents of this field are usually copied by the + KDC into the caddr field of the resulting ticket. +additional-tickets + Additional tickets may be optionally included in a request to the + ticket-granting server. If the ENC-TKT-IN-SKEY option has been + specified, then the session key from the additional ticket will be used + in place of the server's key to encrypt the new ticket. If more than + one option which requires additional tickets has been specified, then + the additional tickets are used in the order specified by the ordering + of the options bits (see kdc-options, above). + +The application code will be either ten (10) or twelve (12) depending on +whether the request is for an initial ticket (AS-REQ) or for an additional +ticket (TGS-REQ). + +The optional fields (addresses, authorization-data and additional-tickets) +are only included if necessary to perform the operation specified in the +kdc-options field. + +It should be noted that in KRB_TGS_REQ, the protocol version number appears +twice and two different message types appear: the KRB_TGS_REQ message +contains these fields as does the authentication header (KRB_AP_REQ) that is +passed in the padata field. + +5.4.2. KRB_KDC_REP definition + +The KRB_KDC_REP message format is used for the reply from the KDC for either +an initial (AS) request or a subsequent (TGS) request. There is no message +type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or +KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply +depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in +the client's secret key, and the client's key version number is included in +the key version number for the encrypted data. For KRB_TGS_REP, the +ciphertext is encrypted in the sub-session key from the Authenticator, or if +absent, the session key from the ticket-granting ticket used in the request. +In that case, no version number will be present in the EncryptedData +sequence. + +The KRB_KDC_REP message contains the following fields: + +AS-REP ::= [APPLICATION 11] KDC-REP +TGS-REP ::= [APPLICATION 13] KDC-REP + +KDC-REP ::= SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + padata[2] SEQUENCE OF PA-DATA OPTIONAL, + crealm[3] Realm, + cname[4] PrincipalName, + ticket[5] Ticket, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + enc-part[6] EncryptedData +} + +EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart +EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + +EncKDCRepPart ::= SEQUENCE { + key[0] EncryptionKey, + last-req[1] LastReq, + nonce[2] INTEGER, + key-expiration[3] KerberosTime OPTIONAL, + flags[4] TicketFlags, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + srealm[9] Realm, + sname[10] PrincipalName, + caddr[11] HostAddresses OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is either + KRB_AS_REP or KRB_TGS_REP. +padata + This field is described in detail in section 5.4.1. One possible use + for this field is to encode an alternate "mix-in" string to be used + with a string-to-key algorithm (such as is described in section 6.3.2). + This ability is useful to ease transitions if a realm name needs to + change (e.g. when a company is acquired); in such a case all existing + password-derived entries in the KDC database would be flagged as + needing a special mix-in string until the next password change. +crealm, cname, srealm and sname + These fields are the same as those described for the ticket in section + 5.3.1. +ticket + The newly-issued ticket, from section 5.3.1. +enc-part + This field is a place holder for the ciphertext and related information + that forms the encrypted part of a message. The description of the + encrypted part of the message follows each appearance of this field. + The encrypted part is encoded as described in section 6.1. +key + This field is the same as described for the ticket in section 5.3.1. +last-req + This field is returned by the KDC and specifies the time(s) of the last + request by a principal. Depending on what information is available, + this might be the last time that a request for a ticket-granting ticket + was made, or the last time that a request based on a ticket-granting + ticket was successful. It also might cover all servers for a realm, or + just the particular server. Some implementations may display this + information to the user to aid in discovering unauthorized use of one's + identity. It is similar in spirit to the last login time displayed when + logging into timesharing systems. +nonce + This field is described above in section 5.4.1. +key-expiration + The key-expiration field is part of the response from the KDC and + specifies the time that the client's secret key is due to expire. The + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + expiration might be the result of password aging or an account + expiration. This field will usually be left out of the TGS reply since + the response to the TGS request is encrypted in a session key and no + client information need be retrieved from the KDC database. It is up to + the application client (usually the login program) to take appropriate + action (such as notifying the user) if the expiration time is imminent. +flags, authtime, starttime, endtime, renew-till and caddr + These fields are duplicates of those found in the encrypted portion of + the attached ticket (see section 5.3.1), provided so the client may + verify they match the intended request and to assist in proper ticket + caching. If the message is of type KRB_TGS_REP, the caddr field will + only be filled in if the request was for a proxy or forwarded ticket, + or if the user is substituting a subset of the addresses from the + ticket granting ticket. If the client-requested addresses are not + present or not used, then the addresses contained in the ticket will be + the same as those included in the ticket-granting ticket. + +5.5. Client/Server (CS) message specifications + +This section specifies the format of the messages used for the +authentication of the client to the application server. + +5.5.1. KRB_AP_REQ definition + +The KRB_AP_REQ message contains the Kerberos protocol version number, the +message type KRB_AP_REQ, an options field to indicate any options in use, +and the ticket and authenticator themselves. The KRB_AP_REQ message is often +referred to as the 'authentication header'. + +AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ap-options[2] APOptions, + ticket[3] Ticket, + authenticator[4] EncryptedData +} + +APOptions ::= BIT STRING { + reserved(0), + use-session-key(1), + mutual-required(2) +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REQ. +ap-options + This field appears in the application request (KRB_AP_REQ) and affects + the way the request is processed. It is a bit-field, where the selected + options are indicated by the bit being set (1), and the unselected + options and reserved fields being reset (0). The encoding of the bits + is specified in section 5.2. The meanings of the options are: + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + field. + + 1 USE-SESSION-KEY + The USE-SESSION-KEY option indicates + that the ticket the client is presenting + to a server is encrypted in the session + key from the server's ticket-granting + ticket. When this option is not speci- + fied, the ticket is encrypted in the + server's secret key. + + 2 MUTUAL-REQUIRED + The MUTUAL-REQUIRED option tells the + server that the client requires mutual + authentication, and that it must respond + with a KRB_AP_REP message. + + 3-31 RESERVED + Reserved for future use. + +ticket + This field is a ticket authenticating the client to the server. +authenticator + This contains the authenticator, which includes the client's choice of + a subkey. Its encoding is described in section 5.3.2. + +5.5.2. KRB_AP_REP definition + +The KRB_AP_REP message contains the Kerberos protocol version number, the +message type, and an encrypted time- stamp. The message is sent in in +response to an application request (KRB_AP_REQ) where the mutual +authentication option has been selected in the ap-options field. + +AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[2] EncryptedData +} + +EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { + ctime[0] KerberosTime, + cusec[1] INTEGER, + subkey[2] EncryptionKey OPTIONAL, + seq-number[3] INTEGER OPTIONAL +} + +The encoded EncAPRepPart is encrypted in the shared session key of the +ticket. The optional subkey field can be used in an application-arranged +negotiation to choose a per association session key. + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REP. +enc-part + This field is described above in section 5.4.2. +ctime + This field contains the current time on the client's host. +cusec + This field contains the microsecond part of the client's timestamp. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +subkey + This field contains an encryption key which is to be used to protect + this specific application session. See section 3.2.6 for specifics on + how this field is used to negotiate a key. Unless an application + specifies otherwise, if this field is left out, the sub-session key + from the authenticator, or if also left out, the session key from the + ticket will be used. + +5.5.3. Error message reply + +If an error occurs while processing the application request, the KRB_ERROR +message will be sent in response. See section 5.9.1 for the format of the +error message. The cname and crealm fields may be left out if the server +cannot determine their appropriate values from the corresponding KRB_AP_REQ +message. If the authenticator was decipherable, the ctime and cusec fields +will contain the values from it. + +5.6. KRB_SAFE message specification + +This section specifies the format of a message that can be used by either +side (client or server) of an application to send a tamper-proof message to +its peer. It presumes that a session key has previously been exchanged (for +example, by using the KRB_AP_REQ/KRB_AP_REP messages). + +5.6.1. KRB_SAFE definition + +The KRB_SAFE message contains user data along with a collision-proof +checksum keyed with the last encryption key negotiated via subkeys, or the +session key if no negotiation has occured. The message fields are: + +KRB-SAFE ::= [APPLICATION 20] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + safe-body[2] KRB-SAFE-BODY, + cksum[3] Checksum +} + +KRB-SAFE-BODY ::= SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_SAFE. +safe-body + This field is a placeholder for the body of the KRB-SAFE message. +cksum + This field contains the checksum of the application data. Checksum + details are described in section 6.4. The checksum is computed over the + encoding of the KRB-SAFE sequence. First, the cksum is zeroed and the + checksum is computed over the encoding of the KRB-SAFE sequence, then + the checksum is set to the result of that computation, and finally the + KRB-SAFE sequence is encoded again. +user-data + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + This field is part of the KRB_SAFE and KRB_PRIV messages and contain + the application specific data that is being passed from the sender to + the recipient. +timestamp + This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents + are the current time as known by the sender of the message. By checking + the timestamp, the recipient of the message is able to make sure that + it was recently generated, and is not a replay. +usec + This field is part of the KRB_SAFE and KRB_PRIV headers. It contains + the microsecond part of the timestamp. +seq-number + This field is described above in section 5.3.2. +s-address + This field specifies the address in use by the sender of the message. + It may be omitted if not required by the application protocol. The + application designer considering omission of this field is warned, that + the inclusion of this address prevents some kinds of replay attacks + (e.g., reflection attacks) and that it is only acceptable to omit this + address if there is sufficient information in the integrity protected + part of the application message for the recipient to unambiguously + determine if it was the intended recipient. +r-address + This field specifies the address in use by the recipient of the + message. It may be omitted for some uses (such as broadcast protocols), + but the recipient may arbitrarily reject such messages. This field + along with s-address can be used to help detect messages which have + been incorrectly or maliciously delivered to the wrong recipient. + +5.7. KRB_PRIV message specification + +This section specifies the format of a message that can be used by either +side (client or server) of an application to securely and privately send a +message to its peer. It presumes that a session key has previously been +exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). + +5.7.1. KRB_PRIV definition + +The KRB_PRIV message contains user data encrypted in the Session Key. The +message fields are: + +KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[3] EncryptedData +} + +EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, -- sender's addr + r-address[5] HostAddress OPTIONAL -- recip's addr +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_PRIV. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +enc-part + This field holds an encoding of the EncKrbPrivPart sequence encrypted + under the session key[32]. This encrypted encoding is used for the + enc-part field of the KRB-PRIV message. See section 6 for the format of + the ciphertext. +user-data, timestamp, usec, s-address and r-address + These fields are described above in section 5.6.1. +seq-number + This field is described above in section 5.3.2. + +5.8. KRB_CRED message specification + +This section specifies the format of a message that can be used to send +Kerberos credentials from one principal to another. It is presented here to +encourage a common mechanism to be used by applications when forwarding +tickets or providing proxies to subordinate servers. It presumes that a +session key has already been exchanged perhaps by using the +KRB_AP_REQ/KRB_AP_REP messages. + +5.8.1. KRB_CRED definition + +The KRB_CRED message contains a sequence of tickets to be sent and +information needed to use the tickets, including the session key from each. +The information needed to use the tickets is encrypted under an encryption +key previously exchanged or transferred alongside the KRB_CRED message. The +message fields are: + +KRB-CRED ::= [APPLICATION 22] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, -- KRB_CRED + tickets[2] SEQUENCE OF Ticket, + enc-part[3] EncryptedData +} + +EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info[0] SEQUENCE OF KrbCredInfo, + nonce[1] INTEGER OPTIONAL, + timestamp[2] KerberosTime OPTIONAL, + usec[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + +KrbCredInfo ::= SEQUENCE { + key[0] EncryptionKey, + prealm[1] Realm OPTIONAL, + pname[2] PrincipalName OPTIONAL, + flags[3] TicketFlags OPTIONAL, + authtime[4] KerberosTime OPTIONAL, + starttime[5] KerberosTime OPTIONAL, + endtime[6] KerberosTime OPTIONAL + renew-till[7] KerberosTime OPTIONAL, + srealm[8] Realm OPTIONAL, + sname[9] PrincipalName OPTIONAL, + caddr[10] HostAddresses OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + KRB_CRED. +tickets + These are the tickets obtained from the KDC specifically for use by the + intended recipient. Successive tickets are paired with the + corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED + message. +enc-part + This field holds an encoding of the EncKrbCredPart sequence encrypted + under the session key shared between the sender and the intended + recipient. This encrypted encoding is used for the enc-part field of + the KRB-CRED message. See section 6 for the format of the ciphertext. +nonce + If practical, an application may require the inclusion of a nonce + generated by the recipient of the message. If the same value is + included as the nonce in the message, it provides evidence that the + message is fresh and has not been replayed by an attacker. A nonce must + never be re-used; it should be generated randomly by the recipient of + the message and provided to the sender of the message in an application + specific manner. +timestamp and usec + These fields specify the time that the KRB-CRED message was generated. + The time is used to provide assurance that the message is fresh. +s-address and r-address + These fields are described above in section 5.6.1. They are used + optionally to provide additional assurance of the integrity of the + KRB-CRED message. +key + This field exists in the corresponding ticket passed by the KRB-CRED + message and is used to pass the session key from the sender to the + intended recipient. The field's encoding is described in section 6.2. + +The following fields are optional. If present, they can be associated with +the credentials in the remote ticket file. If left out, then it is assumed +that the recipient of the credentials already knows their value. + +prealm and pname + The name and realm of the delegated principal identity. +flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr + These fields contain the values of the correspond- ing fields from the + ticket found in the ticket field. Descriptions of the fields are + identical to the descriptions in the KDC-REP message. + +5.9. Error message specification + +This section specifies the format for the KRB_ERROR message. The fields +included in the message are intended to return as much information as +possible about an error. It is not expected that all the information +required by the fields will be available for all types of errors. If the +appropriate information is not available when the message is composed, the +corresponding field will be left out of the message. + +Note that since the KRB_ERROR message is only optionally integrity +protected, it is quite possible for an intruder to synthesize or modify such +a message. In particular, this means that unless appropriate integrity +protection mechanisms have been applied to the KRB_ERROR message, the client +should not use any fields in this message for security-critical purposes, +such as setting a system clock or generating a fresh authenticator. The +message can be useful, however, for advising a user on the reason for some +failure. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + +5.9.1. KRB_ERROR definition + +The KRB_ERROR message consists of the following fields: + +KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ctime[2] KerberosTime OPTIONAL, + cusec[3] INTEGER OPTIONAL, + stime[4] KerberosTime, + susec[5] INTEGER, + error-code[6] INTEGER, + crealm[7] Realm OPTIONAL, + cname[8] PrincipalName OPTIONAL, + realm[9] Realm, -- Correct realm + sname[10] PrincipalName, -- Correct name + e-text[11] GeneralString OPTIONAL, + e-data[12] OCTET STRING OPTIONAL, + e-cksum[13] Checksum OPTIONAL, +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_ERROR. +ctime + This field is described above in section 5.4.1. +cusec + This field is described above in section 5.5.2. +stime + This field contains the current time on the server. It is of type + KerberosTime. +susec + This field contains the microsecond part of the server's timestamp. Its + value ranges from 0 to 999999. It appears along with stime. The two + fields are used in conjunction to specify a reasonably accurate + timestamp. +error-code + This field contains the error code returned by Kerberos or the server + when a request fails. To interpret the value of this field see the list + of error codes in section 8. Implementations are encouraged to provide + for national language support in the display of error messages. +crealm, cname, srealm and sname + These fields are described above in section 5.3.1. +e-text + This field contains additional text to help explain the error code + associated with the failed request (for example, it might include a + principal name which was unknown). +e-data + This field contains additional data about the error for use by the + application to help it recover from or handle the error. If present, + this field will contain the encoding of a sequence of TypedData + (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED, + in which case it will contain the encoding of a sequence of of padata + fields (METHOD-DATA below), each corresponding to an acceptable + pre-authentication method and optionally containing data for the + method: + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + TYPED-DATA ::= SEQUENCE of TypeData + METHOD-DATA ::= SEQUENCE of PA-DATA + + TypedData ::= SEQUENCE { + data-type[0] INTEGER, + data-value[1] OCTET STRING OPTIONAL + } + + Note that e-data-types have been reserved for all PA data types defined + prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, when + using new PA data types defined in July 1999 or later, the METHOD-DATA + sequence must itself be encapsulated in an TypedData element of type + TD-PADATA. All new implementations interpreting the METHOD-DATA field + for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of + TD-PADATA, extract the typed data field and interpret the use any + elements encapsulated in the TD-PADATA elements as if they were present + in the METHOD-DATA sequence. +e-cksum + This field contains an optional checksum for the KRB-ERROR message. The + checksum is calculated over the Kerberos ASN.1 encoding of the + KRB-ERROR message with the checksum absent. The checksum is then added + to the KRB-ERROR structure and the message is re-encoded. The Checksum + should be calculated using the session key from the ticket granting + ticket or service ticket, where available. If the error is in response + to a TGS or AP request, the checksum should be calculated uing the the + session key from the client's ticket. If the error is in response to an + AS request, then the checksum should be calulated using the client's + secret key ONLY if there has been suitable preauthentication to prove + knowledge of the secret key by the client[33]. If a checksum can not be + computed because the key to be used is not available, no checksum will + be included. + + 6. Encryption and Checksum Specifications + + The Kerberos protocols described in this document are designed to use + stream encryption ciphers, which can be simulated using commonly + available block encryption ciphers, such as the Data Encryption + Standard [DES77], and triple DES variants, in conjunction with block + chaining and checksum methods [DESM80]. Encryption is used to prove the + identities of the network entities participating in message exchanges. + The Key Distribution Center for each realm is trusted by all principals + registered in that realm to store a secret key in confidence. Proof of + knowledge of this secret key is used to verify the authenticity of a + principal. + + The KDC uses the principal's secret key (in the AS exchange) or a + shared session key (in the TGS exchange) to encrypt responses to ticket + requests; the ability to obtain the secret key or session key implies + the knowledge of the appropriate keys and the identity of the KDC. The + ability of a principal to decrypt the KDC response and present a Ticket + and a properly formed Authenticator (generated with the session key + from the KDC response) to a service verifies the identity of the + principal; likewise the ability of the service to extract the session + key from the Ticket and prove its knowledge thereof in a response + verifies the identity of the service. + + The Kerberos protocols generally assume that the encryption used is + secure from cryptanalysis; however, in some cases, the order of fields + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + in the encrypted portions of messages are arranged to minimize the + effects of poorly chosen keys. It is still important to choose good + keys. If keys are derived from user-typed passwords, those passwords + need to be well chosen to make brute force attacks more difficult. + Poorly chosen keys still make easy targets for intruders. + + The following sections specify the encryption and checksum mechanisms + currently defined for Kerberos. The encodings, chaining, and padding + requirements for each are described. For encryption methods, it is + often desirable to place random information (often referred to as a + confounder) at the start of the message. The requirements for a + confounder are specified with each encryption mechanism. + + Some encryption systems use a block-chaining method to improve the the + security characteristics of the ciphertext. However, these chaining + methods often don't provide an integrity check upon decryption. Such + systems (such as DES in CBC mode) must be augmented with a checksum of + the plain-text which can be verified at decryption and used to detect + any tampering or damage. Such checksums should be good at detecting + burst errors in the input. If any damage is detected, the decryption + routine is expected to return an error indicating the failure of an + integrity check. Each encryption type is expected to provide and verify + an appropriate checksum. The specification of each encryption method + sets out its checksum requirements. + + Finally, where a key is to be derived from a user's password, an + algorithm for converting the password to a key of the appropriate type + is included. It is desirable for the string to key function to be + one-way, and for the mapping to be different in different realms. This + is important because users who are registered in more than one realm + will often use the same password in each, and it is desirable that an + attacker compromising the Kerberos server in one realm not obtain or + derive the user's key in another. + + For an discussion of the integrity characteristics of the candidate + encryption and checksum methods considered for Kerberos, the reader is + referred to [SG92]. + + 6.1. Encryption Specifications + + The following ASN.1 definition describes all encrypted messages. The + enc-part field which appears in the unencrypted part of messages in + section 5 is a sequence consisting of an encryption type, an optional + key version number, and the ciphertext. + + EncryptedData ::= SEQUENCE { + etype[0] INTEGER, -- EncryptionType + kvno[1] INTEGER OPTIONAL, + cipher[2] OCTET STRING -- ciphertext + } + + + + etype + This field identifies which encryption algorithm was used to + encipher the cipher. Detailed specifications for selected + encryption types appear later in this section. + kvno + This field contains the version number of the key under which data + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + is encrypted. It is only present in messages encrypted under long + lasting keys, such as principals' secret keys. + cipher + This field contains the enciphered text, encoded as an OCTET + STRING. + The cipher field is generated by applying the specified encryption + algorithm to data composed of the message and algorithm-specific + inputs. Encryption mechanisms defined for use with Kerberos must take + sufficient measures to guarantee the integrity of the plaintext, and we + recommend they also take measures to protect against precomputed + dictionary attacks. If the encryption algorithm is not itself capable + of doing so, the protections can often be enhanced by adding a checksum + and a confounder. + + The suggested format for the data to be encrypted includes a + confounder, a checksum, the encoded plaintext, and any necessary + padding. The msg-seq field contains the part of the protocol message + described in section 5 which is to be encrypted. The confounder, + checksum, and padding are all untagged and untyped, and their length is + exactly sufficient to hold the appropriate item. The type and length is + implicit and specified by the particular encryption type being used + (etype). The format for the data to be encrypted for some methods is + described in the following diagram, but other methods may deviate from + this layour - so long as the definition of the method defines the + layout actually in use. + + +-----------+----------+-------------+-----+ + |confounder | check | msg-seq | pad | + +-----------+----------+-------------+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + CipherText ::= ENCRYPTED SEQUENCE { + confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL, + check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, + msg-seq[2] MsgSequence, + pad UNTAGGED OCTET STRING(pad_length) OPTIONAL + } + + One generates a random confounder of the appropriate length, placing it + in confounder; zeroes out check; calculates the appropriate checksum + over confounder, check, and msg-seq, placing the result in check; adds + the necessary padding; then encrypts using the specified encryption + type and the appropriate key. + + Unless otherwise specified, a definition of an encryption algorithm + that specifies a checksum, a length for the confounder field, or an + octet boundary for padding uses this ciphertext format[36]. Those + fields which are not specified will be omitted. + + In the interest of allowing all implementations using a particular + encryption type to communicate with all others using that type, the + specification of an encryption type defines any checksum that is needed + as part of the encryption process. If an alternative checksum is to be + used, a new encryption type must be defined. + + Some cryptosystems require additional information beyond the key and + the data to be encrypted. For example, DES, when used in + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + cipher-block-chaining mode, requires an initialization vector. If + required, the description for each encryption type must specify the + source of such additional information. 6.2. Encryption Keys + + The sequence below shows the encoding of an encryption key: + + EncryptionKey ::= SEQUENCE { + keytype[0] INTEGER, + keyvalue[1] OCTET STRING + } + + keytype + This field specifies the type of encryption that is to be + performed using the key that follows in the keyvalue field. It + will always correspond to the etype to be used to generate or + decode the EncryptedData. In cases when multiple algorithms use a + common kind of key (e.g., if the encryption algorithm uses an + alternate checksum algorithm for an integrity check, or a + different chaining mechanism), the keytype provides information + needed to determine which algorithm is to be used. + keyvalue + This field contains the key itself, encoded as an octet string. + All negative values for the encryption key type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpreta- tions. + + 6.3. Encryption Systems + + 6.3.1. The NULL Encryption System (null) + + If no encryption is in use, the encryption system is said to be the + NULL encryption system. In the NULL encryption system there is no + checksum, confounder or padding. The ciphertext is simply the + plaintext. The NULL Key is used by the null encryption system and is + zero octets in length, with keytype zero (0). + + 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) + + The des-cbc-crc encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is + applied to the confounder and message sequence (msg-seq) and placed in + the cksum field. DES blocks are 8 bytes. As a result, the data to be + encrypted (the concatenation of confounder, checksum, and message) must + be padded to an 8 byte boundary before encryption. The details of the + encryption of this data are identical to those for the des-cbc-md5 + encryption mode. + + Note that, since the CRC-32 checksum is not collision-proof, an + attacker could use a probabilistic chosen-plaintext attack to generate + a valid message even if a confounder is used [SG92]. The use of + collision-proof checksums is recommended for environments where such + attacks represent a significant threat. The use of the CRC-32 as the + checksum for ticket or authenticator is no longer mandated as an + interoperability requirement for Kerberos Version 5 Specification 1 + (See section 9.1 for specific details). + + 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The des-cbc-md4 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD4 checksum (described in [MD492]) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be padded + to an 8 byte boundary before encryption. The details of the encryption + of this data are identical to those for the des-cbc-md5 encryption + mode. + + 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) + + The des-cbc-md5 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be padded + to an 8 byte boundary before encryption. + + Plaintext and DES ciphtertext are encoded as blocks of 8 octets which + are concatenated to make the 64-bit inputs for the DES algorithms. The + first octet supplies the 8 most significant bits (with the octet's + MSbit used as the DES input block's MSbit, etc.), the second octet the + next 8 bits, ..., and the eighth octet supplies the 8 least significant + bits. + + Encryption under DES using cipher block chaining requires an additional + input in the form of an initialization vector. Unless otherwise + specified, zero should be used as the initialization vector. Kerberos' + use of DES requires an 8 octet confounder. + + The DES specifications identify some 'weak' and 'semi-weak' keys; those + keys shall not be used for encrypting messages for use in Kerberos. + Additionally, because of the way that keys are derived for the + encryption of checksums, keys shall not be used that yield 'weak' or + 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant + F0F0F0F0F0F0F0F0. + + A DES key is 8 octets of data, with keytype one (1). This consists of + 56 bits of key, and 8 parity bits (one per octet). The key is encoded + as a series of 8 octets written in MSB-first order. The bits within the + key are also encoded in MSB order. For example, if the encryption key + is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where + B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the + parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with + B1 as the MSbit). [See the FIPS 81 introduction for reference.] + + String to key transformation + + To generate a DES key from a text string (password), a "salt" is + concatenated to the text string, and then padded with ASCII nulls to an + 8 byte boundary. This "salt" is normally the realm and each component + of the principal's name appended. However, sometimes different salts + are used --- for example, when a realm is renamed, or if a user changes + her username, or for compatibility with Kerberos V4 (whose + string-to-key algorithm uses a null string for the salt). This string + is then fan-folded and eXclusive-ORed with itself to form an 8 byte DES + key. Before eXclusive-ORing a block, every byte is shifted one bit to + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + the left to leave the lowest bit zero. The key is the "corrected" by + correcting the parity on the key, and if the key matches a 'weak' or + 'semi-weak' key as described in the DES specification, it is + eXclusive-ORed with the constant 00000000000000F0. This key is then + used to generate a DES CBC checksum on the initial string (with the + salt appended). The result of the CBC checksum is the "corrected" as + described above to form the result which is return as the key. + Pseudocode follows: + + name_to_default_salt(realm, name) { + s = realm + for(each component in name) { + s = s + component; + } + return s; + } + + key_correction(key) { + fixparity(key); + if (is_weak_key_key(key)) + key = key XOR 0xF0; + return(key); + } + + string_to_key(string,salt) { + + odd = 1; + s = string + salt; + tempkey = NULL; + pad(s); /* with nulls to 8 byte boundary */ + for(8byteblock in s) { + if(odd == 0) { + odd = 1; + reverse(8byteblock) + } + else odd = 0; + left shift every byte in 8byteblock one bit; + tempkey = tempkey XOR 8byteblock; + } + tempkey = key_correction(tempkey); + key = key_correction(DES-CBC-check(s,tempkey)); + return(key); + } + + 6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and + without Key Derivation [Original draft by Marc Horowitz, revisions by + David Miller] + + This encryption type is based on the Triple DES cryptosystem, the + HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key + derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may not + be used in conjunction with the use of Triple DES keys. + + Algorithm Identifiers + + The des3-cbc-hmac-sha1 encryption type has been assigned the value 7. + The des3-cbc-hmac-sha1-kd encryption type, specifying the key + derivation variant of the encryption type, has been assigned the value + 16. The hmac-sha1-des3 checksum type has been assigned the value 13. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The hmac-sha1-des3-kd checksum type, specifying the key derivation + variant of the checksum, has been assigned the value 12. + + Triple DES Key Production + + The EncryptionKey value is 24 octets long. The 7 most significant bits + of each octet contain key bits, and the least significant bit is the + inverse of the xor of the key bits. + + For the purposes of key derivation, the block size is 64 bits, and the + key size is 168 bits. The 168 bits output by key derivation are + converted to an EncryptionKey value as follows. First, the 168 bits are + divided into three groups of 56 bits, which are expanded individually + into 64 bits as follows: + + 1 2 3 4 5 6 7 p + 9 10 11 12 13 14 15 p + 17 18 19 20 21 22 23 p + 25 26 27 28 29 30 31 p + 33 34 35 36 37 38 39 p + 41 42 43 44 45 46 47 p + 49 50 51 52 53 54 55 p + 56 48 40 32 24 16 8 p + + The "p" bits are parity bits computed over the data bits. The output of + the three expansions are concatenated to form the EncryptionKey value. + + When the HMAC-SHA1 of a string is computed, the key is used in the + EncryptedKey form. + + The string-to-key function is used to tranform UNICODE passwords into + DES3 keys. The DES3 string-to-key function relies on the "N-fold" + algorithm, which is detailed in [9]. The description of the N-fold + algorithm in that document is as follows: + o To n-fold a number X, replicate the input value to a length that + is the least common multiple of n and the length of X. Before each + repetition, the input is rotated to the right by 13 bit positions. + The successive n-bit chunks are added together using + 1's-complement addition (that is, addition with end-around carry) + to yield an n-bit result" + o The n-fold algorithm, as with DES string-to-key, is applied to the + password string concatenated with a salt value. The salt value is + derived in the same was as for the DES string-to-key algorithm. + For 3-key triple DES then, the operation will involve a 168-fold + of the input password string. The remainder of the string-to-key + function for DES3 is shown here in pseudocode: + + DES3string-to-key(passwordString, key) + + salt = name_to_default_salt(realm, name) + s = passwordString + salt + tmpKey1 = 168-fold(s) + parityFix(tmpKey1); + if not weakKey(tmpKey1) + /* + * Encrypt temp key in itself with a + * zero initialization vector + * + * Function signature is DES3encrypt(plain, key, iv) + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + * with cipher as the return value + */ + tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec) + /* + * Encrypt resultant temp key in itself with third component + * of first temp key as initialization vector + */ + key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2]) + parityFix(key) + if not weakKey(key) + return SUCCESS + else + return FAILURE + else + return FAILURE + + The weakKey function above is the same weakKey function used with DES + keys, but applied to each of the three single DES keys that comprise + the triple DES key. + + The lengths of UNICODE encoded character strings include the trailing + terminator character (0). + + Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd + + EncryptedData using this type must be generated as described in + [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. + The checksum algorithm is HMAC-SHA1. If the key derivation variant of + the encryption type is used, encryption key values are modified + according to the method under the Key Derivation section below. + + Unless otherwise specified, a zero IV must be used. + + If the length of the input data is not a multiple of the block size, + zero octets must be used to pad the plaintext to the next eight-octet + boundary. The counfounder must be eight random octets (one block). + + Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd + + Checksums using this type must be generated as described in + [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key + derivation variant of the checksum type is used, checksum key values + are modified according to the method under the Key Derivation section + below. + + Key Derivation + + In the Kerberos protocol, cryptographic keys are used in a number of + places. In order to minimize the effect of compromising a key, it is + desirable to use a different key for each of these places. Key + derivation [Horowitz96] can be used to construct different keys for + each operation from the keys transported on the network. For this to be + possible, a small change to the specification is necessary. + + This section specifies a profile for the use of key derivation + [Horowitz96] with Kerberos. For each place where a key is used, a ``key + usage'' must is specified for that purpose. The key, key usage, and + encryption/checksum type together describe the transformation from + plaintext to ciphertext, or plaintext to checksum. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + Key Usage Values + + This is a complete list of places keys are used in the kerberos + protocol, with key usage values and RFC 1510 section numbers: + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the + client key (section 5.4.1) + 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or + application session key), encrypted with the service key + (section 5.4.2) + 3. AS-REP encrypted part (includes tgs session key or application + session key), encrypted with the client key (section 5.4.2) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + session key (section 5.4.1) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + authenticator subkey (section 5.4.1) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed + with the tgs session key (sections 5.3.2, 5.4.1) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs + authenticator subkey), encrypted with the tgs session key + (section 5.3.2) + 8. TGS-REP encrypted part (includes application session key), + encrypted with the tgs session key (section 5.4.2) + 9. TGS-REP encrypted part (includes application session key), + encrypted with the tgs authenticator subkey (section 5.4.2) + 10. AP-REQ Authenticator cksum, keyed with the application session + key (section 5.3.2) + 11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key (section + 5.3.2) + 12. AP-REP encrypted part (includes application session subkey), + encrypted with the application session key (section 5.5.2) + 13. KRB-PRIV encrypted part, encrypted with a key chosen by the + application (section 5.7.1) + 14. KRB-CRED encrypted part, encrypted with a key chosen by the + application (section 5.6.1) + 15. KRB-SAVE cksum, keyed with a key chosen by the application + (section 5.8.1) + 18. KRB-ERROR checksum (e-cksum in section 5.9.1) + 19. AD-KDCIssued checksum (ad-checksum in appendix B.1) + 20. Checksum for Mandatory Ticket Extensions (appendix B.6) + 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) + + Key usage values between 1024 and 2047 (inclusive) are reserved for + application use. Applications should use even values for encryption and + odd values for checksums within this range. + + A few of these key usages need a little clarification. A service which + receives an AP-REQ has no way to know if the enclosed Ticket was part + of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used for + generating a Ticket, whether it is in response to an AS- REQ or + TGS-REQ. + + There might exist other documents which define protocols in terms of + the RFC1510 encryption types or checksum types. Such documents would + not know about key usages. In order that these documents continue to be + meaningful until they are updated, key usages 1024 and 1025 must be + used to derive keys for encryption and checksums, respectively. New + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + protocols defined in terms of the Kerberos encryption and checksum + types should use their own key usages. Key usages may be registered + with IANA to avoid conflicts. Key usages must be unsigned 32 bit + integers. Zero is not permitted. + + Defining Cryptosystems Using Key Derivation + + Kerberos requires that the ciphertext component of EncryptedData be + tamper-resistant as well as confidential. This implies encryption and + integrity functions, which must each use their own separate keys. So, + for each key usage, two keys must be generated, one for encryption + (Ke), and one for integrity (Ki): + + Ke = DK(protocol key, key usage | 0xAA) + Ki = DK(protocol key, key usage | 0x55) + + where the protocol key is from the EncryptionKey from the wire + protocol, and the key usage is represented as a 32 bit integer in + network byte order. The ciphertest must be generated from the plaintext + as follows: + + ciphertext = E(Ke, confounder | plaintext | padding) | + H(Ki, confounder | plaintext | padding) + + The confounder and padding are specific to the encryption algorithm E. + + When generating a checksum only, there is no need for a confounder or + padding. Again, a new key (Kc) must be used. Checksums must be + generated from the plaintext as follows: + + Kc = DK(protocol key, key usage | 0x99) + MAC = H(Kc, plaintext) + + Note that each enctype is described by an encryption algorithm E and a + keyed hash algorithm H, and each checksum type is described by a keyed + hash algorithm H. HMAC, with an appropriate hash, is required for use + as H. + + Key Derivation from Passwords + + The well-known constant for password key derivation must be the byte + string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values + correspond to the ASCII encoding for the string "kerberos". + + 6.4. Checksums + + The following is the ASN.1 definition used for a checksum: + + Checksum ::= SEQUENCE { + cksumtype[0] INTEGER, + checksum[1] OCTET STRING + } + + cksumtype + This field indicates the algorithm used to generate the + accompanying checksum. + checksum + This field contains the checksum itself, encoded as an octet + string. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + Detailed specification of selected checksum types appear later in this + section. Negative values for the checksum type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpretations. + + Checksums used by Kerberos can be classified by two properties: whether + they are collision-proof, and whether they are keyed. It is infeasible + to find two plaintexts which generate the same checksum value for a + collision-proof checksum. A key is required to perturb or initialize + the algorithm in a keyed checksum. To prevent message-stream + modification by an active attacker, unkeyed checksums should only be + used when the checksum and message will be subsequently encrypted (e.g. + the checksums defined as part of the encryption algorithms covered + earlier in this section). + + Collision-proof checksums can be made tamper-proof if the checksum + value is encrypted before inclusion in a message. In such cases, the + composition of the checksum and the encryption algorithm must be + considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using + DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed + checksums, as well as for the encrypted forms of unkeyed + collision-proof checksums, Kerberos prepends a confounder before the + checksum is calculated. + + 6.4.1. The CRC-32 Checksum (crc32) + + The CRC-32 checksum calculates a checksum based on a cyclic redundancy + check as described in ISO 3309 [ISO3309]. The resulting checksum is + four (4) octets in length. The CRC-32 is neither keyed nor + collision-proof. The use of this checksum is not recommended. An + attacker using a probabilistic chosen-plaintext attack as described in + [SG92] might be able to generate an alternative message that satisfies + the checksum. The use of collision-proof checksums is recommended for + environments where such attacks represent a significant threat. + + 6.4.2. The RSA MD4 Checksum (rsa-md4) + + The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm + [MD4-92]. The algorithm takes as input an input message of arbitrary + length and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is + believed to be collision-proof. + + 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) + + The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by + prepending an 8 octet confounder before the text, applying the RSA MD4 + checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be + zero. The resulting checksum is 24 octets long (8 octets of which are + redundant). This checksum is tamper-proof and believed to be + collision-proof. + + The DES specifications identify some weak keys' and 'semi-weak keys'; + those keys shall not be used for generating RSA-MD4 checksums for use + in Kerberos. + + The format for the checksum is described in the follow- ing diagram: + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + + 6.4.4. The RSA MD5 Checksum (rsa-md5) + + The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm. + [MD5-92]. The algorithm takes as input an input message of arbitrary + length and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is + believed to be collision-proof. + + 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) + + The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by + prepending an 8 octet confounder before the text, applying the RSA MD5 + checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should + be zero. The resulting checksum is 24 octets long (8 octets of which + are redundant). This checksum is tamper-proof and believed to be + collision-proof. + + The DES specifications identify some 'weak keys' and 'semi-weak keys'; + those keys shall not be used for encrypting RSA-MD5 checksums for use + in Kerberos. + + The format for the checksum is described in the following diagram: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + + 6.4.6. DES cipher-block chained checksum (des-mac) + + The DES-MAC checksum is computed by prepending an 8 octet confounder to + the plaintext, performing a DES CBC-mode encryption on the result using + the key and an initialization vector of zero, taking the last block of + the ciphertext, prepending the same confounder and encrypting the pair + using DES in cipher-block-chaining (CBC) mode using a a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + be zero. The resulting checksum is 128 bits (16 octets) long, 64 bits + of which are redundant. This checksum is tamper-proof and + collision-proof. + + The format for the checksum is described in the following diagram: + + +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(8) + } + + The DES specifications identify some 'weak' and 'semi-weak' keys; those + keys shall not be used for generating DES-MAC checksums for use in + Kerberos, nor shall a key be used whose variant is 'weak' or + 'semi-weak'. + + 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative + (rsa-md4-des-k) + + The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum + by applying the RSA MD4 checksum algorithm and encrypting the results + using DES in cipher-block-chaining (CBC) mode using a DES key as both + key and initialization vector. The resulting checksum is 16 octets + long. This checksum is tamper-proof and believed to be collision-proof. + Note that this checksum type is the old method for encoding the + RSA-MD4-DES checksum and it is no longer recommended. + + 6.4.8. DES cipher-block chained checksum alternative (des-mac-k) + + The DES-MAC-K checksum is computed by performing a DES CBC-mode + encryption of the plaintext, and using the last block of the ciphertext + as the checksum value. It is keyed with an encryption key and an + initialization vector; any uses which do not specify an additional + initialization vector will use the key as both key and initialization + vector. The resulting checksum is 64 bits (8 octets) long. This + checksum is tamper-proof and collision-proof. Note that this checksum + type is the old method for encoding the DES-MAC checksum and it is no + longer recommended. The DES specifications identify some 'weak keys' + and 'semi-weak keys'; those keys shall not be used for generating + DES-MAC checksums for use in Kerberos. + + 7. Naming Constraints + + 7.1. Realm Names + + Although realm names are encoded as GeneralStrings and although a realm + can technically select any name it chooses, interoperability across + realm boundaries requires agreement on how realm names are to be + assigned, and what information they imply. + + To enforce these conventions, each realm must conform to the + conventions itself, and it must require that any realms with which + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + inter-realm keys are shared also conform to the conventions and require + the same from its neighbors. + + Kerberos realm names are case sensitive. Realm names that differ only + in the case of the characters are not equivalent. There are presently + four styles of realm names: domain, X500, other, and reserved. Examples + of each style follow: + + domain: ATHENA.MIT.EDU (example) + X500: C=US/O=OSF (example) + other: NAMETYPE:rest/of.name=without-restrictions (example) + reserved: reserved, but will not conflict with above + + Domain names must look like domain names: they consist of components + separated by periods (.) and they contain neither colons (:) nor + slashes (/). Domain names must be converted to upper case when used as + realm names. + + X.500 names contain an equal (=) and cannot contain a colon (:) before + the equal. The realm names for X.500 names will be string + representations of the names with components separated by slashes. + Leading and trailing slashes will not be included. + + Names that fall into the other category must begin with a prefix that + contains no equal (=) or period (.) and the prefix must be followed by + a colon (:) and the rest of the name. All prefixes must be assigned + before they may be used. Presently none are assigned. + + The reserved category includes strings which do not fall into the first + three categories. All names in this category are reserved. It is + unlikely that names will be assigned to this category unless there is a + very strong argument for not using the 'other' category. + + These rules guarantee that there will be no conflicts between the + various name styles. The following additional constraints apply to the + assignment of realm names in the domain and X.500 categories: the name + of a realm for the domain or X.500 formats must either be used by the + organization owning (to whom it was assigned) an Internet domain name + or X.500 name, or in the case that no such names are registered, + authority to use a realm name may be derived from the authority of the + parent realm. For example, if there is no domain name for E40.MIT.EDU, + then the administrator of the MIT.EDU realm can authorize the creation + of a realm with that name. + + This is acceptable because the organization to which the parent is + assigned is presumably the organization authorized to assign names to + its children in the X.500 and domain name systems as well. If the + parent assigns a realm name without also registering it in the domain + name or X.500 hierarchy, it is the parent's responsibility to make sure + that there will not in the future exists a name identical to the realm + name of the child unless it is assigned to the same entity as the realm + name. + + 7.2. Principal Names + + As was the case for realm names, conventions are needed to ensure that + all agree on what information is implied by a principal name. The + name-type field that is part of the principal name indicates the kind + of information implied by the name. The name-type should be treated as + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + a hint. Ignoring the name type, no two names can be the same (i.e. at + least one of the components, or the realm, must be different). The + following name types are defined: + + name-type value meaning + + NT-UNKNOWN 0 Name type not known + NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal) + NT-SRV-INST 2 Service and other unique instance (krbtgt) + NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) + NT-SRV-XHST 4 Service with slash-separated host name components + NT-UID 5 Unique ID + NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] + + When a name implies no information other than its uniqueness at a + particular time the name type PRINCIPAL should be used. The principal + name type should be used for users, and it might also be used for a + unique server. If the name is a unique machine generated ID that is + guaranteed never to be reassigned then the name type of UID should be + used (note that it is generally a bad idea to reassign names of any + type since stale entries might remain in access control lists). + + If the first component of a name identifies a service and the remaining + components identify an instance of the service in a server specified + manner, then the name type of SRV-INST should be used. An example of + this name type is the Kerberos ticket-granting service whose name has a + first component of krbtgt and a second component identifying the realm + for which the ticket is valid. + + If instance is a single component following the service name and the + instance identifies the host on which the server is running, then the + name type SRV-HST should be used. This type is typically used for + Internet services such as telnet and the Berkeley R commands. If the + separate components of the host name appear as successive components + following the name of the service, then the name type SRV-XHST should + be used. This type might be used to identify servers on hosts with + X.500 names where the slash (/) might otherwise be ambiguous. + + A name type of NT-X500-PRINCIPAL should be used when a name from an + X.509 certificiate is translated into a Kerberos name. The encoding of + the X.509 name as a Kerberos principal shall conform to the encoding + rules specified in RFC 2253. + + A name type of UNKNOWN should be used when the form of the name is not + known. When comparing names, a name of type UNKNOWN will match + principals authenticated with names of any type. A principal + authenticated with a name of type UNKNOWN, however, will only match + other names of type UNKNOWN. + + Names of any type with an initial component of 'krbtgt' are reserved + for the Kerberos ticket granting service. See section 8.2.3 for the + form of such names. + + 7.2.1. Name of server principals + + The principal identifier for a server on a host will generally be + composed of two parts: (1) the realm of the KDC with which the server + is registered, and (2) a two-component name of type NT-SRV-HST if the + host name is an Internet domain name or a multi-component name of type + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + NT-SRV-XHST if the name of the host is of a form such as X.500 that + allows slash (/) separators. The first component of the two- or + multi-component name will identify the service and the latter + components will identify the host. Where the name of the host is not + case sensitive (for example, with Internet domain names) the name of + the host must be lower case. If specified by the application protocol + for services such as telnet and the Berkeley R commands which run with + system privileges, the first component may be the string 'host' instead + of a service specific identifier. When a host has an official name and + one or more aliases, the official name of the host must be used when + constructing the name of the server principal. + + 8. Constants and other defined values + + 8.1. Host address types + + All negative values for the host address type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpretations. + + The values of the types for the following addresses are chosen to match + the defined address family constants in the Berkeley Standard + Distributions of Unix. They can be found in with symbolic names AF_xxx + (where xxx is an abbreviation of the address family name). + + Internet (IPv4) Addresses + + Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in + MSB order. The type of IPv4 addresses is two (2). + + Internet (IPv6) Addresses [Westerlund] + + IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. + The type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. + The following addresses (see [RFC1884]) MUST not appear in any Kerberos + packet: + o the Unspecified Address + o the Loopback Address + o Link-Local addresses + IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. + + CHAOSnet addresses + + CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB + order. The type of CHAOSnet addresses is five (5). + + ISO addresses + + ISO addresses are variable-length. The type of ISO addresses is seven + (7). + + Xerox Network Services (XNS) addresses + + XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. + The type of XNS addresses is six (6). + + AppleTalk Datagram Delivery Protocol (DDP) addresses + + AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + network number. The first octet of the address is the node number; the + remaining two octets encode the network number in MSB order. The type + of AppleTalk DDP addresses is sixteen (16). + + DECnet Phase IV addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. + The type of DECnet Phase IV addresses is twelve (12). + + Netbios addresses + + Netbios addresses are 16-octet addresses typically composed of 1 to 15 + characters, trailing blank (ascii char 20) filled, with a 16th octet of + 0x0. The type of Netbios addresses is 20 (0x14). + + 8.2. KDC messages + + 8.2.1. UDP/IP transport + + When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using + UDP IP transport, the client shall send a UDP datagram containing only + an encoding of the request to port 88 (decimal) at the KDC's IP + address; the KDC will respond with a reply datagram containing only an + encoding of the reply message (either a KRB_ERROR or a KRB_KDC_REP) to + the sending port at the sender's IP address. Kerberos servers + supporting IP transport must accept UDP requests on port 88 (decimal). + The response to a request made through UDP/IP transport must also use + UDP/IP transport. + + 8.2.2. TCP/IP transport [Westerlund,Danielsson] + + Kerberos servers (KDC's) should accept TCP requests on port 88 + (decimal) and clients should support the sending of TCP requests on + port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC over + a TCP stream, a new connection will be established for each + authentication exchange (request and response). The KRB_KDC_REP or + KRB_ERROR message will be returned to the client on the same TCP stream + that was established for the request. The response to a request made + through TCP/IP transport must also use TCP/IP transport. Implementors + should note that some extentions to the Kerberos protocol will not work + if any implementation not supporting the TCP transport is involved + (client or KDC). Implementors are strongly urged to support the TCP + transport on both the client and server and are advised that the + current notation of "should" support will likely change in the future + to must support. The KDC may close the TCP stream after sending a + response, but may leave the stream open if it expects a followup - in + which case it may close the stream at any time if resource constratints + or other factors make it desirable to do so. Care must be taken in + managing TCP/IP connections with the KDC to prevent denial of service + attacks based on the number of TCP/IP connections with the KDC that + remain open. If multiple exchanges with the KDC are needed for certain + forms of preauthentication, multiple TCP connections may be required. A + client may close the stream after receiving response, and should close + the stream if it does not expect to send followup messages. The client + must be prepared to have the stream closed by the KDC at anytime, in + which case it must simply connect again when it is ready to send + subsequent messages. + + The first four octets of the TCP stream used to transmit the request + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + request will encode in network byte order the length of the request + (KRB_KDC_REQ), and the length will be followed by the request itself. + The response will similarly be preceeded by a 4 octet encoding in + network byte order of the length of the KRB_KDC_REP or the KRB_ERROR + message and will be followed by the KRB_KDC_REP or the KRB_ERROR + response. If the sign bit is set on the integer represented by the + first 4 octets, then the next 4 octets will be read, extending the + length of the field by another 4 octets (less the sign bit which is + reserved for future expansion). + + 8.2.3. OSI transport + + During authentication of an OSI client to an OSI server, the mutual + authentication of an OSI server to an OSI client, the transfer of + credentials from an OSI client to an OSI server, or during exchange of + private or integrity checked messages, Kerberos protocol messages may + be treated as opaque objects and the type of the authentication + mechanism will be: + + OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)} + + Depending on the situation, the opaque object will be an authentication + header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe + message (KRB_SAFE), a private message (KRB_PRIV), or a credentials + message (KRB_CRED). The opaque data contains an application code as + specified in the ASN.1 description for each message. The application + code may be used by Kerberos to determine the message type. + + 8.2.3. Name of the TGS + + The principal identifier of the ticket-granting service shall be + composed of three parts: (1) the realm of the KDC issuing the TGS + ticket (2) a two-part name of type NT-SRV-INST, with the first part + "krbtgt" and the second part the name of the realm which will accept + the ticket-granting ticket. For example, a ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" + (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), + ("krbtgt", "MIT.EDU") (name). + + 8.3. Protocol constants and associated values + + The following tables list constants used in the protocol and defines + their meanings. Ranges are specified in the "specification" section + that limit the values of constants for which values are defined here. + This allows implementations to make assumptions about the maximum + values that will be received for these constants. Implementation + receiving values outside the range specified in the "specification" + section may reject the request, but they must recover cleanly. + + Encryption type etype value block size minimum pad size confounder size + NULL 0 1 0 0 + des-cbc-crc 1 8 4 8 + des-cbc-md4 2 8 0 8 + des-cbc-md5 3 8 0 8 + <reserved> 4 + des3-cbc-md5 5 8 0 8 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + <reserved> 6 + des3-cbc-sha1 7 8 0 8 + dsaWithSHA1-CmsOID 9 (pkinit) + md5WithRSAEncryption-CmsOID 10 (pkinit) + sha1WithRSAEncryption-CmsOID 11 (pkinit) + rc2CBC-EnvOID 12 (pkinit) + rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) + rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) + des-ede3-cbc-Env-OID 15 (pkinit) + des3-cbc-sha1-kd 16 (Tom Yu) + rc4-hmac 23 (swift) + rc4-hmac-exp 24 (swift) + + ENCTYPE_PK_CROSS 48 (reserved for pkcross) + <reserved> 0x8003 + + Checksum type sumtype value checksum size + CRC32 1 4 + rsa-md4 2 16 + rsa-md4-des 3 24 + des-mac 4 16 + des-mac-k 5 8 + rsa-md4-des-k 6 16 (drop rsa ?) + rsa-md5 7 16 (drop rsa ?) + rsa-md5-des 8 24 (drop rsa ?) + rsa-md5-des3 9 24 (drop rsa ?) + hmac-sha1-des3-kd 12 20 + hmac-sha1-des3 13 20 + + padata type padata-type value + + PA-TGS-REQ 1 + PA-ENC-TIMESTAMP 2 + PA-PW-SALT 3 + <reserved> 4 + PA-ENC-UNIX-TIME 5 (depricated) + PA-SANDIA-SECUREID 6 + PA-SESAME 7 + PA-OSF-DCE 8 + PA-CYBERSAFE-SECUREID 9 + PA-AFS3-SALT 10 + PA-ETYPE-INFO 11 + PA-SAM-CHALLENGE 12 (sam/otp) + PA-SAM-RESPONSE 13 (sam/otp) + PA-PK-AS-REQ 14 (pkinit) + PA-PK-AS-REP 15 (pkinit) + PA-USE-SPECIFIED-KVNO 20 + PA-SAM-REDIRECT 21 (sam/otp) + PA-GET-FROM-TYPED-DATA 22 + PA-SAM-ETYPE-INFO 23 (sam/otp) + +data-type value form of typed-data + +<reserved> 1-21 +TD-PADATA 22 +TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS +TD-KRB-PRINCIPAL 102 +TD-KRB-REALM 103 +TD-TRUSTED-CERTIFIERS 104 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +TD-CERTIFICATE-INDEX 105 + +authorization data type ad-type value +AD-IF-RELEVANT 1 +AD-INTENDED-FOR-SERVER 2 +AD-INTENDED-FOR-APPLICATION-CLASS 3 +AD-KDC-ISSUED 4 +AD-OR 5 +AD-MANDATORY-TICKET-EXTENSIONS 6 +AD-IN-TICKET-EXTENSIONS 7 +reserved values 8-63 +OSF-DCE 64 +SESAME 65 +AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) + +Ticket Extension Types + +TE-TYPE-NULL 0 Null ticket extension +TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data +<reserved> 2 TE-TYPE-PKCROSS-KDC (I have reservations) +TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket +TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp +<reserved> 5 TE-TYPE-DEST-HOST (I have reservations) + +alternate authentication type method-type value +reserved values 0-63 +ATT-CHALLENGE-RESPONSE 64 + +transited encoding type tr-type value +DOMAIN-X500-COMPRESS 1 +reserved values all others + +Label Value Meaning or MIT code + +pvno 5 current Kerberos protocol version number + +message types + +KRB_AS_REQ 10 Request for initial authentication +KRB_AS_REP 11 Response to KRB_AS_REQ request +KRB_TGS_REQ 12 Request for authentication based on TGT +KRB_TGS_REP 13 Response to KRB_TGS_REQ request +KRB_AP_REQ 14 application request to server +KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL +KRB_SAFE 20 Safe (checksummed) application message +KRB_PRIV 21 Private (encrypted) application message +KRB_CRED 22 Private (encrypted) message to forward credentials +KRB_ERROR 30 Error response + +name types + +KRB_NT_UNKNOWN 0 Name type not known +KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users +KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) +KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) +KRB_NT_SRV_XHST 4 Service with host as remaining components +KRB_NT_UID 5 Unique ID +KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +error codes + +KDC_ERR_NONE 0 No error +KDC_ERR_NAME_EXP 1 Client's entry in database has expired +KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired +KDC_ERR_BAD_PVNO 3 Requested prot vers number not supported +KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key +KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key +KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database +KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database +KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database +KDC_ERR_NULL_KEY 9 The client or server has a null key +KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating +KDC_ERR_NEVER_VALID 11 Requested start time is later than end time +KDC_ERR_POLICY 12 KDC policy rejects request +KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option +KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type +KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type +KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type +KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type +KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked +KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked +KDC_ERR_TGT_REVOKED 20 TGT has been revoked +KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later +KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later +KDC_ERR_KEY_EXPIRED 23 Password has expired - change password +KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid +KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] +KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match +KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only +KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path +KDC_ERR_SVC_UNAVAILABLE 29 A service is not available +KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed +KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired +KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid +KRB_AP_ERR_REPEAT 34 Request is a replay +KRB_AP_ERR_NOT_US 35 The ticket isn't for us +KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match +KRB_AP_ERR_SKEW 37 Clock skew too great +KRB_AP_ERR_BADADDR 38 Incorrect net address +KRB_AP_ERR_BADVERSION 39 Protocol version mismatch +KRB_AP_ERR_MSG_TYPE 40 Invalid msg type +KRB_AP_ERR_MODIFIED 41 Message stream modified +KRB_AP_ERR_BADORDER 42 Message out of order +KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available +KRB_AP_ERR_NOKEY 45 Service key not available +KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed +KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction +KRB_AP_ERR_METHOD 48 Alternative authentication method required +KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message +KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message +KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path +KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP +KRB_ERR_GENERIC 60 Generic error (description in e-text) +KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation +KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) +KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) +KDC_ERROR_INVALID_SIG 64 (pkinit) +KDC_ERR_KEY_TOO_WEAK 65 (pkinit) + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) +KRB_AP_ERR_NO_TGT 67 (user-to-user) +KDC_ERR_WRONG_REALM 68 (user-to-user) +KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) +KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) +KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) +KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) +KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) +KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) +KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) +KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) + + 9. Interoperability requirements + + Version 5 of the Kerberos protocol supports a myriad of options. Among + these are multiple encryption and checksum types, alternative encoding + schemes for the transited field, optional mechanisms for + pre-authentication, the handling of tickets with no addresses, options + for mutual authentication, user to user authentication, support for + proxies, forwarding, postdating, and renewing tickets, the format of + realm names, and the handling of authorization data. + + In order to ensure the interoperability of realms, it is necessary to + define a minimal configuration which must be supported by all + implementations. This minimal configuration is subject to change as + technology does. For example, if at some later date it is discovered + that one of the required encryption or checksum algorithms is not + secure, it will be replaced. + + 9.1. Specification 2 + + This section defines the second specification of these options. + Implementations which are configured in this way can be said to support + Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) + may be found in RFC1510. + + Transport + + TCP/IP and UDP/IP transport must be supported by KDCs claiming + conformance to specification 2. Kerberos clients claiming conformance + to specification 2 must support UDP/IP transport for messages with the + KDC and should support TCP/IP transport. + + Encryption and checksum methods + + The following encryption and checksum mechanisms must be supported. + Implementations may support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to also support them: This list is to be determined. + + Encryption: DES-CBC-MD5, one triple des variant (tbd) + Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd) + + Realm Names + + All implementations must understand hierarchical realms in both the + Internet Domain and the X.500 style. When a ticket granting ticket for + an unknown realm is requested, the KDC must be able to determine the + names of the intermediate realms between the KDCs realm and the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + requested realm. + + Transited field encoding + + DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. + Alternative encodings may be supported, but they may be used only when + that encoding is supported by ALL intermediate realms. + + Pre-authentication methods + + The TGS-REQ method must be supported. The TGS-REQ method is not used on + the initial request. The PA-ENC-TIMESTAMP method must be supported by + clients but whether it is enabled by default may be determined on a + realm by realm basis. If not used in the initial request and the error + KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an + acceptable method, the client should retry the initial request using + the PA-ENC-TIMESTAMP preauthentication method. Servers need not support + the PA-ENC-TIMESTAMP method, but if not supported the server should + ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a + request. + + Mutual authentication + + Mutual authentication (via the KRB_AP_REP message) must be supported. + + Ticket addresses and flags + + All KDC's must pass on tickets that carry no addresses (i.e. if a TGT + contains no addresses, the KDC will return derivative tickets), but + each realm may set its own policy for issuing such tickets, and each + application server will set its own policy with respect to accepting + them. + + Proxies and forwarded tickets must be supported. Individual realms and + application servers can set their own policy on when such tickets will + be accepted. + + All implementations must recognize renewable and postdated tickets, but + need not actually implement them. If these options are not supported, + the starttime and endtime in the ticket shall specify a ticket's entire + useful life. When a postdated ticket is decoded by a server, all + implementations shall make the presence of the postdated flag visible + to the calling server. + + User-to-user authentication + + Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC + option) must be provided by implementations, but individual realms may + decide as a matter of policy to reject such requests on a per-principal + or realm-wide basis. + + Authorization data + + Implementations must pass all authorization data subfields from + ticket-granting tickets to any derivative tickets unless directed to + suppress a subfield as part of the definition of that registered + subfield type (it is never incorrect to pass on a subfield, and no + registered subfield types presently specify suppression at the KDC). + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + Implementations must make the contents of any authorization data + subfields available to the server when a ticket is used. + Implementations are not required to allow clients to specify the + contents of the authorization data fields. + + Constant ranges + + All protocol constants are constrained to 32 bit (signed) values unless + further constrained by the protocol definition. This limit is provided + to allow implementations to make assumptions about the maximum values + that will be received for these constants. Implementation receiving + values outside this range may reject the request, but they must recover + cleanly. + + 9.2. Recommended KDC values + + Following is a list of recommended values for a KDC implementation, + based on the list of suggested configuration constants (see section + 4.4). + + minimum lifetime 5 minutes + maximum renewable lifetime 1 week + maximum ticket lifetime 1 day + empty addresses only when suitable restrictions appear + in authorization data + proxiable, etc. Allowed. + + 10. REFERENCES + + [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- + cation Service for Computer Networks," IEEE Communica- + tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). + + [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. + Saltzer, Section E.2.1: Kerberos Authentication and + Authorization System, M.I.T. Project Athena, Cambridge, + Massachusetts (December 21, 1987). + + [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- + beros: An Authentication Service for Open Network Sys- + tems," pp. 191-202 in Usenix Conference Proceedings, + Dallas, Texas (February, 1988). + + [NS78] Roger M. Needham and Michael D. Schroeder, "Using + Encryption for Authentication in Large Networks of Com- + puters," Communications of the ACM, Vol. 21(12), + pp. 993-999 (December, 1978). + + [DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- + stamps in Key Distribution Protocols," Communications + of the ACM, Vol. 24(8), pp. 533-536 (August 1981). + + [KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, + "The Evolution of the Kerberos Authentication Service," + in an IEEE Computer Society Text soon to be published + (June 1992). + + [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and + Accounting for Distributed Systems," in Proceedings of + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + the 13th International Conference on Distributed Com- + puting Systems, Pittsburgh, PA (May, 1993). + + [DS90] Don Davis and Ralph Swick, "Workstation Services and + Kerberos Authentication at Project Athena," Technical + Memorandum TM-424, MIT Laboratory for Computer Science + (February 1990). + + [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- + merfeld, and K. Raeburn, Section E.1: Service Manage- + ment System, M.I.T. Project Athena, Cambridge, Mas- + sachusetts (1987). + + [X509-88] CCITT, Recommendation X.509: The Directory Authentica- + tion Framework, December 1988. + + [Pat92]. J. Pato, Using Pre-Authentication to Avoid Password + Guessing Attacks, Open Software Foundation DCE Request + for Comments 26 (December 1992). + + [DES77] National Bureau of Standards, U.S. Department of Com- + merce, "Data Encryption Standard," Federal Information + Processing Standards Publication 46, Washington, DC + (1977). + + [DESM80] National Bureau of Standards, U.S. Department of Com- + merce, "DES Modes of Operation," Federal Information + Processing Standards Publication 81, Springfield, VA + (December 1980). + + [SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message + Integrity in Cryptographic Protocols," in Proceedings + of the IEEE Symposium on Research in Security and + Privacy, Oakland, California (May 1992). + + [IS3309] International Organization for Standardization, "ISO + Information Processing Systems - Data Communication - + High-Level Data Link Control Procedure - Frame Struc- + ture," IS 3309 (October 1984). 3rd Edition. + + [MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC + 1320, MIT Laboratory for Computer Science (April + 1992). + + [MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC + 1321, MIT Laboratory for Computer Science (April + 1992). + + [KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication," Working Draft + draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). + + [Horowitz96] Horowitz, M., "Key Derivation for Authentication, + Integrity, and Privacy", draft-horowitz-key-derivation-02.txt, + August 1998. + + [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- + horowitz-kerb-key-derivation-01.txt, September 1998. + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac- + md5-01.txt, August, 1996. + + A. Pseudo-code for protocol processing + + This appendix provides pseudo-code describing how the messages are to + be constructed and interpreted by clients and servers. + + A.1. KRB_AS_REQ generation + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_AS_REQ */ + + if(pa_enc_timestamp_required) then + request.padata.padata-type = PA-ENC-TIMESTAMP; + get system_time; + padata-body.patimestamp,pausec = system_time; + encrypt padata-body into request.padata.padata-value + using client.key; /* derived from password */ + endif + + body.kdc-options := users's preferences; + body.cname := user's name; + body.realm := user's realm; + body.sname := service's name; /* usually "krbtgt", + "localrealm" */ + + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + omit body.enc-authorization-data; + request.req-body := body; + + kerberos := lookup(name of local kerberos server (or servers)); + send(packet,kerberos); + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.2. KRB_AS_REQ verification and KRB_AS_REP generation + + decode message into req; + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + client := lookup(req.cname,req.realm); + server := lookup(req.sname,req.realm); + + get system_time; + kdc_time := system_time.seconds; + + if (!client) then + /* no client in Database */ + error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); + endif + if (!server) then + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + + if(client.pa_enc_timestamp_required and + pa_enc_timestamp not present) then + error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); + endif + + if(pa_enc_timestamp present) then + decrypt req.padata-value into decrypted_enc_timestamp + using client.key; + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + if(decrypted_enc_timestamp is not within allowable skew) + then + error_out(KDC_ERR_PREAUTH_FAILED); + endif + if(decrypted_enc_timestamp and usec is replay) + error_out(KDC_ERR_PREAUTH_FAILED); + endif + add decrypted_enc_timestamp and usec to replay cache; + endif + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := req.srealm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + if (req.kdc-options.FORWARDABLE is set) then + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.PROXIABLE is set) then + set new_tkt.flags.PROXIABLE; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + set new_tkt.flags.MAY-POSTDATE; + endif + if ((req.kdc-options.RENEW is set) or + (req.kdc-options.VALIDATE is set) or + (req.kdc-options.PROXY is set) or + (req.kdc-options.FORWARDED is set) or + (req.kdc-options.ENC-TKT-IN-SKEY is set)) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.session := random_session_key(); + new_tkt.cname := req.cname; + new_tkt.crealm := req.crealm; + new_tkt.transited := empty_transited_field(); + + new_tkt.authtime := kdc_time; + + if (req.kdc-options.POSTDATED is set) then + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + new_tkt.starttime := req.from; + else + omit new_tkt.starttime; /* treated as authtime when omitted */ + endif + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + + new_tkt.endtime := min(till, + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till)) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := req.till; + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if (req.kdc-options.RENEWABLE is set) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + new_tkt.starttime+client.max_rlife, + new_tkt.starttime+server.max_rlife, + new_tkt.starttime+max_rlife_for_realm); + else + omit new_tkt.renew-till; /* only present if RENEWABLE */ + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + endif + + if (req.addresses) then + new_tkt.caddr := req.addresses; + else + omit new_tkt.caddr; + endif + + new_tkt.authorization_data := empty_authorization_data(); + + encode to-be-encrypted part of ticket into OCTET STRING; + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, server.p_kvno; + + /* Start processing the response */ + + resp.pvno := 5; + resp.msg-type := KRB_AS_REP; + resp.cname := req.cname; + resp.crealm := req.realm; + resp.ticket := new_tkt; + + resp.key := new_tkt.session; + resp.last-req := fetch_last_request_info(client); + resp.nonce := req.nonce; + resp.key-expiration := client.expiration; + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + resp.realm := new_tkt.realm; + resp.sname := new_tkt.sname; + + resp.caddr := new_tkt.caddr; + + encode body of reply into OCTET STRING; + + resp.enc-part := encrypt OCTET STRING + using use_etype, client.key, client.p_kvno; + send(resp); + + A.3. KRB_AS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then + set pa_enc_timestamp_required; + goto KRB_AS_REQ; + endif + process_error(resp); + return; + endif + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + /* On error, discard the response, and zero the session key */ + /* from the response immediately */ + + key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, + resp.padata); + unencrypted part of resp := decode of decrypt of resp.enc-part + using resp.enc-part.etype and key; + zero(key); + + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + if near(resp.princ_exp) then + print(warning message); + endif + save_for_later(ticket,session,client,server,times,flags); + + A.4. KRB_AS_REP and KRB_TGS_REP common checks + + if (decryption_error() or + (req.cname != resp.cname) or + (req.realm != resp.crealm) or + (req.sname != resp.sname) or + (req.realm != resp.realm) or + (req.nonce != resp.nonce) or + (req.addresses != resp.caddr)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + /* make sure no flags are set that shouldn't be, and that all that */ + /* should be are set */ + if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.from = 0) and + (resp.starttime is not within allowable skew)) then + destroy resp.key; + return KRB_AP_ERR_SKEW; + endif + if ((req.from != 0) and (req.from != resp.starttime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + if ((req.till != 0) and (resp.endtime > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (req.rtime != 0) and (resp.renew-till > req.rtime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if ((req.kdc-options.RENEWABLE-OK is set) and + (resp.flags.RENEWABLE) and + (req.till != 0) and + (resp.renew-till > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + A.5. KRB_TGS_REQ generation + + /* Note that make_application_request might have to recursivly */ + /* call this routine to get the appropriate ticket-granting ticket */ + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_TGS_REQ */ + + body.kdc-options := users's preferences; + /* If the TGT is not for the realm of the end-server */ + /* then the sname will be for a TGT for the end-realm */ + /* and the realm of the requested ticket (body.realm) */ + /* will be that of the TGS to which the TGT we are */ + /* sending applies */ + body.sname := service's name; + body.realm := service's realm; + + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + + body.enc-authorization-data := user-supplied data; + if (body.kdc-options.ENC-TKT-IN-SKEY) then + body.additional-tickets_ticket := second TGT; + endif + + request.req-body := body; + check := generate_checksum (req.body,checksumtype); + + request.padata[0].padata-type := PA-TGS-REQ; + request.padata[0].padata-value := create a KRB_AP_REQ using + the TGT and checksum + + /* add in any other padata as required/supplied */ + + kerberos := lookup(name of local kerberose server (or servers)); + send(packet,kerberos); + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation + + /* note that reading the application request requires first + determining the server for which a ticket was issued, and + choosing the correct key for decryption. The name of the + server appears in the plaintext part of the ticket. */ + + if (no KRB_AP_REQ in req.padata) then + error_out(KDC_ERR_PADATA_TYPE_NOSUPP); + endif + verify KRB_AP_REQ in req.padata; + + /* Note that the realm in which the Kerberos server is + operating is determined by the instance from the + ticket-granting ticket. The realm in the ticket-granting + ticket is the realm under which the ticket granting + ticket was issued. It is possible for a single Kerberos + server to support more than one realm. */ + + auth_hdr := KRB_AP_REQ; + tgt := auth_hdr.ticket; + + if (tgt.sname is not a TGT for local realm and is not req.sname) + then + error_out(KRB_AP_ERR_NOT_US); + + realm := realm_tgt_is_for(tgt); + + decode remainder of request; + + if (auth_hdr.authenticator.cksum is missing) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + if (auth_hdr.authenticator.cksum type is not supported) then + error_out(KDC_ERR_SUMTYPE_NOSUPP); + endif + if (auth_hdr.authenticator.cksum is not both collision-proof + and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + set computed_checksum := checksum(req); + if (computed_checksum != auth_hdr.authenticatory.cksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + server := lookup(req.sname,realm); + + if (!server) then + if (is_foreign_tgt_name(req.sname)) then + server := best_intermediate_tgs(req.sname); + else + /* no server in Database */ + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + endif + + session := generate_random_session_key(); + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := realm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + new_tkt.caddr := tgt.caddr; + resp.caddr := NULL; /* We only include this if they change */ + if (req.kdc-options.FORWARDABLE is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.FORWARDED is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDED; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + if (tgt.flags.FORWARDED is set) then + set new_tkt.flags.FORWARDED; + endif + + if (req.kdc-options.PROXIABLE is set) then + if (tgt.flags.PROXIABLE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXIABLE; + endif + if (req.kdc-options.PROXY is set) then + if (tgt.flags.PROXIABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXY; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + if (tgt.flags.MAY-POSTDATE is reset) + error_out(KDC_ERR_BADOPTION); + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + endif + set new_tkt.flags.MAY-POSTDATE; + endif + if (req.kdc-options.POSTDATED is set) then + if (tgt.flags.MAY-POSTDATE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + new_tkt.starttime := req.from; + endif + + if (req.kdc-options.VALIDATE is set) then + if (tgt.flags.INVALID is reset) then + error_out(KDC_ERR_POLICY); + endif + if (tgt.starttime > kdc_time) then + error_out(KRB_AP_ERR_NYV); + endif + if (check_hot_list(tgt)) then + error_out(KRB_AP_ERR_REPEAT); + endif + tkt := tgt; + reset new_tkt.flags.INVALID; + endif + + if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, + and those already processed) is set) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.authtime := tgt.authtime; + + if (req.kdc-options.RENEW is set) then + /* Note that if the endtime has already passed, the ticket would */ + /* have been rejected in the initial authentication stage, so */ + /* there is no need to check again here */ + if (tgt.flags.RENEWABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + if (tgt.renew-till < kdc_time) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + tkt := tgt; + new_tkt.starttime := kdc_time; + old_life := tgt.endttime - tgt.starttime; + new_tkt.endtime := min(tgt.renew-till, + new_tkt.starttime + old_life); + else + new_tkt.starttime := kdc_time; + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + new_tkt.endtime := min(till, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm, + tgt.endtime); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till) and + (tgt.flags.RENEWABLE is set) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := min(req.till, tgt.renew-till); + endif + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (tgt.flags.RENEWABLE is set)) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + new_tkt.starttime+client.max_rlife, + new_tkt.starttime+server.max_rlife, + new_tkt.starttime+max_rlife_for_realm, + tgt.renew-till); + else + new_tkt.renew-till := OMIT; /* leave the + renew-till field out */ + endif + if (req.enc-authorization-data is present) then + decrypt req.enc-authorization-data into + decrypted_authorization_data + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + endif + new_tkt.authorization_data := + req.auth_hdr.ticket.authorization_data + + decrypted_authorization_data; + + new_tkt.key := session; + new_tkt.crealm := tgt.crealm; + new_tkt.cname := req.auth_hdr.ticket.cname; + + if (realm_tgt_is_for(tgt) := tgt.realm) then + /* tgt issued by local realm */ + new_tkt.transited := tgt.transited; + else + /* was issued for this realm by some other realm */ + if (tgt.transited.tr-type not supported) then + error_out(KDC_ERR_TRTYPE_NOSUPP); + endif + new_tkt.transited := + compress_transited(tgt.transited + tgt.realm) + /* Don't check tranited field if TGT for foreign realm, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + * or requested not to check */ + if (is_not_foreign_tgt_name(new_tkt.server) + && req.kdc-options.DISABLE-TRANSITED-CHECK not + set) then + /* Check it, so end-server does not have to + * but don't fail, end-server may still accept it */ + if (check_transited_field(new_tkt.transited) == OK) + set new_tkt.flags.TRANSITED-POLICY-CHECKED; + endif + endif + endif + + encode encrypted part of new_tkt into OCTET STRING; + if (req.kdc-options.ENC-TKT-IN-SKEY is set) then + if (server not specified) then + server = req.second_ticket.client; + endif + if ((req.second_ticket is not a TGT) or + (req.second_ticket.client != server)) then + error_out(KDC_ERR_POLICY); + endif + + new_tkt.enc-part := encrypt OCTET STRING using + using etype_for_key(second-ticket.key), + second-ticket.key; + else + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), + server.key, server.p_kvno; + endif + + resp.pvno := 5; + resp.msg-type := KRB_TGS_REP; + resp.crealm := tgt.crealm; + resp.cname := tgt.cname; + resp.ticket := new_tkt; + + resp.key := session; + resp.nonce := req.nonce; + resp.last-req := fetch_last_request_info(client); + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + omit resp.key-expiration; + + resp.sname := new_tkt.sname; + resp.realm := new_tkt.realm; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + encode body of reply into OCTET STRING; + + if (req.padata.authenticator.subkey) + resp.enc-part := encrypt OCTET STRING using use_etype, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + req.padata.authenticator.subkey; + else resp.enc-part := encrypt OCTET STRING using + use_etype, tgt.key; + + send(resp); + + A.7. KRB_TGS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + process_error(resp); + return; + endif + + /* On error, discard the response, and zero the session key from + the response immediately */ + + if (req.padata.authenticator.subkey) + unencrypted part of resp := decode of decrypt of + resp.enc-part + using resp.enc-part.etype and subkey; + else unencrypted part of resp := decode of decrypt of + resp.enc-part + using resp.enc-part.etype and + tgt's session key; + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + check authorization_data as necessary; + save_for_later(ticket,session,client,server,times,flags); + + A.8. Authenticator generation + + body.authenticator-vno := authenticator vno; /* = 5 */ + body.cname, body.crealm := client name; + if (supplying checksum) then + body.cksum := checksum; + endif + get system_time; + body.ctime, body.cusec := system_time; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + A.9. KRB_AP_REQ generation + + obtain ticket and session_key from cache; + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REQ */ + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if (desired(MUTUAL_AUTHENTICATION)) then + set packet.ap-options.MUTUAL-REQUIRED; + else + reset packet.ap-options.MUTUAL-REQUIRED; + endif + if (using session key for ticket) then + set packet.ap-options.USE-SESSION-KEY; + else + reset packet.ap-options.USE-SESSION-KEY; + endif + packet.ticket := ticket; /* ticket */ + generate authenticator; + encode authenticator into OCTET STRING; + encrypt OCTET STRING into packet.authenticator using session_key; + + A.10. KRB_AP_REQ verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REQ) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.ticket.tkt_vno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.ap_options.USE-SESSION-KEY is set) then + retrieve session key from ticket-granting ticket for + packet.ticket.{sname,srealm,enc-part.etype}; + else + retrieve service key for + packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; + endif + if (no_key_available) then + if (cannot_find_specified_skvno) then + error_out(KRB_AP_ERR_BADKEYVER); + else + error_out(KRB_AP_ERR_NOKEY); + endif + endif + decrypt packet.ticket.enc-part into decr_ticket using + retrieved key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + decrypt packet.authenticator into decr_authenticator + using decr_ticket.key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (decr_authenticator.{cname,crealm} != + decr_ticket.{cname,crealm}) then + error_out(KRB_AP_ERR_BADMATCH); + endif + if (decr_ticket.caddr is present) then + if (sender_address(packet) is not in + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + decr_ticket.caddr) then + error_out(KRB_AP_ERR_BADADDR); + endif + elseif (application requires addresses) then + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(decr_authenticator.ctime, + decr_authenticator.cusec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then + error_out(KRB_AP_ERR_REPEAT); + endif + save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); + get system_time; + if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or + (decr_ticket.flags.INVALID is set)) then + /* it hasn't yet become valid */ + error_out(KRB_AP_ERR_TKT_NYV); + endif + if (system_time-decr_ticket.endtime > CLOCK_SKEW) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + if (decr_ticket.transited) then + /* caller may ignore the TRANSITED-POLICY-CHECKED and do + * check anyway */ + if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then + if (check_transited_field(decr_ticket.transited) then + error_out(KDC_AP_PATH_NOT_ACCPETED); + endif + endif + endif + /* caller must check decr_ticket.flags for any pertinent details */ + return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); + + A.11. KRB_AP_REP generation + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REP */ + + body.ctime := packet.ctime; + body.cusec := packet.cusec; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part; + + A.12. KRB_AP_REP verification + + receive packet; + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REP) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + cleartext := decrypt(packet.enc-part) using ticket's session key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (cleartext.ctime != authenticator.ctime) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.cusec != authenticator.cusec) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.subkey is present) then + save cleartext.subkey for future use; + endif + if (cleartext.seq-number is present) then + save cleartext.seq-number for future verifications; + endif + return(AUTHENTICATION_SUCCEEDED); + + A.13. KRB_SAFE generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_SAFE */ + + body.user-data := buffer; /* DATA */ + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + checksum.cksumtype := checksum type; + compute checksum over body; + checksum.checksum := checksum value; /* checksum.checksum */ + packet.cksum := checksum; + packet.safe-body := body; + + A.14. KRB_SAFE verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_SAFE) then + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.checksum.cksumtype is not both collision-proof + and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + if (safe_priv_common_checks_ok(packet)) then + set computed_checksum := checksum(packet.body); + if (computed_checksum != packet.checksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + return (packet, PACKET_IS_GENUINE); + else + return common_checks_error; + endif + + A.15. KRB_SAFE and KRB_PRIV common checks + + if (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it */ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (((packet.timestamp is present) and + (not in_clock_skew(packet.timestamp,packet.usec))) or + (packet.timestamp is not present and timestamp expected)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) then + error_out(KRB_AP_ERR_REPEAT); + endif + + if (((packet.seq-number is present) and + ((not in_sequence(packet.seq-number)))) or + (packet.seq-number is not present and sequence expected)) then + error_out(KRB_AP_ERR_BADORDER); + endif + if (packet.timestamp not present and packet.seq-number + not present) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + save_identifier(packet.{timestamp,usec,s-address}, + sender_principal(packet)); + + return PACKET_IS_OK; + + A.16. KRB_PRIV generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_PRIV */ + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + packet.enc-part.etype := encryption type; + + body.user-data := buffer; + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher; + + A.17. KRB_PRIV verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_PRIV) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + + if (safe_priv_common_checks_ok(cleartext)) then + return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); + else + return common_checks_error; + endif + + A.18. KRB_CRED generation + + invoke KRB_TGS; /* obtain tickets to be provided to peer */ + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_CRED */ + + for (tickets[n] in tickets to be forwarded) do + packet.tickets[n] = tickets[n].ticket; + done + + packet.enc-part.etype := encryption type; + + for (ticket[n] in tickets to be forwarded) do + body.ticket-info[n].key = tickets[n].session; + body.ticket-info[n].prealm = tickets[n].crealm; + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + body.ticket-info[n].pname = tickets[n].cname; + body.ticket-info[n].flags = tickets[n].flags; + body.ticket-info[n].authtime = tickets[n].authtime; + body.ticket-info[n].starttime = tickets[n].starttime; + body.ticket-info[n].endtime = tickets[n].endtime; + body.ticket-info[n].renew-till = tickets[n].renew-till; + body.ticket-info[n].srealm = tickets[n].srealm; + body.ticket-info[n].sname = tickets[n].sname; + body.ticket-info[n].caddr = tickets[n].caddr; + done + + get system_time; + body.timestamp, body.usec := system_time; + + if (using nonce) then + body.nonce := nonce; + endif + + if (using s-address) then + body.s-address := sender host addresses; + endif + if (limited recipients) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher + using negotiated encryption key; + + A.19. KRB_CRED verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_CRED) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if ((packet.r-address is present or required) and + (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it */ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(packet.timestamp,packet.usec)) then + error_out(KRB_AP_ERR_SKEW); + endif + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if (repeated(packet.timestamp,packet.usec,packet.s-address)) then + error_out(KRB_AP_ERR_REPEAT); + endif + if (packet.nonce is required or present) and + (packet.nonce != expected-nonce) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + for (ticket[n] in tickets that were forwarded) do + save_for_later(ticket[n],key[n],principal[n], + server[n],times[n],flags[n]); + return + + A.20. KRB_ERROR generation + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_ERROR */ + + get system_time; + packet.stime, packet.susec := system_time; + packet.realm, packet.sname := server name; + + if (client time available) then + packet.ctime, packet.cusec := client_time; + endif + packet.error-code := error code; + if (client name available) then + packet.cname, packet.crealm := client name; + endif + if (error text available) then + packet.e-text := error text; + endif + if (error data available) then + packet.e-data := error data; + endif + + B. Definition of common authorization data elements + + This appendix contains the definitions of common authorization data + elements. These common authorization data elements are recursivly + defined, meaning the ad-data for these types will itself contain a + sequence of authorization data whose interpretation is affected by the + encapsulating element. Depending on the meaning of the encapsulating + element, the encapsulated elements may be ignored, might be interpreted + as issued directly by the KDC, or they might be stored in a separate + plaintext part of the ticket. The types of the encapsulating elements + are specified as part of the Kerberos specification because the + behavior based on these values should be understood across + implementations whereas other elements need only be understood by the + applications which they affect. + + In the definitions that follow, the value of the ad-type for the + element will be specified in the subsection number, and the value of + the ad-data will be as shown in the ASN.1 structure that follows the + subsection heading. + + B.1. If relevant + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + AD-IF-RELEVANT AuthorizationData + + AD elements encapsulated within the if-relevant element are intended + for interpretation only by application servers that understand the + particular ad-type of the embedded element. Application servers that do + not understand the type of an element embedded within the if-relevant + element may ignore the uninterpretable element. This element promotes + interoperability across implementations which may have local extensions + for authorization. + + B.2. Intended for server + + AD-INTENDED-FOR-SERVER SEQUENCE { + intended-server[0] SEQUENCE OF PrincipalName + elements[1] AuthorizationData + } + + AD elements encapsulated within the intended-for-server element may be + ignored if the application server is not in the list of principal names + of intended servers. Further, a KDC issuing a ticket for an application + server can remove this element if the application server is not in the + list of intended servers. + + Application servers should check for their principal name in the + intended-server field of this element. If their principal name is not + found, this element should be ignored. If found, then the encapsulated + elements should be evaluated in the same manner as if they were present + in the top level authorization data field. Applications and application + servers that do not implement this element should reject tickets that + contain authorization data elements of this type. + + B.3. Intended for application class + + AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { + intended-application-class[0] SEQUENCE OF GeneralString elements[1] + AuthorizationData } AD elements encapsulated within the + intended-for-application-class element may be ignored if the + application server is not in one of the named classes of application + servers. Examples of application server classes include "FILESYSTEM", + and other kinds of servers. + + This element and the elements it encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.4. KDC Issued + + AD-KDCIssued SEQUENCE { + ad-checksum[0] Checksum, + i-realm[1] Realm OPTIONAL, + i-sname[2] PrincipalName OPTIONAL, + elements[3] AuthorizationData. + } + + ad-checksum + A checksum over the elements field using a cryptographic checksum + method that is identical to the checksum used to protect the + ticket itself (i.e. using the same hash function and the same + encryption algorithm used to encrypt the ticket) and using a key + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + derived from the same key used to protect the ticket. + i-realm, i-sname + The name of the issuing principal if different from the KDC + itself. This field would be used when the KDC can verify the + authenticity of elements signed by the issuing principal and it + allows this KDC to notify the application server of the validity + of those elements. + elements + A sequence of authorization data elements issued by the KDC. + The KDC-issued ad-data field is intended to provide a means for + Kerberos principal credentials to embed within themselves privilege + attributes and other mechanisms for positive authorization, amplifying + the priveleges of the principal beyond what can be done using a + credentials without such an a-data element. + + This can not be provided without this element because the definition of + the authorization-data field allows elements to be added at will by the + bearer of a TGT at the time that they request service tickets and + elements may also be added to a delegated ticket by inclusion in the + authenticator. + + For KDC-issued elements this is prevented because the elements are + signed by the KDC by including a checksum encrypted using the server's + key (the same key used to encrypt the ticket - or a key derived from + that key). Elements encapsulated with in the KDC-issued element will be + ignored by the application server if this "signature" is not present. + Further, elements encapsulated within this element from a ticket + granting ticket may be interpreted by the KDC, and used as a basis + according to policy for including new signed elements within derivative + tickets, but they will not be copied to a derivative ticket directly. + If they are copied directly to a derivative ticket by a KDC that is not + aware of this element, the signature will not be correct for the + application ticket elements, and the field will be ignored by the + application server. + + This element and the elements it encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.5. And-Or + + AD-AND-OR SEQUENCE { + condition-count[0] INTEGER, + elements[1] AuthorizationData + } + + When restrictive AD elements encapsulated within the and-or element are + encountered, only the number specified in condition-count of the + encapsulated conditions must be met in order to satisfy this element. + This element may be used to implement an "or" operation by setting the + condition-count field to 1, and it may specify an "and" operation by + setting the condition count to the number of embedded elements. + Application servers that do not implement this element must reject + tickets that contain authorization data elements of this type. + + B.6. Mandatory ticket extensions + + AD-Mandatory-Ticket-Extensions Checksum + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + An authorization data element of type mandatory-ticket-extensions + specifies a collision-proof checksum using the same hash algorithm used + to protect the integrity of the ticket itself. This checksum will be + calculated over an individual extension field. If there are more than + one extension, multiple Mandatory-Ticket-Extensions authorization data + elements may be present, each with a checksum for a different extension + field. This restriction indicates that the ticket should not be + accepted if a ticket extension is not present in the ticket for which + the checksum does not match that checksum specified in the + authorization data element. Application servers that do not implement + this element must reject tickets that contain authorization data + elements of this type. + + B.7. Authorization Data in ticket extensions + + AD-IN-Ticket-Extensions Checksum + + An authorization data element of type in-ticket-extensions specifies a + collision-proof checksum using the same hash algorithm used to protect + the integrity of the ticket itself. This checksum is calculated over a + separate external AuthorizationData field carried in the ticket + extensions. Application servers that do not implement this element must + reject tickets that contain authorization data elements of this type. + Application servers that do implement this element will search the + ticket extensions for authorization data fields, calculate the + specified checksum over each authorization data field and look for one + matching the checksum in this in-ticket-extensions element. If not + found, then the ticket must be rejected. If found, the corresponding + authorization data elements will be interpreted in the same manner as + if they were contained in the top level authorization data field. + + Note that if multiple external authorization data fields are present in + a ticket, each will have a corresponding element of type + in-ticket-extensions in the top level authorization data field, and the + external entries will be linked to the corresponding element by their + checksums. + + C. Definition of common ticket extensions + + This appendix contains the definitions of common ticket extensions. + Support for these extensions is optional. However, certain extensions + have associated authorization data elements that may require rejection + of a ticket containing an extension by application servers that do not + implement the particular extension. Other extensions have been defined + beyond those described in this specification. Such extensions are + described elswhere and for some of those extensions the reserved number + may be found in the list of constants. + + It is known that older versions of Kerberos did not support this field, + and that some clients will strip this field from a ticket when they + parse and then reassemble a ticket as it is passed to the application + servers. The presence of the extension will not break such clients, but + any functionaly dependent on the extensions will not work when such + tickets are handled by old clients. In such situations, some + implementation may use alternate methods to transmit the information in + the extensions field. + + C.1. Null ticket extension + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + TE-NullExtension OctetString -- The empty Octet String + + The te-data field in the null ticket extension is an octet string of + lenght zero. This extension may be included in a ticket granting ticket + so that the KDC can determine on presentation of the ticket granting + ticket whether the client software will strip the extensions field. + + C.2. External Authorization Data + + TE-ExternalAuthorizationData AuthorizationData + + The te-data field in the external authorization data ticket extension + is field of type AuthorizationData containing one or more authorization + data elements. If present, a corresponding authorization data element + will be present in the primary authorization data for the ticket and + that element will contain a checksum of the external authorization data + ticket extension. + ----------------------------------------------------------------------- + [TM] Project Athena, Athena, and Kerberos are trademarks of the + Massachusetts Institute of Technology (MIT). No commercial use of these + trademarks may be made without prior written permission of MIT. + + [1] Note, however, that many applications use Kerberos' functions only + upon the initiation of a stream-based network connection. Unless an + application subsequently provides integrity protection for the data + stream, the identity verification applies only to the initiation of the + connection, and does not guarantee that subsequent messages on the + connection originate from the same principal. + + [2] Secret and private are often used interchangeably in the + literature. In our usage, it takes two (or more) to share a secret, + thus a shared DES key is a secret key. Something is only private when + no one but its owner knows it. Thus, in public key cryptosystems, one + has a public and a private key. + + [3] Of course, with appropriate permission the client could arrange + registration of a separately-named prin- cipal in a remote realm, and + engage in normal exchanges with that realm's services. However, for + even small numbers of clients this becomes cumbersome, and more + automatic methods as described here are necessary. + + [4] Though it is permissible to request or issue tick- ets with no + network addresses specified. + + [5] The password-changing request must not be honored unless the + requester can provide the old password (the user's current secret key). + Otherwise, it would be possible for someone to walk up to an unattended + ses- sion and change another user's password. + + [6] To authenticate a user logging on to a local system, the + credentials obtained in the AS exchange may first be used in a TGS + exchange to obtain credentials for a local server. Those credentials + must then be verified by a local server through successful completion + of the Client/Server exchange. + + [7] "Random" means that, among other things, it should be impossible to + guess the next session key based on knowledge of past session keys. + This can only be achieved in a pseudo-random number generator if it is + based on cryptographic principles. It is more desirable to use a truly + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + random number generator, such as one based on measurements of random + physical phenomena. + + [8] Tickets contain both an encrypted and unencrypted portion, so + cleartext here refers to the entire unit, which can be copied from one + message and replayed in another without any cryptographic skill. + + [9] Note that this can make applications based on unreliable transports + difficult to code correctly. If the transport might deliver duplicated + messages, either a new authenticator must be generated for each retry, + or the application server must match requests and replies and replay + the first reply in response to a detected duplicate. + + [10] This is used for user-to-user authentication as described in [8]. + + [11] Note that the rejection here is restricted to authenticators from + the same principal to the same server. Other client principals + communicating with the same server principal should not be have their + authenticators rejected if the time and microsecond fields happen to + match some other client's authenticator. + + [12] In the Kerberos version 4 protocol, the timestamp in the reply was + the client's timestamp plus one. This is not necessary in version 5 + because version 5 messages are formatted in such a way that it is not + possible to create the reply by judicious message surgery (even in + encrypted form) without knowledge of the appropriate encryption keys. + + [13] Note that for encrypting the KRB_AP_REP message, the sub-session + key is not used, even if present in the Authenticator. + + [14] Implementations of the protocol may wish to provide routines to + choose subkeys based on session keys and random numbers and to generate + a negotiated key to be returned in the KRB_AP_REP message. + + [15]This can be accomplished in several ways. It might be known + beforehand (since the realm is part of the principal identifier), it + might be stored in a nameserver, or it might be obtained from a + configura- tion file. If the realm to be used is obtained from a + nameserver, there is a danger of being spoofed if the nameservice + providing the realm name is not authenti- cated. This might result in + the use of a realm which has been compromised, and would result in an + attacker's ability to compromise the authentication of the application + server to the client. + + [16] If the client selects a sub-session key, care must be taken to + ensure the randomness of the selected sub- session key. One approach + would be to generate a random number and XOR it with the session key + from the ticket-granting ticket. + + [17] This allows easy implementation of user-to-user authentication + [8], which uses ticket-granting ticket session keys in lieu of secret + server keys in situa- tions where such secret keys could be easily + comprom- ised. + + [18] For the purpose of appending, the realm preceding the first listed + realm is considered to be the null realm (""). + + [19] For the purpose of interpreting null subfields, the client's realm + is considered to precede those in the transited field, and the server's + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + realm is considered to follow them. + + [20] This means that a client and server running on the same host and + communicating with one another using the KRB_SAFE messages should not + share a common replay cache to detect KRB_SAFE replays. + + [21] The implementation of the Kerberos server need not combine the + database and the server on the same machine; it is feasible to store + the principal database in, say, a network name service, as long as the + entries stored therein are protected from disclosure to and + modification by unauthorized parties. However, we recommend against + such strategies, as they can make system management and threat analysis + quite complex. + + [22] See the discussion of the padata field in section 5.4.2 for + details on why this can be useful. + + [23] Warning for implementations that unpack and repack data structures + during the generation and verification of embedded checksums: Because + any checksums applied to data structures must be checked against the + original data the length of bit strings must be preserved within a data + structure between the time that a checksum is generated through + transmission to the time that the checksum is verified. + + [24] It is NOT recommended that this time value be used to adjust the + workstation's clock since the workstation cannot reliably determine + that such a KRB_AS_REP actually came from the proper KDC in a timely + manner. + + [25] Note, however, that if the time is used as the nonce, one must + make sure that the workstation time is monotonically increasing. If the + time is ever reset backwards, there is a small, but finite, probability + that a nonce will be reused. + + [27] An application code in the encrypted part of a message provides an + additional check that the message was decrypted properly. + + [29] An application code in the encrypted part of a message provides an + additional check that the message was decrypted properly. + + [31] An application code in the encrypted part of a message provides an + additional check that the message was decrypted properly. + + [32] If supported by the encryption method in use, an initialization + vector may be passed to the encryption procedure, in order to achieve + proper cipher chaining. The initialization vector might come from the + last block of the ciphertext from the previous KRB_PRIV message, but it + is the application's choice whether or not to use such an + initialization vector. If left out, the default initialization vector + for the encryption algorithm will be used. + + [33] This prevents an attacker who generates an incorrect AS request + from obtaining verifiable plaintext for use in an off-line password + guessing attack. + + [35] In the above specification, UNTAGGED OCTET STRING(length) is the + notation for an octet string with its tag and length removed. It is not + a valid ASN.1 type. The tag bits and length must be removed from the + confounder since the purpose of the confounder is so that the message + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + starts with random data, but the tag and its length are fixed. For + other fields, the length and tag would be redundant if they were + included because they are specified by the encryption type. [36] The + ordering of the fields in the CipherText is important. Additionally, + messages encoded in this format must include a length as part of the + msg-seq field. This allows the recipient to verify that the message has + not been truncated. Without a length, an attacker could use a chosen + plaintext attack to generate a message which could be truncated, while + leaving the checksum intact. Note that if the msg-seq is an encoding of + an ASN.1 SEQUENCE or OCTET STRING, then the length is part of that + encoding. + + [37] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [38] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [39] A variant of the key is used to limit the use of a key to a + particular function, separating the functions of generating a checksum + from other encryption performed using the session key. The constant + F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The + properties of DES precluded the use of the complement. The same + constant is used for similar purpose in the Message Integrity Check in + the Privacy Enhanced Mail standard. + + [40] This error carries additional information in the e- data field. + The contents of the e-data field for this message is described in + section 5.9.1. diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt new file mode 100644 index 000000000000..ae79e8a7c4fb --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt @@ -0,0 +1,7301 @@ +INTERNET-DRAFT Clifford Neuman + John Kohl + Theodore Ts'o + July 14, 2000 + Expires January 14, 2001 + +The Kerberos Network Authentication Service (V5) + + +draft-ietf-cat-kerberos-revisions-06.txt + +STATUS OF THIS MEMO + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC 2026. Internet-Drafts are working documents +of the Internet Engineering Task Force (IETF), its areas, and its working +groups. Note that other groups may also distribute working documents as +Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months and +may be updated, replaced, or obsoleted by other documents at any time. It +is inappropriate to use Internet-Drafts as reference material or to cite +them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +To learn the current status of any Internet-Draft, please check the +"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow +Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), +ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-revisions-06.txt, and expires January 14, 2001. +Please send comments to: krb-protocol@MIT.EDU + + This document is getting closer to a last call, but there are several + issues to be discussed. Some, but not all of these issues, are + highlighted in comments in the draft. We hope to resolve these issues + on the mailing list for the Kerberos working group, leading up to and + during the Pittsburgh IETF on a section by section basis, since this + is a long document, and it has been difficult to consider it as a + whole. Once sections are agreed to, it is out intent to issue the more + formal WG and IETF last calls. + +ABSTRACT + +This document provides an overview and specification of Version 5 of the +Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol +and its intended use that require more detailed or clearer explanation than +was provided in RFC1510. This document is intended to provide a detailed +description of the protocol, suitable for implementation, together with +descriptions of the appropriate use of protocol messages and fields within +those messages. + +This document is not intended to describe Kerberos to the end user, system +administrator, or application developer. Higher level papers describing +Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], +are available elsewhere. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +OVERVIEW + +This INTERNET-DRAFT describes the concepts and model upon which the +Kerberos network authentication system is based. It also specifies Version +5 of the Kerberos protocol. + +The motivations, goals, assumptions, and rationale behind most design +decisions are treated cursorily; they are more fully described in a paper +available in IEEE communications [NT94] and earlier in the Kerberos portion +of the Athena Technical Plan [MNSS87]. The protocols have been a proposed +standard and are being considered for advancement for draft standard +through the IETF standard process. Comments are encouraged on the +presentation, but only minor refinements to the protocol as implemented or +extensions that fit within current protocol framework will be considered at +this time. + +Requests for addition to an electronic mailing list for discussion of +Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. +This mailing list is gatewayed onto the Usenet as the group +comp.protocols.kerberos. Requests for further information, including +documents and code availability, may be sent to info-kerberos@MIT.EDU. + +BACKGROUND + +The Kerberos model is based in part on Needham and Schroeder's trusted +third-party authentication protocol [NS78] and on modifications suggested +by Denning and Sacco [DS81]. The original design and implementation of +Kerberos Versions 1 through 4 was the work of two former Project Athena +staff members, Steve Miller of Digital Equipment Corporation and Clifford +Neuman (now at the Information Sciences Institute of the University of +Southern California), along with Jerome Saltzer, Technical Director of +Project Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many +other members of Project Athena have also contributed to the work on +Kerberos. + +Version 5 of the Kerberos protocol (described in this document) has evolved +from Version 4 based on new requirements and desires for features not +available in Version 4. The design of Version 5 of the Kerberos protocol +was led by Clifford Neuman and John Kohl with much input from the +community. The development of the MIT reference implementation was led at +MIT by John Kohl and Theodore T'so, with help and contributed code from +many others. Since RFC1510 was issued, extensions and revisions to the +protocol have been proposed by many individuals. Some of these proposals +are reflected in this document. Where such changes involved significant +effort, the document cites the contribution of the proposer. + +Reference implementations of both version 4 and version 5 of Kerberos are +publicly available and commercial implementations have been developed and +are widely used. Details on the differences between Kerberos Versions 4 and +5 can be found in [KNT92]. + +1. Introduction + +Kerberos provides a means of verifying the identities of principals, (e.g. +a workstation user or a network server) on an open (unprotected) network. +This is accomplished without relying on assertions by the host operating +system, without basing trust on host addresses, without requiring physical +security of all the hosts on the network, and under the assumption that +packets traveling along the network can be read, modified, and inserted at +will[1]. Kerberos performs authentication under these conditions as a +trusted third-party authentication service by using conventional (shared +secret key [2] cryptography. Kerberos extensions have been proposed and +implemented that provide for the use of public key cryptography during +certain phases of the authentication protocol. These extensions provide for + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +authentication of users registered with public key certification +authorities, and allow the system to provide certain benefits of public key +cryptography in situations where they are needed. + +The basic Kerberos authentication process proceeds as follows: A client +sends a request to the authentication server (AS) requesting 'credentials' +for a given server. The AS responds with these credentials, encrypted in +the client's key. The credentials consist of 1) a 'ticket' for the server +and 2) a temporary encryption key (often called a "session key"). The +client transmits the ticket (which contains the client's identity and a +copy of the session key, all encrypted in the server's key) to the server. +The session key (now shared by the client and server) is used to +authenticate the client, and may optionally be used to authenticate the +server. It may also be used to encrypt further communication between the +two parties or to exchange a separate sub-session key to be used to encrypt +further communication. + +Implementation of the basic protocol consists of one or more authentication +servers running on physically secure hosts. The authentication servers +maintain a database of principals (i.e., users and servers) and their +secret keys. Code libraries provide encryption and implement the Kerberos +protocol. In order to add authentication to its transactions, a typical +network application adds one or two calls to the Kerberos library directly +or through the Generic Security Services Application Programming Interface, +GSSAPI, described in separate document. These calls result in the +transmission of the necessary messages to achieve authentication. + +The Kerberos protocol consists of several sub-protocols (or exchanges). +There are two basic methods by which a client can ask a Kerberos server for +credentials. In the first approach, the client sends a cleartext request +for a ticket for the desired server to the AS. The reply is sent encrypted +in the client's secret key. Usually this request is for a ticket-granting +ticket (TGT) which can later be used with the ticket-granting server (TGS). +In the second method, the client sends a request to the TGS. The client +uses the TGT to authenticate itself to the TGS in the same manner as if it +were contacting any other application server that requires Kerberos +authentication. The reply is encrypted in the session key from the TGT. +Though the protocol specification describes the AS and the TGS as separate +servers, they are implemented in practice as different protocol entry +points within a single Kerberos server. + +Once obtained, credentials may be used to verify the identity of the +principals in a transaction, to ensure the integrity of messages exchanged +between them, or to preserve privacy of the messages. The application is +free to choose whatever protection may be necessary. + +To verify the identities of the principals in a transaction, the client +transmits the ticket to the application server. Since the ticket is sent +"in the clear" (parts of it are encrypted, but this encryption doesn't +thwart replay) and might be intercepted and reused by an attacker, +additional information is sent to prove that the message originated with +the principal to whom the ticket was issued. This information (called the +authenticator) is encrypted in the session key, and includes a timestamp. +The timestamp proves that the message was recently generated and is not a +replay. Encrypting the authenticator in the session key proves that it was +generated by a party possessing the session key. Since no one except the +requesting principal and the server know the session key (it is never sent +over the network in the clear) this guarantees the identity of the client. + +The integrity of the messages exchanged between principals can also be +guaranteed using the session key (passed in the ticket and contained in the +credentials). This approach provides detection of both replay attacks and +message stream modification attacks. It is accomplished by generating and +transmitting a collision-proof checksum (elsewhere called a hash or digest +function) of the client's message, keyed with the session key. Privacy and + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +integrity of the messages exchanged between principals can be secured by +encrypting the data to be passed using the session key contained in the +ticket or the subsession key found in the authenticator. + +The authentication exchanges mentioned above require read-only access to +the Kerberos database. Sometimes, however, the entries in the database must +be modified, such as when adding new principals or changing a principal's +key. This is done using a protocol between a client and a third Kerberos +server, the Kerberos Administration Server (KADM). There is also a protocol +for maintaining multiple copies of the Kerberos database. Neither of these +protocols are described in this document. + +1.1. Cross-Realm Operation + +The Kerberos protocol is designed to operate across organizational +boundaries. A client in one organization can be authenticated to a server +in another. Each organization wishing to run a Kerberos server establishes +its own 'realm'. The name of the realm in which a client is registered is +part of the client's name, and can be used by the end-service to decide +whether to honor a request. + +By establishing 'inter-realm' keys, the administrators of two realms can +allow a client authenticated in the local realm to prove its identity to +servers in other realms[3]. The exchange of inter-realm keys (a separate +key may be used for each direction) registers the ticket-granting service +of each realm as a principal in the other realm. A client is then able to +obtain a ticket-granting ticket for the remote realm's ticket-granting +service from its local realm. When that ticket-granting ticket is used, the +remote ticket-granting service uses the inter-realm key (which usually +differs from its own normal TGS key) to decrypt the ticket-granting ticket, +and is thus certain that it was issued by the client's own TGS. Tickets +issued by the remote ticket-granting service will indicate to the +end-service that the client was authenticated from another realm. + +A realm is said to communicate with another realm if the two realms share +an inter-realm key, or if the local realm shares an inter-realm key with an +intermediate realm that communicates with the remote realm. An +authentication path is the sequence of intermediate realms that are +transited in communicating from one realm to another. + +Realms are typically organized hierarchically. Each realm shares a key with +its parent and a different key with each child. If an inter-realm key is +not directly shared by two realms, the hierarchical organization allows an +authentication path to be easily constructed. If a hierarchical +organization is not used, it may be necessary to consult a database in +order to construct an authentication path between realms. + +Although realms are typically hierarchical, intermediate realms may be +bypassed to achieve cross-realm authentication through alternate +authentication paths (these might be established to make communication +between two realms more efficient). It is important for the end-service to +know which realms were transited when deciding how much faith to place in +the authentication process. To facilitate this decision, a field in each +ticket contains the names of the realms that were involved in +authenticating the client. + +The application server is ultimately responsible for accepting or rejecting +authentication and should check the transited field. The application server +may choose to rely on the KDC for the application server's realm to check +the transited field. The application server's KDC will set the +TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate +realms may also check the transited field as they issue +ticket-granting-tickets for other realms, but they are encouraged not to do +so. A client may request that the KDC's not check the transited field by +setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not +required to honor this flag. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + [JBrezak] Should there be a section here on how clients determine what + realm a service is in? Something like: + + The client may not immediately know what realm a particular service + principal is in. There are 2 basic mechanisms that can be used to + determine the realm of a service. The first requires that the client + fully specify the service principal including the realm in the + Kerberos protocol request. If the Kerberos server for the specified + realm does not have a principal that exactly matches the service in + the request, the Kerberos server will return an error indicating that + the service principal was not found. Alternatively the client can make + a request providing just the service principal name and requesting + name canonicalization from the Kerberos server. The Kerberos server + will attempt to locate a service principal in its database that best + matches the request principal or provide a referral to another + Kerberos realm that may be contain the requested service principal. + +1.2. Authorization + +As an authentication service, Kerberos provides a means of verifying the +identity of principals on a network. Authentication is usually useful +primarily as a first step in the process of authorization, determining +whether a client may use a service, which objects the client is allowed to +access, and the type of access allowed for each. Kerberos does not, by +itself, provide authorization. Possession of a client ticket for a service +provides only for authentication of the client to that service, and in the +absence of a separate authorization procedure, it should not be considered +by an application as authorizing the use of that service. + +Such separate authorization methods may be implemented as application +specific access control functions and may be based on files such as the +application server, or on separately issued authorization credentials such +as those based on proxies [Neu93], or on other authorization services. +Separately authenticated authorization credentials may be embedded in a +tickets authorization data when encapsulated by the kdc-issued +authorization data element. + +Applications should not be modified to accept the mere issuance of a +service ticket by the Kerberos server (even by a modified Kerberos server) +as granting authority to use the service, since such applications may +become vulnerable to the bypass of this authorization check in an +environment if they interoperate with other KDCs or where other options for +application authentication (e.g. the PKTAPP proposal) are provided. + +1.3. Environmental assumptions + +Kerberos imposes a few assumptions on the environment in which it can +properly function: + + * 'Denial of service' attacks are not solved with Kerberos. There are + places in these protocols where an intruder can prevent an application + from participating in the proper authentication steps. Detection and + solution of such attacks (some of which can appear to be nnot-uncommon + 'normal' failure modes for the system) is usually best left to the + human administrators and users. + * Principals must keep their secret keys secret. If an intruder somehow + steals a principal's key, it will be able to masquerade as that + principal or impersonate any server to the legitimate principal. + * 'Password guessing' attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to + successfully mount an offline dictionary attack by repeatedly + attempting to decrypt, with successive entries from a dictionary, + messages obtained which are encrypted under a key derived from the + user's password. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + * Each host on the network must have a clock which is 'loosely + synchronized' to the time of the other hosts; this synchronization is + used to reduce the bookkeeping needs of application servers when they + do replay detection. The degree of "looseness" can be configured on a + per-server basis, but is typically on the order of 5 minutes. If the + clocks are synchronized over the network, the clock synchronization + protocol must itself be secured from network attackers. + * Principal identifiers are not recycled on a short-term basis. A + typical mode of access control will use access control lists (ACLs) to + grant permissions to particular principals. If a stale ACL entry + remains for a deleted principal and the principal identifier is + reused, the new principal will inherit rights specified in the stale + ACL entry. By not re-using principal identifiers, the danger of + inadvertent access is removed. + +1.4. Glossary of terms + +Below is a list of terms used throughout this document. + +Authentication + Verifying the claimed identity of a principal. +Authentication header + A record containing a Ticket and an Authenticator to be presented to a + server as part of the authentication process. +Authentication path + A sequence of intermediate realms transited in the authentication + process when communicating from one realm to another. +Authenticator + A record containing information that can be shown to have been + recently generated using the session key known only by the client and + server. +Authorization + The process of determining whether a client may use a service, which + objects the client is allowed to access, and the type of access + allowed for each. +Capability + A token that grants the bearer permission to access an object or + service. In Kerberos, this might be a ticket whose use is restricted + by the contents of the authorization data field, but which lists no + network addresses, together with the session key necessary to use the + ticket. +Ciphertext + The output of an encryption function. Encryption transforms plaintext + into ciphertext. +Client + A process that makes use of a network service on behalf of a user. + Note that in some cases a Server may itself be a client of some other + server (e.g. a print server may be a client of a file server). +Credentials + A ticket plus the secret session key necessary to successfully use + that ticket in an authentication exchange. +KDC + Key Distribution Center, a network service that supplies tickets and + temporary session keys; or an instance of that service or the host on + which it runs. The KDC services both initial ticket and + ticket-granting ticket requests. The initial ticket portion is + sometimes referred to as the Authentication Server (or service). The + ticket-granting ticket portion is sometimes referred to as the + ticket-granting server (or service). +Kerberos + Aside from the 3-headed dog guarding Hades, the name given to Project + Athena's authentication service, the protocol used by that service, or + the code used to implement the authentication service. +Plaintext + The input to an encryption function or the output of a decryption + function. Decryption transforms ciphertext into plaintext. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +Principal + A uniquely named client or server instance that participates in a + network communication. +Principal identifier + The name used to uniquely identify each different principal. +Seal + To encipher a record containing several fields in such a way that the + fields cannot be individually replaced without either knowledge of the + encryption key or leaving evidence of tampering. +Secret key + An encryption key shared by a principal and the KDC, distributed + outside the bounds of the system, with a long lifetime. In the case of + a human user's principal, the secret key is derived from a password. +Server + A particular Principal which provides a resource to network clients. + The server is sometimes refered to as the Application Server. +Service + A resource provided to network clients; often provided by more than + one server (for example, remote file service). +Session key + A temporary encryption key used between two principals, with a + lifetime limited to the duration of a single login "session". +Sub-session key + A temporary encryption key used between two principals, selected and + exchanged by the principals using the session key, and with a lifetime + limited to the duration of a single association. +Ticket + A record that helps a client authenticate itself to a server; it + contains the client's identity, a session key, a timestamp, and other + information, all sealed using the server's secret key. It only serves + to authenticate a client when presented along with a fresh + Authenticator. + +2. Ticket flag uses and requests + +Each Kerberos ticket contains a set of flags which are used to indicate +various attributes of that ticket. Most flags may be requested by a client +when the ticket is obtained; some are automatically turned on and off by a +Kerberos server as required. The following sections explain what the +various flags mean, and gives examples of reasons to use such a flag. + +2.1. Initial and pre-authenticated tickets + +The INITIAL flag indicates that a ticket was issued using the AS protocol +and not issued based on a ticket-granting ticket. Application servers that +want to require the demonstrated knowledge of a client's secret key (e.g. a +password-changing program) can insist that this flag be set in any tickets +they accept, and thus be assured that the client's key was recently +presented to the application client. + +The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the +initial authentication, regardless of whether the current ticket was issued +directly (in which case INITIAL will also be set) or issued on the basis of +a ticket-granting ticket (in which case the INITIAL flag is clear, but the +PRE-AUTHENT and HW-AUTHENT flags are carried forward from the +ticket-granting ticket). + +2.2. Invalid tickets + +The INVALID flag indicates that a ticket is invalid. Application servers +must reject tickets which have this flag set. A postdated ticket will +usually be issued in this form. Invalid tickets must be validated by the +KDC before use, by presenting them to the KDC in a TGS request with the +VALIDATE option specified. The KDC will only validate tickets after their +starttime has passed. The validation is required so that postdated tickets +which have been stolen before their starttime can be rendered permanently +invalid (through a hot-list mechanism) (see section 3.3.3.1). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +2.3. Renewable tickets + +Applications may desire to hold tickets which can be valid for long periods +of time. However, this can expose their credentials to potential theft for +equally long periods, and those stolen credentials would be valid until the +expiration time of the ticket(s). Simply using short-lived tickets and +obtaining new ones periodically would require the client to have long-term +access to its secret key, an even greater risk. Renewable tickets can be +used to mitigate the consequences of theft. Renewable tickets have two +"expiration times": the first is when the current instance of the ticket +expires, and the second is the latest permissible value for an individual +expiration time. An application client must periodically (i.e. before it +expires) present a renewable ticket to the KDC, with the RENEW option set +in the KDC request. The KDC will issue a new ticket with a new session key +and a later expiration time. All other fields of the ticket are left +unmodified by the renewal process. When the latest permissible expiration +time arrives, the ticket expires permanently. At each renewal, the KDC may +consult a hot-list to determine if the ticket had been reported stolen +since its last renewal; it will refuse to renew such stolen tickets, and +thus the usable lifetime of stolen tickets is reduced. + +The RENEWABLE flag in a ticket is normally only interpreted by the +ticket-granting service (discussed below in section 3.3). It can usually be +ignored by application servers. However, some particularly careful +application servers may wish to disallow renewable tickets. + +If a renewable ticket is not renewed by its expiration time, the KDC will +not renew the ticket. The RENEWABLE flag is reset by default, but a client +may request it be set by setting the RENEWABLE option in the KRB_AS_REQ +message. If it is set, then the renew-till field in the ticket contains the +time after which the ticket may not be renewed. + +2.4. Postdated tickets + +Applications may occasionally need to obtain tickets for use much later, +e.g. a batch submission system would need tickets to be valid at the time +the batch job is serviced. However, it is dangerous to hold valid tickets +in a batch queue, since they will be on-line longer and more prone to +theft. Postdated tickets provide a way to obtain these tickets from the KDC +at job submission time, but to leave them "dormant" until they are +activated and validated by a further request of the KDC. If a ticket theft +were reported in the interim, the KDC would refuse to validate the ticket, +and the thief would be foiled. + +The MAY-POSTDATE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. This +flag must be set in a ticket-granting ticket in order to issue a postdated +ticket based on the presented ticket. It is reset by default; it may be +requested by a client by setting the ALLOW-POSTDATE option in the +KRB_AS_REQ message. This flag does not allow a client to obtain a postdated +ticket-granting ticket; postdated ticket-granting tickets can only by +obtained by requesting the postdating in the KRB_AS_REQ message. The life +(endtime-starttime) of a postdated ticket will be the remaining life of the +ticket-granting ticket at the time of the request, unless the RENEWABLE +option is also set, in which case it can be the full life +(endtime-starttime) of the ticket-granting ticket. The KDC may limit how +far in the future a ticket may be postdated. + +The POSTDATED flag indicates that a ticket has been postdated. The +application server can check the authtime field in the ticket to see when +the original authentication occurred. Some services may choose to reject +postdated tickets, or they may only accept them within a certain period +after the original authentication. When the KDC issues a POSTDATED ticket, +it will also be marked as INVALID, so that the application client must +present the ticket to the KDC to be validated before use. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +2.5. Proxiable and proxy tickets + +At times it may be necessary for a principal to allow a service to perform +an operation on its behalf. The service must be able to take on the +identity of the client, but only for a particular purpose. A principal can +allow a service to take on the principal's identity for a particular +purpose by granting it a proxy. + +The process of granting a proxy using the proxy and proxiable flags is used +to provide credentials for use with specific services. Though conceptually +also a proxy, user's wishing to delegate their identity for ANY purpose +must use the ticket forwarding mechanism described in the next section to +forward a ticket granting ticket. + +The PROXIABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. When +set, this flag tells the ticket-granting server that it is OK to issue a +new ticket (but not a ticket-granting ticket) with a different network +address based on this ticket. This flag is set if requested by the client +on initial authentication. By default, the client will request that it be +set when requesting a ticket granting ticket, and reset when requesting any +other ticket. + +This flag allows a client to pass a proxy to a server to perform a remote +request on its behalf, e.g. a print service client can give the print +server a proxy to access the client's files on a particular file server in +order to satisfy a print request. + +In order to complicate the use of stolen credentials, Kerberos tickets are +usually valid from only those network addresses specifically included in +the ticket[4]. When granting a proxy, the client must specify the new +network address from which the proxy is to be used, or indicate that the +proxy is to be issued for use from any address. + +The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. +Application servers may check this flag and at their option they may +require additional authentication from the agent presenting the proxy in +order to provide an audit trail. + +2.6. Forwardable tickets + +Authentication forwarding is an instance of a proxy where the service is +granted complete use of the client's identity. An example where it might be +used is when a user logs in to a remote system and wants authentication to +work from that system as if the login were local. + +The FORWARDABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. The +FORWARDABLE flag has an interpretation similar to that of the PROXIABLE +flag, except ticket-granting tickets may also be issued with different +network addresses. This flag is reset by default, but users may request +that it be set by setting the FORWARDABLE option in the AS request when +they request their initial ticket- granting ticket. + +This flag allows for authentication forwarding without requiring the user +to enter a password again. If the flag is not set, then authentication +forwarding is not permitted, but the same result can still be achieved if +the user engages in the AS exchange specifying the requested network +addresses and supplies a password. + +The FORWARDED flag is set by the TGS when a client presents a ticket with +the FORWARDABLE flag set and requests a forwarded ticket by specifying the +FORWARDED KDC option and supplying a set of addresses for the new ticket. +It is also set in all tickets issued based on tickets with the FORWARDED +flag set. Application servers may choose to process FORWARDED tickets +differently than non-FORWARDED tickets. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +2.7 Name canonicalization [JBrezak] + +If a client does not have the full name information for a principal, it can +request that the Kerberos server attempt to lookup the name in its database +and return a canonical form of the requested principal or a referral to a +realm that has the requested principal in its namespace. Name +canonicalization allows a principal to have alternate names. Name +canonicalization must not be used to locate principal names supplied from +wildcards and is not a mechanism to be used to search a Kerberos database. + +The CANONICALIZE flag in a ticket request is used to indicate to the +Kerberos server that the client will accept an alternative name to the +principal in the request or a referral to another realm. Both the AS and +TGS must be able to interpret requests with this flag. + +By using this flag, the client can avoid extensive configuration needed to +map specific host names to a particular realm. + +2.8. Other KDC options + +There are two additional options which may be set in a client's request of +the KDC. The RENEWABLE-OK option indicates that the client will accept a +renewable ticket if a ticket with the requested life cannot otherwise be +provided. If a ticket with the requested life cannot be provided, then the +KDC may issue a renewable ticket with a renew-till equal to the the +requested endtime. The value of the renew-till field may still be adjusted +by site-determined limits or limits imposed by the individual principal or +server. + +The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. +It indicates that the ticket to be issued for the end server is to be +encrypted in the session key from the a additional second ticket-granting +ticket provided with the request. See section 3.3.3 for specific details. + +3. Message Exchanges + +The following sections describe the interactions between network clients +and servers and the messages involved in those exchanges. + +3.1. The Authentication Service Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_AS_REQ 5.4.1 + 2. Kerberos to client KRB_AS_REP or 5.4.2 + KRB_ERROR 5.9.1 + +The Authentication Service (AS) Exchange between the client and the +Kerberos Authentication Server is initiated by a client when it wishes to +obtain authentication credentials for a given server but currently holds no +credentials. In its basic form, the client's secret key is used for +encryption and decryption. This exchange is typically used at the +initiation of a login session to obtain credentials for a Ticket-Granting +Server which will subsequently be used to obtain credentials for other +servers (see section 3.3) without requiring further use of the client's +secret key. This exchange is also used to request credentials for services +which must not be mediated through the Ticket-Granting Service, but rather +require a principal's secret key, such as the password-changing service[5]. +This exchange does not by itself provide any assurance of the the identity +of the user[6]. + +The exchange consists of two messages: KRB_AS_REQ from the client to +Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these +messages are described in sections 5.4.1, 5.4.2, and 5.9.1. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +In the request, the client sends (in cleartext) its own identity and the +identity of the server for which it is requesting credentials. The +response, KRB_AS_REP, contains a ticket for the client to present to the +server, and a session key that will be shared by the client and the server. +The session key and additional information are encrypted in the client's +secret key. The KRB_AS_REP message contains information which can be used +to detect replays, and to associate it with the message to which it +replies. Various errors can occur; these are indicated by an error response +(KRB_ERROR) instead of the KRB_AS_REP response. The error message is not +encrypted. The KRB_ERROR message contains information which can be used to +associate it with the message to which it replies. The lack of encryption +in the KRB_ERROR message precludes the ability to detect replays, +fabrications, or modifications of such messages. + +Without preautentication, the authentication server does not know whether +the client is actually the principal named in the request. It simply sends +a reply without knowing or caring whether they are the same. This is +acceptable because nobody but the principal whose identity was given in the +request will be able to use the reply. Its critical information is +encrypted in that principal's key. The initial request supports an optional +field that can be used to pass additional information that might be needed +for the initial exchange. This field may be used for preauthentication as +described in section [hl<>]. + +3.1.1. Generation of KRB_AS_REQ message + +The client may specify a number of options in the initial request. Among +these options are whether pre-authentication is to be performed; whether +the requested ticket is to be renewable, proxiable, or forwardable; whether +it should be postdated or allow postdating of derivative tickets; whether +the client requests name-canonicalization; and whether a renewable ticket +will be accepted in lieu of a non-renewable ticket if the requested ticket +expiration date cannot be satisfied by a non-renewable ticket (due to +configuration constraints; see section 4). See section A.1 for pseudocode. + +The client prepares the KRB_AS_REQ message and sends it to the KDC. + +3.1.2. Receipt of KRB_AS_REQ message + +If all goes well, processing the KRB_AS_REQ message will result in the +creation of a ticket for the client to present to the server. The format +for the ticket is described in section 5.3.1. The contents of the ticket +are determined as follows. + +3.1.3. Generation of KRB_AS_REP message + +The authentication server looks up the client and server principals named +in the KRB_AS_REQ in its database, extracting their respective keys. If +the requested client principal named in the request is not found in its +database, then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is +returned. If the request had the CANONICALIZE option set, then the AS can +attempt to lookup the client principal name in an alternate database, if it +is found an error message with a KDC_ERR_WRONG_REALM error code and the +cname and crealm in the error message must contain the true client +principal name and realm. + +If required, the server pre-authenticates the request, and if the +pre-authentication check fails, an error message with the code +KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the +requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP +is returned. Otherwise it generates a 'random' session key[7]. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +If there are multiple encryption keys registered for a client in the +Kerberos database (or if the key registered supports multiple encryption +types; e.g. DES3-CBC-SHA1 and DES3-CBC-SHA1-KD), then the etype field from +the AS request is used by the KDC to select the encryption method to be +used for encrypting the response to the client. If there is more than one +supported, strong encryption type in the etype list, the first valid etype +for which an encryption key is available is used. The encryption method +used to respond to a TGS request is taken from the keytype of the session +key found in the ticket granting ticket. + + JBrezak - the behavior of PW-SALT, and ETYPE-INFO should be explained + here; also about using keys that have different string-to-key + functions like AFSsalt + +When the etype field is present in a KDC request, whether an AS or TGS +request, the KDC will attempt to assign the type of the random session key +from the list of methods in the etype field. The KDC will select the +appropriate type using the list of methods provided together with +information from the Kerberos database indicating acceptable encryption +methods for the application server. The KDC will not issue tickets with a +weak session key encryption type. + +If the requested start time is absent, indicates a time in the past, or is +within the window of acceptable clock skew for the KDC and the POSTDATE +option has not been specified, then the start time of the ticket is set to +the authentication server's current time. If it indicates a time in the +future beyond the acceptable clock skew, but the POSTDATED option has not +been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. +Otherwise the requested start time is checked against the policy of the +local realm (the administrator might decide to prohibit certain types or +ranges of postdated tickets), and if acceptable, the ticket's start time is +set as requested and the INVALID flag is set in the new ticket. The +postdated ticket must be validated before use by presenting it to the KDC +after the start time has been reached. + +The expiration time of the ticket will be set to the minimum of the +following: + + * The expiration time (endtime) requested in the KRB_AS_REQ message. + * The ticket's start time plus the maximum allowable lifetime associated + with the client principal (the authentication server's database + includes a maximum ticket lifetime field in each principal's record; + see section 4). + * The ticket's start time plus the maximum allowable lifetime associated + with the server principal. + * The ticket's start time plus the maximum lifetime set by the policy of + the local realm. + +If the requested expiration time minus the start time (as determined above) +is less than a site-determined minimum lifetime, an error message with code +KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the +ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' +option was requested, then the 'RENEWABLE' flag is set in the new ticket, +and the renew-till value is set as if the 'RENEWABLE' option were requested +(the field and option names are described fully in section 5.4.1). + +If the RENEWABLE option has been requested or if the RENEWABLE-OK option +has been set and a renewable ticket is to be issued, then the renew-till +field is set to the minimum of: + + * Its requested value. + * The start time of the ticket plus the minimum of the two maximum + renewable lifetimes associated with the principals' database entries. + * The start time of the ticket plus the maximum renewable lifetime set + by the policy of the local realm. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The flags field of the new ticket will have the following options set if +they have been requested and if the policy of the local realm allows: +FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new +ticket is post-dated (the start time is in the future), its INVALID flag +will also be set. + +If all of the above succeed, the server formats a KRB_AS_REP message (see +section 5.4.2), copying the addresses in the request into the caddr of the +response, placing any required pre-authentication data into the padata of +the response, and encrypts the ciphertext part in the client's key using +the requested encryption method, and sends it to the client. See section +A.2 for pseudocode. + +3.1.4. Generation of KRB_ERROR message + +Several errors can occur, and the Authentication Server responds by +returning an error message, KRB_ERROR, to the client, with the error-code +and e-text fields set to appropriate values. The error message contents and +details are described in Section 5.9.1. + +3.1.5. Receipt of KRB_AS_REP message + +If the reply message type is KRB_AS_REP, then the client verifies that the +cname and crealm fields in the cleartext portion of the reply match what it +requested. If any padata fields are present, they may be used to derive the +proper secret key to decrypt the message. The client decrypts the encrypted +part of the response using its secret key, verifies that the nonce in the +encrypted part matches the nonce it supplied in its request (to detect +replays). It also verifies that the sname and srealm in the response match +those in the request (or are otherwise expected values), and that the host +address field is also correct. It then stores the ticket, session key, +start and expiration times, and other information for later use. The +key-expiration field from the encrypted part of the response may be checked +to notify the user of impending key expiration (the client program could +then suggest remedial action, such as a password change). See section A.3 +for pseudocode. + +Proper decryption of the KRB_AS_REP message is not sufficient to verify the +identity of the user; the user and an attacker could cooperate to generate +a KRB_AS_REP format message which decrypts properly but is not from the +proper KDC. If the host wishes to verify the identity of the user, it must +require the user to present application credentials which can be verified +using a securely-stored secret key for the host. If those credentials can +be verified, then the identity of the user can be assured. + +3.1.6. Receipt of KRB_ERROR message + +If the reply message type is KRB_ERROR, then the client interprets it as an +error and performs whatever application-specific tasks are necessary to +recover. If the client set the CANONICALIZE option and a +KDC_ERR_WRONG_REALM error was returned, the AS request should be retried to +the realm and client principal name specified in the error message crealm +and cname field respectively. + +3.2. The Client/Server Authentication Exchange + + Summary +Message direction Message type Section +Client to Application server KRB_AP_REQ 5.5.1 +[optional] Application server to client KRB_AP_REP or 5.5.2 + KRB_ERROR 5.9.1 + +The client/server authentication (CS) exchange is used by network +applications to authenticate the client to the server and vice versa. The +client must have already acquired credentials for the server using the AS +or TGS exchange. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.2.1. The KRB_AP_REQ message + +The KRB_AP_REQ contains authentication information which should be part of +the first message in an authenticated transaction. It contains a ticket, an +authenticator, and some additional bookkeeping information (see section +5.5.1 for the exact format). The ticket by itself is insufficient to +authenticate a client, since tickets are passed across the network in +cleartext[DS90], so the authenticator is used to prevent invalid replay of +tickets by proving to the server that the client knows the session key of +the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message +is referred to elsewhere as the 'authentication header.' + +3.2.2. Generation of a KRB_AP_REQ message + +When a client wishes to initiate authentication to a server, it obtains +(either through a credentials cache, the AS exchange, or the TGS exchange) +a ticket and session key for the desired service. The client may re-use any +tickets it holds until they expire. To use a ticket the client constructs a +new Authenticator from the the system time, its name, and optionally an +application specific checksum, an initial sequence number to be used in +KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in +negotiations for a session key unique to this particular session. +Authenticators may not be re-used and will be rejected if replayed to a +server[LGDSR87]. If a sequence number is to be included, it should be +randomly chosen so that even after many messages have been exchanged it is +not likely to collide with other sequence numbers in use. + +The client may indicate a requirement of mutual authentication or the use +of a session-key based ticket by setting the appropriate flag(s) in the +ap-options field of the message. + +The Authenticator is encrypted in the session key and combined with the +ticket to form the KRB_AP_REQ message which is then sent to the end server +along with any additional application-specific information. See section A.9 +for pseudocode. + +3.2.3. Receipt of KRB_AP_REQ message + +Authentication is based on the server's current time of day (clocks must be +loosely synchronized), the authenticator, and the ticket. Several errors +are possible. If an error occurs, the server is expected to reply to the +client with a KRB_ERROR message. This message may be encapsulated in the +application protocol if its 'raw' form is not acceptable to the protocol. +The format of error messages is described in section 5.9.1. + +The algorithm for verifying authentication information is as follows. If +the message type is not KRB_AP_REQ, the server returns the +KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket in +the KRB_AP_REQ is not one the server can use (e.g., it indicates an old +key, and the server no longer possesses a copy of the old key), the +KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-KEY flag is set +in the ap-options field, it indicates to the server that the ticket is +encrypted in the session key from the server's ticket-granting ticket +rather than its secret key[10]. Since it is possible for the server to be +registered in multiple realms, with different keys in each, the srealm +field in the unencrypted portion of the ticket in the KRB_AP_REQ is used to +specify which secret key the server should use to decrypt that ticket. The +KRB_AP_ERR_NOKEY error code is returned if the server doesn't have the +proper key to decipher the ticket. + +The ticket is decrypted using the version of the server's key specified by +the ticket. If the decryption routines detect a modification of the ticket +(each encryption system must provide safeguards to detect modified +ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned +(chances are good that different keys were used to encrypt and decrypt). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The authenticator is decrypted using the session key extracted from the +decrypted ticket. If decryption shows it to have been modified, the +KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the +client from the ticket are compared against the same fields in the +authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is +returned (they might not match, for example, if the wrong session key was +used to encrypt the authenticator). The addresses in the ticket (if any) +are then searched for an address matching the operating-system reported +address of the client. If no match is found or the server insists on ticket +addresses but none are present in the ticket, the KRB_AP_ERR_BADADDR error +is returned. + +If the local (server) time and the client time in the authenticator differ +by more than the allowable clock skew (e.g., 5 minutes), the +KRB_AP_ERR_SKEW error is returned. If the server name, along with the +client name, time and microsecond fields from the Authenticator match any +recently-seen such tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The +server must remember any authenticator presented within the allowable clock +skew, so that a replay attempt is guaranteed to fail. If a server loses +track of any authenticator presented within the allowable clock skew, it +must reject all requests until the clock skew interval has passed. This +assures that any lost or re-played authenticators will fall outside the +allowable clock skew and can no longer be successfully replayed (If this is +not done, an attacker could conceivably record the ticket and authenticator +sent over the network to a server, then disable the client's host, pose as +the disabled host, and replay the ticket and authenticator to subvert the +authentication.). If a sequence number is provided in the authenticator, +the server saves it for later use in processing KRB_SAFE and/or KRB_PRIV +messages. If a subkey is present, the server either saves it for later use +or uses it to help generate its own choice for a subkey to be returned in a +KRB_AP_REP message. + +The server computes the age of the ticket: local (server) time minus the +start time inside the Ticket. If the start time is later than the current +time by more than the allowable clock skew or if the INVALID flag is set in +the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the +current time is later than end time by more than the allowable clock skew, +the KRB_AP_ERR_TKT_EXPIRED error is returned. + +If all these checks succeed without an error, the server is assured that +the client possesses the credentials of the principal named in the ticket +and thus, the client has been authenticated to the server. See section A.10 +for pseudocode. + +Passing these checks provides only authentication of the named principal; +it does not imply authorization to use the named service. Applications must +make a separate authorization decisions based upon the authenticated name +of the user, the requested operation, local acces control information such +as that contained in a .k5login or .k5users file, and possibly a separate +distributed authorization service. + +3.2.4. Generation of a KRB_AP_REP message + +Typically, a client's request will include both the authentication +information and its initial request in the same message, and the server +need not explicitly reply to the KRB_AP_REQ. However, if mutual +authentication (not only authenticating the client to the server, but also +the server to the client) is being performed, the KRB_AP_REQ message will + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +have MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message +is required in response. As with the error message, this message may be +encapsulated in the application protocol if its "raw" form is not +acceptable to the application's protocol. The timestamp and microsecond +field used in the reply must be the client's timestamp and microsecond +field (as provided in the authenticator)[12]. If a sequence number is to be +included, it should be randomly chosen as described above for the +authenticator. A subkey may be included if the server desires to negotiate +a different subkey. The KRB_AP_REP message is encrypted in the session key +extracted from the ticket. See section A.11 for pseudocode. + +3.2.5. Receipt of KRB_AP_REP message + +If a KRB_AP_REP message is returned, the client uses the session key from +the credentials obtained for the server[13] to decrypt the message, and +verifies that the timestamp and microsecond fields match those in the +Authenticator it sent to the server. If they match, then the client is +assured that the server is genuine. The sequence number and subkey (if +present) are retained for later use. See section A.12 for pseudocode. + +3.2.6. Using the encryption key + +After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and +server share an encryption key which can be used by the application. The +'true session key' to be used for KRB_PRIV, KRB_SAFE, or other +application-specific uses may be chosen by the application based on the +subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases, +the use of this session key will be implicit in the protocol; in others the +method of use must be chosen from several alternatives. We leave the +protocol negotiations of how to use the key (e.g. selecting an encryption +or checksum type) to the application programmer; the Kerberos protocol does +not constrain the implementation options, but an example of how this might +be done follows. + +One way that an application may choose to negotiate a key to be used for +subequent integrity and privacy protection is for the client to propose a +key in the subkey field of the authenticator. The server can then choose a +key using the proposed key from the client as input, returning the new +subkey in the subkey field of the application reply. This key could then be +used for subsequent communication. To make this example more concrete, if +the encryption method in use required a 56 bit key, and for whatever +reason, one of the parties was prevented from using a key with more than 40 +unknown bits, this method would allow the the party which is prevented from +using more than 40 bits to either propose (if the client) an initial key +with a known quantity for 16 of those bits, or to mask 16 of the bits (if +the server) with the known quantity. The application implementor is warned, +however, that this is only an example, and that an analysis of the +particular crytosystem to be used, and the reasons for limiting the key +length, must be made before deciding whether it is acceptable to mask bits +of the key. + +With both the one-way and mutual authentication exchanges, the peers should +take care not to send sensitive information to each other without proper +assurances. In particular, applications that require privacy or integrity +should use the KRB_AP_REP response from the server to client to assure both +client and server of their peer's identity. If an application protocol +requires privacy of its messages, it can use the KRB_PRIV message (section +3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.3. The Ticket-Granting Service (TGS) Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_TGS_REQ 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 5.4.2 + KRB_ERROR 5.9.1 + +The TGS exchange between a client and the Kerberos Ticket-Granting Server +is initiated by a client when it wishes to obtain authentication +credentials for a given server (which might be registered in a remote +realm), when it wishes to renew or validate an existing ticket, or when it +wishes to obtain a proxy ticket. In the first case, the client must already +have acquired a ticket for the Ticket-Granting Service using the AS +exchange (the ticket-granting ticket is usually obtained when a client +initially authenticates to the system, such as when a user logs in). The +message format for the TGS exchange is almost identical to that for the AS +exchange. The primary difference is that encryption and decryption in the +TGS exchange does not take place under the client's key. Instead, the +session key from the ticket-granting ticket or renewable ticket, or +sub-session key from an Authenticator is used. As is the case for all +application servers, expired tickets are not accepted by the TGS, so once a +renewable or ticket-granting ticket expires, the client must use a separate +exchange to obtain valid tickets. + +The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the +client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or +KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the +client plus a request for credentials. The authentication information +consists of the authentication header (KRB_AP_REQ) which includes the +client's previously obtained ticket-granting, renewable, or invalid ticket. +In the ticket-granting ticket and proxy cases, the request may include one +or more of: a list of network addresses, a collection of typed +authorization data to be sealed in the ticket for authorization use by the +application server, or additional tickets (the use of which are described +later). The TGS reply (KRB_TGS_REP) contains the requested credentials, +encrypted in the session key from the ticket-granting ticket or renewable +ticket, or if present, in the sub-session key from the Authenticator (part +of the authentication header). The KRB_ERROR message contains an error code +and text explaining what went wrong. The KRB_ERROR message is not +encrypted. The KRB_TGS_REP message contains information which can be used +to detect replays, and to associate it with the message to which it +replies. The KRB_ERROR message also contains information which can be used +to associate it with the message to which it replies, but the lack of +encryption in the KRB_ERROR message precludes the ability to detect replays +or fabrications of such messages. + +3.3.1. Generation of KRB_TGS_REQ message + +Before sending a request to the ticket-granting service, the client must +determine in which realm the application server is registered[15], if it is +known. If the client does know the service principal name and realm and it +does not already possess a ticket-granting ticket for the appropriate +realm, then one must be obtained. This is first attempted by requesting a +ticket-granting ticket for the destination realm from a Kerberos server for +which the client does posess a ticket-granting ticket (using the +KRB_TGS_REQ message recursively). The Kerberos server may return a TGT for +the desired realm in which case one can proceed. + +If the client does not know the realm of the service or the true service +principal name, then the CANONICALIZE option must be used in the request. +This will cause the TGS to locate the service principal based on the target +service name in the ticket and return the service principal name in the +response. Alternatively, the Kerberos server may return a TGT for a realm +which is 'closer' to the desired realm (further along the standard + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +hierarchical path) or the realm that may contain the requested service +principal name in a request with the CANONCALIZE option set [JBrezak], in +which case this step must be repeated with a Kerberos server in the realm +specified in the returned TGT. If neither are returned, then the request +must be retried with a Kerberos server for a realm higher in the hierarchy. +This request will itself require a ticket-granting ticket for the higher +realm which must be obtained by recursively applying these directions. + +Once the client obtains a ticket-granting ticket for the appropriate realm, +it determines which Kerberos servers serve that realm, and contacts one. +The list might be obtained through a configuration file or network service +or it may be generated from the name of the realm; as long as the secret +keys exchanged by realms are kept secret, only denial of service results +from using a false Kerberos server. + +As in the AS exchange, the client may specify a number of options in the +KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing +an authentication header as an element of the padata field, and including +the same fields as used in the KRB_AS_REQ message along with several +optional fields: the enc-authorization-data field for application server +use and additional tickets required by some options. + +In preparing the authentication header, the client can select a sub-session +key under which the response from the Kerberos server will be +encrypted[16]. If the sub-session key is not specified, the session key +from the ticket-granting ticket will be used. If the enc-authorization-data +is present, it must be encrypted in the sub-session key, if present, from +the authenticator portion of the authentication header, or if not present, +using the session key from the ticket-granting ticket. + +Once prepared, the message is sent to a Kerberos server for the destination +realm. See section A.5 for pseudocode. + +3.3.2. Receipt of KRB_TGS_REQ message + +The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ +message, but there are many additional checks to be performed. First, the +Kerberos server must determine which server the accompanying ticket is for +and it must select the appropriate key to decrypt it. For a normal +KRB_TGS_REQ message, it will be for the ticket granting service, and the +TGS's key will be used. If the TGT was issued by another realm, then the +appropriate inter-realm key must be used. If the accompanying ticket is not +a ticket granting ticket for the current realm, but is for an application +server in the current realm, the RENEW, VALIDATE, or PROXY options are +specified in the request, and the server for which a ticket is requested is +the server named in the accompanying ticket, then the KDC will decrypt the +ticket in the authentication header using the key of the server for which +it was issued. If no ticket can be found in the padata field, the +KDC_ERR_PADATA_TYPE_NOSUPP error is returned. + +Once the accompanying ticket has been decrypted, the user-supplied checksum +in the Authenticator must be verified against the contents of the request, +and the message rejected if the checksums do not match (with an error code +of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not +collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the +checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is +returned. If the authorization-data are present, they are decrypted using +the sub-session key from the Authenticator. + +If any of the decryptions indicate failed integrity checks, the +KRB_AP_ERR_BAD_INTEGRITY error is returned. If the CANONICALIZE option is +set in the KRB_TGS_REQ, then the requested service name may not be the true +principal name or the service may not be in the TGS realm. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.3.3. Generation of KRB_TGS_REP message + +The KRB_TGS_REP message shares its format with the KRB_AS_REP +(KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The detailed +specification is in section 5.4.2. + +The response will include a ticket for the requested server. The Kerberos +database is queried to retrieve the record for the requested server +(including the key with which the ticket will be encrypted). If the request +is for a ticket granting ticket for a remote realm, and if no key is shared +with the requested realm, then the Kerberos server will select the realm +"closest" to the requested realm with which it does share a key, and use +that realm instead. If the CANONICALIZE option is set, the TGS may return a +ticket containing the server name of the true service principal. If the +requested server cannot be found in the TGS database, then a TGT for +another trusted realm may be returned instead of a ticket for the service. +This TGT is a referral mechanism to cause the client to retry the request +to the realm of the TGT. These are the only cases where the response for +the KDC will be for a different server than that requested by the client. + +By default, the address field, the client's name and realm, the list of +transited realms, the time of initial authentication, the expiration time, +and the authorization data of the newly-issued ticket will be copied from +the ticket-granting ticket (TGT) or renewable ticket. If the transited +field needs to be updated, but the transited type is not supported, the +KDC_ERR_TRTYPE_NOSUPP error is returned. + +If the request specifies an endtime, then the endtime of the new ticket is +set to the minimum of (a) that request, (b) the endtime from the TGT, and +(c) the starttime of the TGT plus the minimum of the maximum life for the +application server and the maximum life for the local realm (the maximum +life for the requesting principal was already applied when the TGT was +issued). If the new ticket is to be a renewal, then the endtime above is +replaced by the minimum of (a) the value of the renew_till field of the +ticket and (b) the starttime for the new ticket plus the life +(endtime-starttime) of the old ticket. + +If the FORWARDED option has been requested, then the resulting ticket will +contain the addresses specified by the client. This option will only be +honored if the FORWARDABLE flag is set in the TGT. The PROXY option is +similar; the resulting ticket will contain the addresses specified by the +client. It will be honored only if the PROXIABLE flag in the TGT is set. +The PROXY option will not be honored on requests for additional +ticket-granting tickets. + +If the requested start time is absent, indicates a time in the past, or is +within the window of acceptable clock skew for the KDC and the POSTDATE +option has not been specified, then the start time of the ticket is set to +the authentication server's current time. If it indicates a time in the +future beyond the acceptable clock skew, but the POSTDATED option has not +been specified or the MAY-POSTDATE flag is not set in the TGT, then the +error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the +ticket-granting ticket has the MAY-POSTDATE flag set, then the resulting +ticket will be postdated and the requested starttime is checked against the +policy of the local realm. If acceptable, the ticket's start time is set as +requested, and the INVALID flag is set. The postdated ticket must be +validated before use by presenting it to the KDC after the starttime has +been reached. However, in no case may the starttime, endtime, or renew-till +time of a newly-issued postdated ticket extend beyond the renew-till time +of the ticket-granting ticket. + +If the ENC-TKT-IN-SKEY option has been specified and an additional ticket +has been included in the request, the KDC will decrypt the additional +ticket using the key for the server to which the additional ticket was +issued and verify that it is a ticket-granting ticket. If the name of the + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +requested server is missing from the request, the name of the client in the +additional ticket will be used. Otherwise the name of the requested server +will be compared to the name of the client in the additional ticket and if +different, the request will be rejected. If the request succeeds, the +session key from the additional ticket will be used to encrypt the new +ticket that is issued instead of using the key of the server for which the +new ticket will be used[17]. + +If the name of the server in the ticket that is presented to the KDC as +part of the authentication header is not that of the ticket-granting server +itself, the server is registered in the realm of the KDC, and the RENEW +option is requested, then the KDC will verify that the RENEWABLE flag is +set in the ticket, that the INVALID flag is not set in the ticket, and that +the renew_till time is still in the future. If the VALIDATE option is +rqeuested, the KDC will check that the starttime has passed and the INVALID +flag is set. If the PROXY option is requested, then the KDC will check that +the PROXIABLE flag is set in the ticket. If the tests succeed, and the +ticket passes the hotlist check described in the next paragraph, the KDC +will issue the appropriate new ticket. + +3.3.3.1. Checking for revoked tickets + +Whenever a request is made to the ticket-granting server, the presented +ticket(s) is(are) checked against a hot-list of tickets which have been +canceled. This hot-list might be implemented by storing a range of issue +timestamps for 'suspect tickets'; if a presented ticket had an authtime in +that range, it would be rejected. In this way, a stolen ticket-granting +ticket or renewable ticket cannot be used to gain additional tickets +(renewals or otherwise) once the theft has been reported. Any normal ticket +obtained before it was reported stolen will still be valid (because they +require no interaction with the KDC), but only until their normal +expiration time. + +The ciphertext part of the response in the KRB_TGS_REP message is encrypted +in the sub-session key from the Authenticator, if present, or the session +key key from the ticket-granting ticket. It is not encrypted using the +client's secret key. Furthermore, the client's key's expiration date and +the key version number fields are left out since these values are stored +along with the client's database record, and that record is not needed to +satisfy a request based on a ticket-granting ticket. See section A.6 for +pseudocode. + +3.3.3.2. Encoding the transited field + +If the identity of the server in the TGT that is presented to the KDC as +part of the authentication header is that of the ticket-granting service, +but the TGT was issued from another realm, the KDC will look up the +inter-realm key shared with that realm and use that key to decrypt the +ticket. If the ticket is valid, then the KDC will honor the request, +subject to the constraints outlined above in the section describing the AS +exchange. The realm part of the client's identity will be taken from the +ticket-granting ticket. The name of the realm that issued the +ticket-granting ticket will be added to the transited field of the ticket +to be issued. This is accomplished by reading the transited field from the +ticket-granting ticket (which is treated as an unordered set of realm +names), adding the new realm to the set, then constructing and writing out +its encoded (shorthand) form (this may involve a rearrangement of the +existing encoding). + +Note that the ticket-granting service does not add the name of its own +realm. Instead, its responsibility is to add the name of the previous +realm. This prevents a malicious Kerberos server from intentionally leaving +out its own name (it could, however, omit other realms' names). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The names of neither the local realm nor the principal's realm are to be +included in the transited field. They appear elsewhere in the ticket and +both are known to have taken part in authenticating the principal. Since +the endpoints are not included, both local and single-hop inter-realm +authentication result in a transited field that is empty. + +Because the name of each realm transited is added to this field, it might +potentially be very long. To decrease the length of this field, its +contents are encoded. The initially supported encoding is optimized for the +normal case of inter-realm communication: a hierarchical arrangement of +realms using either domain or X.500 style realm names. This encoding +(called DOMAIN-X500-COMPRESS) is now described. + +Realm names in the transited field are separated by a ",". The ",", "\", +trailing "."s, and leading spaces (" ") are special characters, and if they +are part of a realm name, they must be quoted in the transited field by +preced- ing them with a "\". + +A realm name ending with a "." is interpreted as being prepended to the +previous realm. For example, we can encode traversal of EDU, MIT.EDU, +ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: + + "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". + +Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that +they would not be included in this field, and we would have: + + "EDU,MIT.,WASHINGTON.EDU" + +A realm name beginning with a "/" is interpreted as being appended to the +previous realm[18]. If it is to stand by itself, then it should be preceded +by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, +/COM/HP, /COM, and /COM/DEC as: + + "/COM,/HP,/APOLLO, /COM/DEC". + +Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they +they would not be included in this field, and we would have: + + "/COM,/HP" + +A null subfield preceding or following a "," indicates that all realms +between the previous realm and the next realm have been traversed[19]. +Thus, "," means that all realms along the path between the client and the +server have been traversed. ",EDU, /COM," means that that all realms from +the client's realm up to EDU (in a domain style hierarchy) have been +traversed, and that everything from /COM down to the server's realm in an +X.500 style has also been traversed. This could occur if the EDU realm in +one hierarchy shares an inter-realm key directly with the /COM realm in +another hierarchy. + +3.3.4. Receipt of KRB_TGS_REP message + +When the KRB_TGS_REP is received by the client, it is processed in the same +manner as the KRB_AS_REP processing described above. The primary difference +is that the ciphertext part of the response must be decrypted using the +session key from the ticket-granting ticket rather than the client's secret +key. The server name returned in the reply is the true principal name of +the service. See section A.7 for pseudocode. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.4. The KRB_SAFE Exchange + +The KRB_SAFE message may be used by clients requiring the ability to detect +modifications of messages they exchange. It achieves this by including a +keyed collision-proof checksum of the user data and some control +information. The checksum is keyed with an encryption key (usually the last +key negotiated via subkeys, or the session key if no negotiation has +occured). + +3.4.1. Generation of a KRB_SAFE message + +When an application wishes to send a KRB_SAFE message, it collects its data +and the appropriate control information and computes a checksum over them. +The checksum algorithm should be a keyed one-way hash function (such as the +RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES +MAC), generated using the sub-session key if present, or the session key. +Different algorithms may be selected by changing the checksum type in the +message. Unkeyed or non-collision-proof checksums are not suitable for this +use. + +The control information for the KRB_SAFE message includes both a timestamp +and a sequence number. The designer of an application using the KRB_SAFE +message must choose at least one of the two mechanisms. This choice should +be based on the needs of the application protocol. + +Sequence numbers are useful when all messages sent will be received by +one's peer. Connection state is presently required to maintain the session +key, so maintaining the next sequence number should not present an +additional problem. + +If the application protocol is expected to tolerate lost messages without +them being resent, the use of the timestamp is the appropriate replay +detection mechanism. Using timestamps is also the appropriate mechanism for +multi-cast protocols where all of one's peers share a common sub-session +key, but some messages will be sent to a subset of one's peers. + +After computing the checksum, the client then transmits the information and +checksum to the recipient in the message format specified in section 5.6.1. + +3.4.2. Receipt of KRB_SAFE message + +When an application receives a KRB_SAFE message, it verifies it as follows. +If any error occurs, an error code is reported for use by the application. + +The message is first checked by verifying that the protocol version and +type fields match the current version and KRB_SAFE, respectively. A +mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. +The application verifies that the checksum used is a collision-proof keyed +checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If +the sender's address was included in the control information, the recipient +verifies that the operating system's report of the sender's address matches +the sender's address in the message, and (if a recipient address is +specified or the recipient requires an address) that one of the recipient's +addresses appears as the recipient's address in the message. A failed match +for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp +and usec and/or the sequence number fields are checked. If timestamp and +usec are expected and not present, or they are present but not current, the +KRB_AP_ERR_SKEW error is generated. If the server name, along with the +client name, time and microsecond fields from the Authenticator match any +recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT +error is generated. If an incorrect sequence number is included, or a +sequence number is expected but not present, the KRB_AP_ERR_BADORDER error +is generated. If neither a time-stamp and usec or a sequence number is +present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is +computed over the data and control information, and if it doesn't match the +received checksum, a KRB_AP_ERR_MODIFIED error is generated. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +If all the checks succeed, the application is assured that the message was +generated by its peer and was not modi- fied in transit. + +3.5. The KRB_PRIV Exchange + +The KRB_PRIV message may be used by clients requiring confidentiality and +the ability to detect modifications of exchanged messages. It achieves this +by encrypting the messages and adding control information. + +3.5.1. Generation of a KRB_PRIV message + +When an application wishes to send a KRB_PRIV message, it collects its data +and the appropriate control information (specified in section 5.7.1) and +encrypts them under an encryption key (usually the last key negotiated via +subkeys, or the session key if no negotiation has occured). As part of the +control information, the client must choose to use either a timestamp or a +sequence number (or both); see the discussion in section 3.4.1 for +guidelines on which to use. After the user data and control information are +encrypted, the client transmits the ciphertext and some 'envelope' +information to the recipient. + +3.5.2. Receipt of KRB_PRIV message + +When an application receives a KRB_PRIV message, it verifies it as follows. +If any error occurs, an error code is reported for use by the application. + +The message is first checked by verifying that the protocol version and +type fields match the current version and KRB_PRIV, respectively. A +mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. +The application then decrypts the ciphertext and processes the resultant +plaintext. If decryption shows the data to have been modified, a +KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was +included in the control information, the recipient verifies that the +operating system's report of the sender's address matches the sender's +address in the message, and (if a recipient address is specified or the +recipient requires an address) that one of the recipient's addresses +appears as the recipient's address in the message. A failed match for +either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and +usec and/or the sequence number fields are checked. If timestamp and usec +are expected and not present, or they are present but not current, the +KRB_AP_ERR_SKEW error is generated. If the server name, along with the +client name, time and microsecond fields from the Authenticator match any +recently-seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an +incorrect sequence number is included, or a sequence number is expected but +not present, the KRB_AP_ERR_BADORDER error is generated. If neither a +time-stamp and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED +error is generated. + +If all the checks succeed, the application can assume the message was +generated by its peer, and was securely transmitted (without intruders able +to see the unencrypted contents). + +3.6. The KRB_CRED Exchange + +The KRB_CRED message may be used by clients requiring the ability to send +Kerberos credentials from one host to another. It achieves this by sending +the tickets together with encrypted data containing the session keys and +other information associated with the tickets. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.6.1. Generation of a KRB_CRED message + +When an application wishes to send a KRB_CRED message it first (using the +KRB_TGS exchange) obtains credentials to be sent to the remote host. It +then constructs a KRB_CRED message using the ticket or tickets so obtained, +placing the session key needed to use each ticket in the key field of the +corresponding KrbCredInfo sequence of the encrypted part of the the +KRB_CRED message. + +Other information associated with each ticket and obtained during the +KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence +in the encrypted part of the KRB_CRED message. The current time and, if +specifically required by the application the nonce, s-address, and +r-address fields, are placed in the encrypted part of the KRB_CRED message +which is then encrypted under an encryption key previosuly exchanged in the +KRB_AP exchange (usually the last key negotiated via subkeys, or the +session key if no negotiation has occured). + +3.6.2. Receipt of KRB_CRED message + +When an application receives a KRB_CRED message, it verifies it. If any +error occurs, an error code is reported for use by the application. The +message is verified by checking that the protocol version and type fields +match the current version and KRB_CRED, respectively. A mismatch generates +a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then +decrypts the ciphertext and processes the resultant plaintext. If +decryption shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY +error is generated. + +If present or required, the recipient verifies that the operating system's +report of the sender's address matches the sender's address in the message, +and that one of the recipient's addresses appears as the recipient's +address in the message. A failed match for either case generates a +KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce +field if required) are checked next. If the timestamp and usec are not +present, or they are present but not current, the KRB_AP_ERR_SKEW error is +generated. + +If all the checks succeed, the application stores each of the new tickets +in its ticket cache together with the session key and other information in +the corresponding KrbCredInfo sequence from the encrypted part of the +KRB_CRED message. + +4. The Kerberos Database + +The Kerberos server must have access to a database containing the principal +identifiers and secret keys of principals to be authenticated[21]. + +4.1. Database contents + +A database entry should contain at least the following fields: + +Field Value + +name Principal's identifier +key Principal's secret key +p_kvno Principal's key version +max_life Maximum lifetime for Tickets +max_renewable_life Maximum total lifetime for renewable Tickets + +The name field is an encoding of the principal's identifier. The key field +contains an encryption key. This key is the principal's secret key. (The +key can be encrypted before storage under a Kerberos "master key" to +protect it in case the database is compromised but the master key is not. +In that case, an extra field must be added to indicate the master key + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +version used, see below.) The p_kvno field is the key version number of the +principal's secret key. The max_life field contains the maximum allowable +lifetime (endtime - starttime) for any Ticket issued for this principal. +The max_renewable_life field contains the maximum allowable total lifetime +for any renewable Ticket issued for this principal. (See section 3.1 for a +description of how these lifetimes are used in determining the lifetime of +a given Ticket.) + +A server may provide KDC service to several realms, as long as the database +representation provides a mechanism to distinguish between principal +records with identifiers which differ only in the realm name. + +When an application server's key changes, if the change is routine (i.e. +not the result of disclosure of the old key), the old key should be +retained by the server until all tickets that had been issued using that +key have expired. Because of this, it is possible for several keys to be +active for a single principal. Ciphertext encrypted in a principal's key is +always tagged with the version of the key that was used for encryption, to +help the recipient find the proper key for decryption. + +When more than one key is active for a particular principal, the principal +will have more than one record in the Kerberos database. The keys and key +version numbers will differ between the records (the rest of the fields may +or may not be the same). Whenever Kerberos issues a ticket, or responds to +a request for initial authentication, the most recent key (known by the +Kerberos server) will be used for encryption. This is the key with the +highest key version number. + +4.2. Additional fields + +Project Athena's KDC implementation uses additional fields in its database: + +Field Value + +K_kvno Kerberos' key version +expiration Expiration date for entry +attributes Bit field of attributes +mod_date Timestamp of last modification +mod_name Modifying principal's identifier + +The K_kvno field indicates the key version of the Kerberos master key under +which the principal's secret key is encrypted. + +After an entry's expiration date has passed, the KDC will return an error +to any client attempting to gain tickets as or for the principal. (A +database may want to maintain two expiration dates: one for the principal, +and one for the principal's current key. This allows password aging to work +independently of the principal's expiration date. However, due to the +limited space in the responses, the KDC must combine the key expiration and +principal expiration date into a single value called 'key_exp', which is +used as a hint to the user to take administrative action.) + +The attributes field is a bitfield used to govern the operations involving +the principal. This field might be useful in conjunction with user +registration procedures, for site-specific policy implementations (Project +Athena currently uses it for their user registration process controlled by +the system-wide database service, Moira [LGDSR87]), to identify whether a +principal can play the role of a client or server or both, to note whether +a server is appropriate trusted to recieve credentials delegated by a +client, or to identify the 'string to key' conversion algorithm used for a +principal's key[22]. Other bits are used to indicate that certain ticket +options should not be allowed in tickets encrypted under a principal's key +(one bit each): Disallow issuing postdated tickets, disallow issuing +forwardable tickets, disallow issuing tickets based on TGT authentication, +disallow issuing renewable tickets, disallow issuing proxiable tickets, and +disallow issuing tickets for which the principal is the server. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The mod_date field contains the time of last modification of the entry, and +the mod_name field contains the name of the principal which last modified +the entry. + +4.3. Frequently Changing Fields + +Some KDC implementations may wish to maintain the last time that a request +was made by a particular principal. Information that might be maintained +includes the time of the last request, the time of the last request for a +ticket-granting ticket, the time of the last use of a ticket-granting +ticket, or other times. This information can then be returned to the user +in the last-req field (see section 5.2). + +Other frequently changing information that can be maintained is the latest +expiration time for any tickets that have been issued using each key. This +field would be used to indicate how long old keys must remain valid to +allow the continued use of outstanding tickets. + +4.4. Site Constants + +The KDC implementation should have the following configurable constants or +options, to allow an administrator to make and enforce policy decisions: + + * The minimum supported lifetime (used to determine whether the + KDC_ERR_NEVER_VALID error should be returned). This constant should + reflect reasonable expectations of round-trip time to the KDC, + encryption/decryption time, and processing time by the client and + target server, and it should allow for a minimum 'useful' lifetime. + * The maximum allowable total (renewable) lifetime of a ticket + (renew_till - starttime). + * The maximum allowable lifetime of a ticket (endtime - starttime). + * Whether to allow the issue of tickets with empty address fields + (including the ability to specify that such tickets may only be issued + if the request specifies some authorization_data). + * Whether proxiable, forwardable, renewable or post-datable tickets are + to be issued. + +5. Message Specifications + +The following sections describe the exact contents and encoding of protocol +messages and objects. The ASN.1 base definitions are presented in the first +subsection. The remaining subsections specify the protocol objects (tickets +and authenticators) and messages. Specification of encryption and checksum +techniques, and the fields related to them, appear in section 6. + +Optional field in ASN.1 sequences + +For optional integer value and date fields in ASN.1 sequences where a +default value has been specified, certain default values will not be +allowed in the encoding because these values will always be represented +through defaulting by the absence of the optional field. For example, one +will not send a microsecond zero value because one must make sure that +there is only one way to encode this value. + +Additional fields in ASN.1 sequences + +Implementations receiving Kerberos messages with additional fields present +in ASN.1 sequences should carry the those fields through, unmodified, when +the message is forwarded. Implementations should not drop such fields if +the sequence is reencoded. + +5.1. ASN.1 Distinguished Encoding Representation + +All uses of ASN.1 in Kerberos shall use the Distinguished Encoding +Representation of the data elements as described in the X.509 +specification, section 8.7 [X509-88]. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.2. ASN.1 Base Definitions + +The following ASN.1 base definitions are used in the rest of this section. +Note that since the underscore character (_) is not permitted in ASN.1 +names, the hyphen (-) is used in its place for the purposes of ASN.1 names. + +Realm ::= GeneralString +PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString +} + +Kerberos realms are encoded as GeneralStrings. Realms shall not contain a +character with the code 0 (the ASCII NUL). Most realms will usually consist +of several components separated by periods (.), in the style of Internet +Domain Names, or separated by slashes (/) in the style of X.500 names. +Acceptable forms for realm names are specified in section 7. A +PrincipalName is a typed sequence of components consisting of the following +sub-fields: + +name-type + This field specifies the type of name that follows. Pre-defined values + for this field are specified in section 7.2. The name-type should be + treated as a hint. Ignoring the name type, no two names can be the + same (i.e. at least one of the components, or the realm, must be + different). This constraint may be eliminated in the future. +name-string + This field encodes a sequence of components that form a name, each + component encoded as a GeneralString. Taken together, a PrincipalName + and a Realm form a principal identifier. Most PrincipalNames will have + only a few components (typically one or two). + +KerberosTime ::= GeneralizedTime + -- Specifying UTC time zone (Z) + +The timestamps used in Kerberos are encoded as GeneralizedTimes. An +encoding shall specify the UTC time zone (Z) and shall not include any +fractional portions of the seconds. It further shall not include any +separators. Example: The only valid format for UTC time 6 minutes, 27 +seconds after 9 pm on 6 November 1985 is 19851106210627Z. + +HostAddress ::= SEQUENCE { + addr-type[0] INTEGER, + address[1] OCTET STRING +} + +HostAddresses ::= SEQUENCE OF HostAddress + +The host adddress encodings consists of two fields: + +addr-type + This field specifies the type of address that follows. Pre-defined + values for this field are specified in section 8.1. +address + This field encodes a single address of type addr-type. + +The two forms differ slightly. HostAddress contains exactly one address; +HostAddresses contains a sequence of possibly many addresses. + +AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type[0] INTEGER, + ad-data[1] OCTET STRING +} + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +ad-data + This field contains authorization data to be interpreted according to + the value of the corresponding ad-type field. +ad-type + This field specifies the format for the ad-data subfield. All negative + values are reserved for local use. Non-negative values are reserved + for registered use. + +Each sequence of type and data is refered to as an authorization element. +Elements may be application specific, however, there is a common set of +recursive elements that should be understood by all implementations. These +elements contain other elements embedded within them, and the +interpretation of the encapsulating element determines which of the +embedded elements must be interpreted, and which may be ignored. +Definitions for these common elements may be found in Appendix B. + +TicketExtensions ::= SEQUENCE OF SEQUENCE { + te-type[0] INTEGER, + te-data[1] OCTET STRING +} + + + +te-data + This field contains opaque data that must be caried with the ticket to + support extensions to the Kerberos protocol including but not limited + to some forms of inter-realm key exchange and plaintext authorization + data. See appendix C for some common uses of this field. +te-type + This field specifies the format for the te-data subfield. All negative + values are reserved for local use. Non-negative values are reserved + for registered use. + +APOptions ::= BIT STRING + -- reserved(0), + -- use-session-key(1), + -- mutual-required(2) + +TicketFlags ::= BIT STRING + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- may-postdate(5), + -- postdated(6), + -- invalid(7), + -- renewable(8), + -- initial(9), + -- pre-authent(10), + -- hw-authent(11), + -- transited-policy-checked(12), + -- ok-as-delegate(13) + +KDCOptions ::= BIT STRING io + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- allow-postdate(5), + -- postdated(6), + -- unused7(7), + -- renewable(8), + -- unused9(9), + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + -- unused10(10), + -- unused11(11), + -- unused12(12), + -- unused13(13), + -- requestanonymous(14), + -- canonicalize(15), + -- disable-transited-check(26), + -- renewable-ok(27), + -- enc-tkt-in-skey(28), + -- renew(30), + -- validate(31) + +ASN.1 Bit strings have a length and a value. When used in Kerberos for the +APOptions, TicketFlags, and KDCOptions, the length of the bit string on +generated values should be the smallest number of bits needed to include +the highest order bit that is set (1), but in no case less than 32 bits. +The ASN.1 representation of the bit strings uses unnamed bits, with the +meaning of the individual bits defined by the comments in the specification +above. Implementations should accept values of bit strings of any length +and treat the value of flags corresponding to bits beyond the end of the +bit string as if the bit were reset (0). Comparison of bit strings of +different length should treat the smaller string as if it were padded with +zeros beyond the high order bits to the length of the longer string[23]. + +LastReq ::= SEQUENCE OF SEQUENCE { + lr-type[0] INTEGER, + lr-value[1] KerberosTime +} + +lr-type + This field indicates how the following lr-value field is to be + interpreted. Negative values indicate that the information pertains + only to the responding server. Non-negative values pertain to all + servers for the realm. If the lr-type field is zero (0), then no + information is conveyed by the lr-value subfield. If the absolute + value of the lr-type field is one (1), then the lr-value subfield is + the time of last initial request for a TGT. If it is two (2), then the + lr-value subfield is the time of last initial request. If it is three + (3), then the lr-value subfield is the time of issue for the newest + ticket-granting ticket used. If it is four (4), then the lr-value + subfield is the time of the last renewal. If it is five (5), then the + lr-value subfield is the time of last request (of any type). If it is + (6), then the lr-value subfield is the time when the password will + expire. +lr-value + This field contains the time of the last request. the time must be + interpreted according to the contents of the accompanying lr-type + subfield. + +See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, +EncryptionKey, EncryptionType, and KeyType. + +5.3. Tickets and Authenticators + +This section describes the format and encryption parameters for tickets and +authenticators. When a ticket or authenticator is included in a protocol +message it is treated as an opaque object. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.3.1. Tickets + +A ticket is a record that helps a client authenticate to a service. A +Ticket contains the following information: + +Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno[0] INTEGER, + realm[1] Realm, + sname[2] PrincipalName, + enc-part[3] EncryptedData, + extensions[4] TicketExtensions OPTIONAL +} + +-- Encrypted part of ticket +EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags[0] TicketFlags, + key[1] EncryptionKey, + crealm[2] Realm, + cname[3] PrincipalName, + transited[4] TransitedEncoding, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + caddr[9] HostAddresses OPTIONAL, + authorization-data[10] AuthorizationData OPTIONAL +} +-- encoded Transited field +TransitedEncoding ::= SEQUENCE { + tr-type[0] INTEGER, -- must be +registered + contents[1] OCTET STRING +} + +The encoding of EncTicketPart is encrypted in the key shared by Kerberos +and the end server (the server's secret key). See section 6 for the format +of the ciphertext. + +tkt-vno + This field specifies the version number for the ticket format. This + document describes version number 5. +realm + This field specifies the realm that issued a ticket. It also serves to + identify the realm part of the server's principal identifier. Since a + Kerberos server can only issue tickets for servers within its realm, + the two will always be identical. +sname + This field specifies all components of the name part of the server's + identity, including those parts that identify a specific instance of a + service. +enc-part + This field holds the encrypted encoding of the EncTicketPart sequence. +extensions + This optional field contains a sequence of extentions that may be used + to carry information that must be carried with the ticket to support + several extensions, including but not limited to plaintext + authorization data, tokens for exchanging inter-realm keys, and other + information that must be associated with a ticket for use by the + application server. See Appendix C for definitions of some common + extensions. + + Note that some older versions of Kerberos did not support this field. + Because this is an optional field it will not break older clients, but + older clients might strip this field from the ticket before sending it + to the application server. This limits the usefulness of this ticket + field to environments where the ticket will not be parsed and + reconstructed by these older Kerberos clients. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + If it is known that the client will strip this field from the ticket, + as an interim measure the KDC may append this field to the end of the + enc-part of the ticket and append a traler indicating the lenght of + the appended extensions field. (this paragraph is open for discussion, + including the form of the traler). +flags + This field indicates which of various options were used or requested + when the ticket was issued. It is a bit-field, where the selected + options are indicated by the bit being set (1), and the unselected + options and reserved fields being reset (0). Bit 0 is the most + significant bit. The encoding of the bits is specified in section 5.2. + The flags are described in more detail above in section 2. The + meanings of the flags are: + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + field. + + 1 FORWARDABLE + The FORWARDABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. When set, this + flag tells the ticket-granting server + that it is OK to issue a new ticket- + granting ticket with a different network + address based on the presented ticket. + + 2 FORWARDED + When set, this flag indicates that the + ticket has either been forwarded or was + issued based on authentication involving + a forwarded ticket-granting ticket. + + 3 PROXIABLE + The PROXIABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. The PROXIABLE + flag has an interpretation identical to + that of the FORWARDABLE flag, except + that the PROXIABLE flag tells the + ticket-granting server that only non- + ticket-granting tickets may be issued + with different network addresses. + + 4 PROXY + When set, this flag indicates that a + ticket is a proxy. + + 5 MAY-POSTDATE + The MAY-POSTDATE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. This flag tells + the ticket-granting server that a post- + dated ticket may be issued based on this + ticket-granting ticket. + + 6 POSTDATED + This flag indicates that this ticket has + been postdated. The end-service can + check the authtime field to see when the + original authentication occurred. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 7 INVALID + This flag indicates that a ticket is + invalid, and it must be validated by the + KDC before use. Application servers + must reject tickets which have this flag + set. + + 8 RENEWABLE + The RENEWABLE flag is normally only + interpreted by the TGS, and can usually + be ignored by end servers (some particu- + larly careful servers may wish to disal- + low renewable tickets). A renewable + ticket can be used to obtain a replace- + ment ticket that expires at a later + date. + + 9 INITIAL + This flag indicates that this ticket was + issued using the AS protocol, and not + issued based on a ticket-granting + ticket. + + 10 PRE-AUTHENT + This flag indicates that during initial + authentication, the client was authenti- + cated by the KDC before a ticket was + issued. The strength of the pre- + authentication method is not indicated, + but is acceptable to the KDC. + + 11 HW-AUTHENT + This flag indicates that the protocol + employed for initial authentication + required the use of hardware expected to + be possessed solely by the named client. + The hardware authentication method is + selected by the KDC and the strength of + the method is not indicated. + + 12 TRANSITED This flag indicates that the KDC for the + POLICY-CHECKED realm has checked the transited field + against a realm defined policy for + trusted certifiers. If this flag is + reset (0), then the application server + must check the transited field itself, + and if unable to do so it must reject + the authentication. If the flag is set + (1) then the application server may skip + its own validation of the transited + field, relying on the validation + performed by the KDC. At its option the + application server may still apply its + own validation based on a separate + policy for acceptance. + + 13 OK-AS-DELEGATE This flag indicates that the server (not + the client) specified in the ticket has + been determined by policy of the realm + to be a suitable recipient of + delegation. A client can use the + presence of this flag to help it make a + decision whether to delegate credentials + (either grant a proxy or a forwarded + ticket granting ticket) to this server. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + The client is free to ignore the value + of this flag. When setting this flag, + an administrator should consider the + Security and placement of the server on + which the service will run, as well as + whether the service requires the use of + delegated credentials. + + 14 ANONYMOUS + This flag indicates that the principal + named in the ticket is a generic princi- + pal for the realm and does not identify + the individual using the ticket. The + purpose of the ticket is only to + securely distribute a session key, and + not to identify the user. Subsequent + requests using the same ticket and ses- + sion may be considered as originating + from the same user, but requests with + the same username but a different ticket + are likely to originate from different + users. + + 15-31 RESERVED + Reserved for future use. + +key + This field exists in the ticket and the KDC response and is used to + pass the session key from Kerberos to the application server and the + client. The field's encoding is described in section 6.2. +crealm + This field contains the name of the realm in which the client is + registered and in which initial authentication took place. +cname + This field contains the name part of the client's principal + identifier. +transited + This field lists the names of the Kerberos realms that took part in + authenticating the user to whom this ticket was issued. It does not + specify the order in which the realms were transited. See section + 3.3.3.2 for details on how this field encodes the traversed realms. + When the names of CA's are to be embedded inthe transited field (as + specified for some extentions to the protocol), the X.500 names of the + CA's should be mapped into items in the transited field using the + mapping defined by RFC2253. +authtime + This field indicates the time of initial authentication for the named + principal. It is the time of issue for the original ticket on which + this ticket is based. It is included in the ticket to provide + additional information to the end service, and to provide the + necessary information for implementation of a `hot list' service at + the KDC. An end service that is particularly paranoid could refuse to + accept tickets for which the initial authentication occurred "too far" + in the past. This field is also returned as part of the response from + the KDC. When returned as part of the response to initial + authentication (KRB_AS_REP), this is the current time on the Kerberos + server[24]. +starttime + This field in the ticket specifies the time after which the ticket is + valid. Together with endtime, this field specifies the life of the + ticket. If it is absent from the ticket, its value should be treated + as that of the authtime field. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +endtime + This field contains the time after which the ticket will not be + honored (its expiration time). Note that individual services may place + their own limits on the life of a ticket and may reject tickets which + have not yet expired. As such, this is really an upper bound on the + expiration time for the ticket. +renew-till + This field is only present in tickets that have the RENEWABLE flag set + in the flags field. It indicates the maximum endtime that may be + included in a renewal. It can be thought of as the absolute expiration + time for the ticket, including all renewals. +caddr + This field in a ticket contains zero (if omitted) or more (if present) + host addresses. These are the addresses from which the ticket can be + used. If there are no addresses, the ticket can be used from any + location. The decision by the KDC to issue or by the end server to + accept zero-address tickets is a policy decision and is left to the + Kerberos and end-service administrators; they may refuse to issue or + accept such tickets. The suggested and default policy, however, is + that such tickets will only be issued or accepted when additional + information that can be used to restrict the use of the ticket is + included in the authorization_data field. Such a ticket is a + capability. + + Network addresses are included in the ticket to make it harder for an + attacker to use stolen credentials. Because the session key is not + sent over the network in cleartext, credentials can't be stolen simply + by listening to the network; an attacker has to gain access to the + session key (perhaps through operating system security breaches or a + careless user's unattended session) to make use of stolen tickets. + + It is important to note that the network address from which a + connection is received cannot be reliably determined. Even if it could + be, an attacker who has compromised the client's workstation could use + the credentials from there. Including the network addresses only makes + it more difficult, not impossible, for an attacker to walk off with + stolen credentials and then use them from a "safe" location. +authorization-data + The authorization-data field is used to pass authorization data from + the principal on whose behalf a ticket was issued to the application + service. If no authorization data is included, this field will be left + out. Experience has shown that the name of this field is confusing, + and that a better name for this field would be restrictions. + Unfortunately, it is not possible to change the name of this field at + this time. + + This field contains restrictions on any authority obtained on the + basis of authentication using the ticket. It is possible for any + principal in posession of credentials to add entries to the + authorization data field since these entries further restrict what can + be done with the ticket. Such additions can be made by specifying the + additional entries when a new ticket is obtained during the TGS + exchange, or they may be added during chained delegation using the + authorization data field of the authenticator. + + Because entries may be added to this field by the holder of + credentials, except when an entry is separately authenticated by + encapulation in the kdc-issued element, it is not allowable for the + presence of an entry in the authorization data field of a ticket to + amplify the priveleges one would obtain from using a ticket. + + The data in this field may be specific to the end service; the field + will contain the names of service specific objects, and the rights to + those objects. The format for this field is described in section 5.2. + Although Kerberos is not concerned with the format of the contents of + the sub-fields, it does carry type information (ad-type). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + By using the authorization_data field, a principal is able to issue a + proxy that is valid for a specific purpose. For example, a client + wishing to print a file can obtain a file server proxy to be passed to + the print server. By specifying the name of the file in the + authorization_data field, the file server knows that the print server + can only use the client's rights when accessing the particular file to + be printed. + + A separate service providing authorization or certifying group + membership may be built using the authorization-data field. In this + case, the entity granting authorization (not the authorized entity), + may obtain a ticket in its own name (e.g. the ticket is issued in the + name of a privelege server), and this entity adds restrictions on its + own authority and delegates the restricted authority through a proxy + to the client. The client would then present this authorization + credential to the application server separately from the + authentication exchange. Alternatively, such authorization credentials + may be embedded in the ticket authenticating the authorized entity, + when the authorization is separately authenticated using the + kdc-issued authorization data element (see B.4). + + Similarly, if one specifies the authorization-data field of a proxy + and leaves the host addresses blank, the resulting ticket and session + key can be treated as a capability. See [Neu93] for some suggested + uses of this field. + + The authorization-data field is optional and does not have to be + included in a ticket. + +5.3.2. Authenticators + +An authenticator is a record sent with a ticket to a server to certify the +client's knowledge of the encryption key in the ticket, to help the server +detect replays, and to help choose a "true session key" to use with the +particular session. The encoding is encrypted in the ticket's session key +shared by the client and the server: + +-- Unencrypted authenticator +Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno[0] INTEGER, + crealm[1] Realm, + cname[2] PrincipalName, + cksum[3] Checksum OPTIONAL, + cusec[4] INTEGER, + ctime[5] KerberosTime, + subkey[6] EncryptionKey OPTIONAL, + seq-number[7] INTEGER OPTIONAL, + authorization-data[8] AuthorizationData OPTIONAL +} + + +authenticator-vno + This field specifies the version number for the format of the + authenticator. This document specifies version 5. +crealm and cname + These fields are the same as those described for the ticket in section + 5.3.1. +cksum + This field contains a checksum of the the applica- tion data that + accompanies the KRB_AP_REQ. +cusec + This field contains the microsecond part of the client's timestamp. + Its value (before encryption) ranges from 0 to 999999. It often + appears along with ctime. The two fields are used together to specify + a reasonably accurate timestamp. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +ctime + This field contains the current time on the client's host. +subkey + This field contains the client's choice for an encryption key which is + to be used to protect this specific application session. Unless an + application specifies otherwise, if this field is left out the session + key from the ticket will be used. +seq-number + This optional field includes the initial sequence number to be used by + the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to + detect replays (It may also be used by application specific messages). + When included in the authenticator this field specifies the initial + sequence number for messages from the client to the server. When + included in the AP-REP message, the initial sequence number is that + for messages from the server to the client. When used in KRB_PRIV or + KRB_SAFE messages, it is incremented by one after each message is + sent. Sequence numbers fall in the range of 0 through 2^32 - 1 and + wrap to zero following the value 2^32 - 1. + + For sequence numbers to adequately support the detection of replays + they should be non-repeating, even across connection boundaries. The + initial sequence number should be random and uniformly distributed + across the full space of possible sequence numbers, so that it cannot + be guessed by an attacker and so that it and the successive sequence + numbers do not repeat other sequences. +authorization-data + This field is the same as described for the ticket in section 5.3.1. + It is optional and will only appear when additional restrictions are + to be placed on the use of a ticket, beyond those carried in the + ticket itself. + +5.4. Specifications for the AS and TGS exchanges + +This section specifies the format of the messages used in the exchange +between the client and the Kerberos server. The format of possible error +messages appears in section 5.9.1. + +5.4.1. KRB_KDC_REQ definition + +The KRB_KDC_REQ message has no type of its own. Instead, its type is one of +KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an +initial ticket or an additional ticket. In either case, the message is sent +from the client to the Authentication Server to request credentials for a +service. + +The message fields are: + +AS-REQ ::= [APPLICATION 10] KDC-REQ +TGS-REQ ::= [APPLICATION 12] KDC-REQ + +KDC-REQ ::= SEQUENCE { + pvno[1] INTEGER, + msg-type[2] INTEGER, + padata[3] SEQUENCE OF PA-DATA OPTIONAL, + req-body[4] KDC-REQ-BODY +} + +PA-DATA ::= SEQUENCE { + padata-type[1] INTEGER, + padata-value[2] OCTET STRING, + -- might be encoded AP-REQ +} + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +KDC-REQ-BODY ::= SEQUENCE { + kdc-options[0] KDCOptions, + cname[1] PrincipalName OPTIONAL, + -- Used only in AS-REQ + realm[2] Realm, -- Server's realm + -- Also client's in AS-REQ + sname[3] PrincipalName OPTIONAL, + from[4] KerberosTime OPTIONAL, + till[5] KerberosTime OPTIONAL, + rtime[6] KerberosTime OPTIONAL, + nonce[7] INTEGER, + etype[8] SEQUENCE OF INTEGER, + -- EncryptionType, + -- in preference order + addresses[9] HostAddresses OPTIONAL, + enc-authorization-data[10] EncryptedData OPTIONAL, + -- Encrypted AuthorizationData + -- encoding + additional-tickets[11] SEQUENCE OF Ticket OPTIONAL +} + +The fields in this message are: + +pvno + This field is included in each message, and specifies the protocol + version number. This document specifies protocol version 5. +msg-type + This field indicates the type of a protocol message. It will almost + always be the same as the application identifier associated with a + message. It is included to make the identifier more readily accessible + to the application. For the KDC-REQ message, this type will be + KRB_AS_REQ or KRB_TGS_REQ. +padata + The padata (pre-authentication data) field contains a sequence of + authentication information which may be needed before credentials can + be issued or decrypted. In the case of requests for additional tickets + (KRB_TGS_REQ), this field will include an element with padata-type of + PA-TGS-REQ and data of an authentication header (ticket-granting + ticket and authenticator). The checksum in the authenticator (which + must be collision-proof) is to be computed over the KDC-REQ-BODY + encoding. In most requests for initial authentication (KRB_AS_REQ) and + most replies (KDC-REP), the padata field will be left out. + + This field may also contain information needed by certain extensions + to the Kerberos protocol. For example, it might be used to initially + verify the identity of a client before any response is returned. When + this field is used to authenticate or pre-authenticate a request, it + should contain a keyed checksum over the KDC-REQ-BODY to bind the + pre-authentication data to rest of the request. The KDC, as a matter + of policy, may decide whether to honor a KDC-REQ which includes any + pre-authentication data that does not contain the checksum field. + PA-ENC-TIMESTAMP defines a pre-authentication data type that is used + for authenticating a client by way of an encrypted timestamp. This is + accomplished with a padata field with padata-type equal to + PA-ENC-TIMESTAMP and padata-value defined as follows (query: the + checksum is new in this definition. If the optional field will break + things we can keep the old PA-ENC-TS-ENC, and define a new alternate + form that includes the checksum). : + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + padata-type ::= PA-ENC-TIMESTAMP + padata-value ::= EncryptedData -- PA-ENC-TS-ENC + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp[0] KerberosTime, -- client's time + pausec[1] INTEGER OPTIONAL, + pachecksum[2] checksum OPTIONAL + -- keyed checksum of +KDC-REQ-BODY + } + + with patimestamp containing the client's time and pausec containing + the microseconds which may be omitted if a client will not generate + more than one request per second. The ciphertext (padata-value) + consists of the PA-ENC-TS-ENC sequence, encrypted using the client's + secret key. + + [use-specified-kvno item is here for discussion and may be removed] It + may also be used by the client to specify the version of a key that is + being used for accompanying preauthentication, and/or which should be + used to encrypt the reply from the KDC. + + PA-USE-SPECIFIED-KVNO ::= Integer + + The KDC should only accept and abide by the value of the + use-specified-kvno preauthentication data field when the specified key + is still valid and until use of a new key is confirmed. This situation + is likely to occur primarily during the period during which an updated + key is propagating to other KDC's in a realm. + + The padata field can also contain information needed to help the KDC + or the client select the key needed for generating or decrypting the + response. This form of the padata is useful for supporting the use of + certain token cards with Kerberos. The details of such extensions are + specified in separate documents. See [Pat92] for additional uses of + this field. +padata-type + The padata-type element of the padata field indicates the way that the + padata-value element is to be interpreted. Negative values of + padata-type are reserved for unregistered use; non-negative values are + used for a registered interpretation of the element type. +req-body + This field is a placeholder delimiting the extent of the remaining + fields. If a checksum is to be calculated over the request, it is + calculated over an encoding of the KDC-REQ-BODY sequence which is + enclosed within the req-body field. +kdc-options + This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the + KDC and indicates the flags that the client wants set on the tickets + as well as other information that is to modify the behavior of the + KDC. Where appropriate, the name of an option may be the same as the + flag that is set by that option. Although in most case, the bit in the + options field will be the same as that in the flags field, this is not + guaranteed, so it is not acceptable to simply copy the options field + to the flags field. There are various checks that must be made before + honoring an option anyway. + + The kdc_options field is a bit-field, where the selected options are + indicated by the bit being set (1), and the unselected options and + reserved fields being reset (0). The encoding of the bits is specified + in section 5.2. The options are described in more detail above in + section 2. The meanings of the options are: + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + Bit(s) Name Description + 0 RESERVED + Reserved for future expansion of +this + field. + + 1 FORWARDABLE + The FORWARDABLE option indicates +that + the ticket to be issued is to have +its + forwardable flag set. It may only +be + set on the initial request, or in a +sub- + sequent request if the +ticket-granting + ticket on which it is based is also +for- + wardable. + + 2 FORWARDED + The FORWARDED option is only +specified + in a request to the +ticket-granting + server and will only be honored if +the + ticket-granting ticket in the +request + has its FORWARDABLE bit set. +This + option indicates that this is a +request + for forwarding. The address(es) of +the + host from which the resulting ticket +is + to be valid are included in +the + addresses field of the request. + + 3 PROXIABLE + The PROXIABLE option indicates that +the + ticket to be issued is to have its +prox- + iable flag set. It may only be set +on + the initial request, or in a +subsequent + request if the ticket-granting ticket +on + which it is based is also proxiable. + + 4 PROXY + The PROXY option indicates that this +is + a request for a proxy. This option +will + only be honored if the +ticket-granting + ticket in the request has its +PROXIABLE + bit set. The address(es) of the +host + from which the resulting ticket is to +be + valid are included in the +addresses + field of the request. + + 5 ALLOW-POSTDATE + The ALLOW-POSTDATE option indicates +that + the ticket to be issued is to have +its + MAY-POSTDATE flag set. It may only +be + set on the initial request, or in a +sub- + sequent request if the +ticket-granting + ticket on which it is based also has +its + MAY-POSTDATE flag set. + + 6 POSTDATED + The POSTDATED option indicates that +this + is a request for a postdated +ticket. + This option will only be honored if +the + ticket-granting ticket on which it +is + based has its MAY-POSTDATE flag +set. + The resulting ticket will also have +its + INVALID flag set, and that flag may +be + reset by a subsequent request to the +KDC + after the starttime in the ticket +has + been reached. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 7 UNUSED + This option is presently unused. + + 8 RENEWABLE + The RENEWABLE option indicates that +the + ticket to be issued is to have +its + RENEWABLE flag set. It may only be +set + on the initial request, or when +the + ticket-granting ticket on which +the + request is based is also renewable. +If + this option is requested, then the +rtime + field in the request contains +the + desired absolute expiration time for +the + ticket. + + 9 RESERVED + Reserved for PK-Cross + + 10-13 UNUSED + These options are presently unused. + + 14 REQUEST-ANONYMOUS + The REQUEST-ANONYMOUS option +indicates + that the ticket to be issued is not +to + identify the user to which it +was + issued. Instead, the principal +identif- + ier is to be generic, as specified +by + the policy of the realm (e.g. +usually + anonymous@realm). The purpose of +the + ticket is only to securely distribute +a + session key, and not to identify +the + user. The ANONYMOUS flag on the +ticket + to be returned should be set. If +the + local realms policy does not +permit + anonymous credentials, the request is +to + be rejected. + + 15 CANONICALIZE + The CANONICALIZE option indicates that + the client will accept the return of a + true server name instead of the name + specified in the request. In addition + the client will be able to process + any TGT referrals that will direct + the client to another realm to locate + the requested server. If a KDC does + not support name- canonicalization, + the option is ignored and the + appropriate + KDC_ERR_C_PRINCIPAL_UNKNOWN or + KDC_ERR_S_PRINCIPAL_UNKNOWN error is + returned. [JBrezak] + + 16-25 RESERVED + Reserved for future use. + + 26 DISABLE-TRANSITED-CHECK + By default the KDC will check the + transited field of a ticket-granting- + ticket against the policy of the local + realm before it will issue derivative + tickets based on the ticket granting + ticket. If this flag is set in the + request, checking of the transited +field + is disabled. Tickets issued without +the + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + performance of this check will be +noted + by the reset (0) value of the + TRANSITED-POLICY-CHECKED flag, + indicating to the application server + that the tranisted field must be +checked + locally. KDC's are encouraged but not + required to honor the + DISABLE-TRANSITED-CHECK option. + + 27 RENEWABLE-OK + The RENEWABLE-OK option indicates that +a + renewable ticket will be acceptable if +a + ticket with the requested life +cannot + otherwise be provided. If a ticket +with + the requested life cannot be +provided, + then a renewable ticket may be +issued + with a renew-till equal to the +the + requested endtime. The value of +the + renew-till field may still be limited +by + local limits, or limits selected by +the + individual principal or server. + + 28 ENC-TKT-IN-SKEY + This option is used only by the +ticket- + granting service. The +ENC-TKT-IN-SKEY + option indicates that the ticket for +the + end server is to be encrypted in +the + session key from the additional +ticket- + granting ticket provided. + + 29 RESERVED + Reserved for future use. + + 30 RENEW + This option is used only by the +ticket- + granting service. The RENEW +option + indicates that the present request +is + for a renewal. The ticket provided +is + encrypted in the secret key for +the + server on which it is valid. +This + option will only be honored if +the + ticket to be renewed has its +RENEWABLE + flag set and if the time in its +renew- + till field has not passed. The +ticket + to be renewed is passed in the +padata + field as part of the +authentication + header. + + 31 VALIDATE + This option is used only by the +ticket- + granting service. The VALIDATE +option + indicates that the request is to +vali- + date a postdated ticket. It will +only + be honored if the ticket presented +is + postdated, presently has its +INVALID + flag set, and would be otherwise +usable + at this time. A ticket cannot be +vali- + dated before its starttime. The +ticket + presented for validation is encrypted +in + the key of the server for which it +is + valid and is passed in the padata +field + as part of the authentication header. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +cname and sname + These fields are the same as those described for the ticket in section + 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is + specified. If absent, the name of the server is taken from the name of + the client in the ticket passed as additional-tickets. +enc-authorization-data + The enc-authorization-data, if present (and it can only be present in + the TGS_REQ form), is an encoding of the desired authorization-data + encrypted under the sub-session key if present in the Authenticator, + or alternatively from the session key in the ticket-granting ticket, + both from the padata field in the KRB_AP_REQ. +realm + This field specifies the realm part of the server's principal + identifier. In the AS exchange, this is also the realm part of the + client's principal identifier. If the CANONICALIZE option is set, the + realm is used as a hint to the KDC for its database lookup. +from + This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket + requests when the requested ticket is to be postdated. It specifies + the desired start time for the requested ticket. If this field is + omitted then the KDC should use the current time instead. +till + This field contains the expiration date requested by the client in a + ticket request. It is optional and if omitted the requested ticket is + to have the maximum endtime permitted according to KDC policy for the + parties to the authentication exchange as limited by expiration date + of the ticket granting ticket or other preauthentication credentials. +rtime + This field is the requested renew-till time sent from a client to the + KDC in a ticket request. It is optional. +nonce + This field is part of the KDC request and response. It it intended to + hold a random number generated by the client. If the same number is + included in the encrypted response from the KDC, it provides evidence + that the response is fresh and has not been replayed by an attacker. + Nonces must never be re-used. Ideally, it should be generated + randomly, but if the correct time is known, it may suffice[25]. +etype + This field specifies the desired encryption algorithm to be used in + the response. +addresses + This field is included in the initial request for tickets, and + optionally included in requests for additional tickets from the + ticket-granting server. It specifies the addresses from which the + requested ticket is to be valid. Normally it includes the addresses + for the client's host. If a proxy is requested, this field will + contain other addresses. The contents of this field are usually copied + by the KDC into the caddr field of the resulting ticket. +additional-tickets + Additional tickets may be optionally included in a request to the + ticket-granting server. If the ENC-TKT-IN-SKEY option has been + specified, then the session key from the additional ticket will be + used in place of the server's key to encrypt the new ticket. When he + ENC-TKT-IN-SKEY option is used for user-to-user authentication, this + addional ticket may be a TGT issued by the local realm or an + inter-realm TGT issued for the current KDC's realm by a remote KDC. If + more than one option which requires additional tickets has been + specified, then the additional tickets are used in the order specified + by the ordering of the options bits (see kdc-options, above). + +The application code will be either ten (10) or twelve (12) depending on +whether the request is for an initial ticket (AS-REQ) or for an additional +ticket (TGS-REQ). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The optional fields (addresses, authorization-data and additional-tickets) +are only included if necessary to perform the operation specified in the +kdc-options field. + +It should be noted that in KRB_TGS_REQ, the protocol version number appears +twice and two different message types appear: the KRB_TGS_REQ message +contains these fields as does the authentication header (KRB_AP_REQ) that +is passed in the padata field. + +5.4.2. KRB_KDC_REP definition + +The KRB_KDC_REP message format is used for the reply from the KDC for +either an initial (AS) request or a subsequent (TGS) request. There is no +message type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP +or KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply +depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in +the client's secret key, and the client's key version number is included in +the key version number for the encrypted data. For KRB_TGS_REP, the +ciphertext is encrypted in the sub-session key from the Authenticator, or +if absent, the session key from the ticket-granting ticket used in the +request. In that case, no version number will be present in the +EncryptedData sequence. + +The KRB_KDC_REP message contains the following fields: + +AS-REP ::= [APPLICATION 11] KDC-REP +TGS-REP ::= [APPLICATION 13] KDC-REP + +KDC-REP ::= SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + padata[2] SEQUENCE OF PA-DATA OPTIONAL, + crealm[3] Realm, + cname[4] PrincipalName, + ticket[5] Ticket, + enc-part[6] EncryptedData +} + +EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart +EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + +EncKDCRepPart ::= SEQUENCE { + key[0] EncryptionKey, + last-req[1] LastReq, + nonce[2] INTEGER, + key-expiration[3] KerberosTime OPTIONAL, + flags[4] TicketFlags, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + srealm[9] Realm, + sname[10] PrincipalName, + caddr[11] HostAddresses OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is either + KRB_AS_REP or KRB_TGS_REP. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +padata + This field is described in detail in section 5.4.1. One possible use + for this field is to encode an alternate "mix-in" string to be used + with a string-to-key algorithm (such as is described in section + 6.3.2). This ability is useful to ease transitions if a realm name + needs to change (e.g. when a company is acquired); in such a case all + existing password-derived entries in the KDC database would be flagged + as needing a special mix-in string until the next password change. +crealm, cname, srealm and sname + These fields are the same as those described for the ticket in section + 5.3.1. +ticket + The newly-issued ticket, from section 5.3.1. +enc-part + This field is a place holder for the ciphertext and related + information that forms the encrypted part of a message. The + description of the encrypted part of the message follows each + appearance of this field. The encrypted part is encoded as described + in section 6.1. +key + This field is the same as described for the ticket in section 5.3.1. +last-req + This field is returned by the KDC and specifies the time(s) of the + last request by a principal. Depending on what information is + available, this might be the last time that a request for a + ticket-granting ticket was made, or the last time that a request based + on a ticket-granting ticket was successful. It also might cover all + servers for a realm, or just the particular server. Some + implementations may display this information to the user to aid in + discovering unauthorized use of one's identity. It is similar in + spirit to the last login time displayed when logging into timesharing + systems. +nonce + This field is described above in section 5.4.1. +key-expiration + The key-expiration field is part of the response from the KDC and + specifies the time that the client's secret key is due to expire. The + expiration might be the result of password aging or an account + expiration. This field will usually be left out of the TGS reply since + the response to the TGS request is encrypted in a session key and no + client information need be retrieved from the KDC database. It is up + to the application client (usually the login program) to take + appropriate action (such as notifying the user) if the expiration time + is imminent. +flags, authtime, starttime, endtime, renew-till and caddr + These fields are duplicates of those found in the encrypted portion of + the attached ticket (see section 5.3.1), provided so the client may + verify they match the intended request and to assist in proper ticket + caching. If the message is of type KRB_TGS_REP, the caddr field will + only be filled in if the request was for a proxy or forwarded ticket, + or if the user is substituting a subset of the addresses from the + ticket granting ticket. If the client-requested addresses are not + present or not used, then the addresses contained in the ticket will + be the same as those included in the ticket-granting ticket. + +5.5. Client/Server (CS) message specifications + +This section specifies the format of the messages used for the +authentication of the client to the application server. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.5.1. KRB_AP_REQ definition + +The KRB_AP_REQ message contains the Kerberos protocol version number, the +message type KRB_AP_REQ, an options field to indicate any options in use, +and the ticket and authenticator themselves. The KRB_AP_REQ message is +often referred to as the 'authentication header'. + +AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ap-options[2] APOptions, + ticket[3] Ticket, + authenticator[4] EncryptedData +} + +APOptions ::= BIT STRING { + reserved(0), + use-session-key(1), + mutual-required(2) +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REQ. +ap-options + This field appears in the application request (KRB_AP_REQ) and affects + the way the request is processed. It is a bit-field, where the + selected options are indicated by the bit being set (1), and the + unselected options and reserved fields being reset (0). The encoding + of the bits is specified in section 5.2. The meanings of the options + are: + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + field. + + 1 USE-SESSION-KEY + The USE-SESSION-KEY option indicates + that the ticket the client is presenting + to a server is encrypted in the session + key from the server's ticket-granting + ticket. When this option is not speci- + fied, the ticket is encrypted in the + server's secret key. + + 2 MUTUAL-REQUIRED + The MUTUAL-REQUIRED option tells the + server that the client requires mutual + authentication, and that it must respond + with a KRB_AP_REP message. + + 3-31 RESERVED + Reserved for future use. + +ticket + This field is a ticket authenticating the client to the server. +authenticator + This contains the authenticator, which includes the client's choice of + a subkey. Its encoding is described in section 5.3.2. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.5.2. KRB_AP_REP definition + +The KRB_AP_REP message contains the Kerberos protocol version number, the +message type, and an encrypted time- stamp. The message is sent in in +response to an application request (KRB_AP_REQ) where the mutual +authentication option has been selected in the ap-options field. + +AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[2] EncryptedData +} + +EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { + ctime[0] KerberosTime, + cusec[1] INTEGER, + subkey[2] EncryptionKey OPTIONAL, + seq-number[3] INTEGER OPTIONAL +} + +The encoded EncAPRepPart is encrypted in the shared session key of the +ticket. The optional subkey field can be used in an application-arranged +negotiation to choose a per association session key. + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REP. +enc-part + This field is described above in section 5.4.2. +ctime + This field contains the current time on the client's host. +cusec + This field contains the microsecond part of the client's timestamp. +subkey + This field contains an encryption key which is to be used to protect + this specific application session. See section 3.2.6 for specifics on + how this field is used to negotiate a key. Unless an application + specifies otherwise, if this field is left out, the sub-session key + from the authenticator, or if also left out, the session key from the + ticket will be used. + +5.5.3. Error message reply + +If an error occurs while processing the application request, the KRB_ERROR +message will be sent in response. See section 5.9.1 for the format of the +error message. The cname and crealm fields may be left out if the server +cannot determine their appropriate values from the corresponding KRB_AP_REQ +message. If the authenticator was decipherable, the ctime and cusec fields +will contain the values from it. + +5.6. KRB_SAFE message specification + +This section specifies the format of a message that can be used by either +side (client or server) of an application to send a tamper-proof message to +its peer. It presumes that a session key has previously been exchanged (for +example, by using the KRB_AP_REQ/KRB_AP_REP messages). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.6.1. KRB_SAFE definition + +The KRB_SAFE message contains user data along with a collision-proof +checksum keyed with the last encryption key negotiated via subkeys, or the +session key if no negotiation has occured. The message fields are: + +KRB-SAFE ::= [APPLICATION 20] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + safe-body[2] KRB-SAFE-BODY, + cksum[3] Checksum +} + +KRB-SAFE-BODY ::= SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_SAFE. +safe-body + This field is a placeholder for the body of the KRB-SAFE message. +cksum + This field contains the checksum of the application data. Checksum + details are described in section 6.4. The checksum is computed over + the encoding of the KRB-SAFE sequence. First, the cksum is zeroed and + the checksum is computed over the encoding of the KRB-SAFE sequence, + then the checksum is set to the result of that computation, and + finally the KRB-SAFE sequence is encoded again. +user-data + This field is part of the KRB_SAFE and KRB_PRIV messages and contain + the application specific data that is being passed from the sender to + the recipient. +timestamp + This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents + are the current time as known by the sender of the message. By + checking the timestamp, the recipient of the message is able to make + sure that it was recently generated, and is not a replay. +usec + This field is part of the KRB_SAFE and KRB_PRIV headers. It contains + the microsecond part of the timestamp. +seq-number + This field is described above in section 5.3.2. +s-address + This field specifies the address in use by the sender of the message. + It may be omitted if not required by the application protocol. The + application designer considering omission of this field is warned, + that the inclusion of this address prevents some kinds of replay + attacks (e.g., reflection attacks) and that it is only acceptable to + omit this address if there is sufficient information in the integrity + protected part of the application message for the recipient to + unambiguously determine if it was the intended recipient. +r-address + This field specifies the address in use by the recipient of the + message. It may be omitted for some uses (such as broadcast + protocols), but the recipient may arbitrarily reject such messages. + This field along with s-address can be used to help detect messages + which have been incorrectly or maliciously delivered to the wrong + recipient. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.7. KRB_PRIV message specification + +This section specifies the format of a message that can be used by either +side (client or server) of an application to securely and privately send a +message to its peer. It presumes that a session key has previously been +exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). + +5.7.1. KRB_PRIV definition + +The KRB_PRIV message contains user data encrypted in the Session Key. The +message fields are: + +KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[3] EncryptedData +} + +EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, -- sender's +addr + r-address[5] HostAddress OPTIONAL -- recip's +addr +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_PRIV. +enc-part + This field holds an encoding of the EncKrbPrivPart sequence encrypted + under the session key[32]. This encrypted encoding is used for the + enc-part field of the KRB-PRIV message. See section 6 for the format + of the ciphertext. +user-data, timestamp, usec, s-address and r-address + These fields are described above in section 5.6.1. +seq-number + This field is described above in section 5.3.2. + +5.8. KRB_CRED message specification + +This section specifies the format of a message that can be used to send +Kerberos credentials from one principal to another. It is presented here to +encourage a common mechanism to be used by applications when forwarding +tickets or providing proxies to subordinate servers. It presumes that a +session key has already been exchanged perhaps by using the +KRB_AP_REQ/KRB_AP_REP messages. + +5.8.1. KRB_CRED definition + +The KRB_CRED message contains a sequence of tickets to be sent and +information needed to use the tickets, including the session key from each. +The information needed to use the tickets is encrypted under an encryption +key previously exchanged or transferred alongside the KRB_CRED message. The +message fields are: + +KRB-CRED ::= [APPLICATION 22] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, -- KRB_CRED + tickets[2] SEQUENCE OF Ticket, + enc-part[3] EncryptedData +} + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info[0] SEQUENCE OF KrbCredInfo, + nonce[1] INTEGER OPTIONAL, + timestamp[2] KerberosTime OPTIONAL, + usec[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + +KrbCredInfo ::= SEQUENCE { + key[0] EncryptionKey, + prealm[1] Realm OPTIONAL, + pname[2] PrincipalName OPTIONAL, + flags[3] TicketFlags OPTIONAL, + authtime[4] KerberosTime OPTIONAL, + starttime[5] KerberosTime OPTIONAL, + endtime[6] KerberosTime OPTIONAL + renew-till[7] KerberosTime OPTIONAL, + srealm[8] Realm OPTIONAL, + sname[9] PrincipalName OPTIONAL, + caddr[10] HostAddresses OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_CRED. +tickets + These are the tickets obtained from the KDC specifically for use by + the intended recipient. Successive tickets are paired with the + corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED + message. +enc-part + This field holds an encoding of the EncKrbCredPart sequence encrypted + under the session key shared between the sender and the intended + recipient. This encrypted encoding is used for the enc-part field of + the KRB-CRED message. See section 6 for the format of the ciphertext. +nonce + If practical, an application may require the inclusion of a nonce + generated by the recipient of the message. If the same value is + included as the nonce in the message, it provides evidence that the + message is fresh and has not been replayed by an attacker. A nonce + must never be re-used; it should be generated randomly by the + recipient of the message and provided to the sender of the message in + an application specific manner. +timestamp and usec + These fields specify the time that the KRB-CRED message was generated. + The time is used to provide assurance that the message is fresh. +s-address and r-address + These fields are described above in section 5.6.1. They are used + optionally to provide additional assurance of the integrity of the + KRB-CRED message. +key + This field exists in the corresponding ticket passed by the KRB-CRED + message and is used to pass the session key from the sender to the + intended recipient. The field's encoding is described in section 6.2. + +The following fields are optional. If present, they can be associated with +the credentials in the remote ticket file. If left out, then it is assumed +that the recipient of the credentials already knows their value. + +prealm and pname + The name and realm of the delegated principal identity. +flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr + These fields contain the values of the correspond- ing fields from the + ticket found in the ticket field. Descriptions of the fields are + identical to the descriptions in the KDC-REP message. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.9. Error message specification + +This section specifies the format for the KRB_ERROR message. The fields +included in the message are intended to return as much information as +possible about an error. It is not expected that all the information +required by the fields will be available for all types of errors. If the +appropriate information is not available when the message is composed, the +corresponding field will be left out of the message. + +Note that since the KRB_ERROR message is only optionally integrity +protected, it is quite possible for an intruder to synthesize or modify +such a message. In particular, this means that unless appropriate integrity +protection mechanisms have been applied to the KRB_ERROR message, the +client should not use any fields in this message for security-critical +purposes, such as setting a system clock or generating a fresh +authenticator. The message can be useful, however, for advising a user on +the reason for some failure. + +5.9.1. KRB_ERROR definition + +The KRB_ERROR message consists of the following fields: + +KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ctime[2] KerberosTime OPTIONAL, + cusec[3] INTEGER OPTIONAL, + stime[4] KerberosTime, + susec[5] INTEGER, + error-code[6] INTEGER, + crealm[7] Realm OPTIONAL, + cname[8] PrincipalName OPTIONAL, + realm[9] Realm, -- Correct realm + sname[10] PrincipalName, -- Correct name + e-text[11] GeneralString OPTIONAL, + e-data[12] OCTET STRING OPTIONAL, + e-cksum[13] Checksum OPTIONAL, +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_ERROR. +ctime + This field is described above in section 5.4.1. +cusec + This field is described above in section 5.5.2. +stime + This field contains the current time on the server. It is of type + KerberosTime. +susec + This field contains the microsecond part of the server's timestamp. + Its value ranges from 0 to 999999. It appears along with stime. The + two fields are used in conjunction to specify a reasonably accurate + timestamp. +error-code + This field contains the error code returned by Kerberos or the server + when a request fails. To interpret the value of this field see the + list of error codes in section 8. Implementations are encouraged to + provide for national language support in the display of error + messages. +crealm, cname, srealm and sname + These fields are described above in section 5.3.1. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +e-text + This field contains additional text to help explain the error code + associated with the failed request (for example, it might include a + principal name which was unknown). +e-data + This field contains additional data about the error for use by the + application to help it recover from or handle the error. If present, + this field will contain the encoding of a sequence of TypedData + (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED, + in which case it will contain the encoding of a sequence of of padata + fields (METHOD-DATA below), each corresponding to an acceptable + pre-authentication method and optionally containing data for the + method: + + TYPED-DATA ::= SEQUENCE of TypeData + METHOD-DATA ::= SEQUENCE of PA-DATA + + TypedData ::= SEQUENCE { + data-type[0] INTEGER, + data-value[1] OCTET STRING OPTIONAL + } + + Note that e-data-types have been reserved for all PA data types + defined prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, + when using new PA data types defined in July 1999 or later, the + METHOD-DATA sequence must itself be encapsulated in an TypedData + element of type TD-PADATA. All new implementations interpreting the + METHOD-DATA field for the KDC_ERR_PREAUTH_REQUIRED message must accept + a type of TD-PADATA, extract the typed data field and interpret the + use any elements encapsulated in the TD-PADATA elements as if they + were present in the METHOD-DATA sequence. +e-cksum + This field contains an optional checksum for the KRB-ERROR message. + The checksum is calculated over the Kerberos ASN.1 encoding of the + KRB-ERROR message with the checksum absent. The checksum is then added + to the KRB-ERROR structure and the message is re-encoded. The Checksum + should be calculated using the session key from the ticket granting + ticket or service ticket, where available. If the error is in response + to a TGS or AP request, the checksum should be calculated uing the the + session key from the client's ticket. If the error is in response to + an AS request, then the checksum should be calulated using the + client's secret key ONLY if there has been suitable preauthentication + to prove knowledge of the secret key by the client[33]. If a checksum + can not be computed because the key to be used is not available, no + checksum will be included. + + 6. Encryption and Checksum Specifications + + The Kerberos protocols described in this document are designed to use + stream encryption ciphers, which can be simulated using commonly + available block encryption ciphers, such as the Data Encryption + Standard [DES77], and triple DES variants, in conjunction with block + chaining and checksum methods [DESM80]. Encryption is used to prove + the identities of the network entities participating in message + exchanges. The Key Distribution Center for each realm is trusted by + all principals registered in that realm to store a secret key in + confidence. Proof of knowledge of this secret key is used to verify + the authenticity of a principal. + + The KDC uses the principal's secret key (in the AS exchange) or a + shared session key (in the TGS exchange) to encrypt responses to + ticket requests; the ability to obtain the secret key or session key + implies the knowledge of the appropriate keys and the identity of the + KDC. The ability of a principal to decrypt the KDC response and + present a Ticket and a properly formed Authenticator (generated with + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + the session key from the KDC response) to a service verifies the + identity of the principal; likewise the ability of the service to + extract the session key from the Ticket and prove its knowledge + thereof in a response verifies the identity of the service. + + The Kerberos protocols generally assume that the encryption used is + secure from cryptanalysis; however, in some cases, the order of fields + in the encrypted portions of messages are arranged to minimize the + effects of poorly chosen keys. It is still important to choose good + keys. If keys are derived from user-typed passwords, those passwords + need to be well chosen to make brute force attacks more difficult. + Poorly chosen keys still make easy targets for intruders. + + The following sections specify the encryption and checksum mechanisms + currently defined for Kerberos. The encodings, chaining, and padding + requirements for each are described. For encryption methods, it is + often desirable to place random information (often referred to as a + confounder) at the start of the message. The requirements for a + confounder are specified with each encryption mechanism. + + Some encryption systems use a block-chaining method to improve the the + security characteristics of the ciphertext. However, these chaining + methods often don't provide an integrity check upon decryption. Such + systems (such as DES in CBC mode) must be augmented with a checksum of + the plain-text which can be verified at decryption and used to detect + any tampering or damage. Such checksums should be good at detecting + burst errors in the input. If any damage is detected, the decryption + routine is expected to return an error indicating the failure of an + integrity check. Each encryption type is expected to provide and + verify an appropriate checksum. The specification of each encryption + method sets out its checksum requirements. + + Finally, where a key is to be derived from a user's password, an + algorithm for converting the password to a key of the appropriate type + is included. It is desirable for the string to key function to be + one-way, and for the mapping to be different in different realms. This + is important because users who are registered in more than one realm + will often use the same password in each, and it is desirable that an + attacker compromising the Kerberos server in one realm not obtain or + derive the user's key in another. + + For an discussion of the integrity characteristics of the candidate + encryption and checksum methods considered for Kerberos, the reader is + referred to [SG92]. + + 6.1. Encryption Specifications + + The following ASN.1 definition describes all encrypted messages. The + enc-part field which appears in the unencrypted part of messages in + section 5 is a sequence consisting of an encryption type, an optional + key version number, and the ciphertext. + + EncryptedData ::= SEQUENCE { + etype[0] INTEGER, -- EncryptionType + kvno[1] INTEGER OPTIONAL, + cipher[2] OCTET STRING -- ciphertext + } + + + + etype + This field identifies which encryption algorithm was used to + encipher the cipher. Detailed specifications for selected + encryption types appear later in this section. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + kvno + This field contains the version number of the key under which + data is encrypted. It is only present in messages encrypted under + long lasting keys, such as principals' secret keys. + cipher + This field contains the enciphered text, encoded as an OCTET + STRING. + The cipher field is generated by applying the specified encryption + algorithm to data composed of the message and algorithm-specific + inputs. Encryption mechanisms defined for use with Kerberos must take + sufficient measures to guarantee the integrity of the plaintext, and + we recommend they also take measures to protect against precomputed + dictionary attacks. If the encryption algorithm is not itself capable + of doing so, the protections can often be enhanced by adding a + checksum and a confounder. + + The suggested format for the data to be encrypted includes a + confounder, a checksum, the encoded plaintext, and any necessary + padding. The msg-seq field contains the part of the protocol message + described in section 5 which is to be encrypted. The confounder, + checksum, and padding are all untagged and untyped, and their length + is exactly sufficient to hold the appropriate item. The type and + length is implicit and specified by the particular encryption type + being used (etype). The format for the data to be encrypted for some + methods is described in the following diagram, but other methods may + deviate from this layour - so long as the definition of the method + defines the layout actually in use. + + +-----------+----------+-------------+-----+ + |confounder | check | msg-seq | pad | + +-----------+----------+-------------+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + CipherText ::= ENCRYPTED SEQUENCE { + confounder[0] UNTAGGED[35] OCTET STRING(conf_length) +OPTIONAL, + check[1] UNTAGGED OCTET STRING(checksum_length) +OPTIONAL, + msg-seq[2] MsgSequence, + pad UNTAGGED OCTET STRING(pad_length) OPTIONAL + } + + One generates a random confounder of the appropriate length, placing + it in confounder; zeroes out check; calculates the appropriate + checksum over confounder, check, and msg-seq, placing the result in + check; adds the necessary padding; then encrypts using the specified + encryption type and the appropriate key. + + Unless otherwise specified, a definition of an encryption algorithm + that specifies a checksum, a length for the confounder field, or an + octet boundary for padding uses this ciphertext format[36]. Those + fields which are not specified will be omitted. + + In the interest of allowing all implementations using a particular + encryption type to communicate with all others using that type, the + specification of an encryption type defines any checksum that is + needed as part of the encryption process. If an alternative checksum + is to be used, a new encryption type must be defined. + + Some cryptosystems require additional information beyond the key and + the data to be encrypted. For example, DES, when used in + cipher-block-chaining mode, requires an initialization vector. If + required, the description for each encryption type must specify the + source of such additional information. 6.2. Encryption Keys + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + The sequence below shows the encoding of an encryption key: + + EncryptionKey ::= SEQUENCE { + keytype[0] INTEGER, + keyvalue[1] OCTET STRING + } + + keytype + This field specifies the type of encryption that is to be + performed using the key that follows in the keyvalue field. It + will always correspond to the etype to be used to generate or + decode the EncryptedData. In cases when multiple algorithms use a + common kind of key (e.g., if the encryption algorithm uses an + alternate checksum algorithm for an integrity check, or a + different chaining mechanism), the keytype provides information + needed to determine which algorithm is to be used. + keyvalue + This field contains the key itself, encoded as an octet string. + All negative values for the encryption key type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpreta- tions. + + 6.3. Encryption Systems + + 6.3.1. The NULL Encryption System (null) + + If no encryption is in use, the encryption system is said to be the + NULL encryption system. In the NULL encryption system there is no + checksum, confounder or padding. The ciphertext is simply the + plaintext. The NULL Key is used by the null encryption system and is + zero octets in length, with keytype zero (0). + + 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) + + The des-cbc-crc encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is + applied to the confounder and message sequence (msg-seq) and placed in + the cksum field. DES blocks are 8 bytes. As a result, the data to be + encrypted (the concatenation of confounder, checksum, and message) + must be padded to an 8 byte boundary before encryption. The details of + the encryption of this data are identical to those for the des-cbc-md5 + encryption mode. + + Note that, since the CRC-32 checksum is not collision-proof, an + attacker could use a probabilistic chosen-plaintext attack to generate + a valid message even if a confounder is used [SG92]. The use of + collision-proof checksums is recommended for environments where such + attacks represent a significant threat. The use of the CRC-32 as the + checksum for ticket or authenticator is no longer mandated as an + interoperability requirement for Kerberos Version 5 Specification 1 + (See section 9.1 for specific details). + + 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) + + The des-cbc-md4 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD4 checksum (described in [MD492]) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be + padded to an 8 byte boundary before encryption. The details of the + encryption of this data are identical to those for the des-cbc-md5 + encryption mode. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) + + The des-cbc-md5 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be + padded to an 8 byte boundary before encryption. + + Plaintext and DES ciphtertext are encoded as blocks of 8 octets which + are concatenated to make the 64-bit inputs for the DES algorithms. The + first octet supplies the 8 most significant bits (with the octet's + MSbit used as the DES input block's MSbit, etc.), the second octet the + next 8 bits, ..., and the eighth octet supplies the 8 least + significant bits. + + Encryption under DES using cipher block chaining requires an + additional input in the form of an initialization vector. Unless + otherwise specified, zero should be used as the initialization vector. + Kerberos' use of DES requires an 8 octet confounder. + + The DES specifications identify some 'weak' and 'semi-weak' keys; + those keys shall not be used for encrypting messages for use in + Kerberos. Additionally, because of the way that keys are derived for + the encryption of checksums, keys shall not be used that yield 'weak' + or 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant + F0F0F0F0F0F0F0F0. + + A DES key is 8 octets of data, with keytype one (1). This consists of + 56 bits of key, and 8 parity bits (one per octet). The key is encoded + as a series of 8 octets written in MSB-first order. The bits within + the key are also encoded in MSB order. For example, if the encryption + key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) + where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 + are the parity bits, the first octet of the key would be + B1,B2,...,B7,P1 (with B1 as the MSbit). [See the FIPS 81 introduction + for reference.] + + String to key transformation + + To generate a DES key from a text string (password), a "salt" is + concatenated to the text string, and then padded with ASCII nulls to + an 8 byte boundary. This "salt" is normally the realm and each + component of the principal's name appended. However, sometimes + different salts are used --- for example, when a realm is renamed, or + if a user changes her username, or for compatibility with Kerberos V4 + (whose string-to-key algorithm uses a null string for the salt). This + string is then fan-folded and eXclusive-ORed with itself to form an 8 + byte DES key. Before eXclusive-ORing a block, every byte is shifted + one bit to the left to leave the lowest bit zero. The key is the + "corrected" by correcting the parity on the key, and if the key + matches a 'weak' or 'semi-weak' key as described in the DES + specification, it is eXclusive-ORed with the constant + 00000000000000F0. This key is then used to generate a DES CBC checksum + on the initial string (with the salt appended). The result of the CBC + checksum is the "corrected" as described above to form the result + which is return as the key. Pseudocode follows: + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + name_to_default_salt(realm, name) { + s = realm + for(each component in name) { + s = s + component; + } + return s; + } + + key_correction(key) { + fixparity(key); + if (is_weak_key_key(key)) + key = key XOR 0xF0; + return(key); + } + + string_to_key(string,salt) { + + odd = 1; + s = string + salt; + tempkey = NULL; + pad(s); /* with nulls to 8 byte boundary */ + for(8byteblock in s) { + if(odd == 0) { + odd = 1; + reverse(8byteblock) + } + else odd = 0; + left shift every byte in 8byteblock one bit; + tempkey = tempkey XOR 8byteblock; + } + tempkey = key_correction(tempkey); + key = key_correction(DES-CBC-check(s,tempkey)); + return(key); + } + + 6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and + without Key Derivation [Original draft by Marc Horowitz, revisions by + David Miller] + + There are still a few pieces of this specification to be included + by falue, rather than by reference. This will be done before the + Pittsburgh IETF. + This encryption type is based on the Triple DES cryptosystem, the + HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key + derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may + not be used in conjunction with the use of Triple DES keys. + + Algorithm Identifiers + + The des3-cbc-hmac-sha1 encryption type has been assigned the value 7. + The des3-cbc-hmac-sha1-kd encryption type, specifying the key + derivation variant of the encryption type, has been assigned the value + 16. The hmac-sha1-des3 checksum type has been assigned the value 13. + The hmac-sha1-des3-kd checksum type, specifying the key derivation + variant of the checksum, has been assigned the value 12. + + Triple DES Key Production + + The EncryptionKey value is 24 octets long. The 7 most significant bits + of each octet contain key bits, and the least significant bit is the + inverse of the xor of the key bits. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + For the purposes of key derivation, the block size is 64 bits, and the + key size is 168 bits. The 168 bits output by key derivation are + converted to an EncryptionKey value as follows. First, the 168 bits + are divided into three groups of 56 bits, which are expanded + individually into 64 bits as follows: + + 1 2 3 4 5 6 7 p + 9 10 11 12 13 14 15 p + 17 18 19 20 21 22 23 p + 25 26 27 28 29 30 31 p + 33 34 35 36 37 38 39 p + 41 42 43 44 45 46 47 p + 49 50 51 52 53 54 55 p + 56 48 40 32 24 16 8 p + + The "p" bits are parity bits computed over the data bits. The output + of the three expansions are concatenated to form the EncryptionKey + value. + + When the HMAC-SHA1 of a string is computed, the key is used in the + EncryptedKey form. + + The string-to-key function is used to tranform UNICODE passwords into + DES3 keys. The DES3 string-to-key function relies on the "N-fold" + algorithm, which is detailed in [9]. The description of the N-fold + algorithm in that document is as follows: + o To n-fold a number X, replicate the input value to a length that + is the least common multiple of n and the length of X. Before + each repetition, the input is rotated to the right by 13 bit + positions. The successive n-bit chunks are added together using + 1's-complement addition (that is, addition with end-around carry) + to yield an n-bit result" + o The n-fold algorithm, as with DES string-to-key, is applied to + the password string concatenated with a salt value. The salt + value is derived in the same was as for the DES string-to-key + algorithm. For 3-key triple DES then, the operation will involve + a 168-fold of the input password string. The remainder of the + string-to-key function for DES3 is shown here in pseudocode: + + DES3string-to-key(passwordString, key) + + salt = name_to_default_salt(realm, name) + s = passwordString + salt + tmpKey1 = 168-fold(s) + parityFix(tmpKey1); + if not weakKey(tmpKey1) + /* + * Encrypt temp key in itself with a + * zero initialization vector + * + * Function signature is DES3encrypt(plain, key, iv) + * with cipher as the return value + */ + tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec) + /* + * Encrypt resultant temp key in itself with third component + * of first temp key as initialization vector + */ + key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2]) + parityFix(key) + if not weakKey(key) + return SUCCESS + else + return FAILURE + else + return FAILURE + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + The weakKey function above is the same weakKey function used with DES + keys, but applied to each of the three single DES keys that comprise + the triple DES key. + + The lengths of UNICODE encoded character strings include the trailing + terminator character (0). + + Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd + + EncryptedData using this type must be generated as described in + [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC + mode. The checksum algorithm is HMAC-SHA1. If the key derivation + variant of the encryption type is used, encryption key values are + modified according to the method under the Key Derivation section + below. + + Unless otherwise specified, a zero IV must be used. + + If the length of the input data is not a multiple of the block size, + zero octets must be used to pad the plaintext to the next eight-octet + boundary. The counfounder must be eight random octets (one block). + + Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd + + Checksums using this type must be generated as described in + [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key + derivation variant of the checksum type is used, checksum key values + are modified according to the method under the Key Derivation section + below. + + Key Derivation + + In the Kerberos protocol, cryptographic keys are used in a number of + places. In order to minimize the effect of compromising a key, it is + desirable to use a different key for each of these places. Key + derivation [Horowitz96] can be used to construct different keys for + each operation from the keys transported on the network. For this to + be possible, a small change to the specification is necessary. + + This section specifies a profile for the use of key derivation + [Horowitz96] with Kerberos. For each place where a key is used, a + ``key usage'' must is specified for that purpose. The key, key usage, + and encryption/checksum type together describe the transformation from + plaintext to ciphertext, or plaintext to checksum. + + Key Usage Values + + This is a complete list of places keys are used in the kerberos + protocol, with key usage values and RFC 1510 section numbers: + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the + client key (section 5.4.1) + 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or + application session key), encrypted with the service key + (section 5.4.2) + 3. AS-REP encrypted part (includes tgs session key or application + session key), encrypted with the client key (section 5.4.2) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + session key (section 5.4.1) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + authenticator subkey (section 5.4.1) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed + with the tgs session key (sections 5.3.2, 5.4.1) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs + authenticator subkey), encrypted with the tgs session key + (section 5.3.2) + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 8. TGS-REP encrypted part (includes application session key), + encrypted with the tgs session key (section 5.4.2) + 9. TGS-REP encrypted part (includes application session key), + encrypted with the tgs authenticator subkey (section 5.4.2) + 10. AP-REQ Authenticator cksum, keyed with the application session + key (section 5.3.2) + 11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key (section + 5.3.2) + 12. AP-REP encrypted part (includes application session subkey), + encrypted with the application session key (section 5.5.2) + 13. KRB-PRIV encrypted part, encrypted with a key chosen by the + application (section 5.7.1) + 14. KRB-CRED encrypted part, encrypted with a key chosen by the + application (section 5.6.1) + 15. KRB-SAVE cksum, keyed with a key chosen by the application + (section 5.8.1) + 18. KRB-ERROR checksum (e-cksum in section 5.9.1) + 19. AD-KDCIssued checksum (ad-checksum in appendix B.1) + 20. Checksum for Mandatory Ticket Extensions (appendix B.6) + 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) + + Key usage values between 1024 and 2047 (inclusive) are reserved for + application use. Applications should use even values for encryption + and odd values for checksums within this range. + + A few of these key usages need a little clarification. A service which + receives an AP-REQ has no way to know if the enclosed Ticket was part + of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used + for generating a Ticket, whether it is in response to an AS- REQ or + TGS-REQ. + + There might exist other documents which define protocols in terms of + the RFC1510 encryption types or checksum types. Such documents would + not know about key usages. In order that these documents continue to + be meaningful until they are updated, key usages 1024 and 1025 must be + used to derive keys for encryption and checksums, respectively. New + protocols defined in terms of the Kerberos encryption and checksum + types should use their own key usages. Key usages may be registered + with IANA to avoid conflicts. Key usages must be unsigned 32 bit + integers. Zero is not permitted. + + Defining Cryptosystems Using Key Derivation + + Kerberos requires that the ciphertext component of EncryptedData be + tamper-resistant as well as confidential. This implies encryption and + integrity functions, which must each use their own separate keys. So, + for each key usage, two keys must be generated, one for encryption + (Ke), and one for integrity (Ki): + + Ke = DK(protocol key, key usage | 0xAA) + Ki = DK(protocol key, key usage | 0x55) + + where the protocol key is from the EncryptionKey from the wire + protocol, and the key usage is represented as a 32 bit integer in + network byte order. The ciphertest must be generated from the + plaintext as follows: + + ciphertext = E(Ke, confounder | plaintext | padding) | + H(Ki, confounder | plaintext | padding) + + The confounder and padding are specific to the encryption algorithm E. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + When generating a checksum only, there is no need for a confounder or + padding. Again, a new key (Kc) must be used. Checksums must be + generated from the plaintext as follows: + + Kc = DK(protocol key, key usage | 0x99) + MAC = H(Kc, plaintext) + + Note that each enctype is described by an encryption algorithm E and a + keyed hash algorithm H, and each checksum type is described by a keyed + hash algorithm H. HMAC, with an appropriate hash, is required for use + as H. + + Key Derivation from Passwords + + The well-known constant for password key derivation must be the byte + string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values + correspond to the ASCII encoding for the string "kerberos". + + 6.4. Checksums + + The following is the ASN.1 definition used for a checksum: + + Checksum ::= SEQUENCE { + cksumtype[0] INTEGER, + checksum[1] OCTET STRING + } + + cksumtype + This field indicates the algorithm used to generate the + accompanying checksum. + checksum + This field contains the checksum itself, encoded as an octet + string. + Detailed specification of selected checksum types appear later in this + section. Negative values for the checksum type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpretations. + + Checksums used by Kerberos can be classified by two properties: + whether they are collision-proof, and whether they are keyed. It is + infeasible to find two plaintexts which generate the same checksum + value for a collision-proof checksum. A key is required to perturb or + initialize the algorithm in a keyed checksum. To prevent + message-stream modification by an active attacker, unkeyed checksums + should only be used when the checksum and message will be subsequently + encrypted (e.g. the checksums defined as part of the encryption + algorithms covered earlier in this section). + + Collision-proof checksums can be made tamper-proof if the checksum + value is encrypted before inclusion in a message. In such cases, the + composition of the checksum and the encryption algorithm must be + considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using + DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed + checksums, as well as for the encrypted forms of unkeyed + collision-proof checksums, Kerberos prepends a confounder before the + checksum is calculated. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 6.4.1. The CRC-32 Checksum (crc32) + + The CRC-32 checksum calculates a checksum based on a cyclic redundancy + check as described in ISO 3309 [ISO3309]. The resulting checksum is + four (4) octets in length. The CRC-32 is neither keyed nor + collision-proof. The use of this checksum is not recommended. An + attacker using a probabilistic chosen-plaintext attack as described in + [SG92] might be able to generate an alternative message that satisfies + the checksum. The use of collision-proof checksums is recommended for + environments where such attacks represent a significant threat. + + 6.4.2. The RSA MD4 Checksum (rsa-md4) + + The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm + [MD4-92]. The algorithm takes as input an input message of arbitrary + length and produces as output a 128-bit (16 octet) checksum. RSA-MD4 + is believed to be collision-proof. + + 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) + + The RSA-MD4-DES checksum calculates a keyed collision-proof checksum + by prepending an 8 octet confounder before the text, applying the RSA + MD4 checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be + zero. The resulting checksum is 24 octets long (8 octets of which are + redundant). This checksum is tamper-proof and believed to be + collision-proof. + + The DES specifications identify some weak keys' and 'semi-weak keys'; + those keys shall not be used for generating RSA-MD4 checksums for use + in Kerberos. + + The format for the checksum is described in the follow- ing diagram: + + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) +| + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + + 6.4.4. The RSA MD5 Checksum (rsa-md5) + + The RSA-MD5 checksum calculates a checksum using the RSA MD5 + algorithm. [MD5-92]. The algorithm takes as input an input message of + arbitrary length and produces as output a 128-bit (16 octet) checksum. + RSA-MD5 is believed to be collision-proof. + + 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) + + The RSA-MD5-DES checksum calculates a keyed collision-proof checksum + by prepending an 8 octet confounder before the text, applying the RSA + MD5 checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector + should be zero. The resulting checksum is 24 octets long (8 octets of + which are redundant). This checksum is tamper-proof and believed to be + collision-proof. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + The DES specifications identify some 'weak keys' and 'semi-weak keys'; + those keys shall not be used for encrypting RSA-MD5 checksums for use + in Kerberos. + + The format for the checksum is described in the following diagram: + + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) +| + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + + 6.4.6. DES cipher-block chained checksum (des-mac) + + The DES-MAC checksum is computed by prepending an 8 octet confounder + to the plaintext, performing a DES CBC-mode encryption on the result + using the key and an initialization vector of zero, taking the last + block of the ciphertext, prepending the same confounder and encrypting + the pair using DES in cipher-block-chaining (CBC) mode using a a + variant of the key, where the variant is computed by eXclusive-ORing + the key with the hexadecimal constant F0F0F0F0F0F0F0F0. The + initialization vector should be zero. The resulting checksum is 128 + bits (16 octets) long, 64 bits of which are redundant. This checksum + is tamper-proof and collision-proof. + + The format for the checksum is described in the following diagram: + + ++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) +| + ++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(8) + } + + The DES specifications identify some 'weak' and 'semi-weak' keys; + those keys shall not be used for generating DES-MAC checksums for use + in Kerberos, nor shall a key be used whose variant is 'weak' or + 'semi-weak'. + + 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative + (rsa-md4-des-k) + + The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum + by applying the RSA MD4 checksum algorithm and encrypting the results + using DES in cipher-block-chaining (CBC) mode using a DES key as both + key and initialization vector. The resulting checksum is 16 octets + long. This checksum is tamper-proof and believed to be + collision-proof. Note that this checksum type is the old method for + encoding the RSA-MD4-DES checksum and it is no longer recommended. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 6.4.8. DES cipher-block chained checksum alternative (des-mac-k) + + The DES-MAC-K checksum is computed by performing a DES CBC-mode + encryption of the plaintext, and using the last block of the + ciphertext as the checksum value. It is keyed with an encryption key + and an initialization vector; any uses which do not specify an + additional initialization vector will use the key as both key and + initialization vector. The resulting checksum is 64 bits (8 octets) + long. This checksum is tamper-proof and collision-proof. Note that + this checksum type is the old method for encoding the DES-MAC checksum + and it is no longer recommended. The DES specifications identify some + 'weak keys' and 'semi-weak keys'; those keys shall not be used for + generating DES-MAC checksums for use in Kerberos. + + 7. Naming Constraints + + 7.1. Realm Names + + Although realm names are encoded as GeneralStrings and although a + realm can technically select any name it chooses, interoperability + across realm boundaries requires agreement on how realm names are to + be assigned, and what information they imply. + + To enforce these conventions, each realm must conform to the + conventions itself, and it must require that any realms with which + inter-realm keys are shared also conform to the conventions and + require the same from its neighbors. + + Kerberos realm names are case sensitive. Realm names that differ only + in the case of the characters are not equivalent. There are presently + four styles of realm names: domain, X500, other, and reserved. + Examples of each style follow: + + domain: ATHENA.MIT.EDU (example) + X500: C=US/O=OSF (example) + other: NAMETYPE:rest/of.name=without-restrictions (example) + reserved: reserved, but will not conflict with above + + Domain names must look like domain names: they consist of components + separated by periods (.) and they contain neither colons (:) nor + slashes (/). Though domain names themselves are case insensitive, in + order for realms to match, the case must match as well. When + establishing a new realm name based on an internet domain name it is + recommended by convention that the characters be converted to upper + case. + + X.500 names contain an equal (=) and cannot contain a colon (:) before + the equal. The realm names for X.500 names will be string + representations of the names with components separated by slashes. + Leading and trailing slashes will not be included. + + Names that fall into the other category must begin with a prefix that + contains no equal (=) or period (.) and the prefix must be followed by + a colon (:) and the rest of the name. All prefixes must be assigned + before they may be used. Presently none are assigned. + + The reserved category includes strings which do not fall into the + first three categories. All names in this category are reserved. It is + unlikely that names will be assigned to this category unless there is + a very strong argument for not using the 'other' category. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + These rules guarantee that there will be no conflicts between the + various name styles. The following additional constraints apply to the + assignment of realm names in the domain and X.500 categories: the name + of a realm for the domain or X.500 formats must either be used by the + organization owning (to whom it was assigned) an Internet domain name + or X.500 name, or in the case that no such names are registered, + authority to use a realm name may be derived from the authority of the + parent realm. For example, if there is no domain name for E40.MIT.EDU, + then the administrator of the MIT.EDU realm can authorize the creation + of a realm with that name. + + This is acceptable because the organization to which the parent is + assigned is presumably the organization authorized to assign names to + its children in the X.500 and domain name systems as well. If the + parent assigns a realm name without also registering it in the domain + name or X.500 hierarchy, it is the parent's responsibility to make + sure that there will not in the future exists a name identical to the + realm name of the child unless it is assigned to the same entity as + the realm name. + + 7.2. Principal Names + + As was the case for realm names, conventions are needed to ensure that + all agree on what information is implied by a principal name. The + name-type field that is part of the principal name indicates the kind + of information implied by the name. The name-type should be treated as + a hint. Ignoring the name type, no two names can be the same (i.e. at + least one of the components, or the realm, must be different). The + following name types are defined: + + name-type value meaning + + NT-UNKNOWN 0 Name type not known + NT-PRINCIPAL 1 General principal name (e.g. username, DCE +principal) + NT-SRV-INST 2 Service and other unique instance (krbtgt) + NT-SRV-HST 3 Service with host name as instance (telnet, rcmds) + NT-SRV-XHST 4 Service with slash-separated host name components + NT-UID 5 Unique ID + NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] + NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. +user@foo.com) + + When a name implies no information other than its uniqueness at a + particular time the name type PRINCIPAL should be used. The principal + name type should be used for users, and it might also be used for a + unique server. If the name is a unique machine generated ID that is + guaranteed never to be reassigned then the name type of UID should be + used (note that it is generally a bad idea to reassign names of any + type since stale entries might remain in access control lists). + + If the first component of a name identifies a service and the + remaining components identify an instance of the service in a server + specified manner, then the name type of SRV-INST should be used. An + example of this name type is the Kerberos ticket-granting service + whose name has a first component of krbtgt and a second component + identifying the realm for which the ticket is valid. + + If instance is a single component following the service name and the + instance identifies the host on which the server is running, then the + name type SRV-HST should be used. This type is typically used for + Internet services such as telnet and the Berkeley R commands. If the + separate components of the host name appear as successive components + following the name of the service, then the name type SRV-XHST should + be used. This type might be used to identify servers on hosts with + X.500 names where the slash (/) might otherwise be ambiguous. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + A name type of NT-X500-PRINCIPAL should be used when a name from an + X.509 certificiate is translated into a Kerberos name. The encoding of + the X.509 name as a Kerberos principal shall conform to the encoding + rules specified in RFC 2253. + + A name type of SMTP allows a name to be of a form that resembles a + SMTP email name. This name type can be used in conjunction with + name-canonicalization to allow a free-form of username to be specified + as a client name and allow the KDC to determine the Kerberos principal + name for the requested name. [JBrezak] + + A name type of UNKNOWN should be used when the form of the name is not + known. When comparing names, a name of type UNKNOWN will match + principals authenticated with names of any type. A principal + authenticated with a name of type UNKNOWN, however, will only match + other names of type UNKNOWN. + + Names of any type with an initial component of 'krbtgt' are reserved + for the Kerberos ticket granting service. See section 8.2.3 for the + form of such names. + + 7.2.1. Name of server principals + + The principal identifier for a server on a host will generally be + composed of two parts: (1) the realm of the KDC with which the server + is registered, and (2) a two-component name of type NT-SRV-HST if the + host name is an Internet domain name or a multi-component name of type + NT-SRV-XHST if the name of the host is of a form such as X.500 that + allows slash (/) separators. The first component of the two- or + multi-component name will identify the service and the latter + components will identify the host. Where the name of the host is not + case sensitive (for example, with Internet domain names) the name of + the host must be lower case. If specified by the application protocol + for services such as telnet and the Berkeley R commands which run with + system privileges, the first component may be the string 'host' + instead of a service specific identifier. When a host has an official + name and one or more aliases, the official name of the host must be + used when constructing the name of the server principal. + + 8. Constants and other defined values + + 8.1. Host address types + + All negative values for the host address type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpretations. + + The values of the types for the following addresses are chosen to + match the defined address family constants in the Berkeley Standard + Distributions of Unix. They can be found in with symbolic names AF_xxx + (where xxx is an abbreviation of the address family name). + + Internet (IPv4) Addresses + + Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in + MSB order. The type of IPv4 addresses is two (2). + + Internet (IPv6) Addresses [Westerlund] + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB + order. The type of IPv6 addresses is twenty-four (24). [RFC1883] + [RFC1884]. The following addresses (see [RFC1884]) MUST not appear in + any Kerberos packet: + o the Unspecified Address + o the Loopback Address + o Link-Local addresses + IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. + + CHAOSnet addresses + + CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB + order. The type of CHAOSnet addresses is five (5). + + ISO addresses + + ISO addresses are variable-length. The type of ISO addresses is seven + (7). + + Xerox Network Services (XNS) addresses + + XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. + The type of XNS addresses is six (6). + + AppleTalk Datagram Delivery Protocol (DDP) addresses + + AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit + network number. The first octet of the address is the node number; the + remaining two octets encode the network number in MSB order. The type + of AppleTalk DDP addresses is sixteen (16). + + DECnet Phase IV addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. + The type of DECnet Phase IV addresses is twelve (12). + + Netbios addresses + + Netbios addresses are 16-octet addresses typically composed of 1 to 15 + characters, trailing blank (ascii char 20) filled, with a 16th octet + of 0x0. The type of Netbios addresses is 20 (0x14). + + 8.2. KDC messages + + 8.2.1. UDP/IP transport + + When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request + using UDP IP transport, the client shall send a UDP datagram + containing only an encoding of the request to port 88 (decimal) at the + KDC's IP address; the KDC will respond with a reply datagram + containing only an encoding of the reply message (either a KRB_ERROR + or a KRB_KDC_REP) to the sending port at the sender's IP address. + Kerberos servers supporting IP transport must accept UDP requests on + port 88 (decimal). The response to a request made through UDP/IP + transport must also use UDP/IP transport. + + 8.2.2. TCP/IP transport [Westerlund,Danielsson] + + Kerberos servers (KDC's) should accept TCP requests on port 88 + (decimal) and clients should support the sending of TCP requests on + port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC + over a TCP stream, a new connection will be established for each + authentication exchange (request and response). The KRB_KDC_REP or + KRB_ERROR message will be returned to the client on the same TCP + stream that was established for the request. The response to a request + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + made through TCP/IP transport must also use TCP/IP transport. + Implementors should note that some extentions to the Kerberos protocol + will not work if any implementation not supporting the TCP transport + is involved (client or KDC). Implementors are strongly urged to + support the TCP transport on both the client and server and are + advised that the current notation of "should" support will likely + change in the future to must support. The KDC may close the TCP stream + after sending a response, but may leave the stream open if it expects + a followup - in which case it may close the stream at any time if + resource constratints or other factors make it desirable to do so. + Care must be taken in managing TCP/IP connections with the KDC to + prevent denial of service attacks based on the number of TCP/IP + connections with the KDC that remain open. If multiple exchanges with + the KDC are needed for certain forms of preauthentication, multiple + TCP connections may be required. A client may close the stream after + receiving response, and should close the stream if it does not expect + to send followup messages. The client must be prepared to have the + stream closed by the KDC at anytime, in which case it must simply + connect again when it is ready to send subsequent messages. + + The first four octets of the TCP stream used to transmit the request + request will encode in network byte order the length of the request + (KRB_KDC_REQ), and the length will be followed by the request itself. + The response will similarly be preceeded by a 4 octet encoding in + network byte order of the length of the KRB_KDC_REP or the KRB_ERROR + message and will be followed by the KRB_KDC_REP or the KRB_ERROR + response. If the sign bit is set on the integer represented by the + first 4 octets, then the next 4 octets will be read, extending the + length of the field by another 4 octets (less the sign bit which is + reserved for future expansion). + + 8.2.3. OSI transport + + During authentication of an OSI client to an OSI server, the mutual + authentication of an OSI server to an OSI client, the transfer of + credentials from an OSI client to an OSI server, or during exchange of + private or integrity checked messages, Kerberos protocol messages may + be treated as opaque objects and the type of the authentication + mechanism will be: + + OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), +security(5),kerberosv5(2)} + + Depending on the situation, the opaque object will be an + authentication header (KRB_AP_REQ), an authentication reply + (KRB_AP_REP), a safe message (KRB_SAFE), a private message (KRB_PRIV), + or a credentials message (KRB_CRED). The opaque data contains an + application code as specified in the ASN.1 description for each + message. The application code may be used by Kerberos to determine the + message type. + + 8.2.3. Name of the TGS + + The principal identifier of the ticket-granting service shall be + composed of three parts: (1) the realm of the KDC issuing the TGS + ticket (2) a two-part name of type NT-SRV-INST, with the first part + "krbtgt" and the second part the name of the realm which will accept + the ticket-granting ticket. For example, a ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" + (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), + ("krbtgt", "MIT.EDU") (name). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 8.3. Protocol constants and associated values + + The following tables list constants used in the protocol and defines + their meanings. Ranges are specified in the "specification" section + that limit the values of constants for which values are defined here. + This allows implementations to make assumptions about the maximum + values that will be received for these constants. Implementation + receiving values outside the range specified in the "specification" + section may reject the request, but they must recover cleanly. + + Encryption type etype value block size minimum pad confounder +size + NULL 0 1 0 0 + des-cbc-crc 1 8 4 8 + des-cbc-md4 2 8 0 8 + des-cbc-md5 3 8 0 8 + reserved 4 + des3-cbc-md5 5 8 0 8 + reserved 6 + des3-cbc-sha1 7 8 0 8 + dsaWithSHA1-CmsOID 9 +(pkinit) + md5WithRSAEncryption-CmsOID 10 +(pkinit) + sha1WithRSAEncryption-CmsOID 11 +(pkinit) + rc2CBC-EnvOID 12 +(pkinit) + rsaEncryption-EnvOID 13 (pkinit from PKCS#1 +v1.5) + rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 +v2.0) + des-ede3-cbc-Env-OID 15 +(pkinit) + des3-cbc-sha1-kd 16 (Tom +Yu) + rc4-hmac 23 +(swift) + rc4-hmac-exp 24 +(swift) + + reserved 0x8003 + + Checksum type sumtype value checksum size + CRC32 1 4 + rsa-md4 2 16 + rsa-md4-des 3 24 + des-mac 4 16 + des-mac-k 5 8 + rsa-md4-des-k 6 16 (drop rsa ?) + rsa-md5 7 16 (drop rsa ?) + rsa-md5-des 8 24 (drop rsa ?) + rsa-md5-des3 9 24 (drop rsa ?) + hmac-sha1-des3-kd 12 20 + hmac-sha1-des3 13 20 + sha1 (unkeyed) 14 20 + + padata type padata-type value + + PA-TGS-REQ 1 + PA-ENC-TIMESTAMP 2 + PA-PW-SALT 3 + reserved 4 + PA-ENC-UNIX-TIME 5 (depricated) + PA-SANDIA-SECUREID 6 + PA-SESAME 7 + PA-OSF-DCE 8 + PA-CYBERSAFE-SECUREID 9 + PA-AFS3-SALT 10 + PA-ETYPE-INFO 11 + PA-SAM-CHALLENGE 12 (sam/otp) + PA-SAM-RESPONSE 13 (sam/otp) + PA-PK-AS-REQ 14 (pkinit) + PA-PK-AS-REP 15 (pkinit) + PA-USE-SPECIFIED-KVNO 20 + PA-SAM-REDIRECT 21 (sam/otp) + PA-GET-FROM-TYPED-DATA 22 + PA-SAM-ETYPE-INFO 23 (sam/otp) + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + data-type value form of typed-data + + reserved 1-21 + TD-PADATA 22 + TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + TD-APP-DEFINED-ERROR 106 + + authorization data type ad-type value + AD-IF-RELEVANT 1 + AD-INTENDED-FOR-SERVER 2 + AD-INTENDED-FOR-APPLICATION-CLASS 3 + AD-KDC-ISSUED 4 + AD-OR 5 + AD-MANDATORY-TICKET-EXTENSIONS 6 + AD-IN-TICKET-EXTENSIONS 7 + reserved values 8-63 + OSF-DCE 64 + SESAME 65 + AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) + AD-WIN200-PAC 128 +(jbrezak@exchange.microsoft.com) + + Ticket Extension Types + + TE-TYPE-NULL 0 Null ticket extension + TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization +data + reserved 2 TE-TYPE-PKCROSS-KDC + TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket + TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp + reserved 5 TE-TYPE-DEST-HOST + + alternate authentication type method-type value + reserved values 0-63 + ATT-CHALLENGE-RESPONSE 64 + + transited encoding type tr-type value + DOMAIN-X500-COMPRESS 1 + reserved values all others + + Label Value Meaning or MIT code + + pvno 5 current Kerberos protocol version number + + message types + + KRB_AS_REQ 10 Request for initial authentication + KRB_AS_REP 11 Response to KRB_AS_REQ request + KRB_TGS_REQ 12 Request for authentication based on TGT + KRB_TGS_REP 13 Response to KRB_TGS_REQ request + KRB_AP_REQ 14 application request to server + KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL + KRB_SAFE 20 Safe (checksummed) application message + KRB_PRIV 21 Private (encrypted) application message + KRB_CRED 22 Private (encrypted) message to forward +credentials + KRB_ERROR 30 Error response + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + name types + + KRB_NT_UNKNOWN 0 Name type not known + KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or +for users + KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) + KRB_NT_SRV_HST 3 Service with host name as instance (telnet, +rcommands) + KRB_NT_SRV_XHST 4 Service with host as remaining components + KRB_NT_UID 5 Unique ID + KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] + + error codes + + KDC_ERR_NONE 0 No error + KDC_ERR_NAME_EXP 1 Client's entry in database has +expired + KDC_ERR_SERVICE_EXP 2 Server's entry in database has +expired + KDC_ERR_BAD_PVNO 3 Requested protocol version number +not supported + KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old +master key + KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old +master key + KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos +database + KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos +database + KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in +database + KDC_ERR_NULL_KEY 9 The client or server has a null key + KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating + KDC_ERR_NEVER_VALID 11 Requested start time is later than +end time + KDC_ERR_POLICY 12 KDC policy rejects request + KDC_ERR_BADOPTION 13 KDC cannot accommodate requested +option + KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption +type + KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum +type + KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type + KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited +type + KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been +revoked + KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been +revoked + KDC_ERR_TGT_REVOKED 20 TGT has been revoked + KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again +later + KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again +later + KDC_ERR_KEY_EXPIRED 23 Password has expired - change +password to reset + KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was +invalid + KDC_ERR_PREAUTH_REQUIRED 25 Additional +pre-authenticationrequired [40] + KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't +match + KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for +user2user only + KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path + KDC_ERR_SVC_UNAVAILABLE 29 A service is not available + KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field +failed + KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired + KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid + KRB_AP_ERR_REPEAT 34 Request is a replay + KRB_AP_ERR_NOT_US 35 The ticket isn't for us + KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't +match + KRB_AP_ERR_SKEW 37 Clock skew too great + KRB_AP_ERR_BADADDR 38 Incorrect net address + KRB_AP_ERR_BADVERSION 39 Protocol version mismatch + KRB_AP_ERR_MSG_TYPE 40 Invalid msg type + KRB_AP_ERR_MODIFIED 41 Message stream modified + KRB_AP_ERR_BADORDER 42 Message out of order + KRB_AP_ERR_BADKEYVER 44 Specified version of key is not +available + KRB_AP_ERR_NOKEY 45 Service key not available + KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed + KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction + KRB_AP_ERR_METHOD 48 Alternative authentication method +required + KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in +message + KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in +message + KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path + KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry +with TCP + KRB_ERR_GENERIC 60 Generic error (description in +e-text) + KRB_ERR_FIELD_TOOLONG 61 Field is too long for this +implementation + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) + KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) + KDC_ERROR_INVALID_SIG 64 (pkinit) + KDC_ERR_KEY_TOO_WEAK 65 (pkinit) + KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) + KRB_AP_ERR_NO_TGT 67 (user-to-user) + KDC_ERR_WRONG_REALM 68 (user-to-user) + KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) + KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) + KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) + KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) + KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) + + 9. Interoperability requirements + + Version 5 of the Kerberos protocol supports a myriad of options. Among + these are multiple encryption and checksum types, alternative encoding + schemes for the transited field, optional mechanisms for + pre-authentication, the handling of tickets with no addresses, options + for mutual authentication, user to user authentication, support for + proxies, forwarding, postdating, and renewing tickets, the format of + realm names, and the handling of authorization data. + + In order to ensure the interoperability of realms, it is necessary to + define a minimal configuration which must be supported by all + implementations. This minimal configuration is subject to change as + technology does. For example, if at some later date it is discovered + that one of the required encryption or checksum algorithms is not + secure, it will be replaced. + + 9.1. Specification 2 + + This section defines the second specification of these options. + Implementations which are configured in this way can be said to + support Kerberos Version 5 Specification 2 (5.1). Specification 1 + (depricated) may be found in RFC1510. + + Transport + + TCP/IP and UDP/IP transport must be supported by KDCs claiming + conformance to specification 2. Kerberos clients claiming conformance + to specification 2 must support UDP/IP transport for messages with the + KDC and should support TCP/IP transport. + + Encryption and checksum methods + + The following encryption and checksum mechanisms must be supported. + Implementations may support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to also support them: This list is to be determined. + + Encryption: DES-CBC-MD5, one triple des variant (tbd) + Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd) + + Realm Names + + All implementations must understand hierarchical realms in both the + Internet Domain and the X.500 style. When a ticket granting ticket for + an unknown realm is requested, the KDC must be able to determine the + names of the intermediate realms between the KDCs realm and the + requested realm. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + Transited field encoding + + DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. + Alternative encodings may be supported, but they may be used only when + that encoding is supported by ALL intermediate realms. + + Pre-authentication methods + + The TGS-REQ method must be supported. The TGS-REQ method is not used + on the initial request. The PA-ENC-TIMESTAMP method must be supported + by clients but whether it is enabled by default may be determined on a + realm by realm basis. If not used in the initial request and the error + KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an + acceptable method, the client should retry the initial request using + the PA-ENC-TIMESTAMP preauthentication method. Servers need not + support the PA-ENC-TIMESTAMP method, but if not supported the server + should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a + request. + + Mutual authentication + + Mutual authentication (via the KRB_AP_REP message) must be supported. + + Ticket addresses and flags + + All KDC's must pass on tickets that carry no addresses (i.e. if a TGT + contains no addresses, the KDC will return derivative tickets), but + each realm may set its own policy for issuing such tickets, and each + application server will set its own policy with respect to accepting + them. + + Proxies and forwarded tickets must be supported. Individual realms and + application servers can set their own policy on when such tickets will + be accepted. + + All implementations must recognize renewable and postdated tickets, + but need not actually implement them. If these options are not + supported, the starttime and endtime in the ticket shall specify a + ticket's entire useful life. When a postdated ticket is decoded by a + server, all implementations shall make the presence of the postdated + flag visible to the calling server. + + User-to-user authentication + + Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC + option) must be provided by implementations, but individual realms may + decide as a matter of policy to reject such requests on a + per-principal or realm-wide basis. + + Authorization data + + Implementations must pass all authorization data subfields from + ticket-granting tickets to any derivative tickets unless directed to + suppress a subfield as part of the definition of that registered + subfield type (it is never incorrect to pass on a subfield, and no + registered subfield types presently specify suppression at the KDC). + + Implementations must make the contents of any authorization data + subfields available to the server when a ticket is used. + Implementations are not required to allow clients to specify the + contents of the authorization data fields. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + Constant ranges + + All protocol constants are constrained to 32 bit (signed) values + unless further constrained by the protocol definition. This limit is + provided to allow implementations to make assumptions about the + maximum values that will be received for these constants. + Implementation receiving values outside this range may reject the + request, but they must recover cleanly. + + 9.2. Recommended KDC values + + Following is a list of recommended values for a KDC implementation, + based on the list of suggested configuration constants (see section + 4.4). + + minimum lifetime 5 minutes + maximum renewable lifetime 1 week + maximum ticket lifetime 1 day + empty addresses only when suitable restrictions appear + in authorization data + proxiable, etc. Allowed. + + 10. REFERENCES + + [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- + cation Service for Computer Networks," IEEE Communica- + tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). + + [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. + Saltzer, Section E.2.1: Kerberos Authentication and + Authorization System, M.I.T. Project Athena, Cambridge, + Massachusetts (December 21, 1987). + + [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- + beros: An Authentication Service for Open Network Sys- + tems," pp. 191-202 in Usenix Conference Proceedings, + Dallas, Texas (February, 1988). + + [NS78] Roger M. Needham and Michael D. Schroeder, "Using + Encryption for Authentication in Large Networks of Com- + puters," Communications of the ACM, Vol. 21(12), + pp. 993-999 (December, 1978). + + [DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- + stamps in Key Distribution Protocols," Communications + of the ACM, Vol. 24(8), pp. 533-536 (August 1981). + + [KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, + "The Evolution of the Kerberos Authentication Service," + in an IEEE Computer Society Text soon to be published + (June 1992). + + [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and + Accounting for Distributed Systems," in Proceedings of + the 13th International Conference on Distributed Com- + puting Systems, Pittsburgh, PA (May, 1993). + + [DS90] Don Davis and Ralph Swick, "Workstation Services and + Kerberos Authentication at Project Athena," Technical + Memorandum TM-424, MIT Laboratory for Computer Science + (February 1990). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- + merfeld, and K. Raeburn, Section E.1: Service Manage- + ment System, M.I.T. Project Athena, Cambridge, Mas- + sachusetts (1987). + + [X509-88] CCITT, Recommendation X.509: The Directory Authentica- + tion Framework, December 1988. + + [Pat92]. J. Pato, Using Pre-Authentication to Avoid Password + Guessing Attacks, Open Software Foundation DCE Request + for Comments 26 (December 1992). + + [DES77] National Bureau of Standards, U.S. Department of Com- + merce, "Data Encryption Standard," Federal Information + Processing Standards Publication 46, Washington, DC + (1977). + + [DESM80] National Bureau of Standards, U.S. Department of Com- + merce, "DES Modes of Operation," Federal Information + Processing Standards Publication 81, Springfield, VA + (December 1980). + + [SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message + Integrity in Cryptographic Protocols," in Proceedings + of the IEEE Symposium on Research in Security and + Privacy, Oakland, California (May 1992). + + [IS3309] International Organization for Standardization, "ISO + Information Processing Systems - Data Communication - + High-Level Data Link Control Procedure - Frame Struc- + ture," IS 3309 (October 1984). 3rd Edition. + + [MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC + 1320, MIT Laboratory for Computer Science (April + 1992). + + [MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC + 1321, MIT Laboratory for Computer Science (April + 1992). + + [KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication," Working Draft + draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). + + [Horowitz96] Horowitz, M., "Key Derivation for Authentication, + Integrity, and Privacy", +draft-horowitz-key-derivation-02.txt, + August 1998. + + [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- + horowitz-kerb-key-derivation-01.txt, September 1998. + + [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", +draft-ietf-ipsec-hmac- + md5-01.txt, August, 1996. + + A. Pseudo-code for protocol processing + + This appendix provides pseudo-code describing how the messages are to + be constructed and interpreted by clients and servers. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + A.1. KRB_AS_REQ generation + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_AS_REQ */ + + if(pa_enc_timestamp_required) then + request.padata.padata-type = PA-ENC-TIMESTAMP; + get system_time; + padata-body.patimestamp,pausec = system_time; + encrypt padata-body into request.padata.padata-value + using client.key; /* derived from password */ + endif + + body.kdc-options := users's preferences; + body.cname := user's name; + body.realm := user's realm; + body.sname := service's name; /* usually "krbtgt", +"localrealm" */ + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + omit body.enc-authorization-data; + request.req-body := body; + + kerberos := lookup(name of local kerberos server (or servers)); + send(packet,kerberos); + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.2. KRB_AS_REQ verification and KRB_AS_REP generation + + decode message into req; + + client := lookup(req.cname,req.realm); + server := lookup(req.sname,req.realm); + + get system_time; + kdc_time := system_time.seconds; + + if (!client) then + /* no client in Database */ + error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); + endif + if (!server) then + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + + if(client.pa_enc_timestamp_required and + pa_enc_timestamp not present) then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); + endif + + if(pa_enc_timestamp present) then + decrypt req.padata-value into decrypted_enc_timestamp + using client.key; + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + if(decrypted_enc_timestamp is not within allowable +skew) then + error_out(KDC_ERR_PREAUTH_FAILED); + endif + if(decrypted_enc_timestamp and usec is replay) + error_out(KDC_ERR_PREAUTH_FAILED); + endif + add decrypted_enc_timestamp and usec to replay cache; + endif + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := req.srealm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + if (req.kdc-options.FORWARDABLE is set) then + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.PROXIABLE is set) then + set new_tkt.flags.PROXIABLE; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + set new_tkt.flags.MAY-POSTDATE; + endif + if ((req.kdc-options.RENEW is set) or + (req.kdc-options.VALIDATE is set) or + (req.kdc-options.PROXY is set) or + (req.kdc-options.FORWARDED is set) or + (req.kdc-options.ENC-TKT-IN-SKEY is set)) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.session := random_session_key(); + new_tkt.cname := req.cname; + new_tkt.crealm := req.crealm; + new_tkt.transited := empty_transited_field(); + + new_tkt.authtime := kdc_time; + + if (req.kdc-options.POSTDATED is set) then + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + new_tkt.starttime := req.from; + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + else + omit new_tkt.starttime; /* treated as authtime when omitted +*/ + endif + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + + new_tkt.endtime := min(till, + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till)) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := req.till; + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if (req.kdc-options.RENEWABLE is set) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + +new_tkt.starttime+client.max_rlife, + +new_tkt.starttime+server.max_rlife, + +new_tkt.starttime+max_rlife_for_realm); + else + omit new_tkt.renew-till; /* only present if RENEWABLE +*/ + endif + + if (req.addresses) then + new_tkt.caddr := req.addresses; + else + omit new_tkt.caddr; + endif + + new_tkt.authorization_data := empty_authorization_data(); + + encode to-be-encrypted part of ticket into OCTET STRING; + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, +server.p_kvno; + + /* Start processing the response */ + + resp.pvno := 5; + resp.msg-type := KRB_AS_REP; + resp.cname := req.cname; + resp.crealm := req.realm; + resp.ticket := new_tkt; + + resp.key := new_tkt.session; + resp.last-req := fetch_last_request_info(client); + resp.nonce := req.nonce; + resp.key-expiration := client.expiration; + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + resp.endtime := new_tkt.endtime; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + resp.realm := new_tkt.realm; + resp.sname := new_tkt.sname; + + resp.caddr := new_tkt.caddr; + + encode body of reply into OCTET STRING; + + resp.enc-part := encrypt OCTET STRING + using use_etype, client.key, client.p_kvno; + send(resp); + + A.3. KRB_AS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) +then + set pa_enc_timestamp_required; + goto KRB_AS_REQ; + endif + process_error(resp); + return; + endif + + /* On error, discard the response, and zero the session key */ + /* from the response immediately */ + + key = get_decryption_key(resp.enc-part.kvno, +resp.enc-part.etype, + resp.padata); + unencrypted part of resp := decode of decrypt of resp.enc-part + using resp.enc-part.etype and key; + zero(key); + + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + if near(resp.princ_exp) then + print(warning message); + endif + save_for_later(ticket,session,client,server,times,flags); + + A.4. KRB_AS_REP and KRB_TGS_REP common checks + + if (decryption_error() or + (req.cname != resp.cname) or + (req.realm != resp.crealm) or + (req.sname != resp.sname) or + (req.realm != resp.realm) or + (req.nonce != resp.nonce) or + (req.addresses != resp.caddr)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + /* make sure no flags are set that shouldn't be, and that all +that */ + /* should be are set +*/ + if (!check_flags_for_compatability(req.kdc-options,resp.flags)) +then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.from = 0) and + (resp.starttime is not within allowable skew)) then + destroy resp.key; + return KRB_AP_ERR_SKEW; + endif + if ((req.from != 0) and (req.from != resp.starttime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + if ((req.till != 0) and (resp.endtime > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (req.rtime != 0) and (resp.renew-till > req.rtime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + if ((req.kdc-options.RENEWABLE-OK is set) and + (resp.flags.RENEWABLE) and + (req.till != 0) and + (resp.renew-till > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + A.5. KRB_TGS_REQ generation + + /* Note that make_application_request might have to recursivly +*/ + /* call this routine to get the appropriate ticket-granting +ticket */ + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_TGS_REQ */ + + body.kdc-options := users's preferences; + /* If the TGT is not for the realm of the end-server */ + /* then the sname will be for a TGT for the end-realm */ + /* and the realm of the requested ticket (body.realm) */ + /* will be that of the TGS to which the TGT we are */ + /* sending applies */ + body.sname := service's name; + body.realm := service's realm; + + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + body.enc-authorization-data := user-supplied data; + if (body.kdc-options.ENC-TKT-IN-SKEY) then + body.additional-tickets_ticket := second TGT; + endif + + request.req-body := body; + check := generate_checksum (req.body,checksumtype); + + request.padata[0].padata-type := PA-TGS-REQ; + request.padata[0].padata-value := create a KRB_AP_REQ using + the TGT and checksum + + /* add in any other padata as required/supplied */ + + kerberos := lookup(name of local kerberose server (or +servers)); + send(packet,kerberos); + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation + + /* note that reading the application request requires first + determining the server for which a ticket was issued, and +choosing the + correct key for decryption. The name of the server appears in +the + plaintext part of the ticket. */ + + if (no KRB_AP_REQ in req.padata) then + error_out(KDC_ERR_PADATA_TYPE_NOSUPP); + endif + verify KRB_AP_REQ in req.padata; + + /* Note that the realm in which the Kerberos server is +operating is + determined by the instance from the ticket-granting ticket. +The realm + in the ticket-granting ticket is the realm under which the +ticket + granting ticket was issued. It is possible for a single +Kerberos + server to support more than one realm. */ + + auth_hdr := KRB_AP_REQ; + tgt := auth_hdr.ticket; + + if (tgt.sname is not a TGT for local realm and is not +req.sname) then + error_out(KRB_AP_ERR_NOT_US); + + realm := realm_tgt_is_for(tgt); + + decode remainder of request; + + if (auth_hdr.authenticator.cksum is missing) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + if (auth_hdr.authenticator.cksum type is not supported) then + error_out(KDC_ERR_SUMTYPE_NOSUPP); + endif + if (auth_hdr.authenticator.cksum is not both collision-proof +and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + set computed_checksum := checksum(req); + if (computed_checksum != auth_hdr.authenticatory.cksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + + server := lookup(req.sname,realm); + + if (!server) then + if (is_foreign_tgt_name(req.sname)) then + server := best_intermediate_tgs(req.sname); + else + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + endif + + session := generate_random_session_key(); + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := realm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + new_tkt.caddr := tgt.caddr; + resp.caddr := NULL; /* We only include this if they change */ + if (req.kdc-options.FORWARDABLE is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.FORWARDED is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDED; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + if (tgt.flags.FORWARDED is set) then + set new_tkt.flags.FORWARDED; + endif + + if (req.kdc-options.PROXIABLE is set) then + if (tgt.flags.PROXIABLE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXIABLE; + endif + if (req.kdc-options.PROXY is set) then + if (tgt.flags.PROXIABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXY; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + if (tgt.flags.MAY-POSTDATE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.MAY-POSTDATE; + endif + if (req.kdc-options.POSTDATED is set) then + if (tgt.flags.MAY-POSTDATE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + new_tkt.starttime := req.from; + endif + + if (req.kdc-options.VALIDATE is set) then + if (tgt.flags.INVALID is reset) then + error_out(KDC_ERR_POLICY); + endif + if (tgt.starttime > kdc_time) then + error_out(KRB_AP_ERR_NYV); + endif + if (check_hot_list(tgt)) then + error_out(KRB_AP_ERR_REPEAT); + endif + tkt := tgt; + reset new_tkt.flags.INVALID; + endif + + if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, + and those already processed) is set) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.authtime := tgt.authtime; + + if (req.kdc-options.RENEW is set) then + /* Note that if the endtime has already passed, the ticket +would */ + /* have been rejected in the initial authentication stage, so +*/ + /* there is no need to check again here +*/ + if (tgt.flags.RENEWABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + if (tgt.renew-till < kdc_time) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + tkt := tgt; + new_tkt.starttime := kdc_time; + old_life := tgt.endttime - tgt.starttime; + new_tkt.endtime := min(tgt.renew-till, + new_tkt.starttime + old_life); + else + new_tkt.starttime := kdc_time; + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + new_tkt.endtime := min(till, + +new_tkt.starttime+client.max_life, + +new_tkt.starttime+server.max_life, + +new_tkt.starttime+max_life_for_realm, + tgt.endtime); + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till) and + (tgt.flags.RENEWABLE is set) then + /* we set the RENEWABLE option for later +processing */ + set req.kdc-options.RENEWABLE; + req.rtime := min(req.till, tgt.renew-till); + endif + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (tgt.flags.RENEWABLE is set)) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + +new_tkt.starttime+client.max_rlife, + +new_tkt.starttime+server.max_rlife, + +new_tkt.starttime+max_rlife_for_realm, + tgt.renew-till); + else + new_tkt.renew-till := OMIT; /* leave the renew-till +field out */ + endif + if (req.enc-authorization-data is present) then + decrypt req.enc-authorization-data into +decrypted_authorization_data + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + endif + new_tkt.authorization_data := +req.auth_hdr.ticket.authorization_data + + decrypted_authorization_data; + + new_tkt.key := session; + new_tkt.crealm := tgt.crealm; + new_tkt.cname := req.auth_hdr.ticket.cname; + + if (realm_tgt_is_for(tgt) := tgt.realm) then + /* tgt issued by local realm */ + new_tkt.transited := tgt.transited; + else + /* was issued for this realm by some other realm */ + if (tgt.transited.tr-type not supported) then + error_out(KDC_ERR_TRTYPE_NOSUPP); + endif + new_tkt.transited := compress_transited(tgt.transited + +tgt.realm) + /* Don't check tranited field if TGT for foreign realm, + * or requested not to check */ + if (is_not_foreign_tgt_name(new_tkt.server) + && req.kdc-options.DISABLE-TRANSITED-CHECK not set) +then + /* Check it, so end-server does not have to + * but don't fail, end-server may still accept +it */ + if (check_transited_field(new_tkt.transited) == +OK) + set +new_tkt.flags.TRANSITED-POLICY-CHECKED; + endif + endif + endif + + encode encrypted part of new_tkt into OCTET STRING; + if (req.kdc-options.ENC-TKT-IN-SKEY is set) then + if (server not specified) then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + server = req.second_ticket.client; + endif + if ((req.second_ticket is not a TGT) or + (req.second_ticket.client != server)) then + error_out(KDC_ERR_POLICY); + endif + + new_tkt.enc-part := encrypt OCTET STRING using + using etype_for_key(second-ticket.key), +second-ticket.key; + else + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, +server.p_kvno; + endif + + resp.pvno := 5; + resp.msg-type := KRB_TGS_REP; + resp.crealm := tgt.crealm; + resp.cname := tgt.cname; + resp.ticket := new_tkt; + + resp.key := session; + resp.nonce := req.nonce; + resp.last-req := fetch_last_request_info(client); + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + omit resp.key-expiration; + + resp.sname := new_tkt.sname; + resp.realm := new_tkt.realm; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + encode body of reply into OCTET STRING; + + if (req.padata.authenticator.subkey) + resp.enc-part := encrypt OCTET STRING using use_etype, + req.padata.authenticator.subkey; + else resp.enc-part := encrypt OCTET STRING using use_etype, +tgt.key; + + send(resp); + + A.7. KRB_TGS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + process_error(resp); + return; + endif + + /* On error, discard the response, and zero the session key +from + the response immediately */ + + if (req.padata.authenticator.subkey) + unencrypted part of resp := decode of decrypt of +resp.enc-part + using resp.enc-part.etype and subkey; + else unencrypted part of resp := decode of decrypt of +resp.enc-part + using resp.enc-part.etype and tgt's +session key; + if (common_as_rep_tgs_rep_checks fail) then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + destroy resp.key; + return error; + endif + + check authorization_data as necessary; + save_for_later(ticket,session,client,server,times,flags); + + A.8. Authenticator generation + + body.authenticator-vno := authenticator vno; /* = 5 */ + body.cname, body.crealm := client name; + if (supplying checksum) then + body.cksum := checksum; + endif + get system_time; + body.ctime, body.cusec := system_time; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + A.9. KRB_AP_REQ generation + + obtain ticket and session_key from cache; + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REQ */ + + if (desired(MUTUAL_AUTHENTICATION)) then + set packet.ap-options.MUTUAL-REQUIRED; + else + reset packet.ap-options.MUTUAL-REQUIRED; + endif + if (using session key for ticket) then + set packet.ap-options.USE-SESSION-KEY; + else + reset packet.ap-options.USE-SESSION-KEY; + endif + packet.ticket := ticket; /* ticket */ + generate authenticator; + encode authenticator into OCTET STRING; + encrypt OCTET STRING into packet.authenticator using +session_key; + + A.10. KRB_AP_REQ verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REQ) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.ticket.tkt_vno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.ap_options.USE-SESSION-KEY is set) then + retrieve session key from ticket-granting ticket for + packet.ticket.{sname,srealm,enc-part.etype}; + else + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + retrieve service key for + +packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; + endif + if (no_key_available) then + if (cannot_find_specified_skvno) then + error_out(KRB_AP_ERR_BADKEYVER); + else + error_out(KRB_AP_ERR_NOKEY); + endif + endif + decrypt packet.ticket.enc-part into decr_ticket using retrieved +key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + decrypt packet.authenticator into decr_authenticator + using decr_ticket.key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (decr_authenticator.{cname,crealm} != + decr_ticket.{cname,crealm}) then + error_out(KRB_AP_ERR_BADMATCH); + endif + if (decr_ticket.caddr is present) then + if (sender_address(packet) is not in decr_ticket.caddr) +then + error_out(KRB_AP_ERR_BADADDR); + endif + elseif (application requires addresses) then + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(decr_authenticator.ctime, + decr_authenticator.cusec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) +then + error_out(KRB_AP_ERR_REPEAT); + endif + save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); + get system_time; + if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or + (decr_ticket.flags.INVALID is set)) then + /* it hasn't yet become valid */ + error_out(KRB_AP_ERR_TKT_NYV); + endif + if (system_time-decr_ticket.endtime > CLOCK_SKEW) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + if (decr_ticket.transited) then + /* caller may ignore the TRANSITED-POLICY-CHECKED and do + * check anyway */ + if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) +then + if (check_transited_field(decr_ticket.transited) then + error_out(KDC_AP_PATH_NOT_ACCPETED); + endif + endif + endif + /* caller must check decr_ticket.flags for any pertinent +details */ + return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); + + A.11. KRB_AP_REP generation + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REP */ + + body.ctime := packet.ctime; + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + body.cusec := packet.cusec; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part; + + A.12. KRB_AP_REP verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REP) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + cleartext := decrypt(packet.enc-part) using ticket's session +key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (cleartext.ctime != authenticator.ctime) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.cusec != authenticator.cusec) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.subkey is present) then + save cleartext.subkey for future use; + endif + if (cleartext.seq-number is present) then + save cleartext.seq-number for future verifications; + endif + return(AUTHENTICATION_SUCCEEDED); + + A.13. KRB_SAFE generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_SAFE */ + + body.user-data := buffer; /* DATA */ + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + checksum.cksumtype := checksum type; + compute checksum over body; + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + checksum.checksum := checksum value; /* checksum.checksum */ + packet.cksum := checksum; + packet.safe-body := body; + + A.14. KRB_SAFE verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_SAFE) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.checksum.cksumtype is not both collision-proof and +keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + if (safe_priv_common_checks_ok(packet)) then + set computed_checksum := checksum(packet.body); + if (computed_checksum != packet.checksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + return (packet, PACKET_IS_GENUINE); + else + return common_checks_error; + endif + + A.15. KRB_SAFE and KRB_PRIV common checks + + if (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it +*/ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (((packet.timestamp is present) and + (not in_clock_skew(packet.timestamp,packet.usec))) or + (packet.timestamp is not present and timestamp expected)) +then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) +then + error_out(KRB_AP_ERR_REPEAT); + endif + + if (((packet.seq-number is present) and + ((not in_sequence(packet.seq-number)))) or + (packet.seq-number is not present and sequence expected)) +then + error_out(KRB_AP_ERR_BADORDER); + endif + if (packet.timestamp not present and packet.seq-number not +present) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + save_identifier(packet.{timestamp,usec,s-address}, + sender_principal(packet)); + + return PACKET_IS_OK; + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + A.16. KRB_PRIV generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_PRIV */ + + packet.enc-part.etype := encryption type; + + body.user-data := buffer; + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher; + + A.17. KRB_PRIV verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_PRIV) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + + if (safe_priv_common_checks_ok(cleartext)) then + return(cleartext.DATA, +PACKET_IS_GENUINE_AND_UNMODIFIED); + else + return common_checks_error; + endif + + A.18. KRB_CRED generation + + invoke KRB_TGS; /* obtain tickets to be provided to peer */ + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_CRED */ + + for (tickets[n] in tickets to be forwarded) do + packet.tickets[n] = tickets[n].ticket; + done + + packet.enc-part.etype := encryption type; + + for (ticket[n] in tickets to be forwarded) do + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + body.ticket-info[n].key = tickets[n].session; + body.ticket-info[n].prealm = tickets[n].crealm; + body.ticket-info[n].pname = tickets[n].cname; + body.ticket-info[n].flags = tickets[n].flags; + body.ticket-info[n].authtime = tickets[n].authtime; + body.ticket-info[n].starttime = tickets[n].starttime; + body.ticket-info[n].endtime = tickets[n].endtime; + body.ticket-info[n].renew-till = tickets[n].renew-till; + body.ticket-info[n].srealm = tickets[n].srealm; + body.ticket-info[n].sname = tickets[n].sname; + body.ticket-info[n].caddr = tickets[n].caddr; + done + + get system_time; + body.timestamp, body.usec := system_time; + + if (using nonce) then + body.nonce := nonce; + endif + + if (using s-address) then + body.s-address := sender host addresses; + endif + if (limited recipients) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher + using negotiated encryption key; + + A.19. KRB_CRED verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_CRED) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if ((packet.r-address is present or required) and + (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it +*/ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(packet.timestamp,packet.usec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) +then + error_out(KRB_AP_ERR_REPEAT); + endif + if (packet.nonce is required or present) and + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + (packet.nonce != expected-nonce) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + for (ticket[n] in tickets that were forwarded) do + save_for_later(ticket[n],key[n],principal[n], + server[n],times[n],flags[n]); + return + + A.20. KRB_ERROR generation + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_ERROR */ + + get system_time; + packet.stime, packet.susec := system_time; + packet.realm, packet.sname := server name; + + if (client time available) then + packet.ctime, packet.cusec := client_time; + endif + packet.error-code := error code; + if (client name available) then + packet.cname, packet.crealm := client name; + endif + if (error text available) then + packet.e-text := error text; + endif + if (error data available) then + packet.e-data := error data; + endif + + B. Definition of common authorization data elements + + This appendix contains the definitions of common authorization data + elements. These common authorization data elements are recursivly + defined, meaning the ad-data for these types will itself contain a + sequence of authorization data whose interpretation is affected by the + encapsulating element. Depending on the meaning of the encapsulating + element, the encapsulated elements may be ignored, might be + interpreted as issued directly by the KDC, or they might be stored in + a separate plaintext part of the ticket. The types of the + encapsulating elements are specified as part of the Kerberos + specification because the behavior based on these values should be + understood across implementations whereas other elements need only be + understood by the applications which they affect. + + In the definitions that follow, the value of the ad-type for the + element will be specified in the subsection number, and the value of + the ad-data will be as shown in the ASN.1 structure that follows the + subsection heading. + + B.1. If relevant + + AD-IF-RELEVANT AuthorizationData + + AD elements encapsulated within the if-relevant element are intended + for interpretation only by application servers that understand the + particular ad-type of the embedded element. Application servers that + do not understand the type of an element embedded within the + if-relevant element may ignore the uninterpretable element. This + element promotes interoperability across implementations which may + have local extensions for authorization. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + B.2. Intended for server + + AD-INTENDED-FOR-SERVER SEQUENCE { + intended-server[0] SEQUENCE OF PrincipalName + elements[1] AuthorizationData + } + + AD elements encapsulated within the intended-for-server element may be + ignored if the application server is not in the list of principal + names of intended servers. Further, a KDC issuing a ticket for an + application server can remove this element if the application server + is not in the list of intended servers. + + Application servers should check for their principal name in the + intended-server field of this element. If their principal name is not + found, this element should be ignored. If found, then the encapsulated + elements should be evaluated in the same manner as if they were + present in the top level authorization data field. Applications and + application servers that do not implement this element should reject + tickets that contain authorization data elements of this type. + + B.3. Intended for application class + + AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { + intended-application-class[0] SEQUENCE OF GeneralString elements[1] + AuthorizationData } AD elements encapsulated within the + intended-for-application-class element may be ignored if the + application server is not in one of the named classes of application + servers. Examples of application server classes include "FILESYSTEM", + and other kinds of servers. + + This element and the elements it encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.4. KDC Issued + + AD-KDCIssued SEQUENCE { + ad-checksum[0] Checksum, + i-realm[1] Realm OPTIONAL, + i-sname[2] PrincipalName OPTIONAL, + elements[3] AuthorizationData. + } + + ad-checksum + A checksum over the elements field using a cryptographic checksum + method that is identical to the checksum used to protect the + ticket itself (i.e. using the same hash function and the same + encryption algorithm used to encrypt the ticket) and using a key + derived from the same key used to protect the ticket. + i-realm, i-sname + The name of the issuing principal if different from the KDC + itself. This field would be used when the KDC can verify the + authenticity of elements signed by the issuing principal and it + allows this KDC to notify the application server of the validity + of those elements. + elements + A sequence of authorization data elements issued by the KDC. + The KDC-issued ad-data field is intended to provide a means for + Kerberos principal credentials to embed within themselves privilege + attributes and other mechanisms for positive authorization, amplifying + the priveleges of the principal beyond what can be done using a + credentials without such an a-data element. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + This can not be provided without this element because the definition + of the authorization-data field allows elements to be added at will by + the bearer of a TGT at the time that they request service tickets and + elements may also be added to a delegated ticket by inclusion in the + authenticator. + + For KDC-issued elements this is prevented because the elements are + signed by the KDC by including a checksum encrypted using the server's + key (the same key used to encrypt the ticket - or a key derived from + that key). Elements encapsulated with in the KDC-issued element will + be ignored by the application server if this "signature" is not + present. Further, elements encapsulated within this element from a + ticket granting ticket may be interpreted by the KDC, and used as a + basis according to policy for including new signed elements within + derivative tickets, but they will not be copied to a derivative ticket + directly. If they are copied directly to a derivative ticket by a KDC + that is not aware of this element, the signature will not be correct + for the application ticket elements, and the field will be ignored by + the application server. + + This element and the elements it encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.5. And-Or + + AD-AND-OR SEQUENCE { + condition-count[0] INTEGER, + elements[1] AuthorizationData + } + + When restrictive AD elements encapsulated within the and-or element + are encountered, only the number specified in condition-count of the + encapsulated conditions must be met in order to satisfy this element. + This element may be used to implement an "or" operation by setting the + condition-count field to 1, and it may specify an "and" operation by + setting the condition count to the number of embedded elements. + Application servers that do not implement this element must reject + tickets that contain authorization data elements of this type. + + B.6. Mandatory ticket extensions + + AD-Mandatory-Ticket-Extensions SEQUENCE { + te-type[0] INTEGER, + te-checksum[0] Checksum + } + + An authorization data element of type mandatory-ticket-extensions + specifies the type and a collision-proof checksum using the same hash + algorithm used to protect the integrity of the ticket itself. This + checksum will be calculated over an individual extension field of the + type indicated. If there are more than one extension, multiple + Mandatory-Ticket-Extensions authorization data elements may be + present, each with a checksum for a different extension field. This + restriction indicates that the ticket should not be accepted if a + ticket extension is not present in the ticket for which the type and + checksum do not match that checksum specified in the authorization + data element. Note that although the type is redundant for the + purposes of the comparison, it makes the comparison easier when + multiple extensions are present. Application servers that do not + implement this element must reject tickets that contain authorization + data elements of this type. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + B.7. Authorization Data in ticket extensions + + AD-IN-Ticket-Extensions Checksum + + An authorization data element of type in-ticket-extensions specifies a + collision-proof checksum using the same hash algorithm used to protect + the integrity of the ticket itself. This checksum is calculated over a + separate external AuthorizationData field carried in the ticket + extensions. Application servers that do not implement this element + must reject tickets that contain authorization data elements of this + type. Application servers that do implement this element will search + the ticket extensions for authorization data fields, calculate the + specified checksum over each authorization data field and look for one + matching the checksum in this in-ticket-extensions element. If not + found, then the ticket must be rejected. If found, the corresponding + authorization data elements will be interpreted in the same manner as + if they were contained in the top level authorization data field. + + Note that if multiple external authorization data fields are present + in a ticket, each will have a corresponding element of type + in-ticket-extensions in the top level authorization data field, and + the external entries will be linked to the corresponding element by + their checksums. + + C. Definition of common ticket extensions + + This appendix contains the definitions of common ticket extensions. + Support for these extensions is optional. However, certain extensions + have associated authorization data elements that may require rejection + of a ticket containing an extension by application servers that do not + implement the particular extension. Other extensions have been defined + beyond those described in this specification. Such extensions are + described elswhere and for some of those extensions the reserved + number may be found in the list of constants. + + It is known that older versions of Kerberos did not support this + field, and that some clients will strip this field from a ticket when + they parse and then reassemble a ticket as it is passed to the + application servers. The presence of the extension will not break such + clients, but any functionaly dependent on the extensions will not work + when such tickets are handled by old clients. In such situations, some + implementation may use alternate methods to transmit the information + in the extensions field. + + C.1. Null ticket extension + + TE-NullExtension OctetString -- The empty Octet String + + The te-data field in the null ticket extension is an octet string of + lenght zero. This extension may be included in a ticket granting + ticket so that the KDC can determine on presentation of the ticket + granting ticket whether the client software will strip the extensions + field. + + C.2. External Authorization Data + + TE-ExternalAuthorizationData AuthorizationData + + The te-data field in the external authorization data ticket extension + is field of type AuthorizationData containing one or more + authorization data elements. If present, a corresponding authorization + data element will be present in the primary authorization data for the + ticket and that element will contain a checksum of the external + authorization data ticket extension. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + ---------------------------------------------------------------------- + [TM] Project Athena, Athena, and Kerberos are trademarks of the + Massachusetts Institute of Technology (MIT). No commercial use of + these trademarks may be made without prior written permission of MIT. + + [1] Note, however, that many applications use Kerberos' functions only + upon the initiation of a stream-based network connection. Unless an + application subsequently provides integrity protection for the data + stream, the identity verification applies only to the initiation of + the connection, and does not guarantee that subsequent messages on the + connection originate from the same principal. + + [2] Secret and private are often used interchangeably in the + literature. In our usage, it takes two (or more) to share a secret, + thus a shared DES key is a secret key. Something is only private when + no one but its owner knows it. Thus, in public key cryptosystems, one + has a public and a private key. + + [3] Of course, with appropriate permission the client could arrange + registration of a separately-named prin- cipal in a remote realm, and + engage in normal exchanges with that realm's services. However, for + even small numbers of clients this becomes cumbersome, and more + automatic methods as described here are necessary. + + [4] Though it is permissible to request or issue tick- ets with no + network addresses specified. + + [5] The password-changing request must not be honored unless the + requester can provide the old password (the user's current secret + key). Otherwise, it would be possible for someone to walk up to an + unattended ses- sion and change another user's password. + + [6] To authenticate a user logging on to a local system, the + credentials obtained in the AS exchange may first be used in a TGS + exchange to obtain credentials for a local server. Those credentials + must then be verified by a local server through successful completion + of the Client/Server exchange. + + [7] "Random" means that, among other things, it should be impossible + to guess the next session key based on knowledge of past session keys. + This can only be achieved in a pseudo-random number generator if it is + based on cryptographic principles. It is more desirable to use a truly + random number generator, such as one based on measurements of random + physical phenomena. + + [8] Tickets contain both an encrypted and unencrypted portion, so + cleartext here refers to the entire unit, which can be copied from one + message and replayed in another without any cryptographic skill. + + [9] Note that this can make applications based on unreliable + transports difficult to code correctly. If the transport might deliver + duplicated messages, either a new authenticator must be generated for + each retry, or the application server must match requests and replies + and replay the first reply in response to a detected duplicate. + + [10] This is used for user-to-user authentication as described in [8]. + + [11] Note that the rejection here is restricted to authenticators from + the same principal to the same server. Other client principals + communicating with the same server principal should not be have their + authenticators rejected if the time and microsecond fields happen to + match some other client's authenticator. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + [12] In the Kerberos version 4 protocol, the timestamp in the reply + was the client's timestamp plus one. This is not necessary in version + 5 because version 5 messages are formatted in such a way that it is + not possible to create the reply by judicious message surgery (even in + encrypted form) without knowledge of the appropriate encryption keys. + + [13] Note that for encrypting the KRB_AP_REP message, the sub-session + key is not used, even if present in the Authenticator. + + [14] Implementations of the protocol may wish to provide routines to + choose subkeys based on session keys and random numbers and to + generate a negotiated key to be returned in the KRB_AP_REP message. + + [15]This can be accomplished in several ways. It might be known + beforehand (since the realm is part of the principal identifier), it + might be stored in a nameserver, or it might be obtained from a + configura- tion file. If the realm to be used is obtained from a + nameserver, there is a danger of being spoofed if the nameservice + providing the realm name is not authenti- cated. This might result in + the use of a realm which has been compromised, and would result in an + attacker's ability to compromise the authentication of the application + server to the client. + + [16] If the client selects a sub-session key, care must be taken to + ensure the randomness of the selected sub- session key. One approach + would be to generate a random number and XOR it with the session key + from the ticket-granting ticket. + + [17] This allows easy implementation of user-to-user authentication + [8], which uses ticket-granting ticket session keys in lieu of secret + server keys in situa- tions where such secret keys could be easily + comprom- ised. + + [18] For the purpose of appending, the realm preceding the first + listed realm is considered to be the null realm (""). + + [19] For the purpose of interpreting null subfields, the client's + realm is considered to precede those in the transited field, and the + server's realm is considered to follow them. + + [20] This means that a client and server running on the same host and + communicating with one another using the KRB_SAFE messages should not + share a common replay cache to detect KRB_SAFE replays. + + [21] The implementation of the Kerberos server need not combine the + database and the server on the same machine; it is feasible to store + the principal database in, say, a network name service, as long as the + entries stored therein are protected from disclosure to and + modification by unauthorized parties. However, we recommend against + such strategies, as they can make system management and threat + analysis quite complex. + + [22] See the discussion of the padata field in section 5.4.2 for + details on why this can be useful. + + [23] Warning for implementations that unpack and repack data + structures during the generation and verification of embedded + checksums: Because any checksums applied to data structures must be + checked against the original data the length of bit strings must be + preserved within a data structure between the time that a checksum is + generated through transmission to the time that the checksum is + verified. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + [24] It is NOT recommended that this time value be used to adjust the + workstation's clock since the workstation cannot reliably determine + that such a KRB_AS_REP actually came from the proper KDC in a timely + manner. + + [25] Note, however, that if the time is used as the nonce, one must + make sure that the workstation time is monotonically increasing. If + the time is ever reset backwards, there is a small, but finite, + probability that a nonce will be reused. + + [27] An application code in the encrypted part of a message provides + an additional check that the message was decrypted properly. + + [29] An application code in the encrypted part of a message provides + an additional check that the message was decrypted properly. + + [31] An application code in the encrypted part of a message provides + an additional check that the message was decrypted properly. + + [32] If supported by the encryption method in use, an initialization + vector may be passed to the encryption procedure, in order to achieve + proper cipher chaining. The initialization vector might come from the + last block of the ciphertext from the previous KRB_PRIV message, but + it is the application's choice whether or not to use such an + initialization vector. If left out, the default initialization vector + for the encryption algorithm will be used. + + [33] This prevents an attacker who generates an incorrect AS request + from obtaining verifiable plaintext for use in an off-line password + guessing attack. + + [35] In the above specification, UNTAGGED OCTET STRING(length) is the + notation for an octet string with its tag and length removed. It is + not a valid ASN.1 type. The tag bits and length must be removed from + the confounder since the purpose of the confounder is so that the + message starts with random data, but the tag and its length are fixed. + For other fields, the length and tag would be redundant if they were + included because they are specified by the encryption type. [36] The + ordering of the fields in the CipherText is important. Additionally, + messages encoded in this format must include a length as part of the + msg-seq field. This allows the recipient to verify that the message + has not been truncated. Without a length, an attacker could use a + chosen plaintext attack to generate a message which could be + truncated, while leaving the checksum intact. Note that if the msg-seq + is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length + is part of that encoding. + + [37] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [38] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [39] A variant of the key is used to limit the use of a key to a + particular function, separating the functions of generating a checksum + from other encryption performed using the session key. The constant + F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The + properties of DES precluded the use of the complement. The same + constant is used for similar purpose in the Message Integrity Check in + the Privacy Enhanced Mail standard. + + [40] This error carries additional information in the e- data field. + The contents of the e-data field for this message is described in + section 5.9.1. + + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt new file mode 100644 index 000000000000..6f7dae0dea70 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt @@ -0,0 +1,325 @@ + +INTERNET-DRAFT Mike Swift +draft-ietf-cat-kerberos-set-passwd-02.txt Microsoft +March 2000 Jonathan Trostle + Cisco Systems + John Brezak + Microsoft + Bill Gossman + Cybersafe + + Kerberos Set/Change Password: Version 2 + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments and suggestions on this document are encouraged. Comments + on this document should be sent to the CAT working group discussion + list: + ietf-cat-wg@stanford.edu + +1. Abstract + + The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), + does not allow for an administrator to set a password for a new user. + This functionality is useful in some environments, and this proposal + extends [4] to allow password setting. The changes are: adding new + fields to the request message to indicate the principal which is + having its password set, not requiring the initial flag in the service + ticket, using a new protocol version number, and adding three new + result codes. We also extend the set/change protocol to allow a + client to send a sequence of keys to the KDC instead of a cleartext + password. If in the cleartext password case, the cleartext password + fails to satisfy password policy, the server should use the result + code KRB5_KPASSWD_POLICY_REJECT. + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + +3. The Protocol + + The service must accept requests on UDP port 464 and TCP port 464 as + well. The protocol consists of a single request message followed by + a single reply message. For UDP transport, each message must be fully + contained in a single UDP packet. + + For TCP transport, there is a 4 octet header in network byte order + precedes the message and specifies the length of the message. This + requirement is consistent with the TCP transport header in 1510bis. + +Request Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REQ length | AP-REQ data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). + + AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REQ data: (see [3]) The AP-REQ message must be for the service + principal kadmin/changepw@REALM, where REALM is the REALM of the user + who wishes to change/set his password. The ticket in the AP-REQ must + must include a subkey in the Authenticator. To enable setting of + passwords/keys, it is not required that the initial flag be set in the + Kerberos service ticket. The initial flag is required for change requests, + but not for set password requests. We have the following definitions: + + old passwd initial flag target principal can be + in request? required? distinct from + authenticating principal? + + change password: yes yes no + + set password: no no yes + + set key: no policy yes + determined + + KRB-PRIV message (see [3]) This KRB-PRIV message must be generated + using the subkey from the authenticator in the AP-REQ data. + + The user-data component of the message consists of the following ASN.1 + structure encoded as an OCTET STRING: + + ChangePasswdData :: = SEQUENCE { + newpasswdorkeys[0] NewPasswdOrKeys, + targname[1] PrincipalName OPTIONAL, + -- only present in set password: the principal + -- which will have its password set + targrealm[2] Realm OPTIONAL, + -- only present in set password: the realm for + -- the principal which will have its password set + + } + + NewPasswdOrKeys :: = CHOICE { + passwords[0] PasswordSequence, + keyseq[1] KeySequences + } + + KeySequences :: = SEQUENCE OF KeySequence + + KeySequence :: = SEQUENCE { + key[0] EncryptionKey, + salt[1] OCTET STRING OPTIONAL, + salt-type[2] INTEGER OPTIONAL + } + + PasswordSequence :: = SEQUENCE { + newpasswd[0] OCTET STRING, + oldpasswd[1] OCTET STRING OPTIONAL + -- oldpasswd always present for change password + -- but not present for set password + } + + The server must verify the AP-REQ message, check whether the client + principal in the ticket is authorized to set or change the password + (either for that principal, or for the principal in the targname + field if present), and decrypt the new password/keys. The server + also checks whether the initial flag is required for this request, + replying with status 0x0007 if it is not set and should be. An + authorization failure is cause to respond with status 0x0005. For + forward compatibility, the server should be prepared to ignore fields + after targrealm in the structure that it does not understand. + + The newpasswdorkeys field contains either the new cleartext password + (with the old cleartext password for a change password operation), + or a sequence of encryption keys with their respective salts. + + In the cleartext password case, if the old password is sent in the + request, the request is defined to be a change password request. If + the old password is not present in the request, the request is a set + password request. The server should apply policy checks to the old + and new password after verifying that the old password is valid. + The server can check validity by obtaining a key from the old + password with a keytype that is present in the KDC database for the + user and comparing the keys for equality. The server then generates + the appropriate keytypes from the password and stores them in the KDC + + database. If all goes well, status 0x0000 is returned to the client + in the reply message (see below). For a change password operation, + the initial flag in the service ticket MUST be set. + + In the key sequence case, the sequence of keys is sent to the set + password service. For a principal that can act as a server, its + preferred keytype should be sent as the first key in the sequence, + but the KDC is not required to honor this preference. Application + servers should use the key sequence option for changing/setting their + keys. The set password service should check that all keys are in the + proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. + +Reply Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REP length | AP-REP data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). (The reply message has the same format as in [4]). + + AP-REP length: length of AP-REP data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REP data: the AP-REP is the response to the AP-REQ in the request + packet. + + KRB-PRIV from [4]: This KRB-PRIV message must be generated using the + subkey in the authenticator in the AP-REQ data. + + The server will respond with a KRB-PRIV message unless it cannot + validate the client AP-REQ or KRB-PRIV message, in which case it will + respond with a KRB-ERROR message. NOTE: Unlike change password version + 1, the KRB-ERROR message will be sent back without any encapsulation. + + The user-data component of the KRB-PRIV message, or e-data component + of the KRB-ERROR message, must consist of the following data. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | result code | result string / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | edata / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + result code (16 bits) (result codes 0-4 are from [4]): + The result code must have one of the following values (network + byte order): + KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not + allowed in a KRB-ERROR message) + KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed + KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in + processing the request (for example, + there is a resource or other problem + causing the request to fail) + KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in + authentication processing + KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error + in processing the request + KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized + KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported + KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required + KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; + the result string should include a text message to be presented + to the user. + KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist + (only in response to a set password request). + KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence + containing at least one etype that is not supported by the KDC. + The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO + type that specifies the etypes that the KDC supports: + + KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { + encryption-type[0] INTEGER, + salt[1] OCTET STRING OPTIONAL -- not sent + } + + PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY + + The client should retry the request using only etypes (keytypes) + that are contained within the PKERB-ETYPE-INFO structure in the + previous response. + 0xFFFF if the request fails for some other reason. + The client must interpret any non-zero result code as a failure. + result string - from [4]: + This field is a UTF-8 encoded string which should be displayed + to the user by the client. Specific reasons for a password + set/change policy failure is one use for this string. + edata: used to convey additional information as defined by the + result code. + +4. References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + [3] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5), Request for Comments 1510. + + [4] M. Horowitz. Kerberos Change Password Protocol, + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerb-chg-password-02.txt + +5. Expiration Date + + This draft expires in September 2000. + +6. Authors' Addresses + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + Email: jtrostle@cisco.com + + Mike Swift + 1 Microsoft Way + Redmond, WA 98052 + Email: mikesw@microsoft.com + + John Brezak + 1 Microsoft Way + Redmond, WA 98052 + Email: jbrezak@microsoft.com + + Bill Gossman + Cybersafe Corporation + 1605 NW Sammamish Rd. + Issaquah, WA 98027-5378 + Email: bill.gossman@cybersafe.com + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt new file mode 100644 index 000000000000..0319f8bf347c --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt @@ -0,0 +1,345 @@ + +INTERNET-DRAFT Mike Swift +draft-ietf-cat-kerberos-set-passwd-03.txt Microsoft +April 2000 Jonathan Trostle + Cisco Systems + John Brezak + Microsoft + Bill Gossman + Cybersafe + + Kerberos Set/Change Password: Version 2 + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments and suggestions on this document are encouraged. Comments + on this document should be sent to the CAT working group discussion + list: + ietf-cat-wg@stanford.edu + +1. Abstract + + The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), + does not allow for an administrator to set a password for a new user. + This functionality is useful in some environments, and this proposal + extends [4] to allow password setting. The changes are: adding new + fields to the request message to indicate the principal which is + having its password set, not requiring the initial flag in the service + ticket, using a new protocol version number, and adding three new + result codes. We also extend the set/change protocol to allow a + client to send a sequence of keys to the KDC instead of a cleartext + password. If in the cleartext password case, the cleartext password + fails to satisfy password policy, the server should use the result + code KRB5_KPASSWD_POLICY_REJECT. + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + +3. The Protocol + + The service must accept requests on UDP port 464 and TCP port 464 as + well. The protocol consists of a single request message followed by + a single reply message. For UDP transport, each message must be fully + contained in a single UDP packet. + + For TCP transport, there is a 4 octet header in network byte order + precedes the message and specifies the length of the message. This + requirement is consistent with the TCP transport header in 1510bis. + +Request Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REQ length | AP-REQ data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). + + AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REQ data: (see [3]) For a change password/key request, the AP-REQ + message service ticket sname, srealm principal identifier is + kadmin/changepw@REALM where REALM is the realm of the change password + service. The same applies to a set password/key request except the + principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ + must include a subkey in the Authenticator. To enable setting of + passwords/keys, it is not required that the initial flag be set in the + Kerberos service ticket. The initial flag is required for change requests, + but not for set requests. We have the following definitions: + + old passwd initial flag target principal can be + in request? required? distinct from + authenticating principal? + + change password: yes yes no + + set password: no policy (*) yes + + set key: no policy (*) yes + + change key: no yes no + + policy (*): implementations SHOULD allow administrators to set the + initial flag required for set requests policy to either yes or no. + Clients MUST be able to retry set requests that fail due to error 7 + (initial flag required) with an initial ticket. Clients SHOULD NOT + cache service tickets targetted at kadmin/changepw. + + KRB-PRIV message (see [3]) This KRB-PRIV message must be generated + using the subkey from the authenticator in the AP-REQ data. + + The user-data component of the message consists of the following ASN.1 + structure encoded as an OCTET STRING: + + ChangePasswdData :: = SEQUENCE { + newpasswdorkeys[0] NewPasswdOrKeys, + targname[1] PrincipalName OPTIONAL, + -- only present in set password/key: the principal + -- which will have its password or keys set. Not + -- present in a set request if the client principal + -- from the ticket is the principal having its + -- passwords or keys set. + targrealm[2] Realm OPTIONAL, + -- only present in set password/key: the realm for + -- the principal which will have its password or + -- keys set. Not present in a set request if the + -- client principal from the ticket is the principal + -- having its passwords or keys set. + } + + NewPasswdOrKeys :: = CHOICE { + passwords[0] PasswordSequence, -- change/set passwd + keyseq[1] KeySequences -- change/set key + } + + KeySequences :: = SEQUENCE OF KeySequence + + KeySequence :: = SEQUENCE { + key[0] EncryptionKey, + salt[1] OCTET STRING OPTIONAL, + salt-type[2] INTEGER OPTIONAL + } + + PasswordSequence :: = SEQUENCE { + newpasswd[0] OCTET STRING, + oldpasswd[1] OCTET STRING OPTIONAL + -- oldpasswd always present for change password + -- but not present for set password, set key, or + -- change key + } + + The server must verify the AP-REQ message, check whether the client + principal in the ticket is authorized to set or change the password + (either for that principal, or for the principal in the targname + field if present), and decrypt the new password/keys. The server + also checks whether the initial flag is required for this request, + replying with status 0x0007 if it is not set and should be. An + authorization failure is cause to respond with status 0x0005. For + forward compatibility, the server should be prepared to ignore fields + after targrealm in the structure that it does not understand. + + The newpasswdorkeys field contains either the new cleartext password + (with the old cleartext password for a change password operation), + or a sequence of encryption keys with their respective salts. + + In the cleartext password case, if the old password is sent in the + request, the request MUST be a change password request. If the old + password is not present in the request, the request MUST be a set + password request. The server should apply policy checks to the old + and new password after verifying that the old password is valid. + The server can check validity by obtaining a key from the old + password with a keytype that is present in the KDC database for the + user and comparing the keys for equality. The server then generates + the appropriate keytypes from the password and stores them in the KDC + database. If all goes well, status 0x0000 is returned to the client + in the reply message (see below). For a change password operation, + the initial flag in the service ticket MUST be set. + + In the key sequence case, the sequence of keys is sent to the change + or set password service (kadmin/changepw or kadmin/setpw respectively). + For a principal that can act as a server, its preferred keytype should + be sent as the first key in the sequence, but the KDC is not required + to honor this preference. Application servers should use the key + sequence option for changing/setting their keys. The change/set password + services should check that all keys are in the proper format, returning + the KRB5_KPASSWD_MALFORMED error otherwise. + +Reply Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REP length | AP-REP data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). (The reply message has the same format as in [4]). + + AP-REP length: length of AP-REP data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REP data: the AP-REP is the response to the AP-REQ in the request + packet. + + KRB-PRIV from [4]: This KRB-PRIV message must be generated using the + subkey in the authenticator in the AP-REQ data. + + The server will respond with a KRB-PRIV message unless it cannot + validate the client AP-REQ or KRB-PRIV message, in which case it will + respond with a KRB-ERROR message. NOTE: Unlike change password version + 1, the KRB-ERROR message will be sent back without any encapsulation. + + The user-data component of the KRB-PRIV message, or e-data component + of the KRB-ERROR message, must consist of the following data. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | result code | result string / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | edata / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + result code (16 bits) (result codes 0-4 are from [4]): + The result code must have one of the following values (network + byte order): + KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not + allowed in a KRB-ERROR message) + KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed + KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in + processing the request (for example, + there is a resource or other problem + causing the request to fail) + KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in + authentication processing + KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error + in processing the request + KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized + KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported + KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required + KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; + the result string should include a text message to be presented + to the user. + KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist + (only in response to a set password request). + KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence + containing at least one etype that is not supported by the KDC. + The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO + type that specifies the etypes that the KDC supports: + + KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { + encryption-type[0] INTEGER, + salt[1] OCTET STRING OPTIONAL -- not sent + } + + PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY + + The client should retry the request using only etypes (keytypes) + that are contained within the PKERB-ETYPE-INFO structure in the + previous response. + 0xFFFF if the request fails for some other reason. + The client must interpret any non-zero result code as a failure. + result string - from [4]: + This field is a UTF-8 encoded string which should be displayed + to the user by the client. Specific reasons for a password + + set/change policy failure is one use for this string. + edata: used to convey additional information as defined by the + result code. + +4. Acknowledgements + + The authors thank Tony Andrea for his input to the document. + +5. References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + [3] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5), Request for Comments 1510. + + [4] M. Horowitz. Kerberos Change Password Protocol, + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerb-chg-password-02.txt + +6. Expiration Date + + This draft expires in October 2000. + +7. Authors' Addresses + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + Email: jtrostle@cisco.com + + Mike Swift + 1 Microsoft Way + Redmond, WA 98052 + Email: mikesw@microsoft.com + + John Brezak + 1 Microsoft Way + Redmond, WA 98052 + Email: jbrezak@microsoft.com + + Bill Gossman + Cybersafe Corporation + 1605 NW Sammamish Rd. + Issaquah, WA 98027-5378 + Email: bill.gossman@cybersafe.com + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt new file mode 100644 index 000000000000..bd31750a15af --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt @@ -0,0 +1,339 @@ + + + + + + +INTERNET-DRAFT Ken Hornstein +<draft-ietf-cat-krb-dns-locate-02.txt> NRL +March 10, 2000 Jeffrey Altman +Expires: September 10, 2000 Columbia University + + + + Distributing Kerberos KDC and Realm Information with DNS + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Distribution of this memo is unlimited. It is filed as <draft-ietf- + cat-krb-dns-locate-02.txt>, and expires on September 10, 2000. Please + send comments to the authors. + +Abstract + + Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto- + col [RFC????] describe any mechanism for clients to learn critical + configuration information necessary for proper operation of the pro- + tocol. Such information includes the location of Kerberos key dis- + tribution centers or a mapping between DNS domains and Kerberos + realms. + + Current Kerberos implementations generally store such configuration + information in a file on each client machine. Experience has shown + this method of storing configuration information presents problems + with out-of-date information and scaling problems, especially when + + + +Hornstein, Altman [Page 1] + +RFC DRAFT March 10, 2000 + + + using cross-realm authentication. + + This memo describes a method for using the Domain Name System + [RFC1035] for storing such configuration information. Specifically, + methods for storing KDC location and hostname/domain name to realm + mapping information are discussed. + +DNS vs. Kerberos - Case Sensitivity of Realm Names + + In Kerberos, realm names are case sensitive. While it is strongly + encouraged that all realm names be all upper case this recommendation + has not been adopted by all sites. Some sites use all lower case + names and other use mixed case. DNS on the other hand is case insen- + sitive for queries but is case preserving for responses to TXT + queries. Since "MYREALM", "myrealm", and "MyRealm" are all different + it is necessary that the DNS entries be distinguishable. + + Since the recommend realm names are all upper case, we will not + require any quoting to be applied to upper case names. If the realm + name contains lower case characters each character is to be quoted by + a '=' character. So "MyRealm" would be represented as "M=yR=e=a=l=m" + and "myrealm" as "=m=y=r=e=a=l=m". If the realm name contains the + '=' character it will be represented as "==". + + +Overview - KDC location information + + KDC location information is to be stored using the DNS SRV RR [RFC + 2052]. The format of this RR is as follows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for Kerberos is always "_kerberos". + + The Proto can be either "_udp" or "_tcp". If these records are to be + used, a "_udp" record MUST be included. If the Kerberos implementa- + tion supports TCP transport, a "_tcp" record SHOULD be included. + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, Port, and Target have the standard + meaning as defined in RFC 2052. + +Example - KDC location information + + These are DNS records for a Kerberos realm ASDF.COM. It has two Ker- + beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be + directed to kdc1.asdf.com first as per the specified priority. + + + +Hornstein, Altman [Page 2] + +RFC DRAFT March 10, 2000 + + + Weights are not used in these records. + + _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. + _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. + +Overview - Kerberos password changing server location information + + Kerberos password changing server [KERB-CHG] location is to be stored + using the DNS SRV RR [RFC 2052]. The format of this RR is as fol- + lows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for the password server is always "_kpasswd". + + The Proto MUST be "_udp". + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, Port, and Target have the standard + meaning as defined in RFC 2052. + +Overview - Kerberos admin server location information + + Kerberos admin location information is to be stored using the DNS SRV + RR [RFC 2052]. The format of this RR is as follows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for the admin server is always "_kerberos-adm". + + The Proto can be either "_udp" or "_tcp". If these records are to be + used, a "_tcp" record MUST be included. If the Kerberos admin imple- + mentation supports UDP transport, a "_udp" record SHOULD be included. + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, Port, and Target have the standard + meaning as defined in RFC 2052. + + Note that there is no formal definition of a Kerberos admin protocol, + so the use of this record is optional and implementation-dependent. + +Example - Kerberos administrative server location information + + These are DNS records for a Kerberos realm ASDF.COM. It has one + administrative server, kdc1.asdf.com. + + + + +Hornstein, Altman [Page 3] + +RFC DRAFT March 10, 2000 + + + _kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. + +Overview - Hostname/domain name to Kerberos realm mapping + + Information on the mapping of DNS hostnames and domain names to Ker- + beros realms is stored using DNS TXT records [RFC 1035]. These + records have the following format. + + Service.Name TTL Class TXT Realm + + The Service field is always "_kerberos", and prefixes all entries of + this type. + + The Name is a DNS hostname or domain name. This is explained in + greater detail below. + + TTL, Class, and TXT have the standard DNS meaning as defined in RFC + 1035. + + The Realm is the data for the TXT RR, and consists simply of the Ker- + beros realm that corresponds to the Name specified. + + When a Kerberos client wishes to utilize a host-specific service, it + will perform a DNS TXT query, using the hostname in the Name field of + the DNS query. If the record is not found, the first label of the + name is stripped and the query is retried. + + Compliant implementations MUST query the full hostname and the most + specific domain name (the hostname with the first label removed). + Compliant implementations SHOULD try stripping all subsequent labels + until a match is found or the Name field is empty. + +Example - Hostname/domain name to Kerberos realm mapping + + For the previously mentioned ASDF.COM realm and domain, some sample + records might be as follows: + + _kerberos.asdf.com. IN TXT "ASDF.COM" + _kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM" + _kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM" + + Let us suppose that in this case, a Kerberos client wishes to use a + Kerberized service on the host foo.asdf.com. It would first query: + + _kerberos.foo.asdf.com. IN TXT + + Finding no match, it would then query: + + + + +Hornstein, Altman [Page 4] + +RFC DRAFT March 10, 2000 + + + _kerberos.asdf.com. IN TXT + + And find an answer of ASDF.COM. This would be the realm that + foo.asdf.com resides in. + + If another Kerberos client wishes to use a Kerberized service on the + host salesserver.asdf.com, it would query: + + _kerberos.salesserver.asdf.com IN TXT + + And find an answer of SALES.ASDF.COM. + +Security considerations + + As DNS is deployed today, it is an unsecure service. Thus the infor- + mation returned by it cannot be trusted. + + Current practice for REALM to KDC mapping is to use hostnames to + indicate KDC hosts (stored in some implementation-dependent location, + but generally a local config file). These hostnames are vulnerable + to the standard set of DNS attacks (denial of service, spoofed + entries, etc). The design of the Kerberos protocol limits attacks of + this sort to denial of service. However, the use of SRV records does + not change this attack in any way. They have the same vulnerabili- + ties that already exist in the common practice of using hostnames for + KDC locations. + + Current practice for HOSTNAME to REALM mapping is to provide a local + configuration of mappings of hostname or domain name to realm which + are then mapped to KDCs. But this again is vulnerable to spoofing + via CNAME records that point to hosts in other domains. This has the + same effect as when a TXT record is spoofed. In a realm with no + cross-realm trusts this is a DoS attack. However, when cross-realm + trusts are used it is possible to redirect a client to use a comprom- + ised realm. + + This is not an exploit of the Kerberos protocol but of the Kerberos + trust model. The same can be done to any application that must + resolve the hostname in order to determine which domain a non-FQDN + belongs to. + + Implementations SHOULD provide a way of specifying this information + locally without the use of DNS. However, to make this feature + worthwhile a lack of any configuration information on a client should + be interpretted as permission to use DNS. + + + + + + +Hornstein, Altman [Page 5] + +RFC DRAFT March 10, 2000 + + +Expiration + + This Internet-Draft expires on September 10, 2000. + +References + + + [RFC1510] + The Kerberos Network Authentication System; Kohl, Newman; Sep- + tember 1993. + + [RFC1035] + Domain Names - Implementation and Specification; Mockapetris; + November 1987 + + [RFC2782] + A DNS RR for specifying the location of services (DNS SRV); Gul- + brandsen, Vixie; Feburary 2000 + + [KERB-CHG] + Kerberos Change Password Protocol; Horowitz; + ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg- + password-02.txt + +Authors' Addresses + + Ken Hornstein + US Naval Research Laboratory + Bldg A-49, Room 2 + 4555 Overlook Avenue + Washington DC 20375 USA + + Phone: +1 (202) 404-4765 + EMail: kenh@cmf.nrl.navy.mil + + Jeffrey Altman + The Kermit Project + Columbia University + 612 West 115th Street #716 + New York NY 10025-7799 USA + + Phone: +1 (212) 854-1344 + EMail: jaltman@columbia.edu + + + + + + + + +Hornstein, Altman [Page 6] + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt new file mode 100644 index 000000000000..11e5dc9f9548 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt @@ -0,0 +1,1333 @@ + +INTERNET-DRAFT Tom Yu +Common Authentication Technology WG MIT +draft-ietf-cat-krb5gss-mech2-03.txt 04 March 2000 + + The Kerberos Version 5 GSSAPI Mechanism, Version 2 + +Status of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments on this document should be sent to + "ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication + Technology WG discussion list. + +Abstract + + This document defines protocols, procedures, and conventions to be + employed by peers implementing the Generic Security Service + Application Program Interface (as specified in RFC 2743) when using + Kerberos Version 5 technology (as specified in RFC 1510). This + obsoletes RFC 1964. + +Acknowledgements + + Much of the material in this specification is based on work done for + Cygnus Solutions by Marc Horowitz. + +Table of Contents + + Status of This Memo ............................................ 1 + Abstract ....................................................... 1 + Acknowledgements ............................................... 1 + Table of Contents .............................................. 1 + 1. Introduction ............................................... 3 + 2. Token Formats .............................................. 3 + 2.1. Packet Notation ....................................... 3 + +Yu Document Expiration: 04 Sep 2000 [Page 1] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + 2.2. Mechanism OID ......................................... 4 + 2.3. Context Establishment ................................. 4 + 2.3.1. Option Format .................................... 4 + 2.3.1.1. Delegated Credentials Option ................ 5 + 2.3.1.2. Null Option ................................. 5 + 2.3.2. Initial Token .................................... 6 + 2.3.2.1. Data to be Checksummed in APREQ ............. 8 + 2.3.3. Response Token ................................... 10 + 2.4. Per-message Tokens .................................... 12 + 2.4.1. Sequence Number Usage ............................ 12 + 2.4.2. MIC Token ........................................ 12 + 2.4.2.1. Data to be Checksummed in MIC Token ......... 13 + 2.4.3. Wrap Token ....................................... 14 + 2.4.3.1. Wrap Token With Integrity Only .............. 14 + 2.4.3.2. Wrap Token With Integrity and Encryption + ............................................. 15 + 2.4.3.2.1. Data to be Encrypted in Wrap Token ..... 16 + 3. ASN.1 Encoding of Octet Strings ............................ 17 + 4. Name Types ................................................. 18 + 4.1. Mandatory Name Forms .................................. 18 + 4.1.1. Kerberos Principal Name Form ..................... 18 + 4.1.2. Exported Name Object Form for Kerberos5 + Mechanism ........................................ 19 + 5. Credentials ................................................ 20 + 6. Parameter Definitions ...................................... 20 + 6.1. Minor Status Codes .................................... 20 + 6.1.1. Non-Kerberos-specific codes ...................... 21 + 6.1.2. Kerberos-specific-codes .......................... 21 + 7. Kerberos Protocol Dependencies ............................. 22 + 8. Security Considerations .................................... 22 + 9. References ................................................. 22 + 10. Author's Address .......................................... 23 + + + + + + + + + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 2] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +1. Introduction + + The original Kerberos 5 GSSAPI mechanism[RFC1964] has a number of + shortcomings. This document attempts to remedy them by defining a + completely new Kerberos 5 GSSAPI mechanism. + + The context establishment token format requires that the + authenticator of AP-REQ messages contain a cleartext data structure + in its checksum field, which is a needless and potentially confusing + overloading of that field. This is implemented by a special checksum + algorithm whose purpose is to copy the input data directly into the + checksum field of the authenticator. + + The number assignments for checksum algorithms and for encryption + types are inconsistent between the Kerberos protocol and the original + GSSAPI mechanism. If new encryption or checksum algorithms are added + to the Kerberos protocol at some point, the GSSAPI mechanism will + need to be separately updated to use these new algorithms. + + The original mechanism specifies a crude method of key derivation (by + using the XOR of the context key with a fixed constant), which is + incompatible with newer cryptosystems which specify key derivation + procedures themselves. The original mechanism also assumes that both + checksums and cryptosystem blocksizes are eight bytes. + + Defining all GSSAPI tokens for the new Kerberos 5 mechanism in terms + of the Kerberos protocol specification ensures that new encryption + types and checksum types may be automatically used as they are + defined for the Kerberos protocol. + +2. Token Formats + + All tokens, not just the initial token, are framed as the + InitialContextToken described in RFC 2743 section 3.1. The + innerContextToken element of the token will not itself be encoded in + ASN.1, with the exception of caller-provided application data. + + One rationale for avoiding the use of ASN.1 in the inner token is + that some implementors may wish to implement this mechanism in a + kernel or other similarly constrained application where handling of + full ASN.1 encoding may be cumbersome. Also, due to the poor + availability of the relevant standards documents, ASN.1 encoders and + decoders are difficult to implement completely correctly, so keeping + ASN.1 usage to a minimum decreases the probability of bugs in the + implementation of the mechanism. In particular, bit strings need to + be transferred at certain points in this mechanism. There are many + conflicting common misunderstandings of how to encode and decode + ASN.1 bit strings, which have led difficulties in the implementaion + of the Kerberos protocol. + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 3] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.1. Packet Notation + + The order of transmission of this protocol is described at the octet + level. Packet diagrams depict bits in the order of transmission, + assuming that individual octets are transmitted with the most + significant bit (MSB) first. The diagrams read from left to right + and from top to bottom, as in printed English. In each octet, bit + number 7 is the MSB and bit number 0 is the LSB. + + Numbers prefixed by the characters "0x" are in hexadecimal notation, + as in the C programming language. Even though packet diagrams are + drawn 16 bits wide, no padding should be used to align the ends of + variable-length fields to a 32-bit or 16-bit boundary. + + All integer fields are in network byte order. All other fields have + the size shown in the diagrams, with the exception of variable length + fields. + +2.2. Mechanism OID + + The Object Identifier (OID) of the new krb5 v2 mechanism is: + + {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2) + krb5v2(3)} + + +2.3. Context Establishment + +2.3.1. Option Format + + Context establishment tokens, i.e., the initial ones that the + GSS_Init_sec_context() and the GSS_Accept_sec_context() calls emit + while a security context is being set up, may contain options that + influence the subsequent behavior of the context. This document + describes only a small set of options, but additional types may be + added by documents intended to supplement this one. The generic + format is as follows: + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | option type | + +-------------------------------+-------------------------------+ + 2 | | + +-- option length (32 bits) --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / option data (variable length) / + | . | + +-------------------------------+-------------------------------+ + + + + +Yu Document Expiration: 04 Sep 2000 [Page 4] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + option type (16 bits) + The type identifier of the following option. + + option length (32 bits) + The length in bytes of the following option. + + option data (variable length) + The actual option data. + + Any number of options may appear in an initator or acceptor token. + The final option in a token must be the null option, in order to mark + the end of the list. Option type 0xffff is reserved. + + The initiator and acceptor shall ignore any options that they do not + understand. + +2.3.1.1. Delegated Credentials Option + + Only the initiator may use this option. The format of the delegated + credentials option is as follows: + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | option type = 0x00001 | + +-------------------------------+-------------------------------+ + 2 | | + +-- KRB-CRED length --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / KRB-CRED message / + | . | + +-------------------------------+-------------------------------+ + + + option type (16 bits) + The option type for this option shall be 0x0001. + + KRB-CRED length (32 bits) + The length in bytes of the following KRB-CRED message. + + KRB-CRED message (variable length) + The option data for this option shall be the KRB-CRED message + that contains the credentials being delegated (forwarded) to the + context acceptor. Only the initiator may use this option. + +2.3.1.2. Null Option + + The Null option terminates the option list, and must be used by both + the initiator and the acceptor. Its format is as follows: + + + + +Yu Document Expiration: 04 Sep 2000 [Page 5] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | option type = 0 | + +-------------------------------+-------------------------------+ + 2 | | + +-- length = 0 --+ + 4 | | + +-------------------------------+-------------------------------+ + + + option type (16 bits) + The option type of this option must be zero. + + option length (32 bits) + The length of this option must be zero. + +2.3.2. Initial Token + + This is the initial token sent by the context initiator, generated by + GSS_Init_sec_context(). + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | initial token id = 0x0101 | + +-------------------------------+-------------------------------+ + 2 | | + +-- reserved flag bits +-----------------------+ + 4 | | I | C | S | R | M | D | + +-------------------------------+-------------------------------+ + 6 | checksum type count | + +-------------------------------+-------------------------------+ + 8 | . | + / checksum type list / + | . | + +-------------------------------+-------------------------------+ + n | . | + / options / + | . | + +-------------------------------+-------------------------------+ + m | | + +-- AP-REQ length --+ + m+2 | | + +-------------------------------+-------------------------------+ + m+4 | . | + / AP-REQ data / + | . | + +-------------------------------+-------------------------------+ + + + initial token ID (16 bits) + Contains the integer 0x0101, which identifies this as the + initial token in the context setup. + + +Yu Document Expiration: 04 Sep 2000 [Page 6] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + reserved flag bits (26 bits) + These bits are reserved for future expansion. They must be set + to zero by the initiator and be ignored by the acceptor. + + I flag (1 bit) + 0x00000020 -- GSS_C_INTEG_FLAG + + C flag (1 bit) + 0x00000010 -- GSS_C_CONF_FLAG + + S flag (1 bit) + 0x00000008 -- GSS_C_SEQUENCE_FLAG + + R flag (1 bit) + 0x00000004 -- GSS_C_REPLAY_FLAG + + M flag (1 bit) + 0x00000002 -- GSS_C_MUTUAL_FLAG + + D flag (1 bit) + 0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the + "delegated credentials" option is included. + + checksum type count (16 bits) + The number of checksum types supported by the initiator. + + checksum type list (variable length) + A list of Kerberos checksum types, as defined in RFC 1510 + section 6.4. These checksum types must be collision-proof and + keyed with the context key; no checksum types that are + incompatible with the encryption key shall be used. Each + checksum type number shall be 32 bits wide. This list should + contain all the checksum types supported by the initiator. If + mutual authentication is not used, then this list shall contain + only one checksum type. + + options (variable length) + The context initiation options, described in section 2.3.1. + + AP-REQ length (32 bits) + The length of the following KRB_AP_REQ message. + + AP-REQ data (variable length) + The AP-REQ message as described in RFC 1510. The checksum in + the authenticator will be computed over the items listed in the + next section. + + The optional sequence number field shall be used in the AP-REQ. The + initiator should generate a subkey in the authenticator, and the + acceptor should generate a subkey in the AP-REP. The key used for + the per-message tokens will be the AP-REP subkey, or if that is not + present, the authenticator subkey, or if that is not present, the + session key. When subkeys are generated, it is strongly recommended + +Yu Document Expiration: 04 Sep 2000 [Page 7] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + that they be of the same type as the associated session key. + + XXX The above is not secure. There should be an algorithmic process + to arrive at a subsession key which both sides of the authentication + exchange can perform based on the ticket sessions key and data known + to both parties, and this should probably be part of the revised + Kerberos protocol rather than bound to the GSSAPI mechanism. + +2.3.2.1. Data to be Checksummed in AP-REQ + + The checksum in the AP-REQ message is calculated over the following + items. Like in the actual tokens, no padding should be added to + force integer fields to align on 32 bit boundaries. This particular + set of data should not be sent as a part of any token; it merely + specifies what is to be checksummed in the AP-REQ. The items in this + encoding that precede the initial token ID correspond to the channel + bindings passed to GSS_Init_sec_context(). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 8] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | | + +-- initiator address type --+ + 2 | | + +-------------------------------+-------------------------------+ + 4 | initiator address length | + +-------------------------------+-------------------------------+ + 6 | . | + / initiator address / + | . | + +-------------------------------+-------------------------------+ + n | | + +-- acceptor address type --+ + | | + +-------------------------------+-------------------------------+ + n+4 | acceptor address length | + +-------------------------------+-------------------------------+ + n+6 | . | + / acceptor address / + | . | + +-------------------------------+-------------------------------+ + m | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + k | initial token id = 0x0101 | + +-------------------------------+-------------------------------+ + k+2 | | + +-- flags --+ + k+4 | | + +-------------------------------+-------------------------------+ + k+6 | checksum type count | + +-------------------------------+-------------------------------+ + k+8 | . | + / checksum type list / + | . | + +-------------------------------+-------------------------------+ + j | . | + / options / + | . | + +-------------------------------+-------------------------------+ + + + initiator address type (32 bits) + The initiator address type, as defined in the Kerberos protocol + specification. If no initiator address is provided, this must + be zero. + + initiator address length (16 bits) + The length in bytes of the following initiator address. If + there is no inititator address provided, this must be zero. + + +Yu Document Expiration: 04 Sep 2000 [Page 9] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + initiator address (variable length) + The actual initiator address, in network byte order. + + acceptor address type (32 bits) + The acceptor address type, as defined in the Kerberos protocol + specification. If no acceptor address is provided, this must be + zero. + + acceptor address length (16 bits) + The length in bytes of the following acceptor address. This + must be zero is there is no acceptor address provided. + + initiator address (variable length) + The actual acceptor address, in network byte order. + + applicatation data (variable length) + The application data, if provided, encoded as a ASN.1 octet + string using DER. If no application data are passed as input + channel bindings, this shall be a zero-length ASN.1 octet + string. + + initial token ID (16 bits) + The initial token ID from the initial token. + + flags (32 bits) + The context establishment flags from the initial token. + + checksum type count (16 bits) + The number of checksum types supported by the initiator. + + checksum type list (variable length) + The same list of checksum types contained in the initial token. + + options (variable length) + The options list from the initial token. + +2.3.3. Response Token + + This is the reponse token sent by the context acceptor, if mutual + authentication is enabled. + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 10] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | response token id = 0x0202 | + +-------------------------------+-------------------------------+ + 2 | | + +-- reserved flag bits +-------+ + 4 | | D | E | + +-------------------------------+-------------------------------+ + 6 | | + +-- checksum type --+ + 8 | | + +-------------------------------+-------------------------------+ + 10 | . | + / options / + | . | + +-------------------------------+-------------------------------+ + n | | + +-- AP-REP or KRB-ERROR length --+ + n+2 | | + +-------------------------------+-------------------------------+ + n+4 | . | + / AP-REP or KRB-ERROR data / + | . | + +-------------------------------+-------------------------------+ + m | . | + / MIC data / + | . | + +-------------------------------+-------------------------------+ + + + response token id (16 bits) + Contains the integer 0x0202, which identifies this as the + response token in the context setup. + + reserved flag bits (30 bits) + These bits are reserved for future expansion. They must be set + to zero by the acceptor and be ignored by the initiator. + + D flag -- delegated creds accepted (1 bit) + 0x00000002 -- If this flag is set, the acceptor processed the + delegated credentials, and GSS_C_DELEG_FLAG should be returned + to the caller. + + E flag -- error (1 bit) + 0x00000001 -- If this flag is set, a KRB-ERROR message shall be + present, rather than an AP-REP message. If this flag is not + set, an AP-REP message shall be present. + + checksum type count (16 bits) + The number of checksum types supported by both the initiator and + the acceptor. + + + +Yu Document Expiration: 04 Sep 2000 [Page 11] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + checksum type (32 bits) + A Kerberos checksum type, as defined in RFC 1510 section 6.4. + This checksum type must be among the types listed by the + initiator, and will be used in for subsequent checksums + generated during this security context. + + options (variable length) + The option list, as described earlier. At this time, no options + are defined for the acceptor, but an implementation might make + use of these options to acknowledge an option from the initial + token. After all the options are specified, a null option must + be used to terminate the list. + + AP-REP or KRB-ERROR length (32 bits) + Depending on the value of the error flag, length in bytes of the + AP-REP or KRB-ERROR message. + + AP-REP or KRB-ERROR data (variable length) + Depending on the value of the error flag, the AP-REP or + KRB-ERROR message as described in RFC 1510. If this field + contains an AP-REP message, the sequence number field in the + AP-REP shall be filled. If this is a KRB-ERROR message, no + further fields will be in this message. + + MIC data (variable length) + A MIC token, as described in section 2.4.2, computed over the + concatentation of the response token ID, flags, checksum length + and type fields, and all option fields. This field and the + preceding length field must not be present if the error flag is + set. + +2.4. Per-message Tokens + +2.4.1. Sequence Number Usage + + Sequence numbers for per-message tokens are 31 bit unsigned integers, + which are incremented by 1 after each token. An overflow condition + should result in a wraparound of the sequence number to zero. The + initiator and acceptor each keep their own sequence numbers per + connection. + + The intial sequence number for tokens sent from the initiator to the + acceptor shall be the least significant 31 bits of sequence number in + the AP-REQ message. The initial sequence number for tokens sent from + the acceptor to the initiator shall be the least significant 31 bits + of the sequence number in the AP-REP message if mutual authentication + is used; if mutual authentication is not used, the initial sequence + number from acceptor to initiator shall be the least significant 31 + bits of the sequence number in the AP-REQ message. + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 12] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.4.2. MIC Token + + Use of the GSS_GetMIC() call yields a token, separate from the user + data being protected, which can be used to verify the integrity of + that data when it is received. The MIC token has the following + format: + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | MIC token id = 0x0303 | + +-------------------------------+-------------------------------+ + 2 | D | | + +---+ sequence number --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | checksum length | + +-------------------------------+-------------------------------+ + 8 | . | + / checksum data / + | . | + +-------------------------------+-------------------------------+ + + + MIC token id (16 bits) + Contains the integer 0x0303, which identifies this as a MIC + token. + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + checksum length (16 bits) + The number of bytes in the following checksum data field. + + checksum data (variable length) + The checksum itself, as defined in RFC 1510 section 6.4. The + checksum is calculated over the encoding described in the + following section. The key usage GSS_TOK_MIC -- 22 [XXX need to + register this] shall be used in cryptosystems that support key + derivation. + + The mechanism implementation shall only use the checksum type + returned by the acceptor in the case of mutual authentication. If + mutual authentication is not requested, then only the checksum type + in the initiator token shall be used. + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 13] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.4.2.1. Data to be Checksummed in MIC Token + + The checksum in the MIC token shall be calculated over the following + elements. This set of data is not actually included in the token as + is; the description only appears for the purpose of specifying the + method of calculating the checksum. + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | MIC token id = 0x0303 | + +-------------------------------+-------------------------------+ + 2 | D | | + +---+ sequence number --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + + + MIC token ID (16 bits) + The MIC token ID from the MIC message. + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + application data (variable length) + The application-supplied data, encoded as an ASN.1 octet string + using DER. + +2.4.3. Wrap Token + + Use of the GSS_Wrap() call yields a token which encapsulates the + input user data (optionally encrypted) along with associated + integrity check quantities. + +2.4.3.1. Wrap Token With Integrity Only + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 14] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | integrity wrap token id = 0x0404 | + +-------------------------------+-------------------------------+ + 2 | D | | + +---+ sequence number --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + n | checksum length | + +-------------------------------+-------------------------------+ + n+2 | . | + / checksum data / + | . | + +-------------------------------+-------------------------------+ + + + integrity wrap token id (16 bits) + Contains the integer 0x0404, which identifies this as a Wrap + token with integrity only. + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + application data (variable length) + The application-supplied data, encoded as an ASN.1 octet string + using DER. + + checksum length (16 bits) + The number of bytes in the following checksum data field. + + checksum data (variable length) + The checksum itself, as defined in RFC 1510 section 6.4, + computed over the concatenation of the token ID, sequence + number, direction field, application data length, and + application data, as in the MIC token checksum in the previous + section. The key usage GSS_TOK_WRAP_INTEG -- 23 [XXX need to + register this] shall be used in cryptosystems that support key + derivation. + + The mechanism implementation should only use checksum types which it + knows to be valid for both peers, as described for MIC tokens. + + + + +Yu Document Expiration: 04 Sep 2000 [Page 15] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.4.3.2. Wrap Token With Integrity and Encryption + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + | encrypted wrap token id = 0x0505 | + +-------------------------------+-------------------------------+ + 2 | . | + / encrypted data / + | . | + +-------------------------------+-------------------------------+ + + + encrypted wrap token id (16 bits) + Contains the integer 0x0505, which identifies this as a Wrap + token with integrity and encryption. + + encrypted data (variable length) + The encrypted data itself, as defined in RFC 1510 section 6.3, + encoded as an ASN.1 octet string using DER. Note that this is + not the ASN.1 type EncryptedData as defined in RFC 1510 + section 6.1, but rather the ciphertext without encryption type + or kvno information. The encryption is performed using the + key/enctype exchanged during context setup. The confounder and + checksum are as specified in the Kerberos protocol + specification. The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need + to register this] shall be used in cryptosystems that support + key derivation. The actual data to be encrypted are specified + below. + +2.4.3.2.1. Data to be Encrypted in Wrap Token + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | D | | + +---+ sequence number --+ + 2 | | + +-------------------------------+-------------------------------+ + 4 | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + application data (variable length) + The application-supplied data, encoded as an ASN.1 octet string + +Yu Document Expiration: 04 Sep 2000 [Page 16] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + using DER. + +3. ASN.1 Encoding of Octet Strings + + In order to encode arbitirarly-sized application data, ASN.1 octet + string encoding is in this protocol. The Distinguished Encoding + Rules (DER) shall always be used in such cases. For reference + purposes, the DER encoding of an ASN.1 octet string, adapted from + ITU-T X.690, follows: + + +--------+-------//-------+-------//-------+ + |00000100| length octets |contents octets | + +--------+-------//-------+-------//-------+ + | + +-- identifier octet = 0x04 = [UNIVERSAL 4] + + + In this section only, the bits in each octet shall be numbered as in + the ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the + octet, and with bit 1 being the LSB of the octet. + + identifier octet (8 bits) + Contains the constant 0x04, the tag for primitive encoding of an + octet string with the default (UNIVERSAL 4) tag. + + length octets (variable length) + Contains the length of the contents octets, in definite form + (since this encoding uses DER). + + contents octets (variable length) + The contents of the octet string. + + The length octets shall consist of either a short form (one byte + only), which is to be used only if the number of octets in the + contents octets is less than or equal to 127, or a long form, which + is to be used in all other cases. The short form shall consist of a + single octet with bit 8 (the MSB) equal to zero, and the remaining + bits encoding the number of contents octets (which may be zero) as an + unsigned binary integer. + + The long form shall consist of an initial octet and one or more + subsequent octets. The first octet shall have bit 8 (the MSB) set to + one, and the remaining bits shall encode the number of subsequent + octets in the length encoding as an unsigned binary integer. The + length must be encoded in the minimum number of octets. An initial + octet of 0xFF is reserved by the ASN.1 specification. Bits 8 to 1 of + the first subsequent octet, followed by bits 8 to 1 of each + subsequent octet in order, shall be the encoding of an unsigned + binary integer, with bit 8 of the first octet being the most + significant bit. Thus, the length encoding within is in network byte + order. + + + +Yu Document Expiration: 04 Sep 2000 [Page 17] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + An initial length octet of 0x80 shall not be used, as that is + reserved by the ASN.1 specification for indefinite lengths in + conjunction with constructed contents encodings, which are not to be + used with DER. + +4. Name Types + + This section discusses the name types which may be passed as input to + the Kerberos 5 GSSAPI mechanism's GSS_Import_name() call, and their + associated identifier values. It defines interface elements in + support of portability, and assumes use of C language bindings per + RFC 2744. In addition to specifying OID values for name type + identifiers, symbolic names are included and recommended to GSSAPI + implementors in the interests of convenience to callers. It is + understood that not all implementations of the Kerberos 5 GSSAPI + mechanism need support all name types in this list, and that + additional name forms will likely be added to this list over time. + Further, the definitions of some or all name types may later migrate + to other, mechanism-independent, specifications. The occurrence of a + name type in this specification is specifically not intended to + suggest that the type may be supported only by an implementation of + the Kerberos 5 mechanism. In particular, the occurrence of the + string "_KRB5_" in the symbolic name strings constitutes a means to + unambiguously register the name strings, avoiding collision with + other documents; it is not meant to limit the name types' usage or + applicability. + + For purposes of clarification to GSSAPI implementors, this section's + discussion of some name forms describes means through which those + forms can be supported with existing Kerberos technology. These + discussions are not intended to preclude alternative implementation + strategies for support of the name forms within Kerberos mechanisms + or mechanisms based on other technologies. To enhance application + portability, implementors of mechanisms are encouraged to support + name forms as defined in this section, even if their mechanisms are + independent of Kerberos 5. + +4.1. Mandatory Name Forms + + This section discusses name forms which are to be supported by all + conformant implementations of the Kerberos 5 GSSAPI mechanism. + +4.1.1. Kerberos Principal Name Form + + This name form shall be represented by the Object Identifier {iso(1) + member-body(2) us(840) mit(113554) infosys(1) gssapi(2) krb5(2) + krb5_name(1)}. The recommended symbolic name for this type is + "GSS_KRB5_NT_PRINCIPAL_NAME". + + This name type corresponds to the single-string representation of a + Kerberos name. (Within the MIT Kerberos 5 implementation, such names + are parseable with the krb5_parse_name() function.) The elements + included within this name representation are as follows, proceeding + +Yu Document Expiration: 04 Sep 2000 [Page 18] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + from the beginning of the string: + + (1) One or more principal name components; if more than one + principal name component is included, the components are + separated by '/'. Arbitrary octets may be included within + principal name components, with the following constraints and + special considerations: + + (1a) Any occurrence of the characters '@' or '/' within a + name component must be immediately preceded by the '\' + quoting character, to prevent interpretation as a component + or realm separator. + + (1b) The ASCII newline, tab, backspace, and null characters + may occur directly within the component or may be + represented, respectively, by '\n', '\t', '\b', or '\0'. + + (1c) If the '\' quoting character occurs outside the contexts + described in (1a) and (1b) above, the following character is + interpreted literally. As a special case, this allows the + doubled representation '\\' to represent a single occurrence + of the quoting character. + + (1d) An occurrence of the '\' quoting character as the last + character of a component is illegal. + + (2) Optionally, a '@' character, signifying that a realm name + immediately follows. If no realm name element is included, the + local realm name is assumed. The '/' , ':', and null characters + may not occur within a realm name; the '@', newline, tab, and + backspace characters may be included using the quoting + conventions described in (1a), (1b), and (1c) above. + +4.1.2. Exported Name Object Form for Kerberos 5 Mechanism + + When generated by the Kerberos 5 mechanism, the Mechanism OID within + the exportable name shall be that of the original Kerberos 5 + mechanism[RFC1964]. The Mechanism OID for the original Kerberos 5 + mechanism is: + + {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2) + krb5(2)} + + The name component within the exportable name shall be a contiguous + string with structure as defined for the Kerberos Principal Name + Form. + + In order to achieve a distinguished encoding for comparison purposes, + the following additional constraints are imposed on the export + operation: + + (1) all occurrences of the characters '@', '/', and '\' within + principal components or realm names shall be quoted with an + +Yu Document Expiration: 04 Sep 2000 [Page 19] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + immediately-preceding '\'. + + (2) all occurrences of the null, backspace, tab, or newline + characters within principal components or realm names will be + represented, respectively, with '\0', '\b', '\t', or '\n'. + + (3) the '\' quoting character shall not be emitted within an + exported name except to accomodate cases (1) and (2). + +5. Credentials + + The Kerberos 5 protocol uses different credentials (in the GSSAPI + sense) for initiating and accepting security contexts. Normal + clients receive a ticket-granting ticket (TGT) and an associated + session key at "login" time; the pair of a TGT and its corresponding + session key forms a credential which is suitable for initiating + security contexts. A ticket-granting ticket, its session key, and + any other (ticket, key) pairs obtained through use of the + ticket-granting-ticket, are typically stored in a Kerberos 5 + credentials cache, sometimes known as a ticket file. + + The encryption key used by the Kerberos server to seal tickets for a + particular application service forms the credentials suitable for + accepting security contexts. These service keys are typically stored + in a Kerberos 5 key table (keytab), or srvtab file (the Kerberos 4 + terminology). In addition to their use as accepting credentials, + these service keys may also be used to obtain initiating credentials + for their service principal. + + The Kerberos 5 mechanism's credential handle may contain references + to either or both types of credentials. It is a local matter how the + Kerberos 5 mechanism implementation finds the appropriate Kerberos 5 + credentials cache or key table. + + However, when the Kerberos 5 mechanism attempts to obtain initiating + credentials for a service principal which are not available in a + credentials cache, and the key for that service principal is + available in a Kerberos 5 key table, the mechanism should use the + service key to obtain initiating credentials for that service. This + should be accomplished by requesting a ticket-granting-ticket from + the Kerberos Key Distribution Center (KDC), and decrypting the KDC's + reply using the service key. + +6. Parameter Definitions + + This section defines parameter values used by the Kerberos V5 GSSAPI + mechanism. It defines interface elements in support of portability, + and assumes use of C language bindings per RFC 2744. + +6.1. Minor Status Codes + + This section recommends common symbolic names for minor_status values + to be returned by the Kerberos 5 GSSAPI mechanism. Use of these + +Yu Document Expiration: 04 Sep 2000 [Page 20] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + definitions will enable independent implementors to enhance + application portability across different implementations of the + mechanism defined in this specification. (In all cases, + implementations of GSS_Display_status() will enable callers to + convert minor_status indicators to text representations.) Each + implementation should make available, through include files or other + means, a facility to translate these symbolic names into the concrete + values which a particular GSSAPI implementation uses to represent the + minor_status values specified in this section. + + It is recognized that this list may grow over time, and that the need + for additional minor_status codes specific to particular + implementations may arise. It is recommended, however, that + implementations should return a minor_status value as defined on a + mechanism-wide basis within this section when that code is accurately + representative of reportable status rather than using a separate, + implementation-defined code. + +6.1.1. Non-Kerberos-specific codes + + These symbols should likely be incorporated into the generic GSSAPI + C-bindings document, since they really are more general. + +GSS_KRB5_S_G_BAD_SERVICE_NAME + /* "No @ in SERVICE-NAME name string" */ +GSS_KRB5_S_G_BAD_STRING_UID + /* "STRING-UID-NAME contains nondigits" */ +GSS_KRB5_S_G_NOUSER + /* "UID does not resolve to username" */ +GSS_KRB5_S_G_VALIDATE_FAILED + /* "Validation error" */ +GSS_KRB5_S_G_BUFFER_ALLOC + /* "Couldn't allocate gss_buffer_t data" */ +GSS_KRB5_S_G_BAD_MSG_CTX + /* "Message context invalid" */ +GSS_KRB5_S_G_WRONG_SIZE + /* "Buffer is the wrong size" */ +GSS_KRB5_S_G_BAD_USAGE + /* "Credential usage type is unknown" */ +GSS_KRB5_S_G_UNKNOWN_QOP + /* "Unknown quality of protection specified" */ + + +6.1.2. Kerberos-specific-codes + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 21] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +GSS_KRB5_S_KG_CCACHE_NOMATCH + /* "Principal in credential cache does not match desired name" */ +GSS_KRB5_S_KG_KEYTAB_NOMATCH + /* "No principal in keytab matches desired name" */ +GSS_KRB5_S_KG_TGT_MISSING + /* "Credential cache has no TGT" */ +GSS_KRB5_S_KG_NO_SUBKEY + /* "Authenticator has no subkey" */ +GSS_KRB5_S_KG_CONTEXT_ESTABLISHED + /* "Context is already fully established" */ +GSS_KRB5_S_KG_BAD_SIGN_TYPE + /* "Unknown signature type in token" */ +GSS_KRB5_S_KG_BAD_LENGTH + /* "Invalid field length in token" */ +GSS_KRB5_S_KG_CTX_INCOMPLETE + /* "Attempt to use incomplete security context" */ + + +7. Kerberos Protocol Dependencies + + This protocol makes several assumptions about the Kerberos protocol, + which may require changes to the successor of RFC 1510. + + Sequence numbers, checksum types, and address types are assumed to be + no wider than 32 bits. The Kerberos protocol specification might + need to be modified to accomodate this. This obviously requires some + further discussion. + + Key usages need to be registered within the Kerberos protocol for use + with GSSAPI per-message tokens. The current specification of the + Kerberos protocol does not include descriptions of key derivations or + key usages, but planned revisions to the protocol will include them. + + This protocol also makes the assumption that any cryptosystem used + with the session key will include integrity protection, i.e., it + assumes that no "raw" cryptosystems will be used. + +8. Security Considerations + + The GSSAPI is a security protocol; therefore, security considerations + are discussed throughout this document. The original Kerberos 5 + GSSAPI mechanism's constraints on possible cryptosystems and checksum + types do not permit it to be readily extended to accomodate more + secure cryptographic technologies with larger checksums or encryption + block sizes. Sites are strongly encouraged to adopt the mechanism + specified in this document in the light of recent publicity about the + deficiencies of DES. + +9. References + + [X.680] ISO/IEC, "Information technology -- Abstract Syntax Notation + One (ASN.1): Specification of basic notation", ITU-T X.680 (1997) | + ISO/IEC 8824-1:1998 + +Yu Document Expiration: 04 Sep 2000 [Page 22] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + [X.690] ISO/IEC, "Information technology -- ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical Encoding Rules + (CER) and Distinguished Encoding Rules (DER)", ITU-T X.690 (1997) | + ISO/IEC 8825-1:1998. + + [RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication + Service (V5)", RFC 1510. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface, Version 2, Update 1", RFC 2743. + + [RFC2744] Wray, J., "Generic Security Service API Version 2: + C-bindings", RFC 2744. + +10. Author's Address + + Tom Yu + Massachusetts Institute of Technology + Room E40-345 + 77 Massachusetts Avenue + Cambridge, MA 02139 + USA + + email: tlyu@mit.edu + phone: +1 617 253 1753 + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 23] + diff --git a/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt b/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt new file mode 100644 index 000000000000..24325fdbda74 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt @@ -0,0 +1,281 @@ +CAT Working Group K. Raeburn +Internet-draft MIT +Category: July 14, 2000 +Updates: RFC 1964 +Document: draft-raeburn-cat-gssapi-krb5-3des-00.txt + + Triple-DES Support for the Kerberos 5 GSSAPI Mechanism + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts + are working documents of the Internet Engineering Task Force + (IETF), its areas, and its working groups. Note that other groups + may also distribute working documents as + Internet-Drafts. Internet-Drafts are draft documents valid for a + maximum of six months and may be updated, replaced, or obsoleted by + other documents at any time. It is inappropriate to use + Internet-Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + The MIT Kerberos 5 release version 1.2 includes support for + triple-DES with key derivation [KrbRev]. Recent work by the EFF + [EFF] has demonstrated the vulnerability of single-DES mechanisms + to brute-force attacks by sufficiently motivated and well-funded + parties. + + The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] + specifically enumerates encryption and checksum types, + independently of how such schemes may be used in Kerberos. In the + long run, a new Kerberos-based mechanism, which does not require + separately enumerating for the GSSAPI mechanism each of the + encryption types defined by Kerberos, appears to be a better + approach. Efforts to produce such a specification are under way. + + In the interest of providing increased security in the interim, + however, MIT is proposing adding support for triple-DES to the + existing mechanism, as described here. + +2. Conventions Used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC 2119. + +3. New Algorithm Identifiers + + One new sealing algorithm is defined, for use in WRAP tokens: + + 02 00 - DES3-KD + + This algorithm uses triple-DES with key derivation, with a usage + value KG_USAGE_SEAL. Padding is still to 8-byte multiples, and the + IV for encrypting application data is zero. + + One new signing algorithm is defined, for use in MIC, Wrap, and + Delete tokens: + + 04 00 - HMAC SHA1 DES3-KD + + This algorithm generates an HMAC using SHA-1 and a derived DES3 key + with usage KG_USAGE_SIGN, as (ought to be described) in [KrbRev]. + + [XXX: The current [KrbRev] description refers to expired I-Ds from + Marc Horowitz. The text in [KrbRev] may be inadequate to produce + an interoperable implementation.] + + The checksum size for this algorithm is 20 octets. See section 5.3 + below for the use of checksum lengths of other than eight bytes. + +4. Key Derivation + + For purposes of key derivation, we add three new usage values to the + list defined in [KrbRev]; one for signing messages, one for + sealing messages, and one for encrypting sequence numbers: + + #define KG_USAGE_SEAL 22 + #define KG_USAGE_SIGN 23 + #define KG_USAGE_SEQ 24 + +5. Adjustments to Previous Definitions + +5.1. Quality of Protection + + The GSSAPI specification [GSSAPI] says that a zero QOP value + indicates the "default". The original specification for the + Kerberos 5 mechanism says that a zero QOP value (or a QOP value + with the appropriate bits clear) means DES encryption. + + Rather than continue to force the use of plain DES when the + application doesn't use mechanism-specific QOP values, the better + choice appears to be to redefine the DES QOP value as some non-zero + value, and define a triple-DES value as well. Then a zero value + continues to imply the default, which would be triple-DES + protection when given a triple-DES session key. + + Our values are: + + GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 + /* SHA-1 checksum encrypted with key derivation */ + + GSS_KRB5_CONF_C_QOP_DES 0x0100 + /* plain DES encryption */ + GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200 + /* triple-DES with key derivation */ + + Rather than open the question of whether to specify means for + deriving a key of one type given a key of another type, and the + security implications of whether to generate a long key from a + shorter one, our implementation will simply return an error if the + QOP value specified does not correspond to the session key type. + + [Implementation note: MIT's code does not implement QoP, and + returns an error for any non-zero QoP value.] + +5.2. MIC Sequence Number Encryption + + The sequence numbers are encrypted in the context key (as defined + in [GSSAPI-KRB5] -- this will be either the Kerberos session key or + asubkey provided by the context initiator), using whatever + encryption system is designated by the type of that context key. + The IV is formed from the first N bytes of the SGN_CKSUM field, + where N is the number of bytes needed for the IV. (With all + algorithms described here and in [GSSAPI-KRB5], the checksum is at + least as large as the IV.) + +5.3. Message Layout + + Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an + checksum field SGN_CKSUM. In [GSSAPI-KRB5], this field was + specified as being 8 bytes long. We now change this size to be + "defined by the checksum algorithm", and retroactively amend the + descriptions of all the checksum algorithms described in + [GSSAPI-KRB5] to explicitly specify 8-byte output. Application + data continues to immediately follow the checksum field in the Wrap + token. + + The revised message descriptions are thus: + + MIC: + + Byte no Name Description + 0..1 TOK_ID Identification field. + 2..3 SGN_ALG Integrity algorithm indicator. + 4..7 Filler Contains ff ff ff ff + 8..15 SND_SEQ Sequence number field. + 16..s+15 SGN_CKSUM Checksum of "to-be-signed data", + calculated according to algorithm + specified in SGN_ALG field. + + Wrap: + + Byte no Name Description + 0..1 TOK_ID Identification field. + Tokens emitted by GSS_Wrap() contain + the hex value 02 01 in this field. + 2..3 SGN_ALG Checksum algorithm indicator. + 4..5 SEAL_ALG Sealing algorithm indicator. + 6..7 Filler Contains ff ff + 8..15 SND_SEQ Encrypted sequence number field. + 16..s+15 SGN_CKSUM Checksum of plaintext padded data, + calculated according to algorithm + specified in SGN_ALG field. + s+16..last Data encrypted or plaintext padded data + + Where "s" indicates the size of the checksum. + + As indicated above in section 2, we define the HMAC SHA1 DES3-KD + checksum algorithm to produce a 20-byte output, so encrypted data + begins at byte 36. + +6. Backwards Compatibility Considerations + + The context initiator SHOULD request of the KDC credentials using + session-key cryptosystem types supported by that implementation; if + the only types returned by the KDC are not supported by the + mechanism implementation, it MUST indicate a failure. This may + seem obvious, but early implementations of both Kerberos and the + GSSAPI Kerberos mechanism supported only DES keys, so the + cryptosystem compatibility question was easy to overlook. + + Under the current mechanism, no negotiation of algorithm types + occurs, so server-side (acceptor) implementations cannot request + that clients not use algorithm types not understood by the server. + However, administration of the server's Kerberos data has to be + done in communication with the KDC, and it is from the KDC that the + client will request credentials. The KDC could therefore be tasked + with limiting session keys for a given service to types actually + supported by the Kerberos and GSSAPI software on the server. + + This does have a drawback for cases where a service principal name + is used both for GSSAPI-based and non-GSSAPI-based communication, + if the GSSAPI implementation does not understand triple-DES but the + Kerberos implementation does. It means that triple-DES session + keys cannot be issued for that service principal, which keeps the + protection of non-GSSAPI services weaker than necessary. However, + in the most recent MIT releases thus far, while triple-DES support + has been present, it has required additional work to enable, so it + is not likely to be in use for many services. + + It would also be possible to have clients attempt to get single-DES + session keys before trying to get triple-DES session keys, and have + the KDC refuse to issue the single-DES keys only for the most + critical of services, for which single-DES protection is considered + inadequate. However, that would eliminate the possibility of + connecting with the more secure cryptosystem to any service that + can be accessed with the weaker cryptosystem. + + We have chosen to go with the former approach, putting the burden + on the KDC administration and gaining the best protection possible + for GSSAPI services, possibly at the cost of protection of + non-GSSAPI Kerberos services running earlier versions of the + software. + +6. Security Considerations + + Various tradeoffs arise regarding the mixing of new and old + software, or GSSAPI-based and non-GSSAPI Kerberos authentication. + They are discussed in section 5. + +7. References + + [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of + Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & + Associates, Inc., May, 1998. + + [GSSAPI] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January, 2000. + + [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June, 1996. + + [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", + draft-ietf-cat-kerberos-revisions-05.txt, March 10, 2000. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", RFC 2026, October, 1996. + +8. Author's Address + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." diff --git a/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt b/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt new file mode 100644 index 000000000000..64ca1ac498be --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt @@ -0,0 +1,395 @@ + + + + + + +Kerberos Working Group K. Raeburn +Category: Informational MIT +Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt November 24, 2000 + + + Triple-DES Support for the Kerberos 5 GSSAPI Mechanism + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. Internet-Drafts are + draft documents valid for a maximum of six months and may be updated, + replaced, or obsoleted by other documents at any time. It is + inappropriate to use Internet-Drafts as reference material or to cite + them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] specifically + enumerates encryption and checksum types, independently of how such + schemes may be used in Kerberos. In the long run, a new Kerberos- + based mechanism, which does not require separately enumerating for + the GSSAPI mechanism each of the various encryption types defined by + Kerberos, is probably a better approach. Various people have + expressed interest in designing one, but the work has not yet been + completed. + + The MIT Kerberos 5 release version 1.2 includes support for triple- + DES with key derivation [KrbRev]. Recent work by the EFF [EFF] has + demonstrated the vulnerability of single-DES mechanisms to brute- + force attacks by sufficiently motivated and well-funded parties. So, + in the interest of providing increased security in the near term, MIT + is adding support for triple-DES to the existing mechanism + implementation we ship, as an interim measure. + + + + + + + + +Raeburn [Page 1] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + +2. New Algorithm Identifiers + + One new sealing algorithm is defined, for use in Wrap tokens. + + + +--------------------------------------------------------------------+ + | name octet values | + +--------------------------------------------------------------------+ + | DES3-KD 02 00 | + +--------------------------------------------------------------------+ + + This algorithm uses triple-DES with key derivation, with a usage + value KG_USAGE_SEAL. (Unlike the EncryptedData definition in + [KrbRev], no integrity protection is needed, so this is "raw" triple- + DES, with no checksum attached to the encrypted data.) Padding is + still to 8-byte multiples, and the IV for encrypting application data + is zero. + + One new signing algorithm is defined, for use in MIC, Wrap, and + Delete tokens. + + + +--------------------------------------------------------------------+ + | name octet values | + +--------------------------------------------------------------------+ + | HMAC SHA1 DES3-KD 04 00 | + +--------------------------------------------------------------------+ + + This algorithm generates an HMAC using SHA-1 and a derived DES3 key + with usage KG_USAGE_SIGN, as described in [KrbRev]. + + [N.B.: The current [KrbRev] description refers to expired I-Ds from + Marc Horowitz. The text in [KrbRev] may be inadequate to produce an + interoperable implementation.] + + The checksum size for this algorithm is 20 octets. See section 4.3 + below for the use of checksum lengths of other than eight bytes. + + + + + + + + + + + + + + +Raeburn [Page 2] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + +3. Key Derivation + + For purposes of key derivation, we add three new usage values to the + list defined in [KrbRev]; one for signing messages, one for sealing + messages, and one for encrypting sequence numbers: + + + +--------------------------------------------------------------------+ + | name value | + +--------------------------------------------------------------------+ + | KG_USAGE_SEAL 22 | + | KG_USAGE_SIGN 23 | + | KG_USAGE_SEQ 24 | + +--------------------------------------------------------------------+ + +4. Adjustments to Previous Definitions + +4.1. Quality of Protection + + The GSSAPI specification [GSSAPI] says that a zero QOP value + indicates the "default". The original specification for the Kerberos + 5 mechanism says that a zero QOP value (or a QOP value with the + appropriate bits clear) means DES encryption. + + Rather than forcing the use of plain DES when the application doesn't + use mechanism-specific QOP values, we redefine the explicit DES QOP + value as a non-zero value, and define a triple-DES value as well. + Then a zero value continues to imply the default, which would be + triple-DES protection when given a triple-DES session key. + + Our values are: + + +--------------------------------------------------------------------+ + | name value meaning | + +--------------------------------------------------------------------+ + | GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 SHA-1 HMAC, using | + | key derivation | + | | + | GSS_KRB5_CONF_C_QOP_DES 0x0100 plain DES encryption | + | | + | GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200 triple-DES with key | + | derivation | + +--------------------------------------------------------------------+ + + Rather than attempt to specify a generic mechanism for deriving a key + of one type given a key of another type, and evaluate the security + implications of using a short key to generate a longer key to satisfy + the requested quality of protection, our implementation will simply + + + +Raeburn [Page 3] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + + return an error if the nonzero QOP value specified does not + correspond to the session key type. + +4.2. MIC Sequence Number Encryption + + The sequence numbers are encrypted in the context key (as defined in + [GSSAPI-KRB5] -- this will be either the Kerberos session key or + asubkey provided by the context initiator), using whatever encryption + system is designated by the type of that context key. The IV is + formed from the first N bytes of the SGN_CKSUM field, where N is the + number of bytes needed for the IV. (With all algorithms described + here and in [GSSAPI-KRB5], the checksum is at least as large as the + IV.) + +4.3. Message Layout + + Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an + checksum field SGN_CKSUM. In [GSSAPI-KRB5], this field was specified + as being 8 bytes long. We now change this size to be "defined by the + checksum algorithm", and retroactively amend the descriptions of all + the checksum algorithms described in [GSSAPI-KRB5] to explicitly + specify 8-byte output. Application data continues to immediately + follow the checksum field in the Wrap token. + + The revised message descriptions are thus: + + MIC token: + + Byte # Name Description + ---------------------------------------------------------------------- + 0..1 TOK_ID Identification field. + 2..3 SGN_ALG Integrity algorithm indicator. + 4..7 Filler Contains ff ff ff ff + 8..15 SND_SEQ Sequence number field. + 16..s+15 SGN_CKSUM Checksum of "to-be-signed + data", calculated according to + algorithm specified in SGN_ALG + field. + + + + + + + + + + + + + +Raeburn [Page 4] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + + Wrap token: + + Byte # Name Description + ---------------------------------------------------------------------- + 0..1 TOK_ID Identification field. Tokens + emitted by GSS_Wrap() contain the + hex value 02 01 in this field. + 2..3 SGN_ALG Checksum algorithm indicator. + 4..5 SEAL_ALG Sealing algorithm indicator. + 6..7 Filler Contains ff ff + 8..15 SND_SEQ Encrypted sequence number field. + 16..s+15 SGN_CKSUM Checksum of plaintext padded data, + calculated according to algorithm + specified in SGN_ALG field. + s+16..last Data encrypted or plaintext padded data + + + Where "s" indicates the size of the checksum. + + As indicated above in section 2, we define the HMAC SHA1 DES3-KD + checksum algorithm to produce a 20-byte output, so encrypted data + begins at byte 36. + +5. Backwards Compatibility Considerations + + The context initiator should request of the KDC credentials using + session-key cryptosystem types supported by that implementation; if + the only types returned by the KDC are not supported by the mechanism + implementation, it should indicate a failure. This may seem obvious, + but early implementations of both Kerberos and the GSSAPI Kerberos + mechanism supported only DES keys, so the cryptosystem compatibility + question was easy to overlook. + + Under the current mechanism, no negotiation of algorithm types + occurs, so server-side (acceptor) implementations cannot request that + clients not use algorithm types not understood by the server. + However, administration of the server's Kerberos data (e.g., the + service key) has to be done in communication with the KDC, and it is + from the KDC that the client will request credentials. The KDC could + therefore be tasked with limiting session keys for a given service to + types actually supported by the Kerberos and GSSAPI software on the + server. + + This does have a drawback for cases where a service principal name is + used both for GSSAPI-based and non-GSSAPI-based communication (most + notably the "host" service key), if the GSSAPI implementation does + not understand triple-DES but the Kerberos implementation does. It + means that triple-DES session keys cannot be issued for that service + + + +Raeburn [Page 5] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + + principal, which keeps the protection of non-GSSAPI services weaker + than necessary. + + It would also be possible to have clients attempt to get single-DES + session keys before trying to get triple-DES session keys, and have + the KDC refuse to issue the single-DES keys only for the most + critical of services, for which single-DES protection is considered + inadequate. However, that would eliminate the possibility of + connecting with the more secure cryptosystem to any service that can + be accessed with the weaker cryptosystem. + + For MIT's 1.2 release, we chose to go with the former approach, + putting the burden on the KDC administration and gaining the best + protection possible for GSSAPI services, possibly at the cost of + weaker protection of non-GSSAPI Kerberos services running earlier + versions of the software. + +6. Security Considerations + + Various tradeoffs arise regarding the mixing of new and old software, + or GSSAPI-based and non-GSSAPI Kerberos authentication. They are + discussed in section 5. + +7. References + + [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of + Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & + Associates, Inc., May, 1998. + + [GSSAPI] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January, 2000. + + [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June, 1996. + + [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos- + revisions-06.txt, July 4, 2000. + +8. Author's Address + + Kenneth Raeburn Massachusetts Institute of Technology 77 + Massachusetts Avenue Cambridge, MA 02139 + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + + + +Raeburn [Page 6] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +10. Document Change History + +>From -00 to -01: + + Converted master to GNU troff and tbl, rewriting tables in the + process. + + Specify informational category only. Modify some text to emphasize + that this document intends to describe MIT's extensions. + + Point out that while EncryptedData for 3des-kd includes a checksum, + DES3-KD GSS encryption does not. + + Shorten backwards-compatibility descriptions a little. + + Submit to Kerberos working group rather than CAT. + + + + + + + + + + + +Raeburn [Page 7] + diff --git a/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt b/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt new file mode 100644 index 000000000000..321c5ba09986 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt @@ -0,0 +1,929 @@ + + +DHC Working Group S. Medvinsky +Internet Draft Motorola +Document: <draft-smedvinsky-dhc-kerbauth-01.txt> +Category: Standards Track P.Lalwaney +Expires: January 2001 Nokia + + July 2000 + + + Kerberos V Authentication Mode for Uninitialized Clients + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of + six months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + The distribution of this memo is unlimited. It is filed as <draft- + smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please + send comments to the authors. + + + +1. Abstract + + The Dynamic Host Configuration Protocol (DHCP) [1] includes an + option that allows authentication of all DHCP messages, as specified + in [2]. This document specifies a DHCP authentication mode based on + Kerberos V tickets. This provides mutual authentication between a + DHCP client and server, as well as authentication of all DHCP + messages. + + This document specifies Kerberos message exchanges between an + uninitialized client and the KDC (Key Distribution Center) using an + IAKERB proxy [7] so that the Kerberos key management phase is + decoupled from, and precedes the address allocation and network + configuration phase that uses the DHCP authentication option. In + order to make use of the IAKERB proxy, this document specifies a + transport mechanism that works with an uninitialized client (i.e. a + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + client without an assigned IP address). In addition, the document + specifies the format of the Kerberos authenticator to be used with + the DHCP authentication option. + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119. + +3. Introduction + + 3.1 Terminology + + o "DHCP client" + + A DHCP client is an Internet host using DHCP to obtain configuration + parameters such as a network address. + + o "DHCP server" + + A DHCP server is an Internet host that returns configuration + parameters to DHCP clients. + + O "Ticket" + + A Kerberos term for a record that helps a client authenticate itself + to a server; it contains the client's identity, a session key, a + timestamp, and other information, all sealed using the server's + secret key. It only serves to authenticate a client when presented + along with a fresh Authenticator. + + o "Key Distribution Center" + + Key Distribution Center, a network service that supplies tickets and + temporary session keys; or an instance of that service or the host + on which it runs. The KDC services both initial ticket and Ticket- + Granting Ticket (TGT) requests. The initial ticket portion is + sometimes referred to as the Authentication Server (or service. The + Ticket-Granting Ticket portion is sometimes referred to as the + Ticket-Granting Server (or service). + + o "Realm" + + A Kerberos administrative domain that represents a group of + principals registered at a KDC. A single KDC may be responsible for + one or more realms. A fully qualified principal name includes a + realm name along with a principal name unique within that realm. + +3.2 Protocol Overview + + + +S. Medvinsky, P. Lalwaney -2- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + DHCP as defined in [1] defines the protocol exchanges for a client + to obtain its IP address and network configuration information from + a DHCP Server. Kerberos V5 as described in [6] defines the protocol + and message exchanges to mutually authenticate two parties. It is + our goal to provide authentication support for DHCP using Kerberos. + This implies that the Kerberos key management exchange has to take + place before a client gets its IP address from the DHCP Server. + Kerberos assumes that the client has a network address and can + contact the Key Distribution Center to obtain its credentials for + authenticated communication with an application server. + + In this specification we utilize the key exchange using an IAKERB + proxy described in [7]. This does not require any changes to either + the IAKERB or the Kerberos V5 specification. This document also + specifies a particular transport that allows an uninitialized client + to contact an IAKERB proxy. + + The Kerberos ticket returned from the key management exchange + discussed in Section 5 of this document is passed to the DHCP Server + inside the DHCP authentication option with the new Kerberos + authenticator type. This is described in Section 6 of this draft. + + +3.3 Related Work + + A prior Internet Draft [3] outlined the use of Kerberos-based + authentication for DHCP. The proposal tightly coupled the Kerberos + client state machines and the DHCP client state machines. As a + result, the Kerberos key management messages were carried in DHCP + messages, along with the Kerberos authenticators. In addition, the + first DHCP message exchange (request, offer) is not authenticated. + + We propose a protocol exchange where Kerberos key management is + decoupled from and precedes authenticated DHCP exchanges. This + implies that the Kerberos ticket returned in the initial key + management exchange could be used to authenticate servers assigning + addresses by non-DHCP address assignment mechanisms like RSIP [4] + and for service specific parameter provisioning mechanisms using SLP + [5]. + + + + + + + + + + + + + + +S. Medvinsky, P. Lalwaney -3- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + +4. System Architecture + + + Client + -------- -------- + | | 5.Authenticated DHCP | | + | DHCP |<------------------------>| DHCP | + | client | | server | + | | | | + | | | | + |Kerberos| | | + | Client | | | + -------- -------- + ^ + | + | + | + | ------- + ------------------------------>| | + Kerberos Key Mgmt | Proxy | + messages: | | + 1. AS Request / 2.AS Reply ------- + 3. TGS Request / 4.TGS Reply ^ + | Kerberos + | Key Mgmt messages + v (1, 2, 3, 4) + -------- + | | + | KDC | + | | + -------- + + Figure 1: System blocks and message interactions between them + + + In this architecture, the DHCP client obtains a Kerberos ticket from + the Key Distribution Center (KDC) using standard Kerberos messages, + as specified in [6]. The client, however, contacts the KDC via a + proxy server, according to the IAKERB mechanism, described in [7]. + The are several reasons why a client has to go through this proxy in + order to contact the KDC: + + a)The client may not know the host address of the KDC and may be + sending its first request message as a broadcast on a local + network. The KDC may not be located on the local network, and + even if it were - it will be unable to communicate with a client + without an IP address. This document describes a specific + mechanism that may be used by a client to communicate with the + Kerberos proxy. + + + +S. Medvinsky, P. Lalwaney -4- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + b)The client may not know its Kerberos realm name. The proxy is + able to fill in the missing client realm name in an AS Request + message, as specified in IAKERB. Note that in the case that + PKINIT pre-authenticator is used [8], the realm name in the AS + Request may be the KDC realm name and not the clientÆs realm name. + + c) The client does not know the realm name of the DHCP server. + + According to IAKERB, when the client sends a TGS Request with a + missing server realm name, the proxy will return to the client an + error message containing the missing realm name. + + Note that in this case the proxy could return the client a wrong + realm name and the client could be fooled into obtaining a ticket + for the wrong DHCP server (on the same local network). However, + the wrong DHCP server must still be a registered principal in a + KDC database. In some circumstances this may be an acceptable + compromise. Also, see the security considerations section. + + IAKERB describes the proxy as part of an application server - the + DHCP server in this case. However, in this document we are not + requiring the proxy to be integrated with the DHCP server. The + same IAKERB mechanisms apply in the more general case, where the + proxy is an independent application. This proxy, however, MUST be + reachable by a client via a local network broadcast. + + After a client has obtained a Kerberos ticket for the DHCP server, + it will use it as part of an authentication option in the DHCP + messages. The only extension to the DHCP protocol is the addition + of a new authenticator type based on Kerberos tickets. + +4.1 Cross-Realm Authentication + + Figure 1 shows a client communicating with a single KDC via a proxy. + However, the DHCP clientÆs realm may be different from the DHCP + serverÆs realm. In that case, the client may need to first contact + the KDC in its local realm to obtain a cross-realm TGT. Then, the + client would use the cross-realm TGT to contact the KDC in the DHCP + serverÆs realm, as specified in [6]. + + In the following example a client doesnÆt know its realm or the DHCP + serverÆs realm, which happens to be different from the clientÆs + realm. Here are the steps in obtaining the ticket for the DHCP + server (based on [6] and [7]): + + 1) The client sends AS Request with NULL realm to the proxy. + 2) The proxy fills in the realm and forwards the AS Request to + the KDC in the clientÆs realm. + 3) The KDC issues a TGT and sends back an AS Reply to the + proxy. + 4) The proxy forwards AS Reply to the client. + + +S. Medvinsky, P. Lalwaney -5- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + 5) The client sends TGS Request for a principal name "dhcpsrvr" + with NULL realm to the proxy. + 6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the + DHCP serverÆs realm to the client. + 7) The client sends another TGS Request for a cross-realm TGT + to the proxy. + 8) The proxy forwards the TGS Request to the KDC in the + clientÆs realm. + 9) The KDC issues a cross-realm TGT and sends back a TGS Reply + to the proxy. + 10) The proxy forwards TGS Reply to the client. + 11) The client sends a TGS Request to the proxy for a principal + "dhcpsrvr" with the realm name filled in, using a cross-realm + TGT. + 12) The proxy forwards TGS Request to the KDC in the DHCP + server's realm. + 13) The KDC issues a ticket for the DHCP server and sends TGS + Reply back to the proxy. + 14) The proxy forwards TGS Reply to the client. + + In a most general case, the client may need to contact any number of + KDCs in different realms before it can get a ticket for the DHCP + server. In each case, the client would contact a KDC via the proxy + server, as specified in Section 5 of this document. + +4.2 Public Key Authentication + + This specification also allows clients to perform public key + authentication to the KDC, based on the PKINIT specification [8]. + In this case, the size of an AS Request and AS Reply messages is + likely to exceed the size of typical link MTU's. + + Here is an example, where PKINIT is used by a DHCP client that is + not a registered principal in the KDC principal database: + + 1) The client sends AS Request with a PKINIT Request pre- + authenticator to the proxy. This includes the clientÆs + signature and X.509 certificate. The KDC realm field is + left as NULL. + 2) The proxy fills in the realm and forwards the AS Request to + the KDC in the filled in realm. This is the realm of the + DHCP server. Here, the clientÆs realm is the name of a + Certification Authority - not the same as the KDC realm. + 3) The KDC issues a TGT and sends back an AS Reply with a + PKINIT Reply pre-authenticator to the proxy. + 4) The proxy forwards the AS Reply to the client. + 5) The client sends TGS Request for a principal name "dhcpsrvr" + with the realm found in the TGT to the proxy. + 6) The proxy forwards TGS Request to the KDC in the DHCP + serverÆs realm. + 7) The KDC issues a ticket for the DHCP server and sends TGS + Reply back to the proxy. + +S. Medvinsky, P. Lalwaney -6- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + 8) The proxy forwards TGS Reply to the client. + + + 5. Key Management Exchange that Precedes Network Address Allocation + + An uninitialized host (e.g. on power-on and reset) does not have a + network address. It does have a link layer address or hardware + address. At this time, the client may not have any information on + its realm or the realm of the address allocation server (DHCP + Server). + + In the Kerberos key management exchange, a client gets its ticket + granting ticket (TGT) by contacting the Authentication Server in the + KDC using the AS_Request / Reply messages (shown as messages 1 and 2 + in Figure 1). The client then contacts the Ticket Granting Server in + the KDC to get the DHCP server ticket (to be used for mutual + authentication with the DHCP server) using the TGS_REQ / TGS_REP + messages (shown as messages 3 and 4 in the above figure). It is + also possible for the client to obtain a DHCP server ticket directly + with the AS Request / Reply exchange, without the use of the TGT. + + In the use of Kerberos for DHCP authentication, the client (a) does + not have an IP/network address (b) does not know he KDCÆs IP address + (c) the KDC may not be on the local network and (d) the client may + not know the DHCP ServerÆs IP address and realm. We therefore + require a Kerberos proxy on the local network to accept broadcast + Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized + clients and relay them to the appropriate KDC. + + The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as + follows: + + The request payload contains the client hardware address in + addresses field with a negative value for the address type. Kerberos + v5 [6] allows for the usage of negative address types for "local" + use. Note that IAKERB [7] discourages the use of the addresses field + as network addresses may not be known or may change in situation + where proxies are used. In this draft we incorporate the negative + values permitted in the Kerberos transport in the address type field + of both the AS_REQ and TGS_REQ messages. The negative value SHOULD + be the negative number of the hardware address type "htype" value + (from assigned numbers RFC) used in RFC 2131. The address field of + the message contains the clients hardware address. + + The request payload is UDP encapsulated and addressed to port 88 on + the server/proxy. The UDP source port is selected by the client. The + source and destination network addresses are the all-zeroÆs address + and the broadcast address, respectively. For IPv4, the source IP + address is set to 0.0.0.0 and the destination IP address is set to + 255.255.255.255. The data link layer header source address + corresponds to the link layer/hardware address of the client. The + + +S. Medvinsky, P. Lalwaney -7- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + destination link layer address is the broadcast address at the link + layer (e.g. for Ethernet the address is ffffffff). + + In the case where AS_REQ message contains a PKINIT pre-authenticator + for public key-based client authentication (based on [8]), the + message will probably not fit into a single UDP packet given typical + link MTU's. + + It is assumed that the proxy server on a network is configured with + a list of KDCÆs, their realms and their IP addresses. The proxy + server will act as a client to the KDC and forward standard Kerberos + messages to/from the KDC using unicast UDP or TCP transport + mechanisms, according to [6]. + + Upon receiving a broadcast request from a client, the proxy MUST + record the clientÆs hardware address that appears as the source + address on the frame as well as in the addresses field of the + request message. Based on the realm of the KDC specified in the + request, the proxy determines the KDC to which this message is + relayed as a unicast message from the proxy to the KDC. In the case + that the client left the KDC realm name as NULL, it is up to the + proxy to first determine the correct realm name and fill it in the + request (according to [7]). + + On receiving a request, the KDC formulates a response (AS_REP or + TGS_REP). It includes the clientÆs addresses field in the encrypted + part of the ticket (according to [6]). This response is unicast to + the proxy. + + Upon receiving the reply, the proxy MUST first determine the + previously saved hardware address of the client. The proxy + broadcasts the reply on its local network. This is a network layer + broadcast. At the link level, it uses the hardware address obtained + from the addresses field of the request. + + The client on receiving the response (link layer destination address + as its hardware address, network layer address is the broadcast + address) must verify that the hardware address in the ticket + corresponds to its link layer address. + + Upon receiving a TGS_REP (or an AS_REP with the application server + ticket) from the proxy, the client will have enough information to + securely communicate with the application server (the DHCP Server in + this case), as specified in the following section. + + + + + + + + + +S. Medvinsky, P. Lalwaney -8- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + 6. Authenticated Message Exchange Between the DHCP Client and the + DHCP Server + + The ticket returned in the TGS response is used by the DHCP client + in the construction of the Kerberos authenticator. The Kerberos + ticket serves two purposes: to establish a shared session key with + the DHCP server, and is also included as part of a Kerberos + authenticator in the DHCP request. + + If the size of the authenticator is greater than 255 bytes, the DHCP + authentication option is repeated multiple times. When the values + of all the authentication options are concatenated together, they + will make up the complete authenticator. + + Once the session key is established, the Kerberos structure + containing the ticket (AP REQ) can be omitted from the authenticator + for subsequent messages sent by both the DHCP client and the DHCP + server. + + The Kerberos authenticator for a DHCP request message is specified + below: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Length | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Replay Detection (64 bits) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Authentication token (n octets) ... + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The format of this authenticator is in accordance with [2]. The code + for the authentication option is TBD, and the length field contains + the length of the remainder of the option, starting with the + protocol field. + + The value of the protocol field for this authenticator MUST be set + to 2. + + The algorithm field MUST take one of the following values: + 1 - HMAC-MD5 + 2 - HMAC-SHA-1 + + Replay protection field is a monotonically increasing counter field. + When the Kerberos AP REQ structure is present in the authenticator + the counter may be set to any value. The AP REQ contains its own + replay protection mechanism in the form of a timestamp. + +S. Medvinsky, P. Lalwaney -9- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + + Once the session key has been established and the AP REQ is not + included in the authenticator, this field MUST be monotonically + increasing in the messages sent by the client. + + Kerberos authenticator token consists of type-length-value + attributes: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Reserved | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | attribute value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The following attributes are included in the Kerberos authenticator + token: + + Type Attribute Name Value + -------------------------------------------------------------------- + 0 Message Integrity Code Depends on the value of the + algorithm field. Its length is + 16 bytes for HMAC-MD5 [9, 10] + and 20 bytes for HMAC-SHA-1 + [11, 10]. The HMAC key must be + derived from Kerberos session + key found in the Kerberos + ticket according to the key + derivation rules in [6]: + + HMAC Key = DK(sess key, + key usage | 0x99) + + Here, DK is defined in [12] and + the key usage value for DHCP is + TBD. + + The HMAC is calculated over the + entire DHCP message. The + Message Integrity Code + attribute MUST be set to all 0s + for the computation of the + HMAC. Because a DHCP relay + agent may alter the values of + the 'giaddr' and 'hops' fields + in the DHCP message, the + contents of those two fields + MUST also be set to zero for + the computation of the HMAC. + Rules specified in Section 3 of + [2] for the exclusion and + +S. Medvinsky, P. Lalwaney -10- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + processing of the relay agent + information are applicable here + too. + + This field MUST always be + present in the Kerberos + authenticator. + + 1 AP_REQ ASN.1 encoding of a Kerberos + AP_REQ message, as specified + in [6]. This MUST be included + by the client when establishing + a new session key. In all + other cases, this attribute + MUST be omitted. + + AP_REQ contains the Kerberos ticket for the DHCP server and also + contains information needed by the DHCP server to authenticate the + client. After verifying the AP_REQ and decrypting the Kerberos + ticket, the DHCP server is able to extract a session key which it + now shares with the DHCP client. + + The Kerberos authenticator token contains its own replay protection + mechanism inside the AP_REQ structure. The AP_REQ contains a + timestamp that must be within an agreed upon time window at the DHCP + server. However, this does not require the DHCP clients to maintain + an accurate clock between reboots. Kerberos allows clients to + synchronize their clock with the KDC with the help of Kerberos + KRB_AP_ERR_SKEW error message, as specified in [6]. + + The DHCP server MUST save both the session key and its associated + expiration time found in the Kerberos ticket. Up until the + expiration time, the server must accept client requests with the + Kerberos authenticator that does not include the AP REQ, using the + saved session key in calculating HMAC values. + + The Kerberos authenticator inside all DHCP server responses MUST NOT + contain the AP REQ and MUST use the saved Kerberos session key in + calculating HMAC values. + + When the session key expires, it is the client's responsibility to + obtain a new ticket from the KDC and to include an AP REQ inside the + Kerberos authenticator for the next DHCP request message. + + + + + + + + + + +S. Medvinsky, P. Lalwaney -11- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + +7. Detailed message flows for Kerberos and DHCP message Exchanges + + The following flow depicts the Kerberos exchange in which a AS REQ + message is used to directly request the DHCP Server ticket. There + are no changes to transport mechanisms below when the additional + phase of using TGS requests/responses with TGTÆs is used. + + Client IAKERB Proxy KDC + + KB-client-------- AS_REQ ------> + + AS REQ Address type = - (htype) + AS REQ Address= hw address + + src UDP port = senders port + destination UDP port = 88 + + src IP = 0.0.0.0 + destination IP = 255.255.255.255 + + src link layer address = + clientÆs HW/link address [e.g Ethernet address] + + destination link layer address = + link broadcast address [e.g. ffffffff for Ethernet] + + + ---------------------------> + (unicast to UDP port 88) + + + + <-------------------------- + (unicast AS REP) + Encrypted portion of ticket + Includes clients HW address + + + <---------------AS_REP ----------- + + + Ticket includes clientÆs hardware address + + src UDP port = 88 + destination UDP port = copied from src port in AS_REQ + + src IP = ProxyÆs IP address + destination IP = 255.255.255.255 + + src link layer address = ProxyÆs HW/link address + destination link layer address = + ClientÆs link layer address from AS_REQ + + +S. Medvinsky, P. Lalwaney -12- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + + + + The client uses the ticket received from the KDC in the DHCP +Authentication option as described in Section 6. + + + Client + DHCP-client DHCP Server + + ------DHCPDISCOVER ----> + (Auth Protocol = 2, includes Kerberos + authenticator with AP REQ ) + ----------------------------------- + | HMAC | AP REQ | + ---------------------------------- + | Ticket| Client Authent | + -------------------------- + + 1. Server decrypts ticket + (inside AP REQ) with service + key + 2. Server decrypts client + authenticator (inside AP REQ) + and checks content and + checksum to validate the + client. + 3. Recompute HMAC with session + key and compare. + + + <-------DHCPOFFER---------- + (Auth Protocol = 2, no AP REQ ) + + + + ---------DHCPREQUEST-------> + (Auth Protocol = 2, no AP REQ) + + + <--------DHCPACK------------- + (Auth Protocol = 2, no AP REQ ) + + + + +8. Security Considerations + + DHCP clients that do not know the DHCP serverÆs realm name will get + it from the proxy, as specified in IAKERB [7]. Since the proxy is + not authenticated, a DHCP client can be fooled into obtaining a + ticket for the wrong DHCP server in the wrong realm. + +S. Medvinsky, P. Lalwaney -13- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + + This could happen when the client leaves out the server realm name + in a TGS Request message to the proxy. It is also possible, + however, for a client to directly request a DHCP server ticket with + an AS Request message. In those cases, the same situation occurs + when the client leaves out the realm name in an AS Request. + + This wrong DHCP server is still registered as a valid principal in a + database of a KDC that can be trusted by the client. In some + circumstances a client may assume that a DHCP server that is a + Kerberos principal registered with a trusted KDC will not attempt to + deliberately misconfigure a client. + + This specification provides a tradeoff between: + + 1) The DHCP clients knowing DHCP serverÆs realm ahead of time, + which provides for full 2-way authentication at the cost of + an additional configuration parameter. + 2) The DHCP clients not requiring any additional configuration + information, besides a password or a key (and a public key + certificate if PKINIT is used). This is at the cost of not + being able to fully authenticate the identity of the DHCP + server. + + + +9. References + + + [1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol", + RFC 2131, Bucknell University, March 1997. + + [2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages", + draft-ietf-dhc-authentication-13.txt, June 2000. + + [3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V", + draft-hornstein-dhc-kerbauth-02.txt, February 2000. + + [4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm + Specific IP: Protocol Specification ", draft-ietf-nat-rsip- + protocol-06.txt, March 2000. + + [5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service + Location Protocol, Version 2", RFC 2608, June 1999. + + [6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- + 05.txt, March 2000. + + + + + +S. Medvinsky, P. Lalwaney -14- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + + [7]Swift, M., Trostle, J., "Initial Authentication and Pass Through + Authentication Using Kerberos V5 and the GSS-API (IAKERB)", + draft-ietf-cat-iakerb-03.txt, September 1999. + + [8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, + J. Trostle, "Public Key Cryptography for Initial Authentication + in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000. + + [9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for + Message Authentication," RFC 2104, February 1997. + + [11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995. + + [12]Horowitz, M., "Key Derivation for Authentication, Integrity, and + Privacy", draft-horowitz-key-derivation-02.txt, August 1998. + + [13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC + 2026. + + + + 10. Author's Addresses + + Sasha Medvinsky + Motorola + 6450 Sequence Drive + San Diego, CA 92121 + Email: smedvinsky@gi.com + + Poornima Lalwaney + Nokia + 12278 Scripps Summit Drive + San Diego, CA 92131 + Email: poornima.lalwaney@nokia.com + + +11. Expiration + + This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and + expires January 1, 2001. + + + +12. Intellectual Property Notices + + + + + + +S. Medvinsky, P. Lalwaney -15- + +Kerberos V Authentication Mode for Uninitialized Clients March 2000 + + + This section contains two notices as required by [13] for + standards track documents. Per [13], section 10.4(A): + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances + of licenses to be made available, or the result of an attempt made + to obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification + can be obtained from the IETF Secretariat. + + Per [13] section 10.4(D): + + The IETF has been notified of intellectual property rights + claimed in regard to some or all of the specification contained in + this document. For more information consult the online list of + claimed rights. + + 13. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. The limited permissions granted above are perpetual and + will not be revoked by the Internet Society or its successors or + assigns. This document and the information contained herein is + provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + +S. Medvinsky, P. Lalwaney -16- +
\ No newline at end of file diff --git a/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt new file mode 100644 index 000000000000..85d745684b2a --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on July 17, 2000. diff --git a/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt new file mode 100644 index 000000000000..85d745684b2a --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on July 17, 2000. diff --git a/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt b/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt new file mode 100644 index 000000000000..68c170b499ed --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt @@ -0,0 +1,1140 @@ + + + + + + +INTERNET-DRAFT Kerberized USM Keying M. Thomas + Cisco Systems + K. McCloghrie + Cisco Systems + July 13, 2000 + + + + + + + Kerberized USM Keying + + draft-thomas-snmpv3-kerbusm-00.txt + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Abstract + + The KerbUSM MIB provides a means of leveraging a trusted third party + authentication and authorization mechanism using Kerberos for SNMP V3 + USM users and their associated VACM views. The MIB encodes the normal + Kerberos AP-REQ and AP-REP means of both authenticating and creating + a shared secret between the SNMP V3 Manager and Agent. + +The SNMP Management Framework + + The SNMP Management Framework presently consists of five major + components: An overall architecture, described in RFC 2571 + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 1] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + [RFC2571]. Mechanisms for describing and naming objects and events + for the purpose of management. The first version of this Structure + of Management Information (SMI) is called SMIv1 and described in STD + 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 + [RFC1215]. The second version, called SMIv2, is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. Message protocols for transferring management + information. The first version of the SNMP message protocol is + called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second + version of the SNMP message protocol, which is not an Internet + standards track protocol, is called SNMPv2c and described in RFC 1901 + [RFC1901] and RFC 1906 [RFC1906]. The third version of the message + protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC + 2572 [RFC2572] and RFC 2574 [RFC2574]. Protocol operations for + accessing management information. The first set of protocol + operations and associated PDU formats is described in STD 15, RFC + 1157 [RFC1157]. A second set of protocol operations and associated + PDU formats is described in RFC 1905 [RFC1905]. A set of fundamental + applications described in RFC 2573 [RFC2573] and the view-based + access control mechanism described in RFC 2575 [RFC2575]. + + A more detailed introduction to the current SNMP Management Framework + can be found in RFC 2570 [RFC2570]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. Objects in the MIB are + defined using the mechanisms defined in the SMI. + + This memo specifies a MIB module that is compliant to the SMIv2. A + MIB conforming to the SMIv1 can be produced through the appropriate + translations. The resulting translated MIB must be semantically + equivalent, except where objects or events are omitted because no + translation is possible (use of Counter64). Some machine readable + information in SMIv2 will be converted into textual descriptions in + SMIv1 during the translation process. However, this loss of machine + readable information is not considered to change the semantics of the + MIB. + + +Introduction + + The User based Security Model of SNMP V3 (USM) [2] provides a means + of associating different users with different access privileges of + the various MIB's that an agent supports. In conjunction with the + View based Access Control Model of SNMP V3 (VACM) [3], SNMP V3 + provides a means of providing resistance from various threats both + from outside attacks such as spoofing, and inside attacks such as an + user having, say, SET access to MIB variable for which they are not + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 2] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + authorized. + + SNMP V3, unfortunately, does not specify a means of doing key + distribution between the managers and the agents. For small numbers + of agents and managers, the O(n*m) manual keying is a cumbersome, but + possibly tractable problem. For a large number of agents with + distribution of managers, the key distribution quickly goes from + cumbersome to unmanageable. Also: there is always the lingering + concern of the security precautions taken for keys on either local + management stations, or even directories. + + Kerberos [1] provides a means of centralizing key management into an + authentication and authorization server known as a Key Distribution + Center (KDC). At a minimum, Kerberos changes the key distribution + problem from a O(n*m) problem to a O(n) problem since keys are shared + between the KDC and the Kerberos principals rather directly between + each host pair. Kerberos also provides a means to use public key + based authentication which can be used to further scale down the + number of pre-shared secrets required. Furthermore, a KDC is intended + and explicitly expected to be a standalone server which is managed + with a much higher level of security concern than a management + station or even a central directory which may host many services and + thus be exposed to many more possible vectors of attack. + + The MIB defined in this memo describes a means of using the desirable + properties of Kerberos within the context of SNMP V3. Kerberos + defines a standardized means of communicating with the KDC as well as + a standard format of Kerberos tickets which Kerberos principals + exchange in order to authenticate to one another. The actual means of + exchanging tickets, however, is left as application specific. This + MIB defines the SNMP MIB designed to transport Kerberos tickets and + by doing so set up SNMP V3 USM keys for authentication and privacy. + + It should be noted that using Kerberos does introduce reliance on a + key network element, the KDC. This flies in the face of one of SNMP's + dictums of working when the network is misbehaving. While this is a + valid concern, the risk of reliance on the KDC can be significantly + diminished with a few common sense actions. Since Kerberos tickets + can have long life times (days, weeks) a manager of key network + elements can and should maintain Kerberos tickets well ahead ticket + expiration so that likelihood of not being able to rekey a session + while the network is misbehaving is minimized. For non-critical, but + high fanout elements such as user CPE, etc, requiring a pre-fetched + ticket may not be practical, which puts the KDC into the critical + path. However, if all KDC's are unreachable, the non-critical network + elements are probably the least of the worries. + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 3] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + +Operation + + The normal Kerberos application ticket exchange is accomplished by a + client first fetching a service ticket from a KDC for the service + principal and then sending an AP-REQ to a server to authenticate + itself to the server. The server then sends a AP-REP to finish the + exchange. This MIB maps Kerberos' concept of client and server into + the SNMP V3 concept of Manager and Agent by designating that the + Kerberos Client is the SNMP V3 Agent. Although it could be argued + that an Agent is really a server, in practice there may be many, many + agents and relatively few managers. Also: Kerberos clients may make + use of public key authentication as defined in [4], and it is very + advantageous to take advantage of that capability for Agents rather + than Managers. + + The MIB is intended to be stateless and map USM users to Kerberos + principals. This mapping is explicitly done by putting a Kerberos + principal name into the usmUserSecurityName in the usmUser MIB and + instatiating the krbUsmMibEntry for the usmUserEntry. MIB variables + are accessed with INFORM's or TRAP PDU's and SET's to perform a + normal Kerberos AP-REQ/AP-REP exchange transaction which causes the + keys for a USM user to be derived and installed. The basic structure + of the MIB is a table which augements usmUserEntry's with a Kerberos + principal name as well as the transaction varbinds. In the normal + case, multiple varbinds should be sent in a single PDU which prevents + various race conditions, as well as increasing efficiency. + + It should be noted that this MIB is silent on the subject of how the + Agent and Manager find the KDC. In practice, this may be either + statically provisioned or use either DNS SRV records (RFC 2782) or + Service Location (RFC 2608). This MIB is does not provide for a means + of doing cipher suite negotiation either. It is expected that the + choices for ciphers in the USM MIB will reflect site specific choices + for ciphers. This matches well with the general philosophy of + centralized keying. + +Keying Transactions + + The following shows an error free transaction: + + Note: optional steps or parameters are shown like [ ] + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 4] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + + Agent Manager KDC + +-- --+ + | 1) <------------------------------- | + | SET (krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx; | + | [ krbUsmPrinTable[usmUserName].krbUsmMibTgt = | + | TGT[usmUserSecurityName] ]); | + | | + | 2) -------------------------------> | + | Response | + +-- (optional) --+ + + 3) ---------------------------------------------------------------> + TGS-REQ (krbUsmPrinTable[usmUserName].krbUsmMibMgrPrinName + [, krbUsmPrinTable[usmUserName].krbUsmMibTgt]); + + 4) <-------------------------------------------------------------- + Tick[usmUserSecurityName] = TGS-REP (); + + 5) ------------------------------> + INFORM (krbUsmPrinTable[usmUserName].krbUsmMibApReq = + AP_REQ[Tick[usmUserSecurityName]]; + [ krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx]); + + 6) <------------------------------ + SET (krbUsmPrinTable[usmUserName].krbUsmMibApRep = AP_REP[]); + + + 7) ------------------------------> + Response + + + The above flow translates to: + + + 1) This step is used when the Manager does not currently have a ses- + sion with the Agent but wishes to start one. The Manager MAY + place a ticket granting ticket into the krbUsmMibMgrTgt varbind + in the same PDU as the krbUsmMibNonce if it does not share a + secret with the KDC (as would be the case if the Manager used + PKinit to do initial authentication with the KDC). + + + 2) This step acknowledges the SET. There are no MIB specific errors + which can happen here. + + + 3) If the Agent is not already in possession of a service ticket for + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 5] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + the Manager in its ticket cache, it MUST request a service ticket + from the Agent's KDC for the service principal given by + krbUsmMibMgrPrinName in the row that the krbUsmMibNonce was SET + in, optionally adding a krbUsmMibMgrTgt. If the TGT is speci- + fied, the Manager's TGT must be placed in the additional-tickets + field with the ENC-TKT-IN-SKEY option set in the TGS-REQ to + obtain a service ticket (see section 3.3.3 of [1]). + + Note: a Kerberos TGS-REQ is but one way to obtain a service + ticket. An Agent may use any normal Kerberos means to + obtain the service ticket. This flow has also elided ini- + tial authentication (ie, AS-REQ) and any cross realm con- + siderations, though those may be necessary prerequisites + to obtaining the service ticket. + + 4) If step 3 was performed, this step receives the ticket or an + error from the KDC. + + + 5) This step sends a krbUsmMibApReq to the Manager via an INFORM or + TRAP PDU. If the message is the result of a request by the + Manager, krbUsmMibNonce received from the Manager MUST be sent in + the same PDU. If the Manager did not initiate the transaction, + the Agent MUST NOT send a krbUsmMibNonce varbind. The Agent also + MUST check krbUsmMibUnsolicitedNotify is not false, otherwise it + MUST abort the transaction. All krbUsmMibApReq's MUST contain a + sequence nonce so that the resulting krbUsmMibApRep can provide a + proof of the freshness of the message to prevent replay attacks. + + If the Agent encounters an error either generated by the KDC or + internally, the Agent MUST send an INFORM or TRAP PDU indicating + the error in the form of a KRB-ERROR placed in krbUsmMibApReq + with the same rules applied to krbUsmMibNonce and krbUsmMibUnsol- + icitedNotify above. If the Agent suspects that it is being + attacked by a purported Manager which is generating many failed + TGS-REQ's to the KDC, it SHOULD meter its TGS-REQ transactions + for that Manager to the KDC using an exponential backoff mechan- + ism truncated at 10 seconds. + + + + 6) Upon recepit of an INFORM or TRAP PDU with a krbUsmMibApReq, a + Manager may accept the AP-REQ. If it is accompanied with a + krbUsmMibNonce it MUST correlate it with any outstanding transac- + tions using its stored nonce for the transaction. If it does not + correlate with a current nonce, the request MUST be rejected as + it may be a replay. + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 6] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + If the Manager chooses to reject an unsolicited keying request, + it SHOULD send a WrongValue Error to the Agent with the krbUsmMi- + bApReq as the subject of the WrongValue. If an Agent receives a + WrongValue Error from a Manager it MUST cease retransmission of + the INFORM or TRAP PDU's so as to mitigate event avalanches by + Agents. There is a possible denial of service attack here, but it + must be weighed against the larger problem of network congestion, + flapping, etc. Therefore, if the Agent finds that it cannot can- + cel an unsolicited Notify (ie, it must be reliable), it MUST use + a truncated exponential backoff mechanism with the maximum trun- + cation interval set to 10 minutes. + + Otherwise, the Manager MUST send a SET PDU to the Agent which + contains a krbUsmMibApRep. + + + 7) If the Agent detects an error (including detecting replays) in + the final AP-REP, it MUST send a WrongValue error with a pointer + to the krbUsmMibApRep varbind to indicate its inability to estab- + lish the security association. Otherwise, receipt of the positive + acknowledgement from the final SET indicates to the Manager that + the proper keys have been installed on the Agent in the USM MIB. + +Unsolicited Agent Keying Requests + + An Agent may find that it needs to set up a security association for + a USM user in order to notify a Manager of some event. When the Agent + engine receives a request for a notify, it SHOULD check to see if + keying material has been established for the user and that the keying + material is valid. If the keying material is not valid and the USM + user has been tagged as being a Kerberos principal in a realm, the + Agent SHOULD first try to instantiate a security association by + obtaining a service ticket for the USM User and follow steps 3-7 of + the flow above. This insures that the USM User will have proper key- + ing material and providing a mechanism to allow for casual security + associations to be built up and torn down. This is especially useful + for Agents which may not normally need to be under constant Manager + supervision, such as the case with high fan out user residential CPE + and other SNMP managed "appliances". In all cases, the Agent MUST NOT + send an unsolicited Notify if krbUsmUnsolicitedNotify is set to + false. + + How the Agent obtains the Manager's address, how it determines + whether a Manager, realm, and whether it can be keyed using this MIB + is outside of the scope of this memo. + + Note: Although the MIB allows for a Manager to set up a session + using User-User mode of Kerberos by sending a TGT along with + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 7] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + the nonce, this, is limited to Manager initiated sessions + only since there is no easy way to store the Manager's ticket + in the MIB since it is publicly writable and as such would be + subject to denial of service attacks. Another method might be + to have the Agent send a krbUsmMibNonce to the Manager which + would tell it to instigate a session. Overall, it seems like + a marginal feature to allow a PKinit authenticated user be + the target of unsolicited informs and it would complicate the + transactions. For this reason, this scenario has been omitted + in favor of simplicity. + +Retransmissions + + Since this MIB defines not only variables, but transactions, discus- + sion of the retransmission state machine is in order. There are two + similar but different state machines for the Manager Solicited and + Agent Unsolicited transactions. There is one timer Timeout which + SHOULD take into consideration round trip considerations and MUST + implement a truncated exponential backoff mechanism. In addition, in + the case where an Agent makes an unsolicited Agent keying request, + the Agent SHOULD perform an initial random backoff if the keying + request to the Manager may result in a restart avalanche. A suitable + method is described in section 4.3.4 of [5]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 8] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + +Manager Solicited Retransmission State Machine + + Timeout + +---+ + | | + | V + +-----------+ Set-Ack (2) +----------+ + | |------------>| | + | Set-Nonce | | Ap-Req | + | (1) |<------------| (5) | + +-----------+ Timeout +----------+ + ^ | + | | Set-Ap-Rep + | +----------+ | (6) + +------| |<------+ + Timeout | Estab-wt | + | (7) | + +----------+ + | + | Set-Ap-Rep-Ack (7) + V + +----------+ + | | + | Estab | + | | + + +----------+ + + + + + + + + + + + + + + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 9] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + +Agent Unsolicited Retransmission State Machine + + Timeout + +---+ + | | + | V + +----------+ + | | + +----> | Ap-Req |-------+ + | | (5) | | + | +----------+ | + | | + | | Set-Ap-Rep + | +----------+ | (6) + +------| |<------+ + Timeout | Estab-wt | + | (7) | + +----------+ + | + | Set-Ap-Rep-Ack (7) + V + +----------+ + | | + | Estab | + | | + +----------+ + +Session Duration and Failures + + The KerbUsmMib uses the ticket lifetime to determine the life of the + USM session. The Agent MUST keep track of whether the ticket which + instigated the session is valid whenever it forms PDU's for that par- + ticular user. If a session expires, or if it wasn't valid to begin + with (from the Agent's perspective), the Agent MUST reject the PDU by + sending a XXX Error [mat: help me here Keith... what does USM say + about this?]. + + Kerberos also inherently implies adding state to the Agent and + Manager since they share not only a key, but a lifetime associated + with that key. This is in some sense soft state because failure of an + Agent will cause it to reject PDU's for Managers with whom it does + not share a secret. The Manager can use the Error PDU's as an indica- + tion that it needs to reauthenticate with the Agent, taking care not + to loop. The Manager is even easier: when it reboots, it can either + check its credential cache to reconstruct state or cause the Agent to + reauthenticate to the Manager with its service ticket by initiating a + authentication transaction with the manager. + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 10] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + +Manager Collisions + + Managers may freely set up keys for different USM users using this + MIB without problem since they access different rows in the krbUsm- + PrinTable. However, multiple Managers trying to set up keys for the + same USM user is possible but discouraged. The requirement for the + Manager is that they MUST share the same service key with the KDC so + that they can all decrypt the same service ticket. There are two race + conditions, however, which are not well handled: + + + +1) At the end of a ticket lifetime, one manager may request the agent + to refresh its service ticket causing a new session key to be + installed for the USM user leaving the other managers with stale + keys. The workaround here is that the Agent will reject the stale + manager's PDU's which should inform them to do their own rekeying + operations. + + +2) If multiple managers try to access the same row at the same time, + the Agent SHOULD try to keep the transactions separate based on the + nonce values. The Managers or the Agents SHOULD NOT break the + krbUsmMibNonce and any other additional varbinds into separate PDU's + as this may result in a meta stable state. Given normal MTU sizes, + this should not be an issue in practice, and this should at worst + devolve into the case above. + + In all cases, the krbUsmMibNonce MUST be the last value to be + transmitted, though its position within a PDU is unimportant. + + + + + + + + + + + + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 11] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + + KrbUSM MIB + + KRB-USM-MIB DEFINITIONS ::= BEGIN + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, OBJECT-IDENTITY, + snmpModules, Counter32, Unsigned32 FROM SNMPv2-SMI + TruthValue, DisplayString FROM SNMPv2-TC + usmUserEntry FROM SNMP-USER-BASED-SM-MIB + + + + krbUsmMib MODULE-IDENTITY + LAST-UPDATED "00071300Z" + ORGANIZATION "IETF SNMP V3 Working Group" + CONTACT-INFO + "Michael Thomas + Cisco Systems + 375 E Tasman Drive + San Jose, Ca 95134 + Phone: +1 408-525-5386 + Fax: +1 801-382-5284 + email: mat@cisco.com" + DESCRIPTION + "This MIB contains the MIB variables to + exchange Kerberos credentials and a session + key to be used to authenticate and set up + USM keys" + + ::= { snmpModules nnn } -- not sure what needs to be here. + krbUsmMibObjects OBJECT INDENTIFIER ::= { krbUsmMib 1 } + + krbUsmMibAuthInAttemps + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Counter of the number of Kerberos + authorization attempts as defined by + receipt of a PDU from a Manager with a + krbUsmMibNonce set in the principal table." + ::= { krbUsmMibObjects 1 } + + krbUsmMibAuthOutAttemps + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 12] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + DESCRIPTION + "Counter of the number of unsolicited Kerberos + authorization attempts as defined by + an Agent sending an INFORM or TRAP PDU with a + krbUsmMibApRep but without krbUsmApMibNonce + varbind." + ::= { krbUsmMibObjects 2 } + krbUsmMibAuthInFail + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Counter of the number of Kerberos + authorization failures as defined by + a Manager setting the krbUsmMibNonce + in the principal table which results + in some sort of failure to install keys + in the requested USM user entry." + ::= { krbUsmMibObjects 3 } + + krbUsmMibAuthOutFail + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Counter of the number of unsolicited Kerberos + authorization failures as defined by + an Agent sending an INFORM or TRAP PDU with a + krbUsmMibApRep but without a krbUsmMibNonce + varbind which does not result in keys being + installed for that USM user entry." + ::= { krbUsmMibObjects 4 } + + krbUsmMibPrinTable OBJECT-TYPE + SYNTAX SEQUENCE OF krbUsmMibEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table which maps Kerberos principals with USM + users as well as the per user variables to key + up sessions" + ::= { krbUsmMibObjects 5 } + + krbUsmMibPrinEntry OBJECT-TYPE + SYNTAX KrbUsmMibPrinEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 13] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + "an entry into the krbMibPrinTable which is a + parallel table to UsmUserEntry table" + AUGMENTS { usmUserEntry } + ::= { krbUsmMibPrinTable 1 } + + KrbUsmMibPrinEntry SEQUENCE + { + krbUsmMibApReq OCTET STRING, + krbUsmMibApRep OCTET STRING, + krbUsmMibNonce OCTET STRING, + krbUsmMibMgrTGT OCTET STRING, + krbUsmMibUnsolicitedNotify TruthValue, + } + + + krbUsmMibApReq OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "This variable contains a DER encoded Kerberos + AP-REQ or KRB-ERROR for the USM user which is + to be keyed. This is sent from the Agent to + the Manager in an INFORM or TRAP request. + KRB-ERROR MUST only be sent to the Manager + if it is in response to a keying request from + the Manager. + " + ::= { krbUsmMibPrinEntry 1 } + + krbUsmMibApRep OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable contains the DER encoded response + to an AP-REQ. This variable is SET by the + Manager to acknowledge receipt of an AP-REQ. If + krbUsmMibApRep contains a Kerberos AP-REP, the + Agent must derive keys from the session key + of the Kerberos ticket in the AP-REQ and place + them in the USM database in a manner specified + by [RFC2574]. If the Manager detects an error, + it will instead place a KRB-ERROR in this + variable to inform the Agent of the error. + + This variable is in effect a write-only variable. + attempts to read this variable will result in a + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 14] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + null octet string being returned" + ::= { krbUsmMibPrinEntry 2 } + + krbUsmMibNonce OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "SET'ing a krbUsmMibnonce allows a Manager to + determine whether an INFORM or TRAP from an + Agent is an outstanding keying request, or + unsolicited from the Agent. The Manager + initiates keying for a particular USM user + by writing a nonce into the row for which + desires to establish a security association. + The nonce is an ASCII string of the form + ``host:port?nonce'' where: + + host: is either an FQDN, or valid ipv4 or ipv6 + numerical notation of the Manager which + desires to initiate keying + port: is the destination port at which that the + Manager may be contacted + nonce: is a number generated by the Manager to + correlate the transaction + + The same nonce MUST be sent to the Manager in a + subsequent INFORM or TRAP with a krbUsmApReq. + The Agent MUST use the host address and port + supplied in the nonce as the destination of a + subsequent INFORM or TRAP. Unsolicited keying + requests MUST NOT contain a nonce, and should + instead use the destination stored Notifies of + this type. + + Nonces MUST be highly collision resistant either + using a time based method or a suitable random + number generator. Managers MUST never create + nonces which are 0. + + This variable is in effect a write-only variable. + Attempts to read this variable will result in a + nonce of value 0 being returned" + + + ::= { krbUsmMibPrinEntry 3 } + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 15] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + krbUsmMibMgrTgt OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "If the Manager does not possess a symmetric + key with the KDC as would be the case with + a Manager using PKinit for authentication, + the Manager MUST SET its DER encoded ticket + granting ticket into KrbUsmMgrTgt along + with krbUsmMibNonce. + + The agent will then attach the Manager's TGT + into the additional tickets field of the + TGS-REQ message to the KDC to get a User-User + service ticket. + + This variable is in effect a write-only variable. + Attempts to read this variable will result in a + null octet string being returned" + ::= { krbUsmMibPrinEntry 4 } + + + krbUsmMibUnsolicitedNotify OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "If this variable is false, the Agent MUST NOT + send unsolicited INFORM or TRAP PDU's to the + Manager. + + Attempts to SET this variable by the no-auth + no-priv user MUST be rejected." + ::= { krbUsmMibPrinEntry 5 } + + -- + -- Conformance section... nothing optional. + + krbUsmMibCompliences MODULE-COMPLIANCE + STATUS current + DESCRIPTION "The compliance statement for SNMP + engines whichimplement the KRB-USM-MIB + " + MODULE -- this module + MANDATORY-GROUPS { krbUsmMib } + ::= { krbUsmMibCompliances 1 } + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 16] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + END + + +Key Derivation + + The session key provides the basis for the keying material for the + USM user specified in the AP-REQ. The actual keys for use for the + authentication and privacy are produced using the cryptographic hash- + ing function used to protect the ticket itself. The keying material + is derived using this function, F(key, salt), using successive + interations of F over the salt string "SNMPV3RULZ%d", where %d is a + monotonic counter starting at zero. The bits are taken directly from + the successive interations to produce two keys of appropriate size + (as specified in the USM user row) for the authentication transform + first, and the privacy transform second. If the authentication + transform is null, the first bits of the derived key are used for the + privacy transform. + +Security Considerations + + Various elements of this MIB must be readable and writable as the + no-auth, no-priv user. Unless specifically necessary for the key + negotiation, elements of this MIB SHOULD be protected by VACM views + which limit access. In particular, there is no reason anything in + this MIB should be visible to a no-auth, no-priv user with the excep- + tion of KrbUsmMibApReq, KrbUsmMibApRep, KrbUsmMibNonce, and + KrbUsmMibMgrTgt, and then only with the restrictions placed on them + in the MIB. As such, probing attacks are still possible, but should + not be profitable: all of the writable variables with interesting + information in them are defined in such a way as to be write only. + + There are some interesting denial of service attacks which are possi- + ble by attackers spoofing managers and putting load on the KDC to + generate unnecessary tickets. For large numbers or agents this could + be problematic. This can probably be mitigated by the KDC prioritiz- + ing TGS-REQ's though. + + +References + +[1] The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos + Network Authentication Service (V5)", RFC 1510, September + 1993 + +[2] The SNMPV3 Working Group, U. Blumenthal, B. Wijnen, "The + User-based Security Model of SNMP V3", RFC 2574, April 1999 + +[3] The SNMPV3 Working Group, B. Wijnen, R. Presuhn, + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 17] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + K.McCloghrie, "The View-based Access Control Model of SNMP + V3", RFC 2575, April 1999 + +[4] The CAT Working Group, Tung, et al, "Public Key Cryptography + for Initial Authentication in Kerberos", draft-ietf-cat-pk- + init-11, November 1999 + +[5] Arango, et al, "Media Gateway Control Protocl (MGCP)", RFC + 2705, October 1999 + + +[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, An Architecture + for Describing SNMP Management Frameworks, RFC 2571, April + 1999. + +[RFC1155] Rose, M., and K. McCloghrie, Structure and Identification of + Management Information for TCP/IP-based Internets, STD 16, + RFC 1155, May 1990. + +[RFC1212] Rose, M., and K. McCloghrie, Concise MIB Definitions, STD + 16, RFC 1212, March 1991. + +[RFC1215] M. Rose, A Convention for Defining Traps for use with the + SNMP, RFC 1215, March 1991. + +[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, Structure of Management Infor- + mation Version 2 (SMIv2), STD 58, RFC 2578, April 1999. + +[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, Textual Conventions for SMIv2, + STD 58, RFC 2579, April 1999. + +[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, Conformance Statements for + SMIv2, STD 58, RFC 2580, April 1999. + +[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple + Network Management Protocol, STD 15, RFC 1157, May 1990. + +[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + Introduction to Community-based SNMPv2, RFC 1901, January + 1996. + +[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Tran- + sport Mappings for Version 2 of the Simple Network Manage- + ment Protocol (SNMPv2), RFC 1906, January 1996. + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 18] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + +[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, Message + Processing and Dispatching for the Simple Network Management + Protocol (SNMP), RFC 2572, April 1999. + +[RFC2574] Blumenthal, U., and B. Wijnen, User-based Security Model + (USM) for version 3 of the Simple Network Management Proto- + col (SNMPv3), RFC 2574, April 1999. + +[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Pro- + tocol Operations for Version 2 of the Simple Network Manage- + ment Protocol (SNMPv2), RFC 1905, January 1996. + +[RFC2573] Levi, D., Meyer, P., and B. Stewart, SNMPv3 Applications, + RFC 2573, April 1999. + +[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, View-based + Access Control Model (VACM) for the Simple Network Manage- + ment Protocol (SNMP), RFC 2575, April 1999. + +[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, Introduc- + tion to Version 3 of the Internet-standard Network Manage- + ment Framework, RFC 2570, April 1999. + +Author's Address + + Michael Thomas + Cisco Systems + 375 E Tasman Rd + San Jose, Ca, 95134, USA + Tel: +1 408-525-5386 + email: mat@cisco.com + + + + + + + + + + + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 19] + + diff --git a/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt b/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt new file mode 100644 index 000000000000..b89108a53be9 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt @@ -0,0 +1,227 @@ + +CAT Working Group Mike Swift +draft-trostle-win2k-cat-kerberos-set-passwd-00.txt Microsoft +February 2000 Jonathan Trostle +Category: Informational Cisco Systems + John Brezak + Microsoft + + Extending Change Password for Setting Kerberos Passwords + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments and suggestions on this document are encouraged. Comments + on this document should be sent to the CAT working group discussion + list: + ietf-cat-wg@stanford.edu + +1. Abstract + + The Kerberos [1] change password protocol [2], does not allow for + an administrator to set a password for a new user. This functionality + is useful in some environments, and this proposal extends [2] to + allow password setting. The changes are: adding new fields to the + request message to indicate the principal which is having its + password set, not requiring the initial flag in the service ticket, + using a new protocol version number, and adding three new result + codes. + +2. The Protocol + + The service must accept requests on UDP port 464 and TCP port 464 as + well. The protocol consists of a single request message followed by + a single reply message. For UDP transport, each message must be fully + contained in a single UDP packet. + + For TCP transport, there is a 4 octet header in network byte order + precedes the message and specifies the length of the message. This + + requirement is consistent with the TCP transport header in 1510bis. + +Request Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REQ length | AP_REQ data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + All 16 bit fields are in big-endian order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0xff80 (big-endian + integer). + + AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REQ data: (see [1]) The AP-REQ message must be for the service + principal kadmin/changepw@REALM, where REALM is the REALM of the user + who wishes to change/set his password. The ticket in the AP-REQ must + must include a subkey in the Authenticator. To enable setting of + passwords, it is not required that the initial flag be set in the + Kerberos service ticket. + + KRB-PRIV message (see [1]) This KRB-PRIV message must be generated + using the subkey from the authenticator in the AP-REQ data. + + The user-data component of the message consists of the following ASN.1 + structure encoded as an OCTET STRING: + + ChangePasswdData ::= SEQUENCE { + newpasswd[0] OCTET STRING, + targname[2] PrincipalName OPTIONAL, + targrealm[3] Realm OPTIONAL + } + + The server must verify the AP-REQ message, check whether the client + principal in the ticket is authorized to set/change the password + (either for that principal, or for the principal in the targname + field if present), and decrypt the new password. The server also + checks whether the initial flag is required for this request, + replying with status 0x0007 if it is not set and should be. An + authorization failure is cause to respond with status 0x0005. For + forward compatibility, the server should be prepared to ignore fields + after targrealm in the structure that it does not understand. + + The newpasswd field contains the cleartext password, and the server + should apply any local policy checks including password policy checks. + The server then generates the appropriate keytypes from the password + + and stores them in the KDC database. If all goes well, status 0x0000 + is returned to the client in the reply message (see below). + +Reply Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REP length | AP-REP data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + All 16 bit fields are in big-endian order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0001 (big-endian + integer). (The reply message has the same format as in [2]). + + AP-REP length: length of AP-REP data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REP data: the AP-REP is the response to the AP-REQ in the request + packet. + + KRB-PRIV from [2]: This KRB-PRIV message must be generated using the + subkey in the authenticator in the AP-REQ data. + + The server will respond with a KRB-PRIV message unless it cannot + decode the client AP-REQ or KRB-PRIV message, in which case it will + respond with a KRB-ERROR message. NOTE: Unlike change password version + 1, the KRB-ERROR message will be sent back without any encapsulation. + + The user-data component of the KRB-PRIV message, or e-data component + of the KRB-ERROR message, must consist of the following data. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | result code | result string / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + result code (16 bits) (result codes 0-4 are from [2]): + The result code must have one of the following values (big- + endian integer): + KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not + allowed in a KRB-ERROR message) + KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed + KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in + processing the request (for example, + there is a resource or other problem + causing the request to fail) + + KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in + authentication processing + KRB5_KPASSWD_SOFTERROR 4 request fails due to a "soft" error + in processing the request + KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized + KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported + KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required + 0xFFFF if the request fails for some other reason. + Although only a few non-zero result codes are specified here, + the client should accept any non-zero result code as indicating + failure. + result string - from [2]: + This field should contain information which the server thinks + might be useful to the user, such as feedback about policy + failures. The string must be encoded in UTF-8. It may be + omitted if the server does not wish to include it. If it is + present, the client should display the string to the user. + This field is analogous to the string which follows the numeric + code in SMTP, FTP, and similar protocols. + +3. References + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5). Request for Comments 1510. + + [2] M. Horowitz. Kerberos Change Password Protocol. + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerb-chg-password-02.txt + +4. Expiration Date + + This draft expires in August 2000. + +5. Authors' Addresses + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + Email: jtrostle@cisco.com + + Mike Swift + 1 Microsoft Way + Redmond, WA 98052 + mikesw@microsoft.com + + John Brezak + 1 Microsoft Way + Redmond, WA 98052 + jbrezak@microsoft.com diff --git a/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt b/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt new file mode 100644 index 000000000000..e9611e395bfd --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt @@ -0,0 +1,327 @@ +Network Working Group T. Ts'o, Editor +Internet-Draft Massachusetts Institute of Technology +draft-tso-telnet-krb5-04.txt April 2000 + + Telnet Authentication: Kerberos Version 5 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference mate- + rial or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + +0. Abstract + + This document describes how Kerberos Version 5 [1] is used with the + telnet protocol. It describes an telnet authentication sub-option + to be used with the telnet authentication option [2]. This mecha- + nism can also used to provide keying material to provide data confi- + dentiality services in conjuction with the telnet encryption option + [3]. + +1. Command Names and Codes + + Authentication Types + + KERBEROS_V5 2 + + Sub-option Commands + + Expires Sept 2000 [Page 1] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + AUTH 0 + REJECT 1 + ACCEPT 2 + RESPONSE 3 + FORWARD 4 + FORWARD_ACCEPT 5 + FORWARD_REJECT 6 + +2. Command Meanings + + IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5 + KRB_AP_REQ message> IAC SE + + This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the + remote side of the connection. The first octet of the <authenti- + cation-type-pair> value is KERBEROS_V5, to indicate that Version 5 + of Kerberos is being used. The Kerberos V5 authenticator in the + KRB_AP_REQ message must contain a Kerberos V5 checksum of the + two-byte authentication type pair. This checksum must be verified + by the server to assure that the authentication type pair was cor- + rectly negotiated. The Kerberos V5 authenticator must also in- + clude the optional subkey field, which shall be filled in with a + randomly chosen key. This key shall be used for encryption pur- + poses if encryption is negotiated, and shall be used as the nego- + tiated session key (i.e., used as keyid 0) for the purposes of the + telnet encryption option; if the subkey is not filled in, then the + ticket session key will be used instead. + + If data confidentiality services is desired the ENCRYPT_US- + ING_TELOPT flag must be set in the authentication-type-pair as + specified in [2]. + + IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE + + This command indicates that the authentication was successful. + + If the AUTH_HOW_MUTUAL bit is set in the second octet of the au- + thentication-type-pair, the RESPONSE command must be sent before + the ACCEPT command is sent. + + IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op- + tional reason for rejection> IAC SE + + This command indicates that the authentication was not successful, + and if there is any more data in the sub-option, it is an ASCII + text message of the reason for the rejection. + + IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE + <KRB_AP_REP message> IAC SE + + Expires Sept 2000 [Page 2] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + This command is used to perform mutual authentication. It is only + used when the AUTH_HOW_MUTUAL bit is set in the second octet of + the authentication-type-pair. After an AUTH command is verified, + a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP + message to perform the mutual authentication. + + IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED + message> IAC SE + + This command is used to forward kerberos credentials for use by + the remote session. The credentials are passed as a Kerberos V5 + KRB_CRED message which includes, among other things, the forwarded + Kerberos ticket and a session key associated with the ticket. Part + of the KRB_CRED message is encrypted in the key previously ex- + changed for the telnet session by the AUTH suboption. + + IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC + SE + + This command indicates that the credential forwarding was success- + ful. + + IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op- + tional reason for rejection> IAC SE + + This command indicates that the credential forwarding was not suc- + cessful, and if there is any more data in the sub-option, it is an + ASCII text message of the reason for the rejection. + +3. Implementation Rules + + If the second octet of the authentication-type-pair has the AUTH_WHO + bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial + AUTH command, and the server responds with either ACCEPT or REJECT. + In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv- + er will send a RESPONSE before it sends the ACCEPT. + + If the second octet of the authentication-type-pair has the AUTH_WHO + bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial + AUTH command, and the client responds with either ACCEPT or REJECT. + In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the + client will send a RESPONSE before it sends the ACCEPT. + + The Kerberos principal used by the server will generally be of the + form "host/<hostname>@realm". That is, the first component of the + Kerberos principal is "host"; the second component is the fully qual- + ified lower-case hostname of the server; and the realm is the Ker- + beros realm to which the server belongs. + + Expires Sept 2000 [Page 3] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP + messages, the KRB_CRED structure, or the optional rejection text + string must be doubled as specified in [4]. Otherwise the following + byte might be mis-interpreted as a Telnet command. + +4. Examples + + User "joe" may wish to log in as user "pete" on machine "foo". If + "pete" has set things up on "foo" to allow "joe" access to his ac- + count, then the client would send IAC SB AUTHENTICATION NAME "pete" + IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE> + IAC SE + + The server would then authenticate the user as "joe" from the + KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by + Kerberos, and if "pete" has allowed "joe" to use his account, the + server would then continue the authentication sequence by sending a + RESPONSE (to do mutual authentication, if it was requested) followed + by the ACCEPT. + + If forwarding has been requested, the client then sends IAC SB AU- + THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure + with credentials to be forwarded> IAC SE. If the server succeeds in + reading the forwarded credentials, the server sends FORWARD_ACCEPT + else, a FORWARD_REJECT is sent back. + + Client Server + IAC DO AUTHENTICATION + IAC WILL AUTHENTICATION + + [ The server is now free to request authentication information. + ] + + IAC SB AUTHENTICATION SEND + KERBEROS_V5 CLIENT|MUTUAL + KERBEROS_V5 CLIENT|ONE_WAY IAC + SE + + [ The server has requested mutual Version 5 Kerberos + authentication. If mutual authentication is not supported, + then the server is willing to do one-way authentication. + + The client will now respond with the name of the user that it + wants to log in as, and the Kerberos ticket. ] + + IAC SB AUTHENTICATION NAME + "pete" IAC SE + IAC SB AUTHENTICATION IS + KERBEROS_V5 CLIENT|MUTUAL AUTH + <KRB_AP_REQ message> IAC SE + + Expires Sept 2000 [Page 4] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + [ Since mutual authentication is desired, the server sends across + a RESPONSE to prove that it really is the right server. ] + + IAC SB AUTHENTICATION REPLY + KERBEROS_V5 CLIENT|MUTUAL + RESPONSE <KRB_AP_REP message> + IAC SE + + [ The server responds with an ACCEPT command to state that the + authentication was successful. ] + + IAC SB AUTHENTICATION REPLY KER- + BEROS_V5 CLIENT|MUTUAL ACCEPT + IAC SE + + [ If so requested, the client now sends the FORWARD command to + forward credentials to the remote site. ] + + IAC SB AUTHENTICATION IS KER- + BEROS_V5 CLIENT|MUTUAL + FORWARD <KRB_CRED message> IAC + SE + + [ The server responds with a FORWARD_ACCEPT command to state that + the credential forwarding was successful. ] + + Expires Sept 2000 [Page 5] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + IAC SB AUTHENTICATION REPLY KER- + BEROS_V5 CLIENT|MUTUAL FOR- + WARD_ACCEPT IAC SE + +5. Security Considerations + + The selection of the random session key in the Kerberos V5 authenti- + cator is critical, since this key will be used for encrypting the + telnet data stream if encryption is enabled. It is strongly advised + that the random key selection be done using cryptographic techniques + that involve the Kerberos ticket's session key. For example, using + the current time, encrypting it with the ticket session key, and then + correcting for key parity is a strong way to generate a subsession + key, since the ticket session key is assumed to be never disclosed to + an attacker. + + Care should be taken before forwarding a user's Kerberos credentials + to the remote server. If the remote server is not trustworthy, this + could result in the user's credentials being compromised. Hence, the + user interface should not forward credentials by default; it would be + far safer to either require the user to explicitly request creden- + tials forwarding for each connection, or to have a trusted list of + hosts for which credentials forwarding is enabled, but to not enable + credentials forwarding by default for all machines. + +6. IANA Considerations + + The authentication type KERBEROS_V5 and its associated suboption values + are registered with IANA. Any suboption values used to extend + the protocol as described in this document must be registered + with IANA before use. IANA is instructed not to issue new suboption + values without submission of documentation of their use. + +7. Acknowledgments + + This document was originally written by Dave Borman of Cray Research, + Inc. Theodore Ts'o of MIT revised it to reflect the latest implemen- + tation experience. Cliff Neuman and Prasad Upasani of USC's Informa- + tion Sciences Institute developed the credential forwarding support. + + In addition, the contributions of the Telnet Working Group are also + gratefully acknowledged. + +8. References + + [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys- + tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem- + ber 1993. + + [2] Internet Engineering Task Force, "Telnet Authentication", draft- + tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems, + April 2000. + + [3] Internet Engineering Task Force, "Telnet Data Encryption Option", + draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux + Systems, April 2000. + + [4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC + + Expires Sept 2000 [Page 6] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + 855, STD 8, USC/Information Sciences Institute, May 1983. + +Editor's Address + + Theodore Ts'o + Massachusetts Institute of Technology + MIT Room E40-343 + 77 Massachusetts Avenue + Cambridge, MA 02139 + + Phone: (617) 253-8091 + EMail: tytso@mit.edu + + Expires Sept 2000 [Page 7] + + + Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 + The Kermit Project * Columbia University + 612 West 115th St #716 * New York, NY * 10025 + http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org + + diff --git a/crypto/heimdal/doc/standardisation/rc4-hmac.txt b/crypto/heimdal/doc/standardisation/rc4-hmac.txt new file mode 100644 index 000000000000..202d44e8639c --- /dev/null +++ b/crypto/heimdal/doc/standardisation/rc4-hmac.txt @@ -0,0 +1,587 @@ +CAT working group M. Swift +Internet Draft J. Brezak +Document: draft-brezak-win2k-krb-rc4-hmac-03.txt Microsoft +Category: Informational June 2000 + + + The Windows 2000 RC4-HMAC Kerberos encryption type + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. Internet-Drafts are + draft documents valid for a maximum of six months and may be + updated, replaced, or obsoleted by other documents at any time. It + is inappropriate to use Internet- Drafts as reference material or to + cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + The Windows 2000 implementation of Kerberos introduces a new + encryption type based on the RC4 encryption algorithm and using an + MD5 HMAC for checksum. This is offered as an alternative to using + the existing DES based encryption types. + + The RC4-HMAC encryption types are used to ease upgrade of existing + Windows NT environments, provide strong crypto (128-bit key + lengths), and provide exportable (meet United States government + export restriction requirements) encryption. + + The Windows 2000 implementation of Kerberos contains new encryption + and checksum types for two reasons: for export reasons early in the + development process, 56 bit DES encryption could not be exported, + and because upon upgrade from Windows NT 4.0 to Windows 2000, + accounts will not have the appropriate DES keying material to do the + standard DES encryption. Furthermore, 3DES is not available for + export, and there was a desire to use a single flavor of encryption + in the product for both US and international products. + + As a result, there are two new encryption types and one new checksum + type introduced in Windows 2000. + + +2. Conventions used in this document + + + +Swift Category - Informational 1 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + +3. Key Generation + + On upgrade from existing Windows NT domains, the user accounts would + not have a DES based key available to enable the use of DES base + encryption types specified in RFC 1510. The key used for RC4-HMAC is + the same as the existing Windows NT key (NT Password Hash) for + compatibility reasons. Once the account password is changed, the DES + based keys are created and maintained. Once the DES keys are + available DES based encryption types can be used with Kerberos. + + The RC4-HMAC String to key function is defined as follow: + + String2Key(password) + + K = MD4(UNICODE(password)) + + The RC4-HMAC keys are generated by using the Windows UNICODE version + of the password. Each Windows UNICODE character is encoded in + little-endian format of 2 octets each. Then performing an MD4 [6] + hash operation on just the UNICODE characters of the password (not + including the terminating zero octets). + + For an account with a password of "foo", this String2Key("foo") will + return: + + 0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, + 0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc + +4. Basic Operations + + The MD5 HMAC function is defined in [3]. It is used in this + encryption type for checksum operations. Refer to [3] for details on + its operation. In this document this function is referred to as + HMAC(Key, Data) returning the checksum using the specified key on + the data. + + The basic MD5 hash operation is used in this encryption type and + defined in [7]. In this document this function is referred to as + MD5(Data) returning the checksum of the data. + + RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A + compatible cipher is described in [8]. In this document the function + is referred to as RC4(Key, Data) returning the encrypted data using + the specified key on the data. + + These encryption types use key derivation as defined in [9] (RFC- + 1510BIS) in Section titled "Key Derivation". With each message, the + message type (T) is used as a component of the keying material. This + summarizes the different key derivation values used in the various + +Swift Category - Informational 2 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + operations. Note that these differ from the key derivations used in + other Kerberos encryption types. + + T = 1 for TS-ENC-TS in the AS-Request + T = 8 for the AS-Reply + T = 7 for the Authenticator in the TGS-Request + T = 8 for the TGS-Reply + T = 2 for the Server Ticket in the AP-Request + T = 11 for the Authenticator in the AP-Request + T = 12 for the Server returned AP-Reply + T = 15 in the generation of checksum for the MIC token + T = 0 in the generation of sequence number for the MIC token + T = 13 in the generation of checksum for the WRAP token + T = 0 in the generation of sequence number for the WRAP token + T = 0 in the generation of encrypted data for the WRAPPED token + + All strings in this document are ASCII unless otherwise specified. + The lengths of ASCII encoded character strings include the trailing + terminator character (0). + + The concat(a,b,c,...) function will return the logical concatenation + (left to right) of the values of the arguments. + + The nonce(n) function returns a pseudo-random number of "n" octets. + +5. Checksum Types + + There is one checksum type used in this encryption type. The + Kerberos constant for this type is: + #define KERB_CHECKSUM_HMAC_MD5 (-138) + + The function is defined as follows: + + K - is the Key + T - the message type, encoded as a little-endian four byte integer + + CHKSUM(K, T, data) + + Ksign = HMAC(K, "signaturekey") //includes zero octet at end + tmp = MD5(concat(T, data)) + CHKSUM = HMAC(Ksign, tmp) + + +6. Encryption Types + + There are two encryption types used in these encryption types. The + Kerberos constants for these types are: + #define KERB_ETYPE_RC4_HMAC 23 + #define KERB_ETYPE_RC4_HMAC_EXP 24 + + The basic encryption function is defined as follow: + + T = the message type, encoded as a little-endian four byte integer. + +Swift Category - Informational 3 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + BYTE L40[14] = "fortybits"; + BYTE SK = "signaturekey"; + + ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 10 + 4, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + add_8_random_bytes(data, data_len, conf_plus_data); + HMAC (K2, conf_plus_data, 8 + data_len, checksum); + HMAC (K1, checksum, 16, K3); + RC4(K3, conf_plus_data, 8 + data_len, edata + 16); + memcpy (edata, checksum, 16); + edata_len = 16 + 8 + data_len; + } + + DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + HMAC (K1, edata, 16, K3); // checksum is at edata + RC4(K3, edata + 16, edata_len - 16, edata + 16); + data_len = edata_len - 16 - 8; + memcpy (data, edata + 16 + 8, data_len); + + // verify generated and received checksums + HMAC (K2, edata + 16, edata_len - 16, checksum); + if (memcmp(edata, checksum, 16) != 0) + printf("CHECKSUM ERROR !!!!!!\n"); + } + + The header field on the encrypted data in KDC messages is: + + typedef struct _RC4_MDx_HEADER { + UCHAR Checksum[16]; + UCHAR Confounder[8]; + } RC4_MDx_HEADER, *PRC4_MDx_HEADER; + + The KDC message is encrypted using the ENCRYPT function not + including the Checksum in the RC4_MDx_HEADER. + + +Swift Category - Informational 4 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + +7. Key Strength Negotiation + + A Kerberos client and server can negotiate over key length if they + are using mutual authentication. If the client is unable to perform + full strength encryption, it may propose a key in the "subkey" field + of the authenticator, using a weaker encryption type. The server + must then either return the same key or suggest its own key in the + subkey field of the AP reply message. The key used to encrypt data + is derived from the key returned by the server. If the client is + able to perform strong encryption but the server is not, it may + propose a subkey in the AP reply without first being sent a subkey + in the authenticator. + +8. GSSAPI Kerberos V5 Mechanism Type + +8.1 Mechanism Specific Changes + + The GSSAPI per-message tokens also require new checksum and + encryption types. The GSS-API per-message tokens must be changed to + support these new encryption types (See [5] Section 1.2.2). The + sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption + is: + Byte 4..5 SEAL_ALG 0x10 0x00 - RC4 + + The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: + Byte 2..3 SGN ALG 0x11 0x00 - HMAC + + The only support quality of protection is: + #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 + + In addition, when using an RC4 based encryption type, the sequence + number is sent in big-endian rather than little-endian order. + + The Windows 2000 implementation also defines new GSSAPI flags in the + initial token passed when initializing a security context. These + flags are passed in the checksum field of the authenticator (See [5] + Section 1.1.1). + + GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s + implementation of DCE RPC, which initially expected three legs of + authentication. Setting this flag causes an extra AP reply to be + sent from the client back to the server after receiving the server’s + AP reply. In addition, the context negotiation tokens do not have + GSSAPI framing - they are raw AP message and do not include object + identifiers. + #define GSS_C_DCE_STYLE 0x1000 + + + +Swift Category - Informational 5 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the + server that it should only allow the server application to identify + the client by name and ID, but not to impersonate the client. + #define GSS_C_IDENTIFY_FLAG 0x2000 + + GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the + client wants to be informed of extended error information. In + particular, Windows 2000 status codes may be returned in the data + field of a Kerberos error message. This allows the client to + understand a server failure more precisely. In addition, the server + may return errors to the client that are normally handled at the + application layer in the server, in order to let the client try to + recover. After receiving an error message, the client may attempt to + resubmit an AP request. + #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 + + These flags are only used if a client is aware of these conventions + when using the SSPI on the Windows platform, they are not generally + used by default. + + When NetBIOS addresses are used in the GSSAPI, they are identified + by the GSS_C_AF_NETBIOS value. This value is defined as: + #define GSS_C_AF_NETBIOS 0x14 + NetBios addresses are 16-octet addresses typically composed of 1 to
th
15 characters, trailing blank (ascii char 20) filled, with a 16 + octet of 0x0. + +8.2 GSSAPI Checksum Type + + The GSSAPI checksum type and algorithm is defined in Section 5. Only + the first 8 octets of the checksum are used. The resulting checksum + is stored in the SGN_CKSUM field (See [5] Section 1.2) for + GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). + + MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, + MIC_seq, MIC_checksum) + { + HMAC (K, SK, 13, K4); + T = 15; + memcpy (T_plus_hdr_plus_msg + 00, &T, 4); + memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8); + // 0101 1100 FFFFFFFF + memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); + MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); + HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); + memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K5); + }else{ + HMAC (K, &T, 4, K5); + +Swift Category - Informational 6 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + } + if (fRC4_EXP) memset(K5+7, 0xAB, 9); + HMAC(K5, MIT_checksum, 8, K6); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K6, seq_plus_direction, 8, MIC_seq); + } + +8.3 GSSAPI Encryption Types + + There are two encryption types for GSSAPI message tokens, one that + is 128 bits in strength, and one that is 56 bits in strength as + defined in Section 6. + + All padding is rounded up to 1 byte. One byte is needed to say that + there is 1 byte of padding. The DES based mechanism type uses 8 byte + padding. See [5] Section 1.2.2.3. + + The encryption mechanism used for GSS wrap based messages is as + follow: + + + WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, + WRAP_seq, WRAP_checksum, edata, edata_len) + { + HMAC (K, SK, 13, K7); + T = 13; + PAD = 1; + memcpy (T_hdr_conf_msg_pad + 00, &T, 4); + memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 + FFFFFFFF + memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); + memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); + MD5 (T_hdr_conf_msg_pad, + 4 + 8 + 8 + msg_len + 1, + MD5_of_T_hdr_conf_msg_pad); + HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); + memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 + bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K8); + }else{ + HMAC (K, &T, 4, K8); + } + if (fRC4_EXP) memset(K8+7, 0xAB, 9); + HMAC(K8, WRAP_checksum, 8, K9); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + +Swift Category - Informational 7 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K9, seq_plus_direction, 8, WRAP_seq); + + for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte + of key with 0xF0 + T = 0; + if (fRC4_EXP){ + *(DWORD *)(L40+10) = T; + HMAC(K10, L40, 14, K11); + memset(K11+7, 0xAB, 9); + }else{ + HMAC(K10, &T, 4, K11); + } + HMAC(K11, seq_num, 4, K12); + RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, + edata); /* skip T & hdr */ + edata_len = 8 + msg_len + 1; // conf + msg_len + pad + } + + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + +9. Security Considerations + + Care must be taken in implementing this encryption type because it + uses a stream cipher. If a different IV isn’t used in each direction + when using a session key, the encryption is weak. By using the + sequence number as an IV, this is avoided. + +10. Acknowledgements + + We would like to thank Salil Dangi for the valuable input in + refining the descriptions of the functions and review input. + +11. References + + 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + 3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, February 1997 + + 4 Kohl, J., Neuman, C., "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993 + + + +Swift Category - Informational 8 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + 5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, + June 1996 + + 6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April + 1992 + + 7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April + 1992 + + 8 Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption + Algorithm", Work in Progress. + + 9 RC4 is a proprietary encryption algorithm available under license + from RSA Data Security Inc. For licensing information, contact: + + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + 10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- + 04.txt, June 25, 1999 + + +12. Author's Addresses + + Mike Swift + Dept. of Computer Science + Sieg Hall + University of Washington + Seattle, WA 98105 + Email: mikesw@cs.washington.edu + + John Brezak + Microsoft + One Microsoft Way + Redmond, Washington + Email: jbrezak@microsoft.com + + + + + + + + + + + + + + + +Swift Category - Informational 9 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + +13. Full Copyright Statement + + "Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and + furnished to others, and derivative works that comment on or + otherwise explain it or assist in its implementation may be + prepared, copied, published and distributed, in whole or in + part, without restriction of any kind, provided that the above + copyright notice and this paragraph are included on all such + copies and derivative works. However, this document itself may + not be modified in any way, such as by removing the copyright + notice or references to the Internet Society or other Internet + organizations, except as needed for the purpose of developing + Internet standards in which case the procedures for copyrights + defined in the Internet Standards process must be followed, or + as required to translate it into languages other than English. + + The limited permissions granted above are perpetual and will + not be revoked by the Internet Society or its successors or + assigns. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Swift Category - Informational 10 + diff --git a/crypto/heimdal/kadmin/add-random-users.c b/crypto/heimdal/kadmin/add-random-users.c new file mode 100644 index 000000000000..24cde703cc01 --- /dev/null +++ b/crypto/heimdal/kadmin/add-random-users.c @@ -0,0 +1,157 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "kadmin_locl.h" + +RCSID("$Id: add-random-users.c,v 1.2 2000/12/31 07:43:39 assar Exp $"); + +#define WORDS_FILENAME "/usr/share/dict/words" + +#define NUSERS 1000 + +static unsigned +read_words (const char *filename, char ***ret_w) +{ + unsigned n, alloc; + FILE *f; + char buf[256]; + char **w = NULL; + + f = fopen (filename, "r"); + if (f == NULL) + err (1, "cannot open %s", filename); + alloc = n = 0; + while (fgets (buf, sizeof(buf), f) != NULL) { + if (buf[strlen (buf) - 1] == '\n') + buf[strlen (buf) - 1] = '\0'; + if (n >= alloc) { + alloc += 16; + w = erealloc (w, alloc * sizeof(char **)); + } + w[n++] = estrdup (buf); + } + *ret_w = w; + return n; +} + +static void +add_user (krb5_context context, void *kadm_handle, + unsigned nwords, char **words) +{ + kadm5_principal_ent_rec princ; + char name[64]; + int r1, r2; + krb5_error_code ret; + int mask; + + r1 = rand(); + r2 = rand(); + + snprintf (name, sizeof(name), "%s%d", words[r1 % nwords], r2 % 1000); + + mask = KADM5_PRINCIPAL; + + memset(&princ, 0, sizeof(princ)); + ret = krb5_parse_name(context, name, &princ.principal); + if (ret) + krb5_err(context, 1, ret, "krb5_parse_name"); + + ret = kadm5_create_principal (kadm_handle, &princ, mask, name); + if (ret) + krb5_err (context, 1, ret, "kadm5_create_principal"); + kadm5_free_principal_ent(kadm_handle, &princ); + printf ("%s\n", name); +} + +static void +add_users (unsigned n) +{ + krb5_error_code ret; + int i; + void *kadm_handle; + krb5_context context; + unsigned nwords; + char **words; + + ret = krb5_init_context(&context); + if (ret) + errx (1, "krb5_init_context failed: %d", ret); + ret = kadm5_s_init_with_password_ctx(context, + KADM5_ADMIN_SERVICE, + NULL, + KADM5_ADMIN_SERVICE, + NULL, 0, 0, + &kadm_handle); + if(ret) + krb5_err(context, 1, ret, "kadm5_init_with_password"); + + nwords = read_words (WORDS_FILENAME, &words); + + for (i = 0; i < n; ++i) + add_user (context, kadm_handle, nwords, words); + kadm5_destroy(kadm_handle); + krb5_free_context(context); +} + +static int version_flag = 0; +static int help_flag = 0; + +static struct getargs args[] = { + { "version", 0, arg_flag, &version_flag }, + { "help", 0, arg_flag, &help_flag } +}; + +static void +usage (int ret) +{ + arg_printusage (args, + sizeof(args)/sizeof(*args), + NULL, + NULL); + exit (ret); +} + +int +main(int argc, char **argv) +{ + int optind = 0; + + set_progname(argv[0]); + if(getarg(args, sizeof(args) / sizeof(args[0]), argc, argv, &optind)) + usage(1); + if (help_flag) + usage (0); + srand (0); + add_users (NUSERS); + return 0; +} diff --git a/crypto/heimdal/kadmin/kadm_conn.c b/crypto/heimdal/kadmin/kadm_conn.c new file mode 100644 index 000000000000..28bf1779d2ed --- /dev/null +++ b/crypto/heimdal/kadmin/kadm_conn.c @@ -0,0 +1,288 @@ +/* + * Copyright (c) 2000 - 2001 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "kadmin_locl.h" +#ifdef HAVE_SYS_WAIT_H +#include <sys/wait.h> +#endif + +RCSID("$Id: kadm_conn.c,v 1.11 2001/01/29 08:43:01 assar Exp $"); + +struct kadm_port { + char *port; + unsigned short def_port; + struct kadm_port *next; +} *kadm_ports; + +static void +add_kadm_port(krb5_context context, const char *service, unsigned int port) +{ + struct kadm_port *p; + p = malloc(sizeof(*p)); + if(p == NULL) { + krb5_warnx(context, "failed to allocate %lu bytes\n", + (unsigned long)sizeof(*p)); + return; + } + + p->port = strdup(service); + p->def_port = port; + + p->next = kadm_ports; + kadm_ports = p; +} + +static void +add_standard_ports (krb5_context context) +{ + add_kadm_port(context, "kerberos-adm", 749); +#ifdef KRB4 + add_kadm_port(context, "kerberos-master", 751); +#endif +} + +/* + * parse the set of space-delimited ports in `str' and add them. + * "+" => all the standard ones + * otherwise it's port|service[/protocol] + */ + +void +parse_ports(krb5_context context, const char *str) +{ + char p[128]; + + while(strsep_copy(&str, " \t", p, sizeof(p)) != -1) { + if(strcmp(p, "+") == 0) + add_standard_ports(context); + else + add_kadm_port(context, p, 0); + } +} + +static pid_t pgrp; +sig_atomic_t term_flag, doing_useful_work; + +static RETSIGTYPE +sigchld(int sig) +{ + int status; + waitpid(-1, &status, 0); + SIGRETURN(0); +} + +static RETSIGTYPE +terminate(int sig) +{ + if(getpid() == pgrp) { + /* parent */ + term_flag = 1; + signal(sig, SIG_IGN); + killpg(pgrp, sig); + } else { + /* child */ + if(doing_useful_work) + term_flag = 1; + else + exit(0); + } + SIGRETURN(0); +} + +static int +spawn_child(krb5_context context, int *socks, int num_socks, int this_sock) +{ + int e, i; + struct sockaddr_storage __ss; + struct sockaddr *sa = (struct sockaddr *)&__ss; + socklen_t sa_size = sizeof(__ss); + int s; + pid_t pid; + krb5_address addr; + char buf[128]; + size_t buf_len; + + s = accept(socks[this_sock], sa, &sa_size); + if(s < 0) { + krb5_warn(context, errno, "accept"); + return 1; + } + e = krb5_sockaddr2address(sa, &addr); + if(e) + krb5_warn(context, e, "krb5_sockaddr2address"); + else { + e = krb5_print_address (&addr, buf, sizeof(buf), + &buf_len); + if(e) + krb5_warn(context, e, "krb5_sockaddr2address"); + else + krb5_warnx(context, "connection from %s", buf); + krb5_free_address(context, &addr); + } + + pid = fork(); + if(pid == 0) { + for(i = 0; i < num_socks; i++) + close(socks[i]); + dup2(s, STDIN_FILENO); + dup2(s, STDOUT_FILENO); + if(s != STDIN_FILENO && s != STDOUT_FILENO) + close(s); + return 0; + } else { + close(s); + } + return 1; +} + +static int +wait_for_connection(krb5_context context, + int *socks, int num_socks) +{ + int i, e; + fd_set orig_read_set, read_set; + int max_fd = -1; + + FD_ZERO(&orig_read_set); + + for(i = 0; i < num_socks; i++) { + if (socks[i] >= FD_SETSIZE) + errx (1, "fd too large"); + FD_SET(socks[i], &orig_read_set); + max_fd = max(max_fd, socks[i]); + } + + pgrp = getpid(); + + if(setpgid(0, pgrp) < 0) + err(1, "setpgid"); + + signal(SIGTERM, terminate); + signal(SIGINT, terminate); + signal(SIGCHLD, sigchld); + + while (term_flag == 0) { + read_set = orig_read_set; + e = select(max_fd + 1, &read_set, NULL, NULL, NULL); + if(e < 0) { + if(errno != EINTR) + krb5_warn(context, errno, "select"); + } else if(e == 0) + krb5_warnx(context, "select returned 0"); + else { + for(i = 0; i < num_socks; i++) { + if(FD_ISSET(socks[i], &read_set)) + if(spawn_child(context, socks, num_socks, i) == 0) + return 0; + } + } + } + signal(SIGCHLD, SIG_IGN); + while(1) { + int status; + pid_t pid; + pid = waitpid(-1, &status, 0); + if(pid == -1 && errno == ECHILD) + break; + } + exit(0); +} + + +int +start_server(krb5_context context) +{ + int e; + struct kadm_port *p; + + int *socks = NULL, *tmp; + int num_socks = 0; + int i; + + for(p = kadm_ports; p; p = p->next) { + struct addrinfo hints, *ai, *ap; + char portstr[32]; + memset (&hints, 0, sizeof(hints)); + hints.ai_flags = AI_PASSIVE; + hints.ai_socktype = SOCK_STREAM; + + e = getaddrinfo(NULL, p->port, &hints, &ai); + if(e) { + snprintf(portstr, sizeof(portstr), "%u", p->def_port); + e = getaddrinfo(NULL, portstr, &hints, &ai); + } + + if(e) { + krb5_warn(context, krb5_eai_to_heim_errno(e), "%s", portstr); + continue; + } + i = 0; + for(ap = ai; ap; ap = ap->ai_next) + i++; + tmp = realloc(socks, (num_socks + i) * sizeof(*socks)); + if(tmp == NULL) { + krb5_warnx(context, "failed to reallocate %lu bytes", + (unsigned long)(num_socks + i) * sizeof(*socks)); + continue; + } + socks = tmp; + for(ap = ai; ap; ap = ap->ai_next) { + int one = 1; + int s = socket(ap->ai_family, ap->ai_socktype, ap->ai_protocol); + if(s < 0) { + krb5_warn(context, errno, "socket"); + continue; + } +#if defined(SO_REUSEADDR) && defined(HAVE_SETSOCKOPT) + if(setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (void *)&one, + sizeof(one)) < 0) + krb5_warn(context, errno, "setsockopt"); +#endif + if (bind (s, ap->ai_addr, ap->ai_addrlen) < 0) { + krb5_warn(context, errno, "bind"); + close(s); + continue; + } + if (listen (s, SOMAXCONN) < 0) { + krb5_warn(context, errno, "listen"); + close(s); + continue; + } + socks[num_socks++] = s; + } + freeaddrinfo (ai); + } + if(num_socks == 0) + krb5_errx(context, 1, "no sockets to listen to - exiting"); + return wait_for_connection(context, socks, num_socks); +} diff --git a/crypto/heimdal/kadmin/kadmin.8 b/crypto/heimdal/kadmin/kadmin.8 new file mode 100644 index 000000000000..bfb4cfc27a66 --- /dev/null +++ b/crypto/heimdal/kadmin/kadmin.8 @@ -0,0 +1,239 @@ +.\" $Id: kadmin.8,v 1.2 2000/09/19 12:29:48 assar Exp $ +.\" +.Dd September 10, 2000 +.Dt KADMIN 8 +.Os HEIMDAL +.Sh NAME +.Nm kadmin +.Nd +Kerberos administration utility +.Sh SYNOPSIS +.Nm +.Oo Fl p Ar string \*(Ba Xo +.Fl -principal= Ns Ar string Oc +.Xc +.Oo Fl c Ar file \*(Ba Xo +.Fl -config-file= Ns Ar file Oc +.Xc +.Oo Fl k Ar file \*(Ba Xo +.Fl -key-file= Ns Ar file Oc +.Xc +.Oo Fl r Ar realm \*(Ba Xo +.Fl -realm= Ns Ar realm Oc +.Xc +.Oo Fl a Ar host \*(Ba Xo +.Fl -admin-server= Ns Ar host Oc +.Xc +.Oo Fl s Ar port number \*(Ba Xo +.Fl -server-port= Ns Ar port number Oc +.Xc +.Op Fl l | Fl -local +.Op Fl h | Fl -help +.Op Fl v | Fl -version +.Op Ar command +.Sh DESCRIPTION +The +.Nm +program is used to make modification to the Kerberos database, either remotely via the +.Xr kadmind 8 +daemon, or locally (with the +.Fl l +option). +.Pp +Supported options: +.Bl -tag -width Ds +.It Xo +.Fl p Ar string Ns , +.Fl -principal= Ns Ar string +.Xc +principal to authenticate as +.It Xo +.Fl c Ar file Ns , +.Fl -config-file= Ns Ar file +.Xc +location of config file +.It Xo +.Fl k Ar file Ns , +.Fl -key-file= Ns Ar file +.Xc +location of master key file +.It Xo +.Fl r Ar realm Ns , +.Fl -realm= Ns Ar realm +.Xc +realm to use +.It Xo +.Fl a Ar host Ns , +.Fl -admin-server= Ns Ar host +.Xc +server to contact +.It Xo +.Fl s Ar port number Ns , +.Fl -server-port= Ns Ar port number +.Xc +port to use +.It Xo +.Fl l Ns , +.Fl -local +.Xc +local admin mode +.El +.Pp +If no +.Ar command +is given on the command line, +.Nm +will prompt for commands to process. Commands include: +.\" not using a list here, since groff apparently gets confused +.\" with nested Xo/Xc +.Bd -ragged -offset indent +.Nm add +.Op Fl r | Fl -random-key +.Op Fl -random-password +.Oo Fl p Ar string \*(Ba Xo +.Fl -password= Ns Ar string Oc +.Xc +.Op Fl -key= Ns Ar string +.Op Fl -max-ticket-life= Ns Ar lifetime +.Op Fl -max-renewable-life= Ns Ar lifetime +.Op Fl -attributes= Ns Ar attributes +.Op Fl -expiration-time= Ns Ar time +.Op Fl -pw-expiration-time= Ns Ar time +.Ar principal... +.Pp +.Bd -filled -offset indent +creates a new principal +.Ed +.Pp +.Nm passwd +.Op Fl r | Fl -random-key +.Op Fl -random-password +.Oo Fl p Ar string \*(Ba Xo +.Fl -password= Ns Ar string Oc +.Xc +.Op Fl -key= Ns Ar string +.Ar principal... +.Pp +.Bd -filled -offset indent +changes the password of an existing principal +.Ed +.Pp +.Nm delete +.Ar principal... +.Pp +.Bd -filled -offset indent +removes a principal +.Ed +.Pp +.Nm del_enctype +.Ar principal enctypes... +.Pp +.Bd -filled -offset indent +removes some enctypes from a principal, this can be useful the service +belonging to the principal is known to not handle certain enctypes +.Ed +.Pp +.Nm ext_keytab +.Oo Fl k Ar string \*(Ba Xo +.Fl -keytab= Ns Ar string Oc +.Xc +.Ar principal... +.Pp +.Bd -filled -offset indent +creates a keytab with the keys of the specified principals +.Ed +.Pp +.Nm get +.Op Fl l | Fl -long +.Op Fl s | Fl -short +.Op Fl t | Fl -terse +.Ar expression... +.Pp +.Bd -filled -offset indent +lists the principals that match the expressions (which are shell glob +like), long format gives more information, and terse just prints the +names +.Ed +.Pp +.Nm rename +.Ar from to +.Pp +.Bd -filled -offset indent +renames a principal +.Ed +.Pp +.Nm modify +.Oo Fl a Ar attributes \*(Ba Xo +.Fl -attributes= Ns Ar attributes Oc +.Xc +.Op Fl -max-ticket-life= Ns Ar lifetime +.Op Fl -max-renewable-life= Ns Ar lifetime +.Op Fl -expiration-time= Ns Ar time +.Op Fl -pw-expiration-time= Ns Ar time +.Op Fl -kvno= Ns Ar number +.Ar principal +.Pp +.Bd -filled -offset indent +modifies certain attributes of a principal +.Ed +.Pp +.Nm privileges +.Pp +.Bd -filled -offset indent +lists the operations you are allowd to perform +.Ed +.Pp +.Ed + +When running in local mode, the following commands can also be used. + +.Bd -ragged -offset indent +.Nm dump +.Op Fl d | Fl -decrypt +.Op Ar dump-file +.Pp +.Bd -filled -offset indent +writes the database in +.Dq human readable +form to the specified file, or standard out +.Ed +.Pp +.Nm init +.Op Fl -realm-max-ticket-life= Ns Ar string +.Op Fl -realm-max-renewable-life= Ns Ar string +.Ar realm +.Pp +.Bd -filled -offset indent +initialises the Kerberos database with entries for a new realm, it's +possible to have more than one realm served by one server +.Ed +.Pp +.Nm load +.Ar file +.Pp +.Bd -filled -offset indent +reads a previously dumped database, and re-creates that database from scratch +.Ed +.Pp +.Nm merge +.Ar file +.Pp +.Bd -filled -offset indent +similar to +.Nm list +but just modifies the database with the entries in the dump file +.Ed +.Pp +.Ed + +.\".Sh ENVIRONMENT +.\".Sh FILES +.\".Sh EXAMPLES +.\".Sh DIAGNOSTICS +.Sh SEE ALSO +.Xr kadmind 8 , +.Xr kdc 8 +.\".Sh STANDARDS +.\".Sh HISTORY +.\".Sh AUTHORS +.\".Sh BUGS diff --git a/crypto/heimdal/kadmin/kadmind.8 b/crypto/heimdal/kadmin/kadmind.8 new file mode 100644 index 000000000000..67d5c9b5bac6 --- /dev/null +++ b/crypto/heimdal/kadmin/kadmind.8 @@ -0,0 +1,133 @@ +.Dd June 7, 2000 +.Dt KADMIND 8 +.Os HEIMDAL +.Sh NAME +.Nm kadmind +.Nd +server for administrative access to kerberos database +.Sh SYNOPSIS +.Nm +.Oo Fl c Ar file \*(Ba Xo +.Fl -config-file= Ns Ar file Oc +.Xc +.Oo Fl k Ar file \*(Ba Xo +.Fl -key-file= Ns Ar file Oc +.Xc +.Op Fl -keytab= Ns Ar keytab +.Oo Fl r Ar realm \*(Ba Xo +.Fl -realm= Ns Ar realm Oc +.Xc +.Op Fl d | Fl -debug +.Oo Fl p Ar port \*(Ba Xo +.Fl -ports= Ns Ar port Oc +.Xc +.Sh DESCRIPTION +.Nm +listens for requests for changes to the Kerberos database and performs +these, subject to permissions. When starting, if stdin is a socket it assumes that it has been started by +.Xr inetd 8 , +otherwise it behaves as a daemon, forking processes for each new +connection. The +.Fl -debug +option causes +.Nm +to accept exactly one connection, which is useful for debugging. + +If built with krb4 support, it implements both the Heimdal Kerberos 5 +administrative protocol and the Kerberos 4 protocol. Password changes +via the Kerberos 4 protocol are also performed by +.Nm kadmind , +but the +.Xr kpasswdd 8 +daemon is responsible for the Kerberos 5 password changing protocol +(used by +.Xr kpasswd 1 ). +.Pp +This daemon should only be run on ther master server, and not on any +slaves. +.Pp +Principals are always allowed to change their own password and list +their own principals. Apart from that, doing any operation requires +permission explicitly added in the ACL file +.Pa /var/heimdal/kadmind.acl . +The format of this file is: +.Bd -ragged +.Va principal +.Va rights +.Op Va principal-pattern +.Ed +.Pp +Where rights is any combination of: +.Bl -bullet +.It +change-password | cpw +.It +list +.It +delete +.It +modify +.It +add +.It +get +.It +all +.El +.Pp +And the optional +.Ar principal-pattern +restricts the rights to principals that match the glob-style pattern. +.Pp +Supported options: +.Bl -tag -width Ds +.It Xo +.Fl c Ar file Ns , +.Fl -config-file= Ns Ar file +.Xc +location of config file +.It Xo +.Fl k Ar file Ns , +.Fl -key-file= Ns Ar file +.Xc +location of master key file +.It Xo +.Fl -keytab= Ns Ar keytab +.Xc +what keytab to use +.It Xo +.Fl r Ar realm Ns , +.Fl -realm= Ns Ar realm +.Xc +realm to use +.It Xo +.Fl d Ns , +.Fl -debug +.Xc +enable debugging +.It Xo +.Fl p Ar port Ns , +.Fl -ports= Ns Ar port +.Xc +ports to listen to. By default, if run as a daemon, it listen to ports +749, and 751 (if built with Kerberos 4 support), but you can add any +number of ports with this option. The port string is a whitespace +separated list of port specifications, with the special string +.Dq + +representing the default set of ports. +.El +.\".Sh ENVIRONMENT +.Sh FILES +.Pa /var/heimdal/kadmind.acl +.Sh EXAMPLES +This will cause kadmind to listen to port 4711 in addition to any +compiled in defaults: +.Bd -literal -offset indent +# kadmind --ports="+ 4711" & +.Ed +.\".Sh DIAGNOSTICS +.Sh SEE ALSO +.Xr kdc 8 , +.Xr kadmin 1 , +.Xr kpasswdd 8 , +.Xr kpasswd 1 diff --git a/crypto/heimdal/kdc/mit_dump.c b/crypto/heimdal/kdc/mit_dump.c new file mode 100644 index 000000000000..336d26579175 --- /dev/null +++ b/crypto/heimdal/kdc/mit_dump.c @@ -0,0 +1,370 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "hprop.h" + +RCSID("$Id: mit_dump.c,v 1.3 2000/08/09 09:57:37 joda Exp $"); + +/* +can have any number of princ stanzas. +format is as follows (only \n indicates newlines) +princ\t%d\t (%d is KRB5_KDB_V1_BASE_LENGTH, always 38) +%d\t (strlen of principal e.g. shadow/foo@ANDREW.CMU.EDU) +%d\t (number of tl_data) +%d\t (number of key data, e.g. how many keys for this user) +%d\t (extra data length) +%s\t (principal name) +%d\t (attributes) +%d\t (max lifetime, seconds) +%d\t (max renewable life, seconds) +%d\t (expiration, seconds since epoch or 2145830400 for never) +%d\t (password expiration, seconds, 0 for never) +%d\t (last successful auth, seconds since epoch) +%d\t (last failed auth, per above) +%d\t (failed auth count) +foreach tl_data 0 to number of tl_data - 1 as above + %d\t%d\t (data type, data length) + foreach tl_data 0 to length-1 + %02x (tl data contents[element n]) + except if tl_data length is 0 + %d (always -1) + \t +foreach key 0 to number of keys - 1 as above + %d\t%d\t (key data version, kvno) + foreach version 0 to key data version - 1 (a key or a salt) + %d\t%d\t(data type for this key, data length for this key) + foreach key data length 0 to length-1 + %02x (key data contents[element n]) + except if key_data length is 0 + %d (always -1) + \t +foreach extra data length 0 to length - 1 + %02x (extra data part) +unless no extra data + %d (always -1) +;\n + +*/ + +static int +hex_to_octet_string(const char *ptr, krb5_data *data) +{ + int i; + unsigned int v; + for(i = 0; i < data->length; i++) { + if(sscanf(ptr + 2 * i, "%02x", &v) != 1) + return -1; + ((unsigned char*)data->data)[i] = v; + } + return 2 * i; +} + +static char * +nexttoken(char **p) +{ + char *q; + do { + q = strsep(p, " \t"); + } while(q && *q == '\0'); + return q; +} + +static size_t +getdata(char **p, unsigned char *buf, size_t len) +{ + size_t i; + int v; + char *q = nexttoken(p); + i = 0; + while(*q && i < len) { + if(sscanf(q, "%02x", &v) != 1) + break; + buf[i++] = v; + q += 2; + } + return i; +} + +static int +getint(char **p) +{ + int val; + char *q = nexttoken(p); + sscanf(q, "%d", &val); + return val; +} + +#include <kadm5/admin.h> + +static void +attr_to_flags(unsigned attr, HDBFlags *flags) +{ + flags->postdate = !(attr & KRB5_KDB_DISALLOW_POSTDATED); + flags->forwardable = !(attr & KRB5_KDB_DISALLOW_FORWARDABLE); + flags->initial = !!(attr & KRB5_KDB_DISALLOW_TGT_BASED); + flags->renewable = !(attr & KRB5_KDB_DISALLOW_RENEWABLE); + flags->proxiable = !(attr & KRB5_KDB_DISALLOW_PROXIABLE); + /* DUP_SKEY */ + flags->invalid = !!(attr & KRB5_KDB_DISALLOW_ALL_TIX); + flags->require_preauth = !!(attr & KRB5_KDB_REQUIRES_PRE_AUTH); + /* HW_AUTH */ + flags->server = !(attr & KRB5_KDB_DISALLOW_SVR); + flags->change_pw = !!(attr & KRB5_KDB_PWCHANGE_SERVICE); + flags->client = 1; /* XXX */ +} + +#define KRB5_KDB_SALTTYPE_NORMAL 0 +#define KRB5_KDB_SALTTYPE_V4 1 +#define KRB5_KDB_SALTTYPE_NOREALM 2 +#define KRB5_KDB_SALTTYPE_ONLYREALM 3 +#define KRB5_KDB_SALTTYPE_SPECIAL 4 +#define KRB5_KDB_SALTTYPE_AFS3 5 + +static krb5_error_code +fix_salt(krb5_context context, hdb_entry *ent, int key_num) +{ + krb5_error_code ret; + Salt *salt = ent->keys.val[key_num].salt; + /* fix salt type */ + switch((int)salt->type) { + case KRB5_KDB_SALTTYPE_NORMAL: + salt->type = KRB5_PADATA_PW_SALT; + break; + case KRB5_KDB_SALTTYPE_V4: + krb5_data_free(&salt->salt); + salt->type = KRB5_PADATA_PW_SALT; + break; + case KRB5_KDB_SALTTYPE_NOREALM: + { + size_t len; + int i; + krb5_error_code ret; + char *p; + + len = 0; + for (i = 0; i < ent->principal->name.name_string.len; ++i) + len += strlen(ent->principal->name.name_string.val[i]); + ret = krb5_data_alloc (&salt->salt, len); + if (ret) + return ret; + p = salt->salt.data; + for (i = 0; i < ent->principal->name.name_string.len; ++i) { + memcpy (p, + ent->principal->name.name_string.val[i], + strlen(ent->principal->name.name_string.val[i])); + p += strlen(ent->principal->name.name_string.val[i]); + } + + salt->type = KRB5_PADATA_PW_SALT; + break; + } + case KRB5_KDB_SALTTYPE_ONLYREALM: + krb5_data_free(&salt->salt); + ret = krb5_data_copy(&salt->salt, + ent->principal->realm, + strlen(ent->principal->realm)); + if(ret) + return ret; + salt->type = KRB5_PADATA_PW_SALT; + break; + case KRB5_KDB_SALTTYPE_SPECIAL: + salt->type = KRB5_PADATA_PW_SALT; + break; + case KRB5_KDB_SALTTYPE_AFS3: + krb5_data_free(&salt->salt); + ret = krb5_data_copy(&salt->salt, + ent->principal->realm, + strlen(ent->principal->realm)); + if(ret) + return ret; + salt->type = KRB5_PADATA_AFS3_SALT; + break; + default: + abort(); + } + return 0; +} + +int +mit_prop_dump(void *arg, const char *file) +{ + krb5_error_code ret; + char buf [1024]; + FILE *f; + int lineno = 0; + struct hdb_entry ent; + + struct prop_data *pd = arg; + + f = fopen(file, "r"); + if(f == NULL) + return errno; + + while(fgets(buf, sizeof(buf), f)) { + char *p = buf, *q; + + int i; + + int num_tl_data; + int num_key_data; + int extra_data_length; + int attributes; + + int tmp; + + lineno++; + + memset(&ent, 0, sizeof(ent)); + + q = nexttoken(&p); + if(strcmp(q, "kdb5_util") == 0) { + int major; + q = nexttoken(&p); /* load_dump */ + if(strcmp(q, "load_dump")) + errx(1, "line %d: unknown version", lineno); + q = nexttoken(&p); /* load_dump */ + if(strcmp(q, "version")) + errx(1, "line %d: unknown version", lineno); + q = nexttoken(&p); /* x.0 */ + if(sscanf(q, "%d", &major) != 1) + errx(1, "line %d: unknown version", lineno); + if(major != 4) + errx(1, "unknown dump file format, got %d, expected 4", major); + continue; + } else if(strcmp(q, "princ") != 0) { + warnx("line %d: not a principal", lineno); + continue; + } + tmp = getint(&p); + if(tmp != 38) { + warnx("line %d: bad base length %d != 38", lineno, tmp); + continue; + } + q = nexttoken(&p); /* length of principal */ + num_tl_data = getint(&p); /* number of tl-data */ + num_key_data = getint(&p); /* number of key-data */ + extra_data_length = getint(&p); /* length of extra data */ + q = nexttoken(&p); /* principal name */ + krb5_parse_name(pd->context, q, &ent.principal); + attributes = getint(&p); /* attributes */ + attr_to_flags(attributes, &ent.flags); + tmp = getint(&p); /* max life */ + if(tmp != 0) { + ALLOC(ent.max_life); + *ent.max_life = tmp; + } + tmp = getint(&p); /* max renewable life */ + if(tmp != 0) { + ALLOC(ent.max_renew); + *ent.max_renew = tmp; + } + tmp = getint(&p); /* expiration */ + if(tmp != 0 && tmp != 2145830400) { + ALLOC(ent.valid_end); + *ent.valid_end = tmp; + } + tmp = getint(&p); /* pw expiration */ + if(tmp != 0) { + ALLOC(ent.pw_end); + *ent.pw_end = tmp; + } + q = nexttoken(&p); /* last auth */ + q = nexttoken(&p); /* last failed auth */ + q = nexttoken(&p); /* fail auth count */ + for(i = 0; i < num_tl_data; i++) { + unsigned long val; + int tl_type, tl_length; + unsigned char *buf; + krb5_principal princ; + + tl_type = getint(&p); /* data type */ + tl_length = getint(&p); /* data length */ + +#define KRB5_TL_LAST_PWD_CHANGE 1 +#define KRB5_TL_MOD_PRINC 2 + switch(tl_type) { + case KRB5_TL_MOD_PRINC: + buf = malloc(tl_length); + getdata(&p, buf, tl_length); /* data itself */ + val = buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24); + ret = krb5_parse_name(pd->context, buf + 4, &princ); + free(buf); + ALLOC(ent.modified_by); + ent.modified_by->time = val; + ent.modified_by->principal = princ; + break; + default: + nexttoken(&p); + break; + } + } + ALLOC_SEQ(&ent.keys, num_key_data); + for(i = 0; i < num_key_data; i++) { + int key_versions; + key_versions = getint(&p); /* key data version */ + ent.kvno = getint(&p); /* XXX kvno */ + + ALLOC(ent.keys.val[i].mkvno); + *ent.keys.val[i].mkvno = 0; + + /* key version 0 -- actual key */ + ent.keys.val[i].key.keytype = getint(&p); /* key type */ + tmp = getint(&p); /* key length */ + /* the first two bytes of the key is the key length -- + skip it */ + krb5_data_alloc(&ent.keys.val[i].key.keyvalue, tmp - 2); + q = nexttoken(&p); /* key itself */ + hex_to_octet_string(q + 4, &ent.keys.val[i].key.keyvalue); + + if(key_versions > 1) { + /* key version 1 -- optional salt */ + ALLOC(ent.keys.val[i].salt); + ent.keys.val[i].salt->type = getint(&p); /* salt type */ + tmp = getint(&p); /* salt length */ + if(tmp > 0) { + krb5_data_alloc(&ent.keys.val[i].salt->salt, tmp - 2); + q = nexttoken(&p); /* salt itself */ + hex_to_octet_string(q + 4, &ent.keys.val[i].salt->salt); + } else { + ent.keys.val[i].salt->salt.length = 0; + ent.keys.val[i].salt->salt.data = NULL; + tmp = getint(&p); /* -1, if no data. */ + } + fix_salt(pd->context, &ent, i); + } + } + q = nexttoken(&p); /* extra data */ + v5_prop(pd->context, NULL, &ent, arg); + } + return 0; +} diff --git a/crypto/heimdal/kdc/string2key.8 b/crypto/heimdal/kdc/string2key.8 new file mode 100644 index 000000000000..be8b1f65f88d --- /dev/null +++ b/crypto/heimdal/kdc/string2key.8 @@ -0,0 +1,76 @@ +.\" $Id: string2key.8,v 1.2 2000/03/04 14:02:55 assar Exp $ +.\" +.Dd March 4, 2000 +.Dt STRING2KEY 8 +.Os HEIMDAL +.Sh NAME +.Nm string2key +.Nd +map a password into a key +.Sh SYNOPSIS +.Nm +.Op Fl 5 | Fl -version5 +.Op Fl 4 | Fl -version4 +.Op Fl a | Fl -afs +.Oo Fl c Ar cell \*(Ba Xo +.Fl -cell= Ns Ar cell Oc +.Xc +.Oo Fl w Ar password \*(Ba Xo +.Fl -password= Ns Ar password Oc +.Xc +.Oo Fl p Ar principal \*(Ba Xo +.Fl -principal= Ns Ar principal Oc +.Xc +.Oo Fl k Ar string \*(Ba Xo +.Fl -keytype= Ns Ar string Oc +.Xc +.Ar password +.Sh DESCRIPTION +.Nm +performs the string-to-key function. +This is useful when you want to handle the raw key instead of the password. +Supported options: +.Bl -tag -width Ds +.It Xo +.Fl 5 Ns , +.Fl -version5 +.Xc +Output Kerberos v5 string-to-key +.It Xo +.Fl 4 Ns , +.Fl -version4 +.Xc +Output Kerberos v4 string-to-key +.It Xo +.Fl a Ns , +.Fl -afs +.Xc +Output AFS string-to-key +.It Xo +.Fl c Ar cell Ns , +.Fl -cell= Ns Ar cell +.Xc +AFS cell to use +.It Xo +.Fl w Ar password Ns , +.Fl -password= Ns Ar password +.Xc +Password to use +.It Xo +.Fl p Ar principal Ns , +.Fl -principal= Ns Ar principal +.Xc +Kerberos v5 principal to use +.It Xo +.Fl k Ar string Ns , +.Fl -keytype= Ns Ar string +.Xc +Keytype +.It Xo +.Fl -version +.Xc +print version +.It Xo +.Fl -help +.Xc +.El diff --git a/crypto/heimdal/kdc/v4_dump.c b/crypto/heimdal/kdc/v4_dump.c new file mode 100644 index 000000000000..dc0a8f20d439 --- /dev/null +++ b/crypto/heimdal/kdc/v4_dump.c @@ -0,0 +1,142 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "hprop.h" + +RCSID("$Id: v4_dump.c,v 1.4 2001/01/26 15:55:07 joda Exp $"); + +static time_t +time_parse(const char *cp) +{ + char wbuf[5]; + struct tm tp; + int local; + + memset(&tp, 0, sizeof(tp)); /* clear out the struct */ + + /* new format is YYYYMMDDHHMM UTC, + old format is YYMMDDHHMM local time */ + if (strlen(cp) > 10) { /* new format */ + strlcpy(wbuf, cp, sizeof(wbuf)); + tp.tm_year = atoi(wbuf) - 1900; + cp += 4; + local = 0; + } else { + wbuf[0] = *cp++; + wbuf[1] = *cp++; + wbuf[2] = '\0'; + tp.tm_year = atoi(wbuf); + if(tp.tm_year < 38) + tp.tm_year += 100; + local = 1; + } + + wbuf[0] = *cp++; + wbuf[1] = *cp++; + wbuf[2] = 0; + tp.tm_mon = atoi(wbuf) - 1; + + wbuf[0] = *cp++; + wbuf[1] = *cp++; + tp.tm_mday = atoi(wbuf); + + wbuf[0] = *cp++; + wbuf[1] = *cp++; + tp.tm_hour = atoi(wbuf); + + wbuf[0] = *cp++; + wbuf[1] = *cp++; + tp.tm_min = atoi(wbuf); + + return(tm2time(tp, local)); +} + +/* convert a version 4 dump file */ +int +v4_prop_dump(void *arg, const char *file) +{ + char buf [1024]; + FILE *f; + int lineno = 0; + + f = fopen(file, "r"); + if(f == NULL) + return errno; + + while(fgets(buf, sizeof(buf), f)) { + int ret; + unsigned long key[2]; /* yes, long */ + char exp_date[64], mod_date[64]; + struct v4_principal pr; + int attributes; + + memset(&pr, 0, sizeof(pr)); + errno = 0; + lineno++; + ret = sscanf(buf, "%s %s %d %d %d %d %lx %lx %s %s %s %s", + pr.name, pr.instance, + &pr.max_life, &pr.mkvno, &pr.kvno, + &attributes, + &key[0], &key[1], + exp_date, mod_date, + pr.mod_name, pr.mod_instance); + if(ret != 12){ + warnx("Line %d malformed (ignored)", lineno); + continue; + } + if(attributes != 0) { + warnx("Line %d (%s.%s) has non-zero attributes - skipping", + lineno, pr.name, pr.instance); + continue; + } + pr.key[0] = (key[0] >> 24) & 0xff; + pr.key[1] = (key[0] >> 16) & 0xff; + pr.key[2] = (key[0] >> 8) & 0xff; + pr.key[3] = (key[0] >> 0) & 0xff; + pr.key[4] = (key[1] >> 24) & 0xff; + pr.key[5] = (key[1] >> 16) & 0xff; + pr.key[6] = (key[1] >> 8) & 0xff; + pr.key[7] = (key[1] >> 0) & 0xff; + pr.exp_date = time_parse(exp_date); + pr.mod_date = time_parse(mod_date); + if (pr.instance[0] == '*') + pr.instance[0] = '\0'; + if (pr.mod_name[0] == '*') + pr.mod_name[0] = '\0'; + if (pr.mod_instance[0] == '*') + pr.mod_instance[0] = '\0'; + v4_prop(arg, &pr); + memset(&pr, 0, sizeof(pr)); + } + return 0; +} diff --git a/crypto/heimdal/kpasswd/kpasswd-generator.c b/crypto/heimdal/kpasswd/kpasswd-generator.c new file mode 100644 index 000000000000..6bd836c98041 --- /dev/null +++ b/crypto/heimdal/kpasswd/kpasswd-generator.c @@ -0,0 +1,193 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "kpasswd_locl.h" + +RCSID("$Id: kpasswd-generator.c,v 1.2 2000/12/31 07:47:38 assar Exp $"); + +static unsigned +read_words (const char *filename, char ***ret_w) +{ + unsigned n, alloc; + FILE *f; + char buf[256]; + char **w = NULL; + + f = fopen (filename, "r"); + if (f == NULL) + err (1, "cannot open %s", filename); + alloc = n = 0; + while (fgets (buf, sizeof(buf), f) != NULL) { + if (buf[strlen (buf) - 1] == '\n') + buf[strlen (buf) - 1] = '\0'; + if (n >= alloc) { + alloc += 16; + w = erealloc (w, alloc * sizeof(char **)); + } + w[n++] = estrdup (buf); + } + *ret_w = w; + return n; +} + +static int +nop_prompter (krb5_context context, + void *data, + const char *banner, + int num_prompts, + krb5_prompt prompts[]) +{ + return 0; +} + +static void +generate_requests (const char *filename, unsigned nreq) +{ + krb5_context context; + krb5_error_code ret; + int i; + char **words; + unsigned nwords; + + ret = krb5_init_context (&context); + if (ret) + errx (1, "krb5_init_context failed: %d", ret); + + nwords = read_words (filename, &words); + + for (i = 0; i < nreq; ++i) { + char *name = words[rand() % nwords]; + krb5_get_init_creds_opt opt; + krb5_creds cred; + krb5_principal principal; + int result_code; + krb5_data result_code_string, result_string; + char *old_pwd, *new_pwd; + + krb5_get_init_creds_opt_init (&opt); + krb5_get_init_creds_opt_set_tkt_life (&opt, 300); + krb5_get_init_creds_opt_set_forwardable (&opt, FALSE); + krb5_get_init_creds_opt_set_proxiable (&opt, FALSE); + + ret = krb5_parse_name (context, name, &principal); + if (ret) + krb5_err (context, 1, ret, "krb5_parse_name %s", name); + + asprintf (&old_pwd, "%s", name); + asprintf (&new_pwd, "%s2", name); + + ret = krb5_get_init_creds_password (context, + &cred, + principal, + old_pwd, + nop_prompter, + NULL, + 0, + "kadmin/changepw", + &opt); + if( ret == KRB5KRB_AP_ERR_BAD_INTEGRITY + || ret == KRB5KRB_AP_ERR_MODIFIED) { + char *tmp; + + tmp = new_pwd; + new_pwd = old_pwd; + old_pwd = tmp; + + ret = krb5_get_init_creds_password (context, + &cred, + principal, + old_pwd, + nop_prompter, + NULL, + 0, + "kadmin/changepw", + &opt); + } + if (ret) + krb5_err (context, 1, ret, "krb5_get_init_creds_password"); + + krb5_free_principal (context, principal); + + ret = krb5_change_password (context, &cred, new_pwd, + &result_code, + &result_code_string, + &result_string); + if (ret) + krb5_err (context, 1, ret, "krb5_change_password"); + + free (old_pwd); + free (new_pwd); + krb5_free_creds_contents (context, &cred); + } +} + +static int version_flag = 0; +static int help_flag = 0; + +static struct getargs args[] = { + { "version", 0, arg_flag, &version_flag }, + { "help", 0, arg_flag, &help_flag } +}; + +static void +usage (int ret) +{ + arg_printusage (args, + sizeof(args)/sizeof(*args), + NULL, + "file [number]"); + exit (ret); +} + +int +main(int argc, char **argv) +{ + int optind = 0; + int nreq; + char *end; + + set_progname(argv[0]); + if(getarg(args, sizeof(args) / sizeof(args[0]), argc, argv, &optind)) + usage(1); + argc -= optind; + argv += optind; + + if (argc != 2) + usage (1); + srand (0); + nreq = strtol (argv[1], &end, 0); + if (argv[1] == end || *end != '\0') + usage (1); + generate_requests (argv[0], nreq); + return 0; +} diff --git a/crypto/heimdal/kuser/generate-requests.c b/crypto/heimdal/kuser/generate-requests.c new file mode 100644 index 000000000000..f7f5dd1bbe59 --- /dev/null +++ b/crypto/heimdal/kuser/generate-requests.c @@ -0,0 +1,151 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "kuser_locl.h" + +RCSID("$Id: generate-requests.c,v 1.2 2000/12/31 07:49:27 assar Exp $"); + +static krb5_error_code +null_key_proc (krb5_context context, + krb5_enctype type, + krb5_salt salt, + krb5_const_pointer keyseed, + krb5_keyblock **key) +{ + return ENOTTY; +} + +static unsigned +read_words (const char *filename, char ***ret_w) +{ + unsigned n, alloc; + FILE *f; + char buf[256]; + char **w = NULL; + + f = fopen (filename, "r"); + if (f == NULL) + err (1, "cannot open %s", filename); + alloc = n = 0; + while (fgets (buf, sizeof(buf), f) != NULL) { + if (buf[strlen (buf) - 1] == '\n') + buf[strlen (buf) - 1] = '\0'; + if (n >= alloc) { + alloc += 16; + w = erealloc (w, alloc * sizeof(char **)); + } + w[n++] = estrdup (buf); + } + *ret_w = w; + return n; +} + +static void +generate_requests (const char *filename, unsigned nreq) +{ + krb5_context context; + krb5_error_code ret; + krb5_creds cred; + int i; + char **words; + unsigned nwords; + + ret = krb5_init_context (&context); + if (ret) + errx (1, "krb5_init_context failed: %d", ret); + + nwords = read_words (filename, &words); + + for (i = 0; i < nreq; ++i) { + char *name = words[rand() % nwords]; + krb5_realm *client_realm; + + memset(&cred, 0, sizeof(cred)); + + ret = krb5_parse_name (context, name, &cred.client); + if (ret) + krb5_err (context, 1, ret, "krb5_parse_name %s", name); + client_realm = krb5_princ_realm (context, cred.client); + + ret = krb5_make_principal(context, &cred.server, *client_realm, + KRB5_TGS_NAME, *client_realm, NULL); + if (ret) + krb5_err (context, 1, ret, "krb5_make_principal"); + + ret = krb5_get_in_cred (context, 0, NULL, NULL, NULL, NULL, + null_key_proc, NULL, NULL, NULL, + &cred, NULL); + krb5_free_creds_contents (context, &cred); + } +} + +static int version_flag = 0; +static int help_flag = 0; + +static struct getargs args[] = { + { "version", 0, arg_flag, &version_flag }, + { "help", 0, arg_flag, &help_flag } +}; + +static void +usage (int ret) +{ + arg_printusage (args, + sizeof(args)/sizeof(*args), + NULL, + "file number"); + exit (ret); +} + +int +main(int argc, char **argv) +{ + int optind = 0; + int nreq; + char *end; + + set_progname(argv[0]); + if(getarg(args, sizeof(args) / sizeof(args[0]), argc, argv, &optind)) + usage(1); + argc -= optind; + argv += optind; + + if (argc != 2) + usage (1); + srand (0); + nreq = strtol (argv[1], &end, 0); + if (argv[1] == end || *end != '\0') + usage (1); + generate_requests (argv[0], nreq); + return 0; +} diff --git a/crypto/heimdal/lib/asn1/asn1-common.h b/crypto/heimdal/lib/asn1/asn1-common.h new file mode 100644 index 000000000000..d3a30f275680 --- /dev/null +++ b/crypto/heimdal/lib/asn1/asn1-common.h @@ -0,0 +1,16 @@ +/* $Id: asn1-common.h,v 1.1 2000/04/14 15:41:31 joda Exp $ */ + +#include <stddef.h> +#include <time.h> + +#ifndef __asn1_common_definitions__ +#define __asn1_common_definitions__ + +typedef struct octet_string { + size_t length; + void *data; +} octet_string; + +typedef char *general_string; + +#endif diff --git a/crypto/heimdal/lib/asn1/pkinit.asn1 b/crypto/heimdal/lib/asn1/pkinit.asn1 new file mode 100644 index 000000000000..92c5de75daac --- /dev/null +++ b/crypto/heimdal/lib/asn1/pkinit.asn1 @@ -0,0 +1,189 @@ +PKINIT DEFINITIONS ::= BEGIN + +IMPORTS EncryptionKey, PrincipalName, Realm, KerberosTime, TypedData + FROM krb5; +IMPORTS SignedData, EnvelopedData FROM CMS; +IMPORTS CertificateSerialNumber, AttributeTypeAndValue, Name FROM X509; + + +-- 3.1 + +CertPrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF UTF8String +} + + +-- 3.2.2 + + +TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 +CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + +PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData[0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Hellman key exchange (if the + -- client public value was present in the + -- request). + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack[1] EnvelopedData + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. +} + + + +KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + nonce[0] INTEGER, + -- binds responce to the request + subjectPublicKey[2] BIT STRING + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING +} + +ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey[0] EncryptionKey, + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce[1] INTEGER + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator +} + +-- subjectAltName EXTENSION ::= { +-- SYNTAX GeneralNames +-- IDENTIFIED BY id-ce-subjectAltName +-- } + +OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value[0] OCTET STRING +-- value[0] EXPLICIT ANY DEFINED BY type-id +} + +GeneralName ::= CHOICE { + otherName [0] OtherName, + ... +} + +GeneralNames ::= SEQUENCE -- SIZE(1..MAX) + OF GeneralName + +KerberosName ::= SEQUENCE { + realm[0] Realm, + -- as defined in RFC 1510 + principalName[1] CertPrincipalName + -- defined above +} + + +-- krb5 OBJECT IDENTIFIER ::= { +-- iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) +-- } + +-- krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + +-- 3.2.1 + + +IssuerAndSerialNumber ::= SEQUENCE { + issuer Name, + serialNumber CertificateSerialNumber +} + +TrustedCas ::= CHOICE { + principalName[0] KerberosName, + -- as defined below + caName[1] Name, + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial[2] IssuerAndSerialNumber + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts +} + +PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack[0] SignedData, + -- defined in CMS [11] + -- AuthPack (below) defines the data + -- that is signed + trustedCertifiers[1] SEQUENCE OF TrustedCas OPTIONAL, + -- CAs that the client trusts + kdcCert[2] IssuerAndSerialNumber OPTIONAL, + -- as defined in CMS [11] + -- specifies a particular KDC + -- certificate if the client + -- already has it; + encryptionCert[3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. +} + +PKAuthenticator ::= SEQUENCE { + kdcName[0] PrincipalName, + kdcRealm[1] Realm, + cusec[2] INTEGER, + -- for replay prevention as in RFC1510 + ctime[3] KerberosTime, + -- for replay prevention as in RFC1510 + nonce[4] INTEGER +} + +-- This is the real definition of AlgorithmIdentifier +-- AlgorithmIdentifier ::= SEQUENCE { +-- algorithm ALGORITHM.&id, +-- parameters ALGORITHM.&Type +-- } -- as specified by the X.509 recommendation[10] + +-- But we'll use this one instead: + +AlgorithmIdentifier ::= SEQUENCE { + algorithm OBJECT IDENTIFIER, + parameters CHOICE { + a INTEGER + } +} + + + +SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) +} -- as specified by the X.509 recommendation[10] + +AuthPack ::= SEQUENCE { + pkAuthenticator[0] PKAuthenticator, + clientPublicValue[1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + -- (ephemeral-ephemeral only) +} + + +END diff --git a/crypto/heimdal/lib/asn1/rfc2459.asn1 b/crypto/heimdal/lib/asn1/rfc2459.asn1 new file mode 100644 index 000000000000..c9adec6093c6 --- /dev/null +++ b/crypto/heimdal/lib/asn1/rfc2459.asn1 @@ -0,0 +1,21 @@ +RFC2459 DEFINITIONS ::= BEGIN + +AttributeType ::= OBJECT-IDENTIFIER + +AttributeValue ::= OCTET STRING --ANY DEFINED BY AttributeType + +AttributeTypeAndValue ::= SEQUENCE { + type AttributeType, + value AttributeValue +} + +RelativeDistinguishedName ::= --SET +SEQUENCE OF AttributeTypeAndValue + +RDNSequence ::= SEQUENCE OF RelativeDistinguishedName + +Name ::= CHOICE { -- RFC2459 + x RDNSequence +} + +END
\ No newline at end of file diff --git a/crypto/heimdal/lib/asn1/x509.asn1 b/crypto/heimdal/lib/asn1/x509.asn1 new file mode 100644 index 000000000000..4a15844c8563 --- /dev/null +++ b/crypto/heimdal/lib/asn1/x509.asn1 @@ -0,0 +1,23 @@ +X509 DEFINITIONS ::= BEGIN + +CertificateSerialNumber ::= INTEGER -- X.509 '97 + +AttributeType ::= OBJECT-IDENTIFIER + +AttributeValue ::= OCTET STRING --ANY DEFINED BY AttributeType + +AttributeTypeAndValue ::= SEQUENCE { + type AttributeType, + value AttributeValue +} + +RelativeDistinguishedName ::= --SET +SEQUENCE OF AttributeTypeAndValue + +RDNSequence ::= SEQUENCE OF RelativeDistinguishedName + +Name ::= CHOICE { -- RFC2459 + x RDNSequence +} + +END
\ No newline at end of file diff --git a/crypto/heimdal/lib/com_err/ChangeLog b/crypto/heimdal/lib/com_err/ChangeLog new file mode 100644 index 000000000000..1ca005bce825 --- /dev/null +++ b/crypto/heimdal/lib/com_err/ChangeLog @@ -0,0 +1,127 @@ +2000-08-16 Assar Westerlund <assar@sics.se> + + * Makefile.am: bump version to 1:1:0 + +2000-07-31 Assar Westerlund <assar@sics.se> + + * com_right.h (initialize_error_table_r): fix prototype + +2000-04-05 Assar Westerlund <assar@sics.se> + + * com_err.c (_et_lit): explicitly initialize it to NULL to make + dyld on Darwin/MacOS X happy + +2000-01-16 Assar Westerlund <assar@sics.se> + + * com_err.h: remove __P definition (now in com_right.h). this + file always includes com_right.h so that's where it should reside. + * com_right.h: moved __P here and added it to the function + prototypes + * com_err.h (error_table_name): add __P + +1999-07-03 Assar Westerlund <assar@sics.se> + + * parse.y (statement): use asprintf + +1999-06-13 Assar Westerlund <assar@sics.se> + + * Makefile.in: make it solaris make vpath-safe + +Thu Apr 1 11:13:53 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * compile_et.c: use getargs + +Sat Mar 20 00:16:30 1999 Assar Westerlund <assar@sics.se> + + * compile_et.c: static-ize + +Thu Mar 18 11:22:13 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * Makefile.am: include Makefile.am.common + +Tue Mar 16 22:30:05 1999 Assar Westerlund <assar@sics.se> + + * parse.y: use YYACCEPT instead of return + +Sat Mar 13 22:22:56 1999 Assar Westerlund <assar@sics.se> + + * compile_et.c (generate_h): cast when calling is* to get rid of a + warning + +Thu Mar 11 15:00:51 1999 Johan Danielsson <joda@hella.pdc.kth.se> + + * parse.y: prototype for error_message + +Sun Nov 22 10:39:02 1998 Assar Westerlund <assar@sics.se> + + * compile_et.h: include ctype and roken + + * compile_et.c: include err.h + (generate_h): remove unused variable + + * Makefile.in (WFLAGS): set + +Fri Nov 20 06:58:59 1998 Assar Westerlund <assar@sics.se> + + * lex.l: undef ECHO to work around AIX lex bug + +Sun Sep 27 02:23:59 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * com_err.c (error_message): try to pass code to strerror, to see + if it might be an errno code (this if broken, but some MIT code + seems to expect this behaviour) + +Sat Sep 26 17:42:39 1998 Johan Danielsson <joda@hella.pdc.kth.se> + + * compile_et.c: <foo_err.h> -> "foo_err.h" + +Tue Jun 30 17:17:36 1998 Assar Westerlund <assar@sics.se> + + * Makefile.in: add str{cpy,cat}_truncate + +Mon May 25 05:24:39 1998 Assar Westerlund <assar@sics.se> + + * Makefile.in (clean): try to remove shared library debris + +Sun Apr 19 09:50:17 1998 Assar Westerlund <assar@sics.se> + + * Makefile.in: add symlink magic for linux + +Sun Apr 5 09:22:11 1998 Assar Westerlund <assar@sics.se> + + * parse.y: define alloca to malloc in case we're using bison but + don't have alloca + +Tue Mar 24 05:13:01 1998 Assar Westerlund <assar@sics.se> + + * Makefile.in: link with snprintf (From Derrick J Brashear + <shadow@dementia.org>) + +Fri Feb 27 05:01:42 1998 Assar Westerlund <assar@sics.se> + + * parse.y: initialize ec->next + +Thu Feb 26 02:22:25 1998 Assar Westerlund <assar@sics.se> + + * Makefile.am: @LEXLIB@ + +Sat Feb 21 15:18:54 1998 assar westerlund <assar@sics.se> + + * Makefile.in: set YACC and LEX + +Tue Feb 17 22:20:27 1998 Bjoern Groenvall <bg@sics.se> + + * com_right.h: Change typedefs so that one may mix MIT compile_et + generated code with krb4 dito. + +Tue Feb 17 16:30:55 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * compile_et.c (generate): Always return a value. + + * parse.y: Files don't have to end with `end'. + +Mon Feb 16 16:09:20 1998 Johan Danielsson <joda@emma.pdc.kth.se> + + * lex.l (getstring): Replace getc() with input(). + + * Makefile.am: Fixes for new compile_et. diff --git a/crypto/heimdal/lib/com_err/Makefile.am b/crypto/heimdal/lib/com_err/Makefile.am new file mode 100644 index 000000000000..8e1810801541 --- /dev/null +++ b/crypto/heimdal/lib/com_err/Makefile.am @@ -0,0 +1,24 @@ +# $Id: Makefile.am,v 1.24 2000/08/16 11:24:54 assar Exp $ + +include $(top_srcdir)/Makefile.am.common + +YFLAGS = -d + +lib_LTLIBRARIES = libcom_err.la +libcom_err_la_LDFLAGS = -version-info 1:1:0 + +bin_PROGRAMS = compile_et + +include_HEADERS = com_err.h com_right.h + +compile_et_SOURCES = compile_et.c compile_et.h parse.y lex.l + +libcom_err_la_SOURCES = error.c com_err.c roken_rename.h + +CLEANFILES = lex.c parse.c parse.h + +$(compile_et_OBJECTS): parse.h + +compile_et_LDADD = \ + $(LIB_roken) \ + $(LEXLIB) diff --git a/crypto/heimdal/lib/com_err/Makefile.in b/crypto/heimdal/lib/com_err/Makefile.in new file mode 100644 index 000000000000..986e078caae3 --- /dev/null +++ b/crypto/heimdal/lib/com_err/Makefile.in @@ -0,0 +1,649 @@ +# Makefile.in generated automatically by automake 1.4a from Makefile.am + +# Copyright (C) 1994, 1995-9, 2000 Free Software Foundation, Inc. +# This Makefile.in is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY, to the extent permitted by law; without +# even the implied warranty of MERCHANTABILITY or FITNESS FOR A +# PARTICULAR PURPOSE. + +SHELL = @SHELL@ + +srcdir = @srcdir@ +top_srcdir = @top_srcdir@ +VPATH = @srcdir@ +prefix = @prefix@ +exec_prefix = @exec_prefix@ + +bindir = @bindir@ +sbindir = @sbindir@ +libexecdir = @libexecdir@ +datadir = @datadir@ +sysconfdir = @sysconfdir@ +sharedstatedir = @sharedstatedir@ +localstatedir = @localstatedir@ +libdir = @libdir@ +infodir = @infodir@ +mandir = @mandir@ +includedir = @includedir@ +oldincludedir = /usr/include + +pkgdatadir = $(datadir)/@PACKAGE@ +pkglibdir = $(libdir)/@PACKAGE@ +pkgincludedir = $(includedir)/@PACKAGE@ + +top_builddir = ../.. + +ACLOCAL = @ACLOCAL@ +AUTOCONF = @AUTOCONF@ +AUTOMAKE = @AUTOMAKE@ +AUTOHEADER = @AUTOHEADER@ + +INSTALL = @INSTALL@ +INSTALL_PROGRAM = @INSTALL_PROGRAM@ +INSTALL_DATA = @INSTALL_DATA@ +INSTALL_SCRIPT = @INSTALL_SCRIPT@ +INSTALL_STRIP_FLAG = +transform = @program_transform_name@ + +NORMAL_INSTALL = : +PRE_INSTALL = : +POST_INSTALL = : +NORMAL_UNINSTALL = : +PRE_UNINSTALL = : +POST_UNINSTALL = : + +@SET_MAKE@ +host_alias = @host_alias@ +host_triplet = @host@ +AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@ +AMDEP = @AMDEP@ +AMTAR = @AMTAR@ +AS = @AS@ +AWK = @AWK@ +CANONICAL_HOST = @CANONICAL_HOST@ +CATMAN = @CATMAN@ +CATMANEXT = @CATMANEXT@ +CC = @CC@ +CPP = @CPP@ +CXX = @CXX@ +CXXCPP = @CXXCPP@ +DBLIB = @DBLIB@ +DEPDIR = @DEPDIR@ +DIR_des = @DIR_des@ +DIR_roken = @DIR_roken@ +DLLTOOL = @DLLTOOL@ +EXEEXT = @EXEEXT@ +EXTRA_LIB45 = @EXTRA_LIB45@ +GROFF = @GROFF@ +INCLUDES_roken = @INCLUDES_roken@ +INCLUDE_ = @INCLUDE_@ +LEX = @LEX@ +LIBOBJS = @LIBOBJS@ +LIBTOOL = @LIBTOOL@ +LIB_ = @LIB_@ +LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@ +LIB_des = @LIB_des@ +LIB_des_appl = @LIB_des_appl@ +LIB_kdb = @LIB_kdb@ +LIB_otp = @LIB_otp@ +LIB_roken = @LIB_roken@ +LIB_security = @LIB_security@ +LN_S = @LN_S@ +LTLIBOBJS = @LTLIBOBJS@ +MAKEINFO = @MAKEINFO@ +NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@ +NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@ +NROFF = @NROFF@ +OBJDUMP = @OBJDUMP@ +OBJEXT = @OBJEXT@ +PACKAGE = @PACKAGE@ +RANLIB = @RANLIB@ +STRIP = @STRIP@ +VERSION = @VERSION@ +VOID_RETSIGTYPE = @VOID_RETSIGTYPE@ +WFLAGS = @WFLAGS@ +WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@ +WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@ +YACC = @YACC@ +dpagaix_CFLAGS = @dpagaix_CFLAGS@ +dpagaix_LDADD = @dpagaix_LDADD@ +install_sh = @install_sh@ + +# $Id: Makefile.am,v 1.24 2000/08/16 11:24:54 assar Exp $ + + +# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $ + + +# $Id: Makefile.am.common,v 1.23 2000/12/05 09:11:09 joda Exp $ + + +AUTOMAKE_OPTIONS = foreign no-dependencies + +SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x + +INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken) + +AM_CFLAGS = $(WFLAGS) + +CP = cp + +COMPILE_ET = $(top_builddir)/lib/com_err/compile_et + +buildinclude = $(top_builddir)/include + +LIB_XauReadAuth = @LIB_XauReadAuth@ +LIB_crypt = @LIB_crypt@ +LIB_dbm_firstkey = @LIB_dbm_firstkey@ +LIB_dbopen = @LIB_dbopen@ +LIB_dlopen = @LIB_dlopen@ +LIB_dn_expand = @LIB_dn_expand@ +LIB_el_init = @LIB_el_init@ +LIB_getattr = @LIB_getattr@ +LIB_gethostbyname = @LIB_gethostbyname@ +LIB_getpwent_r = @LIB_getpwent_r@ +LIB_getpwnam_r = @LIB_getpwnam_r@ +LIB_getsockopt = @LIB_getsockopt@ +LIB_logout = @LIB_logout@ +LIB_logwtmp = @LIB_logwtmp@ +LIB_odm_initialize = @LIB_odm_initialize@ +LIB_pidfile = @LIB_pidfile@ +LIB_readline = @LIB_readline@ +LIB_res_search = @LIB_res_search@ +LIB_setpcred = @LIB_setpcred@ +LIB_setsockopt = @LIB_setsockopt@ +LIB_socket = @LIB_socket@ +LIB_syslog = @LIB_syslog@ +LIB_tgetent = @LIB_tgetent@ + +LIBS = @LIBS@ + +HESIODLIB = @HESIODLIB@ +HESIODINCLUDE = @HESIODINCLUDE@ +INCLUDE_hesiod = @INCLUDE_hesiod@ +LIB_hesiod = @LIB_hesiod@ + +INCLUDE_krb4 = @INCLUDE_krb4@ +LIB_krb4 = @LIB_krb4@ + +INCLUDE_openldap = @INCLUDE_openldap@ +LIB_openldap = @LIB_openldap@ + +INCLUDE_readline = @INCLUDE_readline@ + +LEXLIB = @LEXLIB@ + +NROFF_MAN = groff -mandoc -Tascii + +@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS) + +@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \ +@KRB5_TRUE@ $(top_builddir)/lib/asn1/libasn1.la +@KRB5_TRUE@LIB_gssapi = @KRB5_TRUE@$(top_builddir)/lib/gssapi/libgssapi.la + +CHECK_LOCAL = $(PROGRAMS) + +YFLAGS = -d + +lib_LTLIBRARIES = libcom_err.la +libcom_err_la_LDFLAGS = -version-info 1:1:0 + +bin_PROGRAMS = compile_et + +include_HEADERS = com_err.h com_right.h + +compile_et_SOURCES = compile_et.c compile_et.h parse.y lex.l + +libcom_err_la_SOURCES = error.c com_err.c roken_rename.h + +CLEANFILES = lex.c parse.c parse.h + +compile_et_LDADD = \ + $(LIB_roken) \ + $(LEXLIB) + +subdir = lib/com_err +mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs +CONFIG_HEADER = ../../include/config.h +CONFIG_CLEAN_FILES = +LTLIBRARIES = $(lib_LTLIBRARIES) + + +DEFS = @DEFS@ -I. -I$(srcdir) -I../../include +CPPFLAGS = @CPPFLAGS@ +LDFLAGS = @LDFLAGS@ +X_CFLAGS = @X_CFLAGS@ +X_LIBS = @X_LIBS@ +X_EXTRA_LIBS = @X_EXTRA_LIBS@ +X_PRE_LIBS = @X_PRE_LIBS@ +libcom_err_la_LIBADD = +am_libcom_err_la_OBJECTS = error.lo com_err.lo +libcom_err_la_OBJECTS = $(am_libcom_err_la_OBJECTS) +bin_PROGRAMS = compile_et$(EXEEXT) +PROGRAMS = $(bin_PROGRAMS) + +am_compile_et_OBJECTS = compile_et.$(OBJEXT) parse.$(OBJEXT) \ +lex.$(OBJEXT) +compile_et_OBJECTS = $(am_compile_et_OBJECTS) +compile_et_DEPENDENCIES = +compile_et_LDFLAGS = +COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +CFLAGS = @CFLAGS@ +LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@ +CCLD = $(CC) +LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ +DIST_SOURCES = $(libcom_err_la_SOURCES) $(compile_et_SOURCES) +HEADERS = $(include_HEADERS) + +depcomp = +DIST_COMMON = $(include_HEADERS) ChangeLog Makefile.am Makefile.in \ +lex.c parse.c parse.h + + +DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) + +GZIP_ENV = --best +SOURCES = $(libcom_err_la_SOURCES) $(compile_et_SOURCES) +OBJECTS = $(am_libcom_err_la_OBJECTS) $(am_compile_et_OBJECTS) + +all: all-redirect +.SUFFIXES: +.SUFFIXES: .1 .3 .5 .8 .c .cat1 .cat3 .cat5 .cat8 .et .h .l .lo .o .obj .x .y +$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4) $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common + cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/com_err/Makefile + +Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status + cd $(top_builddir) \ + && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status + + +mostlyclean-libLTLIBRARIES: + +clean-libLTLIBRARIES: + -test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES) + +distclean-libLTLIBRARIES: + +maintainer-clean-libLTLIBRARIES: + +install-libLTLIBRARIES: $(lib_LTLIBRARIES) + @$(NORMAL_INSTALL) + $(mkinstalldirs) $(DESTDIR)$(libdir) + @list='$(lib_LTLIBRARIES)'; for p in $$list; do \ + if test -f $$p; then \ + echo " $(LIBTOOL) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(libdir)/$$p"; \ + $(LIBTOOL) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(libdir)/$$p; \ + else :; fi; \ + done + +uninstall-libLTLIBRARIES: + @$(NORMAL_UNINSTALL) + @list='$(lib_LTLIBRARIES)'; for p in $$list; do \ + echo " $(LIBTOOL) --mode=uninstall rm -f $(DESTDIR)$(libdir)/$$p"; \ + $(LIBTOOL) --mode=uninstall rm -f $(DESTDIR)$(libdir)/$$p; \ + done + +mostlyclean-compile: + -rm -f *.o core *.core + -rm -f *.$(OBJEXT) + +clean-compile: + +distclean-compile: + -rm -f *.tab.c + +maintainer-clean-compile: + +mostlyclean-libtool: + -rm -f *.lo + +clean-libtool: + -rm -rf .libs _libs + +distclean-libtool: + +maintainer-clean-libtool: + +libcom_err.la: $(libcom_err_la_OBJECTS) $(libcom_err_la_DEPENDENCIES) + $(LINK) -rpath $(libdir) $(libcom_err_la_LDFLAGS) $(libcom_err_la_OBJECTS) $(libcom_err_la_LIBADD) $(LIBS) + +mostlyclean-binPROGRAMS: + +clean-binPROGRAMS: + -test -z "$(bin_PROGRAMS)" || rm -f $(bin_PROGRAMS) + +distclean-binPROGRAMS: + +maintainer-clean-binPROGRAMS: + +install-binPROGRAMS: $(bin_PROGRAMS) + @$(NORMAL_INSTALL) + $(mkinstalldirs) $(DESTDIR)$(bindir) + @list='$(bin_PROGRAMS)'; for p in $$list; do \ + if test -f $$p; then \ + f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \ + echo " $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f"; \ + $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f; \ + else :; fi; \ + done + +uninstall-binPROGRAMS: + @$(NORMAL_UNINSTALL) + @list='$(bin_PROGRAMS)'; for p in $$list; do \ + f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \ + echo " rm -f $(DESTDIR)$(bindir)/$$f"; \ + rm -f $(DESTDIR)$(bindir)/$$f; \ + done + +compile_et$(EXEEXT): $(compile_et_OBJECTS) $(compile_et_DEPENDENCIES) + @rm -f compile_et$(EXEEXT) + $(LINK) $(compile_et_LDFLAGS) $(compile_et_OBJECTS) $(compile_et_LDADD) $(LIBS) +.c.o: + $(COMPILE) -c $< +.c.obj: + $(COMPILE) -c `cygpath -w $<` +.c.lo: + $(LTCOMPILE) -c -o $@ $< +.l.c: + $(LEX) $(AM_LFLAGS) $(LFLAGS) $< && mv $(LEX_OUTPUT_ROOT).c $@ +.y.c: + $(YACC) $(AM_YFLAGS) $(YFLAGS) $< && mv y.tab.c $*.c + if test -f y.tab.h; then \ + if cmp -s y.tab.h $*.h; then rm -f y.tab.h; else mv y.tab.h $*.h; fi; \ + else :; fi +parse.h: parse.c + + +install-includeHEADERS: $(include_HEADERS) + @$(NORMAL_INSTALL) + $(mkinstalldirs) $(DESTDIR)$(includedir) + @list='$(include_HEADERS)'; for p in $$list; do \ + if test -f "$$p"; then d= ; else d="$(srcdir)/"; fi; \ + f="`echo $$p | sed -e 's|^.*/||'`"; \ + echo " $(INSTALL_DATA) $$d$$p $(DESTDIR)$(includedir)/$$f"; \ + $(INSTALL_DATA) $$d$$p $(DESTDIR)$(includedir)/$$f; \ + done + +uninstall-includeHEADERS: + @$(NORMAL_UNINSTALL) + @list='$(include_HEADERS)'; for p in $$list; do \ + f="`echo $$p | sed -e 's|^.*/||'`"; \ + echo " rm -f $(DESTDIR)$(includedir)/$$f"; \ + rm -f $(DESTDIR)$(includedir)/$$f; \ + done + +tags: TAGS + +ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES) + list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \ + unique=`for i in $$list; do \ + if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ + done | \ + $(AWK) ' { files[$$0] = 1; } \ + END { for (i in files) print i; }'`; \ + mkid -fID $$unique $(LISP) + +TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \ + $(TAGS_FILES) $(LISP) + tags=; \ + here=`pwd`; \ + list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \ + unique=`for i in $$list; do \ + if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ + done | \ + $(AWK) ' { files[$$0] = 1; } \ + END { for (i in files) print i; }'`; \ + test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \ + || etags $(ETAGS_ARGS) $$tags $$unique $(LISP) + +mostlyclean-tags: + +clean-tags: + +distclean-tags: + -rm -f TAGS ID + +maintainer-clean-tags: + +distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir) + +distdir: $(DISTFILES) + @for file in $(DISTFILES); do \ + d=$(srcdir); \ + if test -d $$d/$$file; then \ + cp -pR $$d/$$file $(distdir) \ + || exit 1; \ + else \ + test -f $(distdir)/$$file \ + || cp -p $$d/$$file $(distdir)/$$file \ + || exit 1; \ + fi; \ + done + $(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-hook +info-am: +info: info-am +dvi-am: +dvi: dvi-am +check-am: all-am + $(MAKE) $(AM_MAKEFLAGS) check-local +check: check-am +installcheck-am: +installcheck: installcheck-am +install-exec-am: install-libLTLIBRARIES install-binPROGRAMS + @$(NORMAL_INSTALL) + $(MAKE) $(AM_MAKEFLAGS) install-exec-hook +install-exec: install-exec-am + +install-data-am: install-includeHEADERS install-data-local +install-data: install-data-am + +install-am: all-am + @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am +install: install-am +uninstall-am: uninstall-libLTLIBRARIES uninstall-binPROGRAMS \ + uninstall-includeHEADERS +uninstall: uninstall-am +all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local +all-redirect: all-am +install-strip: + $(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install +installdirs: + $(mkinstalldirs) $(DESTDIR)$(libdir) $(DESTDIR)$(bindir) \ + $(DESTDIR)$(includedir) + + +mostlyclean-generic: + +clean-generic: + -test -z "$(CLEANFILES)" || rm -f $(CLEANFILES) + +distclean-generic: + -rm -f Makefile $(CONFIG_CLEAN_FILES) + -rm -f config.cache config.log stamp-h stamp-h[0-9]* + +maintainer-clean-generic: + -rm -f Makefile.in + -test -z "lex.cparse.hparse.c" || rm -f lex.c parse.h parse.c +mostlyclean-am: mostlyclean-libLTLIBRARIES mostlyclean-compile \ + mostlyclean-libtool mostlyclean-binPROGRAMS \ + mostlyclean-tags mostlyclean-generic + +mostlyclean: mostlyclean-am + +clean-am: clean-libLTLIBRARIES clean-compile clean-libtool \ + clean-binPROGRAMS clean-tags clean-generic \ + mostlyclean-am + +clean: clean-am + +distclean-am: distclean-libLTLIBRARIES distclean-compile \ + distclean-libtool distclean-binPROGRAMS distclean-tags \ + distclean-generic clean-am + -rm -f libtool + +distclean: distclean-am + +maintainer-clean-am: maintainer-clean-libLTLIBRARIES \ + maintainer-clean-compile maintainer-clean-libtool \ + maintainer-clean-binPROGRAMS maintainer-clean-tags \ + maintainer-clean-generic distclean-am + @echo "This command is intended for maintainers to use;" + @echo "it deletes files that may require special tools to rebuild." + +maintainer-clean: maintainer-clean-am + +.PHONY: mostlyclean-libLTLIBRARIES distclean-libLTLIBRARIES \ +clean-libLTLIBRARIES maintainer-clean-libLTLIBRARIES \ +uninstall-libLTLIBRARIES install-libLTLIBRARIES mostlyclean-compile \ +distclean-compile clean-compile maintainer-clean-compile \ +mostlyclean-libtool distclean-libtool clean-libtool \ +maintainer-clean-libtool mostlyclean-binPROGRAMS distclean-binPROGRAMS \ +clean-binPROGRAMS maintainer-clean-binPROGRAMS uninstall-binPROGRAMS \ +install-binPROGRAMS uninstall-includeHEADERS install-includeHEADERS \ +tags mostlyclean-tags distclean-tags clean-tags maintainer-clean-tags \ +distdir info-am info dvi-am dvi check-local check check-am \ +installcheck-am installcheck install-exec-am install-exec \ +install-data-local install-data-am install-data install-am install \ +uninstall-am uninstall all-local all-redirect all-am all install-strip \ +installdirs mostlyclean-generic distclean-generic clean-generic \ +maintainer-clean-generic clean mostlyclean distclean maintainer-clean + + +install-suid-programs: + @foo='$(bin_SUIDS)'; \ + for file in $$foo; do \ + x=$(DESTDIR)$(bindir)/$$file; \ + if chown 0:0 $$x && chmod u+s $$x; then :; else \ + echo "*"; \ + echo "* Failed to install $$x setuid root"; \ + echo "*"; \ + fi; done + +install-exec-hook: install-suid-programs + +install-build-headers:: $(include_HEADERS) $(build_HEADERZ) + @foo='$(include_HEADERS) $(build_HEADERZ)'; \ + for f in $$foo; do \ + f=`basename $$f`; \ + if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \ + else file="$$f"; fi; \ + if cmp -s $$file $(buildinclude)/$$f 2> /dev/null ; then \ + : ; else \ + echo " $(CP) $$file $(buildinclude)/$$f"; \ + $(CP) $$file $(buildinclude)/$$f; \ + fi ; \ + done + +all-local: install-build-headers +#NROFF_MAN = nroff -man +.1.cat1: + $(NROFF_MAN) $< > $@ +.3.cat3: + $(NROFF_MAN) $< > $@ +.5.cat5: + $(NROFF_MAN) $< > $@ +.8.cat8: + $(NROFF_MAN) $< > $@ + +dist-cat1-mans: + @foo='$(man1_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.1) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat3-mans: + @foo='$(man3_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.3) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat5-mans: + @foo='$(man5_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.5) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat8-mans: + @foo='$(man8_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.8) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans + +install-cat-mans: + $(SHELL) $(top_srcdir)/cf/install-catman.sh "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS) + +install-data-local: install-cat-mans + +.et.h: + $(COMPILE_ET) $< +.et.c: + $(COMPILE_ET) $< + +.x.c: + @cmp -s $< $@ 2> /dev/null || cp $< $@ + +check-local:: + @foo='$(CHECK_LOCAL)'; \ + if test "$$foo"; then \ + failed=0; all=0; \ + for i in $$foo; do \ + all=`expr $$all + 1`; \ + if ./$$i --version > /dev/null 2>&1; then \ + echo "PASS: $$i"; \ + else \ + echo "FAIL: $$i"; \ + failed=`expr $$failed + 1`; \ + fi; \ + done; \ + if test "$$failed" -eq 0; then \ + banner="All $$all tests passed"; \ + else \ + banner="$$failed of $$all tests failed"; \ + fi; \ + dashes=`echo "$$banner" | sed s/./=/g`; \ + echo "$$dashes"; \ + echo "$$banner"; \ + echo "$$dashes"; \ + test "$$failed" -eq 0; \ + fi + +$(compile_et_OBJECTS): parse.h + +# Tell versions [3.59,3.63) of GNU make to not export all variables. +# Otherwise a system limit (for SysV at least) may be exceeded. +.NOEXPORT: diff --git a/crypto/heimdal/lib/com_err/com_err.c b/crypto/heimdal/lib/com_err/com_err.c new file mode 100644 index 000000000000..25c679ef6100 --- /dev/null +++ b/crypto/heimdal/lib/com_err/com_err.c @@ -0,0 +1,151 @@ +/* + * Copyright (c) 1997 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: com_err.c,v 1.15 2000/04/04 22:04:55 assar Exp $"); +#endif +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <roken.h> +#include "com_err.h" + +struct et_list *_et_list = NULL; + + +const char * +error_message (long code) +{ + static char msg[128]; + const char *p = com_right(_et_list, code); + if (p == NULL) + p = strerror(code); + if (p != NULL && *p != '\0') { + strncpy(msg, p, sizeof(msg) - 1); + msg[sizeof(msg) - 1] = 0; + } else + sprintf(msg, "Unknown error %ld", code); + return msg; +} + +int +init_error_table(const char **msgs, long base, int count) +{ + initialize_error_table_r(&_et_list, msgs, count, base); + return 0; +} + +static void +default_proc (const char *whoami, long code, const char *fmt, va_list args) +{ + if (whoami) + fprintf(stderr, "%s: ", whoami); + if (code) + fprintf(stderr, "%s ", error_message(code)); + if (fmt) + vfprintf(stderr, fmt, args); + fprintf(stderr, "\r\n"); /* ??? */ +} + +static errf com_err_hook = default_proc; + +void +com_err_va (const char *whoami, + long code, + const char *fmt, + va_list args) +{ + (*com_err_hook) (whoami, code, fmt, args); +} + +void +com_err (const char *whoami, + long code, + const char *fmt, + ...) +{ + va_list ap; + va_start(ap, fmt); + com_err_va (whoami, code, fmt, ap); + va_end(ap); +} + +errf +set_com_err_hook (errf new) +{ + errf old = com_err_hook; + + if (new) + com_err_hook = new; + else + com_err_hook = default_proc; + + return old; +} + +errf +reset_com_err_hook (void) +{ + return set_com_err_hook(NULL); +} + +#define ERRCODE_RANGE 8 /* # of bits to shift table number */ +#define BITS_PER_CHAR 6 /* # bits to shift per character in name */ + +static const char char_set[] = + "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_"; + +static char buf[6]; + +const char * +error_table_name(int num) +{ + int ch; + int i; + char *p; + + /* num = aa aaa abb bbb bcc ccc cdd ddd d?? ??? ??? */ + p = buf; + num >>= ERRCODE_RANGE; + /* num = ?? ??? ??? aaa aaa bbb bbb ccc ccc ddd ddd */ + num &= 077777777; + /* num = 00 000 000 aaa aaa bbb bbb ccc ccc ddd ddd */ + for (i = 4; i >= 0; i--) { + ch = (num >> BITS_PER_CHAR * i) & ((1 << BITS_PER_CHAR) - 1); + if (ch != 0) + *p++ = char_set[ch-1]; + } + *p = '\0'; + return(buf); +} diff --git a/crypto/heimdal/lib/com_err/com_err.h b/crypto/heimdal/lib/com_err/com_err.h new file mode 100644 index 000000000000..9703336a0337 --- /dev/null +++ b/crypto/heimdal/lib/com_err/com_err.h @@ -0,0 +1,56 @@ +/* + * Copyright (c) 1997 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: com_err.h,v 1.6 2000/01/16 04:51:16 assar Exp $ */ + +/* MIT compatible com_err library */ + +#ifndef __COM_ERR_H__ +#define __COM_ERR_H__ + +#include <com_right.h> + +typedef void (*errf) __P((const char *, long, const char *, va_list)); + +const char * error_message __P((long)); +int init_error_table __P((const char**, long, int)); + +void com_err_va __P((const char *, long, const char *, va_list)); +void com_err __P((const char *, long, const char *, ...)); + +errf set_com_err_hook __P((errf)); +errf reset_com_err_hook __P((void)); + +const char *error_table_name __P((int num)); + +#endif /* __COM_ERR_H__ */ diff --git a/crypto/heimdal/lib/com_err/com_right.h b/crypto/heimdal/lib/com_err/com_right.h new file mode 100644 index 000000000000..c87bb0d1def8 --- /dev/null +++ b/crypto/heimdal/lib/com_err/com_right.h @@ -0,0 +1,66 @@ +/* + * Copyright (c) 1997 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: com_right.h,v 1.11 2000/07/31 01:11:08 assar Exp $ */ + +#ifndef __COM_RIGHT_H__ +#define __COM_RIGHT_H__ + +#ifdef __STDC__ +#include <stdarg.h> +#endif + +#ifndef __P +#ifdef __STDC__ +#define __P(X) X +#else +#define __P(X) () +#endif +#endif + +struct error_table { + char const * const * msgs; + long base; + int n_msgs; +}; +struct et_list { + struct et_list *next; + struct error_table *table; +}; +extern struct et_list *_et_list; + +const char *com_right __P((struct et_list *list, long code)); +void initialize_error_table_r __P((struct et_list **, const char **, int, long)); +void free_error_table __P((struct et_list *)); + +#endif /* __COM_RIGHT_H__ */ diff --git a/crypto/heimdal/lib/com_err/compile_et.c b/crypto/heimdal/lib/com_err/compile_et.c new file mode 100644 index 000000000000..f982dcd5a5ff --- /dev/null +++ b/crypto/heimdal/lib/com_err/compile_et.c @@ -0,0 +1,235 @@ +/* + * Copyright (c) 1998, 1999 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#undef ROKEN_RENAME +#include "compile_et.h" +#include <getarg.h> + +RCSID("$Id: compile_et.c,v 1.13 1999/12/02 16:58:38 joda Exp $"); + +#include <roken.h> +#include <err.h> +#include "parse.h" + +int numerror; +extern FILE *yyin; + +extern void yyparse(void); + +long base; +int number; +char *prefix; +char *id_str; + +char name[128]; +char Basename[128]; + +#ifdef YYDEBUG +extern int yydebug = 1; +#endif + +char *filename; +char hfn[128]; +char cfn[128]; + +struct error_code *codes = NULL; + +static int +generate_c(void) +{ + int n; + struct error_code *ec; + + FILE *c_file = fopen(cfn, "w"); + if(c_file == NULL) + return 1; + + fprintf(c_file, "/* Generated from %s */\n", filename); + if(id_str) + fprintf(c_file, "/* %s */\n", id_str); + fprintf(c_file, "\n"); + fprintf(c_file, "#include <stddef.h>\n"); + fprintf(c_file, "#include <com_err.h>\n"); + fprintf(c_file, "#include \"%s\"\n", hfn); + fprintf(c_file, "\n"); + + fprintf(c_file, "static const char *text[] = {\n"); + + for(ec = codes, n = 0; ec; ec = ec->next, n++) { + while(n < ec->number) { + fprintf(c_file, "\t/* %03d */ \"Reserved %s error (%d)\",\n", + n, name, n); + n++; + + } + fprintf(c_file, "\t/* %03d */ \"%s\",\n", ec->number, ec->string); + } + + fprintf(c_file, "\tNULL\n"); + fprintf(c_file, "};\n"); + fprintf(c_file, "\n"); + fprintf(c_file, + "void initialize_%s_error_table_r(struct et_list **list)\n", + name); + fprintf(c_file, "{\n"); + fprintf(c_file, + " initialize_error_table_r(list, text, " + "%s_num_errors, ERROR_TABLE_BASE_%s);\n", name, name); + fprintf(c_file, "}\n"); + fprintf(c_file, "\n"); + fprintf(c_file, "void initialize_%s_error_table(void)\n", name); + fprintf(c_file, "{\n"); + fprintf(c_file, + " init_error_table(text, ERROR_TABLE_BASE_%s, " + "%s_num_errors);\n", name, name); + fprintf(c_file, "}\n"); + + fclose(c_file); + return 0; +} + +static int +generate_h(void) +{ + struct error_code *ec; + char fn[128]; + FILE *h_file = fopen(hfn, "w"); + char *p; + + if(h_file == NULL) + return 1; + + snprintf(fn, sizeof(fn), "__%s__", hfn); + for(p = fn; *p; p++) + if(!isalnum((unsigned char)*p)) + *p = '_'; + + fprintf(h_file, "/* Generated from %s */\n", filename); + if(id_str) + fprintf(h_file, "/* %s */\n", id_str); + fprintf(h_file, "\n"); + fprintf(h_file, "#ifndef %s\n", fn); + fprintf(h_file, "#define %s\n", fn); + fprintf(h_file, "\n"); + fprintf(h_file, "#include <com_right.h>\n"); + fprintf(h_file, "\n"); + fprintf(h_file, + "void initialize_%s_error_table_r(struct et_list **);\n", + name); + fprintf(h_file, "\n"); + fprintf(h_file, "void initialize_%s_error_table(void);\n", name); + fprintf(h_file, "#define init_%s_err_tbl initialize_%s_error_table\n", + name, name); + fprintf(h_file, "\n"); + fprintf(h_file, "typedef enum %s_error_number{\n", name); + fprintf(h_file, "\tERROR_TABLE_BASE_%s = %ld,\n", name, base); + fprintf(h_file, "\t%s_err_base = %ld,\n", name, base); + + for(ec = codes; ec; ec = ec->next) { + fprintf(h_file, "\t%s = %ld,\n", ec->name, base + ec->number); + } + + fprintf(h_file, "\t%s_num_errors = %d\n", name, number); + fprintf(h_file, "} %s_error_number;\n", name); + fprintf(h_file, "\n"); + fprintf(h_file, "#endif /* %s */\n", fn); + + + fclose(h_file); + return 0; +} + +static int +generate(void) +{ + return generate_c() || generate_h(); +} + +int version_flag; +int help_flag; +struct getargs args[] = { + { "version", 0, arg_flag, &version_flag }, + { "help", 0, arg_flag, &help_flag } +}; +int num_args = sizeof(args) / sizeof(args[0]); + +static void +usage(int code) +{ + arg_printusage(args, num_args, NULL, "error-table"); + exit(code); +} + +int +main(int argc, char **argv) +{ + char *p; + int optind = 0; + + set_progname(argv[0]); + if(getarg(args, num_args, argc, argv, &optind)) + usage(1); + if(help_flag) + usage(0); + if(version_flag) { + print_version(NULL); + exit(0); + } + + if(optind == argc) + usage(1); + filename = argv[optind]; + yyin = fopen(filename, "r"); + if(yyin == NULL) + err(1, "%s", filename); + + + p = strrchr(filename, '/'); + if(p) + p++; + else + p = filename; + strncpy(Basename, p, sizeof(Basename)); + Basename[sizeof(Basename) - 1] = '\0'; + + Basename[strcspn(Basename, ".")] = '\0'; + + snprintf(hfn, sizeof(hfn), "%s.h", Basename); + snprintf(cfn, sizeof(cfn), "%s.c", Basename); + + yyparse(); + if(numerror) + return 1; + + return generate(); +} diff --git a/crypto/heimdal/lib/com_err/compile_et.h b/crypto/heimdal/lib/com_err/compile_et.h new file mode 100644 index 000000000000..86dd1131a7a7 --- /dev/null +++ b/crypto/heimdal/lib/com_err/compile_et.h @@ -0,0 +1,79 @@ +/* + * Copyright (c) 1998 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: compile_et.h,v 1.6 2000/07/01 20:21:48 assar Exp $ */ + +#ifndef __COMPILE_ET_H__ +#define __COMPILE_ET_H__ + +#ifdef HAVE_CONFIG_H +#include <config.h> +#endif + +#include <stdio.h> +#include <string.h> +#include <stdlib.h> +#include <stdarg.h> +#include <ctype.h> +#include <roken.h> + +extern long base; +extern int number; +extern char *prefix; +extern char name[128]; +extern char *id_str; +extern char *filename; +extern int numerror; + +struct error_code { + unsigned number; + char *name; + char *string; + struct error_code *next, **tail; +}; + +extern struct error_code *codes; + +#define APPEND(L, V) \ +do { \ + if((L) == NULL) { \ + (L) = (V); \ + (L)->tail = &(V)->next; \ + (L)->next = NULL; \ + }else{ \ + *(L)->tail = (V); \ + (L)->tail = &(V)->next; \ + } \ +}while(0) + +#endif /* __COMPILE_ET_H__ */ diff --git a/crypto/heimdal/lib/com_err/error.c b/crypto/heimdal/lib/com_err/error.c new file mode 100644 index 000000000000..d1220076d3da --- /dev/null +++ b/crypto/heimdal/lib/com_err/error.c @@ -0,0 +1,91 @@ +/* + * Copyright (c) 1997, 1998 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: error.c,v 1.14 1999/12/02 16:58:38 joda Exp $"); +#endif +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <com_right.h> + +const char * +com_right(struct et_list *list, long code) +{ + struct et_list *p; + for (p = list; p; p = p->next) { + if (code >= p->table->base && code < p->table->base + p->table->n_msgs) + return p->table->msgs[code - p->table->base]; + } + return NULL; +} + +struct foobar { + struct et_list etl; + struct error_table et; +}; + +void +initialize_error_table_r(struct et_list **list, + const char **messages, + int num_errors, + long base) +{ + struct et_list *et; + struct foobar *f; + for (et = *list; et; et = et->next) + if (et->table->msgs == messages) + return; + f = malloc(sizeof(*f)); + if (f == NULL) + return; + et = &f->etl; + et->table = &f->et; + et->table->msgs = messages; + et->table->n_msgs = num_errors; + et->table->base = base; + et->next = *list; + *list = et; +} + + +void +free_error_table(struct et_list *et) +{ + while(et){ + struct et_list *p = et; + et = et->next; + free(p); + } +} diff --git a/crypto/heimdal/lib/com_err/lex.h b/crypto/heimdal/lib/com_err/lex.h new file mode 100644 index 000000000000..9912bf4f0943 --- /dev/null +++ b/crypto/heimdal/lib/com_err/lex.h @@ -0,0 +1,39 @@ +/* + * Copyright (c) 1997 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: lex.h,v 1.1 2000/06/22 00:42:52 assar Exp $ */ + +void error_message (const char *, ...) +__attribute__ ((format (printf, 1, 2))); + +int yylex(void); diff --git a/crypto/heimdal/lib/com_err/lex.l b/crypto/heimdal/lib/com_err/lex.l new file mode 100644 index 000000000000..e98db6f86579 --- /dev/null +++ b/crypto/heimdal/lib/com_err/lex.l @@ -0,0 +1,126 @@ +%{ +/* + * Copyright (c) 1998 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* + * This is to handle the definition of this symbol in some AIX + * headers, which will conflict with the definition that lex will + * generate for it. It's only a problem for AIX lex. + */ + +#undef ECHO + +#include "compile_et.h" +#include "parse.h" +#include "lex.h" + +RCSID("$Id: lex.l,v 1.6 2000/06/22 00:42:52 assar Exp $"); + +static unsigned lineno = 1; +static int getstring(void); + +#define YY_NO_UNPUT + +#undef ECHO + +%} + + +%% +et { return ET; } +error_table { return ET; } +ec { return EC; } +error_code { return EC; } +prefix { return PREFIX; } +index { return INDEX; } +id { return ID; } +end { return END; } +[0-9]+ { yylval.number = atoi(yytext); return NUMBER; } +#[^\n]* ; +[ \t] ; +\n { lineno++; } +\" { return getstring(); } +[a-zA-Z0-9_]+ { yylval.string = strdup(yytext); return STRING; } +. { return *yytext; } +%% + +#ifndef yywrap /* XXX */ +int +yywrap () +{ + return 1; +} +#endif + +static int +getstring(void) +{ + char x[128]; + int i = 0; + int c; + int quote = 0; + while((c = input()) != EOF){ + if(quote) { + x[i++] = c; + quote = 0; + continue; + } + if(c == '\n'){ + error_message("unterminated string"); + lineno++; + break; + } + if(c == '\\'){ + quote++; + continue; + } + if(c == '\"') + break; + x[i++] = c; + } + x[i] = '\0'; + yylval.string = strdup(x); + return STRING; +} + +void +error_message (const char *format, ...) +{ + va_list args; + + va_start (args, format); + fprintf (stderr, "%s:%d:", filename, lineno); + vfprintf (stderr, format, args); + va_end (args); + numerror++; +} diff --git a/crypto/heimdal/lib/com_err/parse.y b/crypto/heimdal/lib/com_err/parse.y new file mode 100644 index 000000000000..82e99ffb809b --- /dev/null +++ b/crypto/heimdal/lib/com_err/parse.y @@ -0,0 +1,167 @@ +%{ +/* + * Copyright (c) 1998 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "compile_et.h" +#include "lex.h" + +RCSID("$Id: parse.y,v 1.11 2000/06/22 00:42:52 assar Exp $"); + +void yyerror (char *s); +static long name2number(const char *str); + +extern char *yytext; + +/* This is for bison */ + +#if !defined(alloca) && !defined(HAVE_ALLOCA) +#define alloca(x) malloc(x) +#endif + +%} + +%union { + char *string; + int number; +} + +%token ET INDEX PREFIX EC ID END +%token <string> STRING +%token <number> NUMBER + +%% + +file : /* */ + | header statements + ; + +header : id et + | et + ; + +id : ID STRING + { + id_str = $2; + } + ; + +et : ET STRING + { + base = name2number($2); + strncpy(name, $2, sizeof(name)); + name[sizeof(name) - 1] = '\0'; + free($2); + } + | ET STRING STRING + { + base = name2number($2); + strncpy(name, $3, sizeof(name)); + name[sizeof(name) - 1] = '\0'; + free($2); + free($3); + } + ; + +statements : statement + | statements statement + ; + +statement : INDEX NUMBER + { + number = $2; + } + | PREFIX STRING + { + prefix = realloc(prefix, strlen($2) + 2); + strcpy(prefix, $2); + strcat(prefix, "_"); + free($2); + } + | PREFIX + { + prefix = realloc(prefix, 1); + *prefix = '\0'; + } + | EC STRING ',' STRING + { + struct error_code *ec = malloc(sizeof(*ec)); + + ec->next = NULL; + ec->number = number; + if(prefix && *prefix != '\0') { + asprintf (&ec->name, "%s%s", prefix, $2); + free($2); + } else + ec->name = $2; + ec->string = $4; + APPEND(codes, ec); + number++; + } + | END + { + YYACCEPT; + } + ; + +%% + +static long +name2number(const char *str) +{ + const char *p; + long base = 0; + const char *x = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz0123456789_"; + if(strlen(str) > 4) { + yyerror("table name too long"); + return 0; + } + for(p = str; *p; p++){ + char *q = strchr(x, *p); + if(q == NULL) { + yyerror("invalid character in table name"); + return 0; + } + base = (base << 6) + (q - x) + 1; + } + base <<= 8; + if(base > 0x7fffffff) + base = -(0xffffffff - base + 1); + return base; +} + +void +yyerror (char *s) +{ + error_message ("%s\n", s); +} diff --git a/crypto/heimdal/lib/com_err/roken_rename.h b/crypto/heimdal/lib/com_err/roken_rename.h new file mode 100644 index 000000000000..173c9a7d5ae9 --- /dev/null +++ b/crypto/heimdal/lib/com_err/roken_rename.h @@ -0,0 +1,39 @@ +/* + * Copyright (c) 1998 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: roken_rename.h,v 1.3 1999/12/02 16:58:38 joda Exp $ */ + +#ifndef __roken_rename_h__ +#define __roken_rename_h__ + +#endif /* __roken_rename_h__ */ diff --git a/crypto/heimdal/lib/gssapi/address_to_krb5addr.c b/crypto/heimdal/lib/gssapi/address_to_krb5addr.c new file mode 100644 index 000000000000..1d8c1b6a5c34 --- /dev/null +++ b/crypto/heimdal/lib/gssapi/address_to_krb5addr.c @@ -0,0 +1,75 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "gssapi_locl.h" + +#include <roken.h> + +krb5_error_code +gss_address_to_krb5addr(OM_uint32 gss_addr_type, + gss_buffer_desc *gss_addr, + int16_t port, + krb5_address *address) +{ + int addr_type; + struct sockaddr sa; + int sa_size = sizeof(sa); + krb5_error_code problem; + + if (gss_addr == NULL) + return GSS_S_FAILURE; + + switch (gss_addr_type) { +#ifdef HAVE_IPV6 + case GSS_C_AF_INET6: addr_type = AF_INET6; + break; +#endif /* HAVE_IPV6 */ + + case GSS_C_AF_INET: addr_type = AF_INET; + break; + default: + return GSS_S_FAILURE; + } + + problem = krb5_h_addr2sockaddr (addr_type, + gss_addr->value, + &sa, + &sa_size, + port); + if (problem) + return GSS_S_FAILURE; + + problem = krb5_sockaddr2address (&sa, address); + + return problem; +} diff --git a/crypto/heimdal/lib/gssapi/copy_ccache.c b/crypto/heimdal/lib/gssapi/copy_ccache.c new file mode 100644 index 000000000000..f91acab4c397 --- /dev/null +++ b/crypto/heimdal/lib/gssapi/copy_ccache.c @@ -0,0 +1,56 @@ +/* + * Copyright (c) 2000 - 2001 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "gssapi_locl.h" + +RCSID("$Id: copy_ccache.c,v 1.1 2001/01/30 00:35:47 assar Exp $"); + +OM_uint32 +gss_krb5_copy_ccache(OM_uint32 *minor, + gss_cred_id_t cred, + krb5_ccache out) +{ + krb5_error_code kret; + + if (cred->ccache == NULL) { + *minor = EINVAL; + return GSS_S_FAILURE; + } + + kret = krb5_cc_copy_cache(gssapi_krb5_context, cred->ccache, out); + if (kret) { + *minor = kret; + return GSS_S_FAILURE; + } + return GSS_S_COMPLETE; +} diff --git a/crypto/heimdal/lib/hdb/db3.c b/crypto/heimdal/lib/hdb/db3.c new file mode 100644 index 000000000000..a682071a6077 --- /dev/null +++ b/crypto/heimdal/lib/hdb/db3.c @@ -0,0 +1,310 @@ +/* + * Copyright (c) 1997 - 2001 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "hdb_locl.h" + +RCSID("$Id: db3.c,v 1.6 2001/01/30 01:24:00 assar Exp $"); + +#if defined(HAVE_DB_H) && DB_VERSION_MAJOR == 3 +static krb5_error_code +DB_close(krb5_context context, HDB *db) +{ + DB *d = (DB*)db->db; + DBC *dbcp = (DBC*)db->dbc; + + dbcp->c_close(dbcp); + db->dbc = 0; + d->close(d, 0); + return 0; +} + +static krb5_error_code +DB_destroy(krb5_context context, HDB *db) +{ + krb5_error_code ret; + + ret = hdb_clear_master_key (context, db); + free(db->name); + free(db); + return ret; +} + +static krb5_error_code +DB_lock(krb5_context context, HDB *db, int operation) +{ + DB *d = (DB*)db->db; + int fd; + if ((*d->fd)(d, &fd)) + return HDB_ERR_CANT_LOCK_DB; + return hdb_lock(fd, operation); +} + +static krb5_error_code +DB_unlock(krb5_context context, HDB *db) +{ + DB *d = (DB*)db->db; + int fd; + if ((*d->fd)(d, &fd)) + return HDB_ERR_CANT_LOCK_DB; + return hdb_unlock(fd); +} + + +static krb5_error_code +DB_seq(krb5_context context, HDB *db, + unsigned flags, hdb_entry *entry, int flag) +{ + DB *d = (DB*)db->db; + DBT key, value; + DBC *dbcp = db->dbc; + krb5_data key_data, data; + int code; + + memset(&key, 0, sizeof(DBT)); + memset(&value, 0, sizeof(DBT)); + if (db->lock(context, db, HDB_RLOCK)) + return HDB_ERR_DB_INUSE; + code = dbcp->c_get(dbcp, &key, &value, flag); + db->unlock(context, db); /* XXX check value */ + if (code == DB_NOTFOUND) + return HDB_ERR_NOENTRY; + if (code) + return code; + + key_data.data = key.data; + key_data.length = key.size; + data.data = value.data; + data.length = value.size; + if (hdb_value2entry(context, &data, entry)) + return DB_seq(context, db, flags, entry, DB_NEXT); + if (db->master_key_set && (flags & HDB_F_DECRYPT)) { + code = hdb_unseal_keys (context, db, entry); + if (code) + hdb_free_entry (context, entry); + } + if (entry->principal == NULL) { + entry->principal = malloc(sizeof(*entry->principal)); + if (entry->principal == NULL) { + code = ENOMEM; + hdb_free_entry (context, entry); + } else { + hdb_key2principal(context, &key_data, entry->principal); + } + } + return 0; +} + + +static krb5_error_code +DB_firstkey(krb5_context context, HDB *db, unsigned flags, hdb_entry *entry) +{ + return DB_seq(context, db, flags, entry, DB_FIRST); +} + + +static krb5_error_code +DB_nextkey(krb5_context context, HDB *db, unsigned flags, hdb_entry *entry) +{ + return DB_seq(context, db, flags, entry, DB_NEXT); +} + +static krb5_error_code +DB_rename(krb5_context context, HDB *db, const char *new_name) +{ + int ret; + char *old, *new; + + asprintf(&old, "%s.db", db->name); + asprintf(&new, "%s.db", new_name); + ret = rename(old, new); + free(old); + free(new); + if(ret) + return errno; + + free(db->name); + db->name = strdup(new_name); + return 0; +} + +static krb5_error_code +DB__get(krb5_context context, HDB *db, krb5_data key, krb5_data *reply) +{ + DB *d = (DB*)db->db; + DBT k, v; + int code; + + memset(&k, 0, sizeof(DBT)); + memset(&v, 0, sizeof(DBT)); + k.data = key.data; + k.size = key.length; + k.flags = 0; + if ((code = db->lock(context, db, HDB_RLOCK))) + return code; + code = d->get(d, NULL, &k, &v, 0); + db->unlock(context, db); + if(code == DB_NOTFOUND) + return HDB_ERR_NOENTRY; + if(code) + return code; + + krb5_data_copy(reply, v.data, v.size); + return 0; +} + +static krb5_error_code +DB__put(krb5_context context, HDB *db, int replace, + krb5_data key, krb5_data value) +{ + DB *d = (DB*)db->db; + DBT k, v; + int code; + + memset(&k, 0, sizeof(DBT)); + memset(&v, 0, sizeof(DBT)); + k.data = key.data; + k.size = key.length; + k.flags = 0; + v.data = value.data; + v.size = value.length; + v.flags = 0; + if ((code = db->lock(context, db, HDB_WLOCK))) + return code; + code = d->put(d, NULL, &k, &v, replace ? 0 : DB_NOOVERWRITE); + db->unlock(context, db); + if(code == DB_KEYEXIST) + return HDB_ERR_EXISTS; + if(code) + return errno; + return 0; +} + +static krb5_error_code +DB__del(krb5_context context, HDB *db, krb5_data key) +{ + DB *d = (DB*)db->db; + DBT k; + krb5_error_code code; + memset(&k, 0, sizeof(DBT)); + k.data = key.data; + k.size = key.length; + k.flags = 0; + code = db->lock(context, db, HDB_WLOCK); + if(code) + return code; + code = d->del(d, NULL, &k, 0); + db->unlock(context, db); + if(code == DB_NOTFOUND) + return HDB_ERR_NOENTRY; + if(code) + return code; + return 0; +} + +static krb5_error_code +DB_open(krb5_context context, HDB *db, int flags, mode_t mode) +{ + char *fn; + krb5_error_code ret; + DB *d; + int myflags = 0; + + if (flags & O_CREAT) + myflags |= DB_CREATE; + + if (flags & O_EXCL) + myflags |= DB_EXCL; + + if (flags & O_RDONLY) + myflags |= DB_RDONLY; + + if (flags & O_TRUNC) + myflags |= DB_TRUNCATE; + + asprintf(&fn, "%s.db", db->name); + if (fn == NULL) + return ENOMEM; + db_create(&d, NULL, 0); + db->db = d; + if ((ret = d->open(db->db, fn, NULL, DB_BTREE, myflags, mode))) { + if(ret == ENOENT) + /* try to open without .db extension */ + if (d->open(db->db, db->name, NULL, DB_BTREE, myflags, mode)) { + free(fn); + return ret; + } + } + free(fn); + + ret = d->cursor(d, NULL, (DBC **)&db->dbc, 0); + if (ret) + return ret; + + if((flags & O_ACCMODE) == O_RDONLY) + ret = hdb_check_db_format(context, db); + else + ret = hdb_init_db(context, db); + if(ret == HDB_ERR_NOENTRY) + return 0; + return ret; +} + +krb5_error_code +hdb_db_create(krb5_context context, HDB **db, + const char *filename) +{ + *db = malloc(sizeof(**db)); + if (*db == NULL) + return ENOMEM; + + (*db)->db = NULL; + (*db)->name = strdup(filename); + (*db)->master_key_set = 0; + (*db)->openp = 0; + (*db)->open = DB_open; + (*db)->close = DB_close; + (*db)->fetch = _hdb_fetch; + (*db)->store = _hdb_store; + (*db)->remove = _hdb_remove; + (*db)->firstkey = DB_firstkey; + (*db)->nextkey= DB_nextkey; + (*db)->lock = DB_lock; + (*db)->unlock = DB_unlock; + (*db)->rename = DB_rename; + (*db)->_get = DB__get; + (*db)->_put = DB__put; + (*db)->_del = DB__del; + (*db)->destroy = DB_destroy; + return 0; +} +#endif diff --git a/crypto/heimdal/lib/hdb/hdb-ldap.c b/crypto/heimdal/lib/hdb/hdb-ldap.c new file mode 100644 index 000000000000..6d264b428153 --- /dev/null +++ b/crypto/heimdal/lib/hdb/hdb-ldap.c @@ -0,0 +1,1344 @@ +/* + * Copyright (c) 1999 - 2001, PADL Software Pty Ltd. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of PADL Software nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY PADL SOFTWARE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL PADL SOFTWARE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "hdb_locl.h" + +RCSID("$Id: hdb-ldap.c,v 1.7 2001/01/30 16:59:08 assar Exp $"); + +#ifdef OPENLDAP + +#include <ldap.h> +#include <lber.h> +#include <ctype.h> +#include <sys/un.h> + +static krb5_error_code LDAP__connect(krb5_context context, HDB * db); + +static krb5_error_code +LDAP_message2entry(krb5_context context, HDB * db, LDAPMessage * msg, + hdb_entry * ent); + +static char *krb5kdcentry_attrs[] = + { "krb5PrincipalName", "cn", "krb5PrincipalRealm", + "krb5KeyVersionNumber", "krb5Key", + "krb5ValidStart", "krb5ValidEnd", "krb5PasswordEnd", + "krb5MaxLife", "krb5MaxRenew", "krb5KDCFlags", "krb5EncryptionType", + "modifiersName", "modifyTimestamp", "creatorsName", "createTimestamp", + NULL +}; + +static char *krb5principal_attrs[] = + { "krb5PrincipalName", "cn", "krb5PrincipalRealm", + "modifiersName", "modifyTimestamp", "creatorsName", "createTimestamp", + NULL +}; + +/* based on samba: source/passdb/ldap.c */ +static krb5_error_code +LDAP_addmod_len(LDAPMod *** modlist, int modop, const char *attribute, + unsigned char *value, size_t len) +{ + LDAPMod **mods = *modlist; + int i, j; + + if (mods == NULL) { + mods = (LDAPMod **) calloc(1, sizeof(LDAPMod *)); + if (mods == NULL) { + return ENOMEM; + } + mods[0] = NULL; + } + + for (i = 0; mods[i] != NULL; ++i) { + if ((mods[i]->mod_op & (~LDAP_MOD_BVALUES)) == modop + && (!strcasecmp(mods[i]->mod_type, attribute))) { + break; + } + } + + if (mods[i] == NULL) { + mods = (LDAPMod **) realloc(mods, (i + 2) * sizeof(LDAPMod *)); + if (mods == NULL) { + return ENOMEM; + } + mods[i] = (LDAPMod *) malloc(sizeof(LDAPMod)); + if (mods[i] == NULL) { + return ENOMEM; + } + mods[i]->mod_op = modop | LDAP_MOD_BVALUES; + mods[i]->mod_bvalues = NULL; + mods[i]->mod_type = strdup(attribute); + if (mods[i]->mod_type == NULL) { + return ENOMEM; + } + mods[i + 1] = NULL; + } + + if (value != NULL) { + j = 0; + if (mods[i]->mod_bvalues != NULL) { + for (; mods[i]->mod_bvalues[j] != NULL; j++); + } + mods[i]->mod_bvalues = + (struct berval **) realloc(mods[i]->mod_bvalues, + (j + 2) * sizeof(struct berval *)); + if (mods[i]->mod_bvalues == NULL) { + return ENOMEM; + } + /* Caller allocates memory on our behalf, unlike LDAP_addmod. */ + mods[i]->mod_bvalues[j] = + (struct berval *) malloc(sizeof(struct berval)); + if (mods[i]->mod_bvalues[j] == NULL) { + return ENOMEM; + } + mods[i]->mod_bvalues[j]->bv_val = value; + mods[i]->mod_bvalues[j]->bv_len = len; + mods[i]->mod_bvalues[j + 1] = NULL; + } + *modlist = mods; + return 0; +} + +static krb5_error_code +LDAP_addmod(LDAPMod *** modlist, int modop, const char *attribute, + const char *value) +{ + LDAPMod **mods = *modlist; + int i, j; + + if (mods == NULL) { + mods = (LDAPMod **) calloc(1, sizeof(LDAPMod *)); + if (mods == NULL) { + return ENOMEM; + } + mods[0] = NULL; + } + + for (i = 0; mods[i] != NULL; ++i) { + if (mods[i]->mod_op == modop + && (!strcasecmp(mods[i]->mod_type, attribute))) { + break; + } + } + + if (mods[i] == NULL) { + mods = (LDAPMod **) realloc(mods, (i + 2) * sizeof(LDAPMod *)); + if (mods == NULL) { + return ENOMEM; + } + mods[i] = (LDAPMod *) malloc(sizeof(LDAPMod)); + if (mods[i] == NULL) { + return ENOMEM; + } + mods[i]->mod_op = modop; + mods[i]->mod_values = NULL; + mods[i]->mod_type = strdup(attribute); + if (mods[i]->mod_type == NULL) { + return ENOMEM; + } + mods[i + 1] = NULL; + } + + if (value != NULL) { + j = 0; + if (mods[i]->mod_values != NULL) { + for (; mods[i]->mod_values[j] != NULL; j++); + } + mods[i]->mod_values = (char **) realloc(mods[i]->mod_values, + (j + 2) * sizeof(char *)); + if (mods[i]->mod_values == NULL) { + return ENOMEM; + } + mods[i]->mod_values[j] = strdup(value); + if (mods[i]->mod_values[j] == NULL) { + return ENOMEM; + } + mods[i]->mod_values[j + 1] = NULL; + } + *modlist = mods; + return 0; +} + +static krb5_error_code +LDAP_addmod_generalized_time(LDAPMod *** mods, int modop, + const char *attribute, KerberosTime * time) +{ + char buf[22]; + struct tm *tm; + + /* XXX not threadsafe */ + tm = gmtime(time); + strftime(buf, sizeof(buf), "%Y%m%d%H%M%SZ", tm); + + return LDAP_addmod(mods, modop, attribute, buf); +} + +static krb5_error_code +LDAP_get_string_value(HDB * db, LDAPMessage * entry, + const char *attribute, char **ptr) +{ + char **vals; + int ret; + + vals = ldap_get_values((LDAP *) db->db, entry, (char *) attribute); + if (vals == NULL) { + return HDB_ERR_NOENTRY; + } + *ptr = strdup(vals[0]); + if (*ptr == NULL) { + ret = ENOMEM; + } else { + ret = 0; + } + + ldap_value_free(vals); + + return ret; +} + +static krb5_error_code +LDAP_get_integer_value(HDB * db, LDAPMessage * entry, + const char *attribute, int *ptr) +{ + char **vals; + + vals = ldap_get_values((LDAP *) db->db, entry, (char *) attribute); + if (vals == NULL) { + return HDB_ERR_NOENTRY; + } + *ptr = atoi(vals[0]); + ldap_value_free(vals); + return 0; +} + +static krb5_error_code +LDAP_get_generalized_time_value(HDB * db, LDAPMessage * entry, + const char *attribute, KerberosTime * kt) +{ + char *tmp, *gentime; + struct tm tm; + int ret; + + *kt = 0; + + ret = LDAP_get_string_value(db, entry, attribute, &gentime); + if (ret != 0) { + return ret; + } + + tmp = strptime(gentime, "%Y%m%d%H%M%SZ", &tm); + if (tmp == NULL) { + free(gentime); + return HDB_ERR_NOENTRY; + } + + free(gentime); + + *kt = timegm(&tm); + + return 0; +} + +static krb5_error_code +LDAP_entry2mods(krb5_context context, HDB * db, hdb_entry * ent, + LDAPMessage * msg, LDAPMod *** pmods) +{ + krb5_error_code ret; + krb5_boolean is_new_entry; + int rc, i; + char *tmp = NULL; + LDAPMod **mods = NULL; + hdb_entry orig; + unsigned long oflags, nflags; + + if (msg != NULL) { + ret = LDAP_message2entry(context, db, msg, &orig); + if (ret != 0) { + goto out; + } + is_new_entry = FALSE; + } else { + /* to make it perfectly obvious we're depending on + * orig being intiialized to zero */ + memset(&orig, 0, sizeof(orig)); + is_new_entry = TRUE; + } + + if (is_new_entry) { + ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "objectClass", "top"); + if (ret != 0) { + goto out; + } + /* person is the structural object class */ + ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "objectClass", "person"); + if (ret != 0) { + goto out; + } + ret = + LDAP_addmod(&mods, LDAP_MOD_ADD, "objectClass", + "krb5Principal"); + if (ret != 0) { + goto out; + } + ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "objectClass", + "krb5KDCEntry"); + if (ret != 0) { + goto out; + } + } + + if (is_new_entry || + krb5_principal_compare(context, ent->principal, orig.principal) == + FALSE) { + ret = krb5_unparse_name(context, ent->principal, &tmp); + if (ret != 0) { + goto out; + } + ret = + LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5PrincipalName", tmp); + if (ret != 0) { + free(tmp); + goto out; + } + free(tmp); + } + + if (ent->kvno != orig.kvno) { + rc = asprintf(&tmp, "%d", ent->kvno); + if (rc < 0) { + ret = ENOMEM; + goto out; + } + ret = + LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5KeyVersionNumber", + tmp); + free(tmp); + if (ret != 0) { + goto out; + } + } + + if (ent->valid_start) { + if (orig.valid_end == NULL + || (*(ent->valid_start) != *(orig.valid_start))) { + ret = + LDAP_addmod_generalized_time(&mods, LDAP_MOD_REPLACE, + "krb5ValidStart", + ent->valid_start); + if (ret != 0) { + goto out; + } + } + } + + if (ent->valid_end) { + if (orig.valid_end == NULL + || (*(ent->valid_end) != *(orig.valid_end))) { + ret = + LDAP_addmod_generalized_time(&mods, LDAP_MOD_REPLACE, + "krb5ValidEnd", + ent->valid_end); + if (ret != 0) { + goto out; + } + } + } + + if (ent->pw_end) { + if (orig.pw_end == NULL || (*(ent->pw_end) != *(orig.pw_end))) { + ret = + LDAP_addmod_generalized_time(&mods, LDAP_MOD_REPLACE, + "krb5PasswordEnd", + ent->pw_end); + if (ret != 0) { + goto out; + } + } + } + + if (ent->max_life) { + if (orig.max_life == NULL + || (*(ent->max_life) != *(orig.max_life))) { + rc = asprintf(&tmp, "%d", *(ent->max_life)); + if (rc < 0) { + ret = ENOMEM; + goto out; + } + ret = LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5MaxLife", tmp); + free(tmp); + if (ret != 0) { + goto out; + } + } + } + + if (ent->max_renew) { + if (orig.max_renew == NULL + || (*(ent->max_renew) != *(orig.max_renew))) { + rc = asprintf(&tmp, "%d", *(ent->max_renew)); + if (rc < 0) { + ret = ENOMEM; + goto out; + } + ret = + LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5MaxRenew", tmp); + free(tmp); + if (ret != 0) { + goto out; + } + } + } + + memset(&oflags, 0, sizeof(oflags)); + memcpy(&oflags, &orig.flags, sizeof(HDBFlags)); + memset(&nflags, 0, sizeof(nflags)); + memcpy(&nflags, &ent->flags, sizeof(HDBFlags)); + + if (memcmp(&oflags, &nflags, sizeof(HDBFlags))) { + rc = asprintf(&tmp, "%lu", nflags); + if (rc < 0) { + ret = ENOMEM; + goto out; + } + ret = LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5KDCFlags", tmp); + free(tmp); + if (ret != 0) { + goto out; + } + } + + if (is_new_entry == FALSE && orig.keys.len > 0) { + /* for the moment, clobber and replace keys. */ + ret = LDAP_addmod(&mods, LDAP_MOD_DELETE, "krb5Key", NULL); + if (ret != 0) { + goto out; + } + } + + for (i = 0; i < ent->keys.len; i++) { + unsigned char *buf; + size_t len; + Key new; + + ret = copy_Key(&ent->keys.val[i], &new); + if (ret != 0) { + goto out; + } + + len = length_Key(&new); + buf = malloc(len); + if (buf == NULL) { + ret = ENOMEM; + free_Key(&new); + goto out; + } + + ret = encode_Key(buf + len - 1, len, &new, &len); + if (ret != 0) { + free(buf); + free_Key(&new); + goto out; + } + free_Key(&new); + + /* addmod_len _owns_ the key, doesn't need to copy it */ + ret = LDAP_addmod_len(&mods, LDAP_MOD_ADD, "krb5Key", buf, len); + if (ret != 0) { + goto out; + } + } + + if (ent->etypes) { + /* clobber and replace encryption types. */ + if (is_new_entry == FALSE) { + ret = + LDAP_addmod(&mods, LDAP_MOD_DELETE, "krb5EncryptionType", + NULL); + } + for (i = 0; i < ent->etypes->len; i++) { + rc = asprintf(&tmp, "%d", ent->etypes->val[i]); + if (rc < 0) { + ret = ENOMEM; + goto out; + } + free(tmp); + ret = + LDAP_addmod(&mods, LDAP_MOD_ADD, "krb5EncryptionType", + tmp); + if (ret != 0) { + goto out; + } + } + } + + /* for clarity */ + ret = 0; + + out: + + if (ret == 0) { + *pmods = mods; + } else if (mods != NULL) { + ldap_mods_free(mods, 1); + *pmods = NULL; + } + + if (msg != NULL) { + hdb_free_entry(context, &orig); + } + + return ret; +} + +static krb5_error_code +LDAP_dn2principal(krb5_context context, HDB * db, const char *dn, + krb5_principal * principal) +{ + krb5_error_code ret; + int rc; + char **values; + LDAPMessage *res = NULL, *e; + + rc = 1; + (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_SIZELIMIT, &rc); + rc = ldap_search_s((LDAP *) db->db, db->name, LDAP_SCOPE_BASE, + "(objectclass=krb5Principal)", krb5principal_attrs, + 0, &res); + + if (rc != LDAP_SUCCESS) { + ret = HDB_ERR_NOENTRY; + goto out; + } + + e = ldap_first_entry((LDAP *) db->db, res); + if (e == NULL) { + ret = HDB_ERR_NOENTRY; + goto out; + } + + values = ldap_get_values((LDAP *) db->db, e, "krb5PrincipalName"); + if (values == NULL) { + ret = HDB_ERR_NOENTRY; + goto out; + } + + ret = krb5_parse_name(context, values[0], principal); + ldap_value_free(values); + + out: + if (res != NULL) { + ldap_msgfree(res); + } + return ret; +} + +static krb5_error_code +LDAP__lookup_princ(krb5_context context, HDB * db, const char *princname, + LDAPMessage ** msg) +{ + krb5_error_code ret; + int rc; + char *filter = NULL; + + (void) LDAP__connect(context, db); + + rc = + asprintf(&filter, + "(&(objectclass=krb5KDCEntry)(krb5PrincipalName=%s))", + princname); + if (rc < 0) { + ret = ENOMEM; + goto out; + } + + rc = 1; + (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_SIZELIMIT, (void *) &rc); + + rc = ldap_search_s((LDAP *) db->db, db->name, LDAP_SCOPE_ONELEVEL, filter, + krb5kdcentry_attrs, 0, msg); + if (rc != LDAP_SUCCESS) { + ret = HDB_ERR_NOENTRY; + goto out; + } + + ret = 0; + + out: + if (filter != NULL) { + free(filter); + } + return ret; +} + +static krb5_error_code +LDAP_principal2message(krb5_context context, HDB * db, + krb5_principal princ, LDAPMessage ** msg) +{ + char *princname = NULL; + krb5_error_code ret; + + ret = krb5_unparse_name(context, princ, &princname); + if (ret != 0) { + return ret; + } + + ret = LDAP__lookup_princ(context, db, princname, msg); + free(princname); + + return ret; +} + +/* + * Construct an hdb_entry from a directory entry. + */ +static krb5_error_code +LDAP_message2entry(krb5_context context, HDB * db, LDAPMessage * msg, + hdb_entry * ent) +{ + char *unparsed_name = NULL, *dn = NULL; + int ret; + unsigned long tmp; + struct berval **keys; + char **values; + + memset(ent, 0, sizeof(*ent)); + memset(&ent->flags, 0, sizeof(HDBFlags)); + + ret = + LDAP_get_string_value(db, msg, "krb5PrincipalName", + &unparsed_name); + if (ret != 0) { + return ret; + } + + ret = krb5_parse_name(context, unparsed_name, &ent->principal); + if (ret != 0) { + goto out; + } + + ret = + LDAP_get_integer_value(db, msg, "krb5KeyVersionNumber", + &ent->kvno); + if (ret != 0) { + ent->kvno = 0; + } + + keys = ldap_get_values_len((LDAP *) db->db, msg, "krb5Key"); + if (keys != NULL) { + int i; + size_t l; + + ent->keys.len = ldap_count_values_len(keys); + ent->keys.val = (Key *) calloc(ent->keys.len, sizeof(Key)); + for (i = 0; i < ent->keys.len; i++) { + decode_Key((unsigned char *) keys[i]->bv_val, + (size_t) keys[i]->bv_len, &ent->keys.val[i], &l); + } + ber_bvecfree(keys); + } else { +#if 1 + /* + * This violates the ASN1 but it allows a principal to + * be related to a general directory entry without creating + * the keys. Hopefully it's OK. + */ + ent->keys.len = 0; + ent->keys.val = NULL; +#else + ret = HDB_ERR_NOENTRY; + goto out; +#endif + } + + ret = + LDAP_get_generalized_time_value(db, msg, "createTimestamp", + &ent->created_by.time); + if (ret != 0) { + ent->created_by.time = time(NULL); + } + + ent->created_by.principal = NULL; + + ret = LDAP_get_string_value(db, msg, "creatorsName", &dn); + if (ret == 0) { + if (LDAP_dn2principal(context, db, dn, &ent->created_by.principal) + != 0) { + ent->created_by.principal = NULL; + } + free(dn); + } + + ent->modified_by = (Event *) malloc(sizeof(Event)); + if (ent->modified_by == NULL) { + ret = ENOMEM; + goto out; + } + ret = + LDAP_get_generalized_time_value(db, msg, "modifyTimestamp", + &ent->modified_by->time); + if (ret == 0) { + ret = LDAP_get_string_value(db, msg, "modifiersName", &dn); + if (LDAP_dn2principal + (context, db, dn, &ent->modified_by->principal) != 0) { + ent->modified_by->principal = NULL; + } + free(dn); + } else { + free(ent->modified_by); + ent->modified_by = NULL; + } + + if ((ent->valid_start = (KerberosTime *) malloc(sizeof(KerberosTime))) + == NULL) { + ret = ENOMEM; + goto out; + } + ret = + LDAP_get_generalized_time_value(db, msg, "krb5ValidStart", + ent->valid_start); + if (ret != 0) { + /* OPTIONAL */ + free(ent->valid_start); + ent->valid_start = NULL; + } + + if ((ent->valid_end = (KerberosTime *) malloc(sizeof(KerberosTime))) == + NULL) {ret = ENOMEM; + goto out; + } + ret = + LDAP_get_generalized_time_value(db, msg, "krb5ValidEnd", + ent->valid_end); + if (ret != 0) { + /* OPTIONAL */ + free(ent->valid_end); + ent->valid_end = NULL; + } + + if ((ent->pw_end = (KerberosTime *) malloc(sizeof(KerberosTime))) == + NULL) {ret = ENOMEM; + goto out; + } + ret = + LDAP_get_generalized_time_value(db, msg, "krb5PasswordEnd", + ent->pw_end); + if (ret != 0) { + /* OPTIONAL */ + free(ent->pw_end); + ent->pw_end = NULL; + } + + ent->max_life = (int *) malloc(sizeof(int)); + if (ent->max_life == NULL) { + ret = ENOMEM; + goto out; + } + ret = LDAP_get_integer_value(db, msg, "krb5MaxLife", ent->max_life); + if (ret != 0) { + free(ent->max_life); + ent->max_life = NULL; + } + + ent->max_renew = (int *) malloc(sizeof(int)); + if (ent->max_renew == NULL) { + ret = ENOMEM; + goto out; + } + ret = LDAP_get_integer_value(db, msg, "krb5MaxRenew", ent->max_renew); + if (ret != 0) { + free(ent->max_renew); + ent->max_renew = NULL; + } + + values = ldap_get_values((LDAP *) db->db, msg, "krb5KDCFlags"); + if (values != NULL) { + tmp = strtoul(values[0], (char **) NULL, 10); + if (tmp == ULONG_MAX && errno == ERANGE) { + ret = ERANGE; + goto out; + } + } else { + tmp = 0; + } + memcpy(&ent->flags, &tmp, sizeof(HDBFlags)); + + values = ldap_get_values((LDAP *) db->db, msg, "krb5EncryptionType"); + if (values != NULL) { + int i; + + ent->etypes = malloc(sizeof(*(ent->etypes))); + if (ent->etypes == NULL) { + ret = ENOMEM; + goto out; + } + ent->etypes->len = ldap_count_values(values); + ent->etypes->val = calloc(ent->etypes->len, sizeof(int)); + for (i = 0; i < ent->etypes->len; i++) { + ent->etypes->val[i] = atoi(values[i]); + } + ldap_value_free(values); + } + + ret = 0; + + out: + if (unparsed_name != NULL) { + free(unparsed_name); + } + + if (ret != 0) { + /* I don't think this frees ent itself. */ + hdb_free_entry(context, ent); + } + + return ret; +} + +static krb5_error_code LDAP_close(krb5_context context, HDB * db) +{ + LDAP *ld = (LDAP *) db->db; + + ldap_unbind(ld); + db->db = NULL; + return 0; +} + +static krb5_error_code +LDAP_lock(krb5_context context, HDB * db, int operation) +{ + return 0; +} + +static krb5_error_code LDAP_unlock(krb5_context context, HDB * db) +{ + return 0; +} + +static krb5_error_code +LDAP_seq(krb5_context context, HDB * db, unsigned flags, hdb_entry * entry) +{ + int msgid, rc, parserc; + krb5_error_code ret; + LDAPMessage *e; + + msgid = db->openp; /* BOGUS OVERLOADING */ + if (msgid < 0) { + return HDB_ERR_NOENTRY; + } + + do { + rc = ldap_result((LDAP *) db->db, msgid, LDAP_MSG_ONE, NULL, &e); + switch (rc) { + case LDAP_RES_SEARCH_ENTRY: + /* We have an entry. Parse it. */ + ret = LDAP_message2entry(context, db, e, entry); + ldap_msgfree(e); + break; + case LDAP_RES_SEARCH_RESULT: + /* We're probably at the end of the results. If not, abandon. */ + parserc = + ldap_parse_result((LDAP *) db->db, e, NULL, NULL, NULL, + NULL, NULL, 1); + if (parserc != LDAP_SUCCESS + && parserc != LDAP_MORE_RESULTS_TO_RETURN) { + ldap_abandon((LDAP *) db->db, msgid); + } + ret = HDB_ERR_NOENTRY; + db->openp = -1; + break; + case 0: + case -1: + default: + /* Some unspecified error (timeout?). Abandon. */ + ldap_msgfree(e); + ldap_abandon((LDAP *) db->db, msgid); + ret = HDB_ERR_NOENTRY; + db->openp = -1; + break; + } + } while (rc == LDAP_RES_SEARCH_REFERENCE); + + if (ret == 0) { + if (db->master_key_set && (flags & HDB_F_DECRYPT)) { + ret = hdb_unseal_keys(context, db, entry); + if (ret) + hdb_free_entry(context,entry); + } + } + + return ret; +} + +static krb5_error_code +LDAP_firstkey(krb5_context context, HDB * db, unsigned flags, + hdb_entry * entry) +{ + int msgid; + + (void) LDAP__connect(context, db); + + msgid = LDAP_NO_LIMIT; + (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_SIZELIMIT, &msgid); + + msgid = ldap_search((LDAP *) db->db, db->name, + LDAP_SCOPE_ONELEVEL, "(objectclass=krb5KDCEntry)", + krb5kdcentry_attrs, 0); + if (msgid < 0) { + return HDB_ERR_NOENTRY; + } + + db->openp = msgid; + + return LDAP_seq(context, db, flags, entry); +} + +static krb5_error_code +LDAP_nextkey(krb5_context context, HDB * db, unsigned flags, + hdb_entry * entry) +{ + return LDAP_seq(context, db, flags, entry); +} + +static krb5_error_code +LDAP_rename(krb5_context context, HDB * db, const char *new_name) +{ + return HDB_ERR_DB_INUSE; +} + +static krb5_boolean LDAP__is_user_namingcontext(const char *ctx, + char *const *subschema) +{ + char *const *p; + + if (!strcasecmp(ctx, "CN=MONITOR") + || !strcasecmp(ctx, "CN=CONFIG")) { + return FALSE; + } + + if (subschema != NULL) { + for (p = subschema; *p != NULL; p++) { + if (!strcasecmp(ctx, *p)) { + return FALSE; + } + } + } + + return TRUE; +} + +static krb5_error_code LDAP__connect(krb5_context context, HDB * db) +{ + int rc; + krb5_error_code ret; + char *attrs[] = { "namingContexts", "subschemaSubentry", NULL }; + LDAPMessage *res = NULL, *e; + + if (db->db != NULL) { + /* connection has been opened. ping server. */ + struct sockaddr_un addr; + socklen_t len; + int sd; + + if (ldap_get_option((LDAP *) db->db, LDAP_OPT_DESC, &sd) == 0 && + getpeername(sd, (struct sockaddr *) &addr, &len) < 0) { + /* the other end has died. reopen. */ + LDAP_close(context, db); + } + } + + if (db->db != NULL) { + /* server is UP */ + return 0; + } + + rc = ldap_initialize((LDAP **) & db->db, "ldapi:///"); + if (rc != LDAP_SUCCESS) { + return HDB_ERR_NOENTRY; + } + + rc = LDAP_VERSION3; + (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_PROTOCOL_VERSION, &rc); + + /* XXX set db->name to the search base */ + rc = ldap_search_s((LDAP *) db->db, "", LDAP_SCOPE_BASE, + "(objectclass=*)", attrs, 0, &res); + if (rc != LDAP_SUCCESS) { + ret = HDB_ERR_BADVERSION; + goto out; + } + + e = ldap_first_entry((LDAP *) db->db, res); + if (e == NULL) { + ret = HDB_ERR_NOENTRY; + goto out; + } + + if (db->name == NULL) { + char **contexts = NULL, **schema_contexts, **p; + + contexts = ldap_get_values((LDAP *) db->db, e, "namingContexts"); + if (contexts == NULL) { + ret = HDB_ERR_NOENTRY; + goto out; + } + + schema_contexts = + ldap_get_values((LDAP *) db->db, e, "subschemaSubentry"); + + if (db->name != NULL) { + free(db->name); + db->name = NULL; + } + + for (p = contexts; *p != NULL; p++) { + if (LDAP__is_user_namingcontext(*p, schema_contexts)) { + break; + } + } + + db->name = strdup(*p); + if (db->name == NULL) { + ldap_value_free(contexts); + ret = ENOMEM; + goto out; + } + + ldap_value_free(contexts); + if (schema_contexts != NULL) { + ldap_value_free(schema_contexts); + } + } + + ret = 0; + + out: + + if (res != NULL) { + ldap_msgfree(res); + } + + if (ret != 0) { + if (db->db != NULL) { + ldap_unbind((LDAP *) db->db); + db->db = NULL; + } + } + + return ret; +} + +static krb5_error_code +LDAP_open(krb5_context context, HDB * db, int flags, mode_t mode) +{ + krb5_error_code ret; + + /* Not the right place for this. */ +#ifdef HAVE_SIGACTION + { + struct sigaction sa; + + sa.sa_flags = 0; + sa.sa_handler = SIG_IGN; + sigemptyset(&sa.sa_mask); + + sigaction(SIGPIPE, &sa, NULL); + } +#else + signal(SIGPIPE, SIG_IGN); +#endif + + if (db->name != NULL) { + free(db->name); + db->name = NULL; + } + + ret = LDAP__connect(context, db); + if (ret != 0) { + return ret; + } + + return ret; +} + +static krb5_error_code +LDAP_fetch(krb5_context context, HDB * db, unsigned flags, + hdb_entry * entry) +{ + LDAPMessage *msg, *e; + krb5_error_code ret; + + ret = LDAP_principal2message(context, db, entry->principal, &msg); + if (ret != 0) { + return ret; + } + + e = ldap_first_entry((LDAP *) db->db, msg); + if (e == NULL) { + ret = HDB_ERR_NOENTRY; + goto out; + } + + ret = LDAP_message2entry(context, db, e, entry); + if (ret == 0) { + if (db->master_key_set && (flags & HDB_F_DECRYPT)) { + ret = hdb_unseal_keys(context, db, entry); + if (ret) + hdb_free_entry(context,entry); + } + } + + out: + ldap_msgfree(msg); + + return ret; +} + +static krb5_error_code +LDAP_store(krb5_context context, HDB * db, unsigned flags, + hdb_entry * entry) +{ + LDAPMod **mods = NULL; + krb5_error_code ret; + LDAPMessage *msg = NULL, *e = NULL; + char *dn = NULL, *name = NULL; + + ret = krb5_unparse_name(context, entry->principal, &name); + if (ret != 0) { + goto out; + } + + ret = LDAP__lookup_princ(context, db, name, &msg); + if (ret == 0) { + e = ldap_first_entry((LDAP *) db->db, msg); + } + + ret = hdb_seal_keys(context, db, entry); + if (ret) + goto out; + + /* turn new entry into LDAPMod array */ + ret = LDAP_entry2mods(context, db, entry, e, &mods); + if (ret != 0) { + goto out; + } + + if (e == NULL) { + /* Doesn't exist yet. */ + char *p; + + e = NULL; + + /* normalize the naming attribute */ + for (p = name; *p != '\0'; p++) { + *p = (char) tolower((int) *p); + } + + /* + * We could do getpwnam() on the local component of + * the principal to find cn/sn but that's probably + * bad thing to do from inside a KDC. Better leave + * it to management tools. + */ + ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "cn", name); + if (ret < 0) { + goto out; + } + + ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "sn", name); + if (ret < 0) { + goto out; + } + + ret = asprintf(&dn, "cn=%s,%s", name, db->name); + if (ret < 0) { + ret = ENOMEM; + goto out; + } + } else if (flags & HDB_F_REPLACE) { + /* Entry exists, and we're allowed to replace it. */ + dn = ldap_get_dn((LDAP *) db->db, e); + } else { + /* Entry exists, but we're not allowed to replace it. Bail. */ + ret = HDB_ERR_EXISTS; + goto out; + } + + /* write entry into directory */ + if (e == NULL) { + /* didn't exist before */ + ret = ldap_add_s((LDAP *) db->db, dn, mods); + } else { + /* already existed, send deltas only */ + ret = ldap_modify_s((LDAP *) db->db, dn, mods); + } + + if (ret == LDAP_SUCCESS) { + ret = 0; + } else { + ret = HDB_ERR_CANT_LOCK_DB; + } + + out: + /* free stuff */ + if (dn != NULL) { + free(dn); + } + + if (msg != NULL) { + ldap_msgfree(msg); + } + + if (mods != NULL) { + ldap_mods_free(mods, 1); + } + + if (name != NULL) { + free(name); + } + + return ret; +} + +static krb5_error_code +LDAP_remove(krb5_context context, HDB * db, hdb_entry * entry) +{ + krb5_error_code ret; + LDAPMessage *msg, *e; + char *dn = NULL; + + ret = LDAP_principal2message(context, db, entry->principal, &msg); + if (ret != 0) { + goto out; + } + + e = ldap_first_entry((LDAP *) db->db, msg); + if (e == NULL) { + ret = HDB_ERR_NOENTRY; + goto out; + } + + dn = ldap_get_dn((LDAP *) db->db, e); + if (dn == NULL) { + ret = HDB_ERR_NOENTRY; + goto out; + } + + ret = LDAP_NO_LIMIT; + (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_SIZELIMIT, &ret); + + ret = ldap_delete_s((LDAP *) db->db, dn); + if (ret == LDAP_SUCCESS) { + ret = 0; + } else { + ret = HDB_ERR_CANT_LOCK_DB; + } + + out: + if (dn != NULL) { + free(dn); + } + + if (msg != NULL) { + ldap_msgfree(msg); + } + + return ret; +} + +static krb5_error_code +LDAP__get(krb5_context context, HDB * db, krb5_data key, krb5_data * reply) +{ + fprintf(stderr, "LDAP__get not implemented\n"); + abort(); + return 0; +} + +static krb5_error_code +LDAP__put(krb5_context context, HDB * db, int replace, + krb5_data key, krb5_data value) +{ + fprintf(stderr, "LDAP__put not implemented\n"); + abort(); + return 0; +} + +static krb5_error_code +LDAP__del(krb5_context context, HDB * db, krb5_data key) +{ + fprintf(stderr, "LDAP__del not implemented\n"); + abort(); + return 0; +} + +static krb5_error_code LDAP_destroy(krb5_context context, HDB * db) +{ + krb5_error_code ret; + + ret = hdb_clear_master_key(context, db); + free(db->name); + free(db); + + return ret; +} + +krb5_error_code +hdb_ldap_create(krb5_context context, HDB ** db, const char *filename) +{ + *db = malloc(sizeof(**db)); + if (*db == NULL) + return ENOMEM; + + (*db)->db = NULL; +/* (*db)->name = strdup(filename); */ + (*db)->name = NULL; + (*db)->master_key_set = 0; + (*db)->openp = 0; + (*db)->open = LDAP_open; + (*db)->close = LDAP_close; + (*db)->fetch = LDAP_fetch; + (*db)->store = LDAP_store; + (*db)->remove = LDAP_remove; + (*db)->firstkey = LDAP_firstkey; + (*db)->nextkey = LDAP_nextkey; + (*db)->lock = LDAP_lock; + (*db)->unlock = LDAP_unlock; + (*db)->rename = LDAP_rename; + /* can we ditch these? */ + (*db)->_get = LDAP__get; + (*db)->_put = LDAP__put; + (*db)->_del = LDAP__del; + (*db)->destroy = LDAP_destroy; + + return 0; +} + +#endif /* OPENLDAP */ diff --git a/crypto/heimdal/lib/hdb/mkey.c b/crypto/heimdal/lib/hdb/mkey.c new file mode 100644 index 000000000000..2c853334f398 --- /dev/null +++ b/crypto/heimdal/lib/hdb/mkey.c @@ -0,0 +1,475 @@ +/* + * Copyright (c) 2000 - 2001 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "hdb_locl.h" +#ifndef O_BINARY +#define O_BINARY 0 +#endif + +RCSID("$Id: mkey.c,v 1.8 2001/01/30 01:20:57 assar Exp $"); + +struct hdb_master_key_data { + krb5_keytab_entry keytab; + krb5_crypto crypto; + struct hdb_master_key_data *next; +}; + +void +hdb_free_master_key(krb5_context context, hdb_master_key mkey) +{ + struct hdb_master_key_data *ptr; + while(mkey) { + krb5_kt_free_entry(context, &mkey->keytab); + krb5_crypto_destroy(context, mkey->crypto); + ptr = mkey; + mkey = mkey->next; + free(ptr); + } +} + +krb5_error_code +hdb_process_master_key(krb5_context context, + int kvno, krb5_keyblock *key, krb5_enctype etype, + hdb_master_key *mkey) +{ + krb5_error_code ret; + *mkey = calloc(1, sizeof(**mkey)); + if(*mkey == NULL) + return ENOMEM; + (*mkey)->keytab.vno = kvno; + ret = krb5_parse_name(context, "K/M", &(*mkey)->keytab.principal); + ret = krb5_copy_keyblock_contents(context, key, &(*mkey)->keytab.keyblock); + if(ret) { + free(*mkey); + *mkey = NULL; + return ret; + } + if(etype != 0) + (*mkey)->keytab.keyblock.keytype = etype; + (*mkey)->keytab.timestamp = time(NULL); + ret = krb5_crypto_init(context, key, etype, &(*mkey)->crypto); + if(ret) { + krb5_free_keyblock_contents(context, &(*mkey)->keytab.keyblock); + free(*mkey); + *mkey = NULL; + } + return ret; +} + +krb5_error_code +hdb_add_master_key(krb5_context context, krb5_keyblock *key, + hdb_master_key *inout) +{ + int vno = 0; + hdb_master_key p; + krb5_error_code ret; + + for(p = *inout; p; p = p->next) + vno = max(vno, p->keytab.vno); + vno++; + ret = hdb_process_master_key(context, vno, key, 0, &p); + if(ret) + return ret; + p->next = *inout; + *inout = p; + return 0; +} + +static krb5_error_code +read_master_keytab(krb5_context context, const char *filename, + hdb_master_key *mkey) +{ + krb5_error_code ret; + krb5_keytab id; + krb5_kt_cursor cursor; + krb5_keytab_entry entry; + hdb_master_key p; + + ret = krb5_kt_resolve(context, filename, &id); + if(ret) + return ret; + + ret = krb5_kt_start_seq_get(context, id, &cursor); + if(ret) + goto out; + *mkey = NULL; + while(krb5_kt_next_entry(context, id, &entry, &cursor) == 0) { + p = calloc(1, sizeof(*p)); + p->keytab = entry; + ret = krb5_crypto_init(context, &p->keytab.keyblock, 0, &p->crypto); + p->next = *mkey; + *mkey = p; + } + krb5_kt_end_seq_get(context, id, &cursor); + out: + krb5_kt_close(context, id); + return ret; +} + +/* read a MIT master keyfile */ +static krb5_error_code +read_master_mit(krb5_context context, const char *filename, + hdb_master_key *mkey) +{ + int fd; + krb5_error_code ret; + krb5_storage *sp; + u_int16_t enctype; + krb5_keyblock key; + + fd = open(filename, O_RDONLY | O_BINARY); + if(fd < 0) + return errno; + sp = krb5_storage_from_fd(fd); + if(sp == NULL) { + close(fd); + return errno; + } + krb5_storage_set_flags(sp, KRB5_STORAGE_HOST_BYTEORDER); +#if 0 + /* could possibly use ret_keyblock here, but do it with more + checks for now */ + ret = krb5_ret_keyblock(sp, &key); +#else + ret = krb5_ret_int16(sp, &enctype); + if((htons(enctype) & 0xff00) == 0x3000) { + ret = HEIM_ERR_BAD_MKEY; + goto out; + } + key.keytype = enctype; + ret = krb5_ret_data(sp, &key.keyvalue); + if(ret) + goto out; +#endif + ret = hdb_process_master_key(context, 0, &key, 0, mkey); + krb5_free_keyblock_contents(context, &key); + out: + krb5_storage_free(sp); + close(fd); + return ret; +} + +/* read an old master key file */ +static krb5_error_code +read_master_encryptionkey(krb5_context context, const char *filename, + hdb_master_key *mkey) +{ + int fd; + krb5_keyblock key; + krb5_error_code ret; + unsigned char buf[256]; + ssize_t len; + + fd = open(filename, O_RDONLY | O_BINARY); + if(fd < 0) + return errno; + + len = read(fd, buf, sizeof(buf)); + close(fd); + if(len < 0) + return errno; + + ret = decode_EncryptionKey(buf, len, &key, &len); + memset(buf, 0, sizeof(buf)); + if(ret) + return ret; + + /* Originally, the keytype was just that, and later it got changed + to des-cbc-md5, but we always used des in cfb64 mode. This + should cover all cases, but will break if someone has hacked + this code to really use des-cbc-md5 -- but then that's not my + problem. */ + if(key.keytype == KEYTYPE_DES || key.keytype == ETYPE_DES_CBC_MD5) + key.keytype = ETYPE_DES_CFB64_NONE; + + ret = hdb_process_master_key(context, 0, &key, 0, mkey); + krb5_free_keyblock_contents(context, &key); + return ret; +} + +/* read a krb4 /.k style file */ +static krb5_error_code +read_master_krb4(krb5_context context, const char *filename, + hdb_master_key *mkey) +{ + int fd; + krb5_keyblock key; + krb5_error_code ret; + unsigned char buf[256]; + ssize_t len; + + fd = open(filename, O_RDONLY | O_BINARY); + if(fd < 0) + return errno; + + len = read(fd, buf, sizeof(buf)); + close(fd); + if(len < 0) + return errno; + + memset(&key, 0, sizeof(key)); + key.keytype = ETYPE_DES_PCBC_NONE; + ret = krb5_data_copy(&key.keyvalue, buf, len); + memset(buf, 0, sizeof(buf)); + if(ret) + return ret; + + ret = hdb_process_master_key(context, 0, &key, 0, mkey); + krb5_free_keyblock_contents(context, &key); + return ret; +} + +krb5_error_code +hdb_read_master_key(krb5_context context, const char *filename, + hdb_master_key *mkey) +{ + FILE *f; + unsigned char buf[16]; + krb5_error_code ret; + + off_t len; + + *mkey = NULL; + + if(filename == NULL) + filename = HDB_DB_DIR "/m-key"; + + f = fopen(filename, "r"); + if(f == NULL) + return errno; + + if(fread(buf, 1, 2, f) != 2) { + fclose(f); + return HEIM_ERR_EOF; + } + + fseek(f, 0, SEEK_END); + len = ftell(f); + + if(fclose(f) != 0) + return errno; + + if(len < 0) + return errno; + + if(len == 8) { + ret = read_master_krb4(context, filename, mkey); + } else if(buf[0] == 0x30 && len <= 127 && buf[1] == len - 2) { + ret = read_master_encryptionkey(context, filename, mkey); + } else if(buf[0] == 5 && buf[1] >= 1 && buf[1] <= 2) { + ret = read_master_keytab(context, filename, mkey); + } else { + ret = read_master_mit(context, filename, mkey); + } + return ret; +} + +krb5_error_code +hdb_write_master_key(krb5_context context, const char *filename, + hdb_master_key mkey) +{ + krb5_error_code ret; + hdb_master_key p; + krb5_keytab kt; + + if(filename == NULL) + filename = HDB_DB_DIR "/m-key"; + + ret = krb5_kt_resolve(context, filename, &kt); + if(ret) + return ret; + + for(p = mkey; p; p = p->next) { + ret = krb5_kt_add_entry(context, kt, &p->keytab); + } + + krb5_kt_close(context, kt); + + return ret; +} + +static hdb_master_key +find_master_key(Key *key, hdb_master_key mkey) +{ + hdb_master_key ret = NULL; + while(mkey) { + if(ret == NULL && mkey->keytab.vno == 0) + ret = mkey; + if(key->mkvno == NULL) { + if(ret == NULL || mkey->keytab.vno > ret->keytab.vno) + ret = mkey; + } else if(mkey->keytab.vno == *key->mkvno) + return mkey; + mkey = mkey->next; + } + return ret; +} + +krb5_error_code +hdb_unseal_keys_mkey(krb5_context context, hdb_entry *ent, hdb_master_key mkey) +{ + int i; + krb5_error_code ret; + krb5_data res; + Key *k; + + for(i = 0; i < ent->keys.len; i++){ + hdb_master_key key; + + k = &ent->keys.val[i]; + if(k->mkvno == NULL) + continue; + + key = find_master_key(&ent->keys.val[i], mkey); + + if (key == NULL) + return HDB_ERR_NO_MKEY; + + ret = krb5_decrypt(context, key->crypto, HDB_KU_MKEY, + k->key.keyvalue.data, + k->key.keyvalue.length, + &res); + if (ret) + return ret; + + memset(k->key.keyvalue.data, 0, k->key.keyvalue.length); + free(k->key.keyvalue.data); + k->key.keyvalue = res; + free(k->mkvno); + k->mkvno = NULL; + } + return 0; +} + +krb5_error_code +hdb_unseal_keys(krb5_context context, HDB *db, hdb_entry *ent) +{ + if (db->master_key_set == 0) + return 0; + return hdb_unseal_keys_mkey(context, ent, db->master_key); +} + +krb5_error_code +hdb_seal_keys_mkey(krb5_context context, hdb_entry *ent, hdb_master_key mkey) +{ + int i; + krb5_error_code ret; + krb5_data res; + for(i = 0; i < ent->keys.len; i++){ + Key *k = &ent->keys.val[i]; + hdb_master_key key; + + if(k->mkvno != NULL) + continue; + + key = find_master_key(k, mkey); + + if (key == NULL) + return HDB_ERR_NO_MKEY; + + ret = krb5_encrypt(context, key->crypto, HDB_KU_MKEY, + k->key.keyvalue.data, + k->key.keyvalue.length, + &res); + if (ret) + return ret; + + memset(k->key.keyvalue.data, 0, k->key.keyvalue.length); + free(k->key.keyvalue.data); + k->key.keyvalue = res; + + k->mkvno = malloc(sizeof(*k->mkvno)); + if (k->mkvno == NULL) + return ENOMEM; + *k->mkvno = key->keytab.vno; + } + return 0; +} + +krb5_error_code +hdb_seal_keys(krb5_context context, HDB *db, hdb_entry *ent) +{ + if (db->master_key_set == 0) + return 0; + + return hdb_seal_keys_mkey(context, ent, db->master_key); +} + +krb5_error_code +hdb_set_master_key (krb5_context context, + HDB *db, + krb5_keyblock *key) +{ + krb5_error_code ret; + hdb_master_key mkey; + + ret = hdb_process_master_key(context, 0, key, 0, &mkey); + if (ret) + return ret; + db->master_key = mkey; +#if 0 /* XXX - why? */ + des_set_random_generator_seed(key.keyvalue.data); +#endif + db->master_key_set = 1; + return 0; +} + +krb5_error_code +hdb_set_master_keyfile (krb5_context context, + HDB *db, + const char *keyfile) +{ + hdb_master_key key; + krb5_error_code ret; + + ret = hdb_read_master_key(context, keyfile, &key); + if (ret) { + if (ret != ENOENT) + return ret; + return 0; + } + db->master_key = key; + db->master_key_set = 1; + return ret; +} + +krb5_error_code +hdb_clear_master_key (krb5_context context, + HDB *db) +{ + if (db->master_key_set) { + hdb_free_master_key(context, db->master_key); + db->master_key_set = 0; + } + return 0; +} diff --git a/crypto/heimdal/lib/kadm5/bump_pw_expire.c b/crypto/heimdal/lib/kadm5/bump_pw_expire.c new file mode 100644 index 000000000000..a185c20daff2 --- /dev/null +++ b/crypto/heimdal/lib/kadm5/bump_pw_expire.c @@ -0,0 +1,59 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "kadm5_locl.h" + +RCSID("$Id: bump_pw_expire.c,v 1.1 2000/07/24 03:47:54 assar Exp $"); + +/* + * extend password_expiration if it's defined + */ + +kadm5_ret_t +_kadm5_bump_pw_expire(kadm5_server_context *context, + hdb_entry *ent) +{ + if (ent->pw_end != NULL) { + time_t life; + + life = krb5_config_get_time_default(context->context, + NULL, + 365 * 24 * 60 * 60, + "kadmin", + "password_lifetime", + NULL); + + *(ent->pw_end) = time(NULL) + life; + } + return 0; +} diff --git a/crypto/heimdal/lib/kadm5/kadm5-private.h b/crypto/heimdal/lib/kadm5/kadm5-private.h new file mode 100644 index 000000000000..4e74a2be1442 --- /dev/null +++ b/crypto/heimdal/lib/kadm5/kadm5-private.h @@ -0,0 +1,245 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: kadm5-private.h,v 1.3 2000/07/24 04:31:17 assar Exp $ */ + +#ifndef __kadm5_privatex_h__ +#define __kadm5_privatex_h__ + +kadm5_ret_t _kadm5_privs_to_string (u_int32_t, char*, size_t); + +kadm5_ret_t _kadm5_string_to_privs (const char*, u_int32_t*); + +HDB *_kadm5_s_get_db (void *); + +kadm5_ret_t +_kadm5_acl_check_permission __P(( + kadm5_server_context *context, + unsigned op, + krb5_const_principal princ)); + +kadm5_ret_t +_kadm5_acl_init __P((kadm5_server_context *context)); + +kadm5_ret_t +_kadm5_c_init_context __P(( + kadm5_client_context **ctx, + kadm5_config_params *params, + krb5_context context)); + +kadm5_ret_t +_kadm5_client_recv __P(( + kadm5_client_context *context, + krb5_data *reply)); + +kadm5_ret_t +_kadm5_client_send __P(( + kadm5_client_context *context, + krb5_storage *sp)); + +kadm5_ret_t +_kadm5_connect __P((void*)); + +kadm5_ret_t +_kadm5_error_code __P((kadm5_ret_t code)); + +kadm5_ret_t +_kadm5_s_init_context __P(( + kadm5_server_context **ctx, + kadm5_config_params *params, + krb5_context context)); + +kadm5_ret_t +_kadm5_set_keys __P(( + kadm5_server_context *context, + hdb_entry *ent, + const char *password)); + +kadm5_ret_t +_kadm5_set_keys2 __P(( + kadm5_server_context *context, + hdb_entry *ent, + int16_t n_key_data, + krb5_key_data *key_data)); + +kadm5_ret_t +_kadm5_set_keys3 __P(( + kadm5_server_context *context, + hdb_entry *ent, + int n_keys, + krb5_keyblock *keyblocks)); + +kadm5_ret_t +_kadm5_set_keys_randomly __P((kadm5_server_context *context, + hdb_entry *ent, + krb5_keyblock **new_keys, + int *n_keys)); + +kadm5_ret_t +_kadm5_set_modifier __P(( + kadm5_server_context *context, + hdb_entry *ent)); + +kadm5_ret_t +_kadm5_bump_pw_expire __P((kadm5_server_context *context, + hdb_entry *ent)); + +kadm5_ret_t +_kadm5_setup_entry __P(( + kadm5_server_context *context, + hdb_entry *ent, + u_int32_t mask, + kadm5_principal_ent_t princ, + u_int32_t princ_mask, + kadm5_principal_ent_t def, + u_int32_t def_mask)); + +kadm5_ret_t +kadm5_log_get_version_fd (int fd, u_int32_t *ver); + +kadm5_ret_t +kadm5_log_get_version (kadm5_server_context *context, u_int32_t *ver); + +kadm5_ret_t +kadm5_log_set_version (kadm5_server_context *context, u_int32_t vno); + +kadm5_ret_t +kadm5_log_init (kadm5_server_context *context); + +kadm5_ret_t +kadm5_log_reinit (kadm5_server_context *context); + +kadm5_ret_t +kadm5_log_create (kadm5_server_context *context, + hdb_entry *ent); + +kadm5_ret_t +kadm5_log_delete (kadm5_server_context *context, + krb5_principal princ); + +kadm5_ret_t +kadm5_log_rename (kadm5_server_context *context, + krb5_principal source, + hdb_entry *ent); + +kadm5_ret_t +kadm5_log_modify (kadm5_server_context *context, + hdb_entry *ent, + u_int32_t mask); + +kadm5_ret_t +kadm5_log_nop (kadm5_server_context *context); + +kadm5_ret_t +kadm5_log_end (kadm5_server_context *context); + +kadm5_ret_t +kadm5_log_foreach (kadm5_server_context *context, + void (*func)(kadm5_server_context *server_context, + u_int32_t ver, + time_t timestamp, + enum kadm_ops op, + u_int32_t len, + krb5_storage *sp)); + +kadm5_ret_t +kadm5_log_replay_create (kadm5_server_context *context, + u_int32_t ver, + u_int32_t len, + krb5_storage *sp); + +kadm5_ret_t +kadm5_log_replay_delete (kadm5_server_context *context, + u_int32_t ver, + u_int32_t len, + krb5_storage *sp); + +kadm5_ret_t +kadm5_log_replay_rename (kadm5_server_context *context, + u_int32_t ver, + u_int32_t len, + krb5_storage *sp); + +kadm5_ret_t +kadm5_log_replay_modify (kadm5_server_context *context, + u_int32_t ver, + u_int32_t len, + krb5_storage *sp); + +kadm5_ret_t +kadm5_log_replay_nop (kadm5_server_context *context, + u_int32_t ver, + u_int32_t len, + krb5_storage *sp); + +kadm5_ret_t +kadm5_log_replay (kadm5_server_context *context, + enum kadm_ops op, + u_int32_t ver, + u_int32_t len, + krb5_storage *sp); + +krb5_storage * +kadm5_log_goto_end (int fd); + +kadm5_ret_t +kadm5_log_previous (krb5_storage *sp, + u_int32_t *ver, + time_t *timestamp, + enum kadm_ops *op, + u_int32_t *len); + +kadm5_ret_t +kadm5_log_truncate (kadm5_server_context *server_context); + +kadm5_ret_t +_kadm5_marshal_params __P((krb5_context context, + kadm5_config_params *params, + krb5_data *out)); + +kadm5_ret_t +_kadm5_unmarshal_params __P((krb5_context context, + krb5_data *in, + kadm5_config_params *params)); + +void +_kadm5_free_keys (kadm5_server_context *context, + int len, Key *keys); + +void +_kadm5_init_keys (Key *keys, int len); + +int +_kadm5_cmp_keys(Key *keys1, int len1, Key *keys2, int len2); + +#endif /* __kadm5_privatex_h__ */ diff --git a/crypto/heimdal/lib/kadm5/kadm5-protos.h b/crypto/heimdal/lib/kadm5/kadm5-protos.h new file mode 100644 index 000000000000..070492bb4a57 --- /dev/null +++ b/crypto/heimdal/lib/kadm5/kadm5-protos.h @@ -0,0 +1,516 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: kadm5-protos.h,v 1.2 2000/07/22 05:52:01 assar Exp $ */ + +#ifndef __kadm5_protos_h__ +#define __kadm5_protos_h__ + +kadm5_ret_t +kadm5_c_chpass_principal __P(( + void *server_handle, + krb5_principal princ, + char *password)); + +kadm5_ret_t +kadm5_c_chpass_principal_with_key __P(( + void *server_handle, + krb5_principal princ, + int n_key_data, + krb5_key_data *key_data)); + +kadm5_ret_t +kadm5_c_create_principal __P(( + void *server_handle, + kadm5_principal_ent_t princ, + u_int32_t mask, + char *password)); + +kadm5_ret_t +kadm5_c_delete_principal __P(( + void *server_handle, + krb5_principal princ)); + +kadm5_ret_t +kadm5_c_destroy __P((void *server_handle)); + +kadm5_ret_t +kadm5_c_flush __P((void *server_handle)); + +kadm5_ret_t +kadm5_c_get_principal __P(( + void *server_handle, + krb5_principal princ, + kadm5_principal_ent_t out, + u_int32_t mask)); + +kadm5_ret_t +kadm5_c_get_principals __P(( + void *server_handle, + const char *exp, + char ***princs, + int *count)); + +kadm5_ret_t +kadm5_c_get_privs __P(( + void *server_handle, + u_int32_t *privs)); + +kadm5_ret_t +kadm5_c_init_with_creds __P(( + const char *client_name, + krb5_ccache ccache, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_c_init_with_creds_ctx __P(( + krb5_context context, + const char *client_name, + krb5_ccache ccache, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_c_init_with_password __P(( + const char *client_name, + const char *password, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_c_init_with_password_ctx __P(( + krb5_context context, + const char *client_name, + const char *password, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_c_init_with_skey __P(( + const char *client_name, + const char *keytab, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_c_init_with_skey_ctx __P(( + krb5_context context, + const char *client_name, + const char *keytab, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_c_modify_principal __P(( + void *server_handle, + kadm5_principal_ent_t princ, + u_int32_t mask)); + +kadm5_ret_t +kadm5_c_randkey_principal __P(( + void *server_handle, + krb5_principal princ, + krb5_keyblock **new_keys, + int *n_keys)); + +kadm5_ret_t +kadm5_c_rename_principal __P(( + void *server_handle, + krb5_principal source, + krb5_principal target)); + +kadm5_ret_t +kadm5_chpass_principal __P(( + void *server_handle, + krb5_principal princ, + char *password)); + +kadm5_ret_t +kadm5_chpass_principal_with_key __P(( + void *server_handle, + krb5_principal princ, + int n_key_data, + krb5_key_data *key_data)); + +kadm5_ret_t +kadm5_create_principal __P(( + void *server_handle, + kadm5_principal_ent_t princ, + u_int32_t mask, + char *password)); + +kadm5_ret_t +kadm5_delete_principal __P(( + void *server_handle, + krb5_principal princ)); + +kadm5_ret_t +kadm5_destroy __P((void *server_handle)); + +kadm5_ret_t +kadm5_flush __P((void *server_handle)); + +void +kadm5_free_key_data __P(( + void *server_handle, + int16_t *n_key_data, + krb5_key_data *key_data)); + +void +kadm5_free_name_list __P(( + void *server_handle, + char **names, + int *count)); + +void +kadm5_free_principal_ent __P(( + void *server_handle, + kadm5_principal_ent_t princ)); + +kadm5_ret_t +kadm5_get_principal __P(( + void *server_handle, + krb5_principal princ, + kadm5_principal_ent_t out, + u_int32_t mask)); + +kadm5_ret_t +kadm5_get_principals __P(( + void *server_handle, + const char *exp, + char ***princs, + int *count)); + +kadm5_ret_t +kadm5_get_privs __P(( + void *server_handle, + u_int32_t *privs)); + +kadm5_ret_t +kadm5_init_with_creds __P(( + const char *client_name, + krb5_ccache ccache, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_init_with_creds_ctx __P(( + krb5_context context, + const char *client_name, + krb5_ccache ccache, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_init_with_password __P(( + const char *client_name, + const char *password, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_init_with_password_ctx __P(( + krb5_context context, + const char *client_name, + const char *password, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_init_with_skey __P(( + const char *client_name, + const char *keytab, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_init_with_skey_ctx __P(( + krb5_context context, + const char *client_name, + const char *keytab, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_modify_principal __P(( + void *server_handle, + kadm5_principal_ent_t princ, + u_int32_t mask)); + +kadm5_ret_t +kadm5_randkey_principal __P(( + void *server_handle, + krb5_principal princ, + krb5_keyblock **new_keys, + int *n_keys)); + +kadm5_ret_t +kadm5_rename_principal __P(( + void *server_handle, + krb5_principal source, + krb5_principal target)); + +kadm5_ret_t +kadm5_ret_key_data __P(( + krb5_storage *sp, + krb5_key_data *key)); + +kadm5_ret_t +kadm5_ret_principal_ent __P(( + krb5_storage *sp, + kadm5_principal_ent_t princ)); + +kadm5_ret_t +kadm5_ret_principal_ent_mask __P(( + krb5_storage *sp, + kadm5_principal_ent_t princ, + u_int32_t *mask)); + +kadm5_ret_t +kadm5_ret_tl_data __P(( + krb5_storage *sp, + krb5_tl_data *tl)); + +kadm5_ret_t +kadm5_s_chpass_principal __P(( + void *server_handle, + krb5_principal princ, + char *password)); + +kadm5_ret_t +kadm5_s_chpass_principal_cond __P(( + void *server_handle, + krb5_principal princ, + char *password)); + +kadm5_ret_t +kadm5_s_chpass_principal_with_key __P(( + void *server_handle, + krb5_principal princ, + int n_key_data, + krb5_key_data *key_data)); + +kadm5_ret_t +kadm5_s_create_principal __P(( + void *server_handle, + kadm5_principal_ent_t princ, + u_int32_t mask, + char *password)); + +kadm5_ret_t +kadm5_s_create_principal_with_key __P(( + void *server_handle, + kadm5_principal_ent_t princ, + u_int32_t mask)); + +kadm5_ret_t +kadm5_s_delete_principal __P(( + void *server_handle, + krb5_principal princ)); + +kadm5_ret_t +kadm5_s_destroy __P((void *server_handle)); + +kadm5_ret_t +kadm5_s_flush __P((void *server_handle)); + +kadm5_ret_t +kadm5_s_get_principal __P(( + void *server_handle, + krb5_principal princ, + kadm5_principal_ent_t out, + u_int32_t mask)); + +kadm5_ret_t +kadm5_s_get_principals __P(( + void *server_handle, + const char *exp, + char ***princs, + int *count)); + +kadm5_ret_t +kadm5_s_get_privs __P(( + void *server_handle, + u_int32_t *privs)); + +kadm5_ret_t +kadm5_s_init_with_creds __P(( + const char *client_name, + krb5_ccache ccache, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_s_init_with_creds_ctx __P(( + krb5_context context, + const char *client_name, + krb5_ccache ccache, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_s_init_with_password __P(( + const char *client_name, + const char *password, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_s_init_with_password_ctx __P(( + krb5_context context, + const char *client_name, + const char *password, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_s_init_with_skey __P(( + const char *client_name, + const char *keytab, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_s_init_with_skey_ctx __P(( + krb5_context context, + const char *client_name, + const char *keytab, + const char *service_name, + kadm5_config_params *realm_params, + unsigned long struct_version, + unsigned long api_version, + void **server_handle)); + +kadm5_ret_t +kadm5_s_modify_principal __P(( + void *server_handle, + kadm5_principal_ent_t princ, + u_int32_t mask)); + +kadm5_ret_t +kadm5_s_randkey_principal __P(( + void *server_handle, + krb5_principal princ, + krb5_keyblock **new_keys, + int *n_keys)); + +kadm5_ret_t +kadm5_s_rename_principal __P(( + void *server_handle, + krb5_principal source, + krb5_principal target)); + +kadm5_ret_t +kadm5_store_key_data __P(( + krb5_storage *sp, + krb5_key_data *key)); + +kadm5_ret_t +kadm5_store_principal_ent __P(( + krb5_storage *sp, + kadm5_principal_ent_t princ)); + +kadm5_ret_t +kadm5_store_principal_ent_mask __P(( + krb5_storage *sp, + kadm5_principal_ent_t princ, + u_int32_t mask)); + +kadm5_ret_t +kadm5_store_tl_data __P(( + krb5_storage *sp, + krb5_tl_data *tl)); + +void +kadm5_setup_passwd_quality_check(krb5_context context, + const char *check_library, + const char *check_function); + +const char * +kadm5_check_password_quality (krb5_context context, + krb5_principal principal, + krb5_data *pwd_data); + +#endif /* __kadm5_protos_h__ */ diff --git a/crypto/heimdal/lib/kadm5/keys.c b/crypto/heimdal/lib/kadm5/keys.c new file mode 100644 index 000000000000..3ae21abb4761 --- /dev/null +++ b/crypto/heimdal/lib/kadm5/keys.c @@ -0,0 +1,112 @@ +/* + * Copyright (c) 1997 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "kadm5_locl.h" + +RCSID("$Id: keys.c,v 1.1 2000/07/22 05:53:02 assar Exp $"); + +/* + * free all the memory used by (len, keys) + */ + +void +_kadm5_free_keys (kadm5_server_context *context, + int len, Key *keys) +{ + int i; + + for (i = 0; i < len; ++i) { + free (keys[i].mkvno); + keys[i].mkvno = NULL; + if (keys[i].salt != NULL) { + free_Salt(keys[i].salt); + free(keys[i].salt); + keys[i].salt = NULL; + } + krb5_free_keyblock_contents(context->context, &keys[i].key); + } + free (keys); +} + +/* + * null-ify `len', `keys' + */ + +void +_kadm5_init_keys (Key *keys, int len) +{ + int i; + + for (i = 0; i < len; ++i) { + keys[i].mkvno = NULL; + keys[i].salt = NULL; + keys[i].key.keyvalue.length = 0; + keys[i].key.keyvalue.data = NULL; + } +} + +/* + * return 0 iff `keys1, len1' and `keys2, len2' are identical + */ + +int +_kadm5_cmp_keys(Key *keys1, int len1, Key *keys2, int len2) +{ + int i; + + if (len1 != len2) + return 1; + + for (i = 0; i < len1; ++i) { + if ((keys1[i].salt != NULL && keys2[i].salt == NULL) + || (keys1[i].salt == NULL && keys2[i].salt != NULL)) + return 1; + if (keys1[i].salt != NULL) { + if (keys1[i].salt->type != keys2[i].salt->type) + return 1; + if (keys1[i].salt->salt.length != keys2[i].salt->salt.length) + return 1; + if (memcmp (keys1[i].salt->salt.data, keys2[i].salt->salt.data, + keys1[i].salt->salt.length) != 0) + return 1; + } + if (keys1[i].key.keytype != keys2[i].key.keytype) + return 1; + if (keys1[i].key.keyvalue.length != keys2[i].key.keyvalue.length) + return 1; + if (memcmp (keys1[i].key.keyvalue.data, keys2[i].key.keyvalue.data, + keys1[i].key.keyvalue.length) != 0) + return 1; + } + return 0; +} diff --git a/crypto/heimdal/lib/kadm5/truncate_log.c b/crypto/heimdal/lib/kadm5/truncate_log.c new file mode 100644 index 000000000000..215fdd7d3cb3 --- /dev/null +++ b/crypto/heimdal/lib/kadm5/truncate_log.c @@ -0,0 +1,88 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "iprop.h" + +RCSID("$Id: truncate_log.c,v 1.1 2000/07/24 04:27:06 assar Exp $"); + +static char *realm; +static int version_flag; +static int help_flag; + +static struct getargs args[] = { + { "realm", 'r', arg_string, &realm }, + { "version", 0, arg_flag, &version_flag }, + { "help", 0, arg_flag, &help_flag } +}; + +static int num_args = sizeof(args) / sizeof(args[0]); + +int +main(int argc, char **argv) +{ + krb5_context context; + krb5_error_code ret; + void *kadm_handle; + kadm5_server_context *server_context; + kadm5_config_params conf; + + krb5_program_setup(&context, argc, argv, args, num_args, NULL); + + if(help_flag) + krb5_std_usage(0, args, num_args); + if(version_flag) { + print_version(NULL); + exit(0); + } + + memset(&conf, 0, sizeof(conf)); + if(realm) { + conf.mask |= KADM5_CONFIG_REALM; + conf.realm = realm; + } + + ret = kadm5_init_with_password_ctx (context, + KADM5_ADMIN_SERVICE, + NULL, + KADM5_ADMIN_SERVICE, + &conf, 0, 0, + &kadm_handle); + if (ret) + krb5_err (context, 1, ret, "kadm5_init_with_password_ctx"); + + server_context = (kadm5_server_context *)kadm_handle; + + ret = kadm5_log_truncate (server_context); + krb5_err (context, 1, ret, "kadm5_log_truncate"); + return 0; +} diff --git a/crypto/heimdal/lib/krb5/acl.c b/crypto/heimdal/lib/krb5/acl.c new file mode 100644 index 000000000000..0106251ff580 --- /dev/null +++ b/crypto/heimdal/lib/krb5/acl.c @@ -0,0 +1,189 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "krb5_locl.h" +#include <fnmatch.h> + +RCSID("$Id: acl.c,v 1.1 2000/06/12 11:17:52 joda Exp $"); + +struct acl_field { + enum { acl_string, acl_fnmatch, acl_retval } type; + union { + const char *cstr; + char **retv; + } u; + struct acl_field *next, **last; +}; + +static void +acl_free_list(struct acl_field *acl) +{ + struct acl_field *next; + while(acl != NULL) { + next = acl->next; + free(acl); + acl = next; + } +} + +static krb5_error_code +acl_parse_format(krb5_context context, + struct acl_field **acl_ret, + const char *format, + va_list ap) +{ + const char *p; + struct acl_field *acl = NULL, *tmp; + + for(p = format; *p != '\0'; p++) { + tmp = malloc(sizeof(*tmp)); + if(tmp == NULL) { + acl_free_list(acl); + return ENOMEM; + } + if(*p == 's') { + tmp->type = acl_string; + tmp->u.cstr = va_arg(ap, const char*); + } else if(*p == 'f') { + tmp->type = acl_fnmatch; + tmp->u.cstr = va_arg(ap, const char*); + } else if(*p == 'r') { + tmp->type = acl_retval; + tmp->u.retv = va_arg(ap, char **); + } + tmp->next = NULL; + if(acl == NULL) + acl = tmp; + else + *acl->last = tmp; + acl->last = &tmp->next; + } + *acl_ret = acl; + return 0; +} + +static krb5_boolean +acl_match_field(krb5_context context, + const char *string, + struct acl_field *field) +{ + if(field->type == acl_string) { + return !strcmp(string, field->u.cstr); + } else if(field->type == acl_fnmatch) { + return !fnmatch(string, field->u.cstr, 0); + } else if(field->type == acl_retval) { + *field->u.retv = strdup(string); + return TRUE; + } + return FALSE; +} + +static krb5_boolean +acl_match_acl(krb5_context context, + struct acl_field *acl, + const char *string) +{ + char buf[256]; + for(;strsep_copy(&string, " \t", buf, sizeof(buf)) != -1; + acl = acl->next) { + if(buf[0] == '\0') + continue; /* skip ws */ + if(!acl_match_field(context, buf, acl)) { + return FALSE; + } + } + return TRUE; +} + + +krb5_error_code +krb5_acl_match_string(krb5_context context, + const char *acl_string, + const char *format, + ...) +{ + krb5_error_code ret; + struct acl_field *acl; + + va_list ap; + va_start(ap, format); + ret = acl_parse_format(context, &acl, format, ap); + va_end(ap); + if(ret) + return ret; + + ret = acl_match_acl(context, acl, acl_string); + + acl_free_list(acl); + return ret ? 0 : EACCES; +} + +krb5_error_code +krb5_acl_match_file(krb5_context context, + const char *file, + const char *format, + ...) +{ + krb5_error_code ret; + struct acl_field *acl; + char buf[256]; + va_list ap; + FILE *f; + + f = fopen(file, "r"); + if(f == NULL) + return errno; + + va_start(ap, format); + ret = acl_parse_format(context, &acl, format, ap); + va_end(ap); + if(ret) { + fclose(f); + return ret; + } + + ret = EACCES; /* XXX */ + while(fgets(buf, sizeof(buf), f)) { + if(buf[0] == '#') + continue; + if(acl_match_acl(context, acl, buf)) { + ret = 0; + goto out; + } + } + + out: + fclose(f); + acl_free_list(acl); + return ret; +} diff --git a/crypto/heimdal/lib/krb5/appdefault.c b/crypto/heimdal/lib/krb5/appdefault.c new file mode 100644 index 000000000000..081dec0d72a8 --- /dev/null +++ b/crypto/heimdal/lib/krb5/appdefault.c @@ -0,0 +1,123 @@ +/* + * Copyright (c) 2000, 2001 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "krb5_locl.h" + +RCSID("$Id: appdefault.c,v 1.3 2001/01/10 00:19:58 assar Exp $"); + +void +krb5_appdefault_boolean(krb5_context context, const char *appname, + krb5_realm realm, const char *option, + krb5_boolean def_val, krb5_boolean *ret_val) +{ + + if(appname == NULL) + appname = __progname; + def_val = krb5_config_get_bool_default(context, NULL, def_val, + "appdefaults", + option, + NULL); + if(realm != NULL) + def_val = krb5_config_get_bool_default(context, NULL, def_val, + "appdefaults", + realm, + option, + NULL); + if(appname != NULL) { + def_val = krb5_config_get_bool_default(context, NULL, def_val, + "appdefaults", + appname, + option, + NULL); + if(realm != NULL) + def_val = krb5_config_get_bool_default(context, NULL, def_val, + "appdefaults", + appname, + realm, + option, + NULL); + } + *ret_val = def_val; +} + +void +krb5_appdefault_string(krb5_context context, const char *appname, + krb5_realm realm, const char *option, + const char *def_val, char **ret_val) +{ + if(appname == NULL) + appname = __progname; + def_val = krb5_config_get_string_default(context, NULL, def_val, + "appdefaults", + option, + NULL); + if(realm != NULL) + def_val = krb5_config_get_string_default(context, NULL, def_val, + "appdefaults", + realm, + option, + NULL); + if(appname != NULL) { + def_val = krb5_config_get_string_default(context, NULL, def_val, + "appdefaults", + appname, + option, + NULL); + if(realm != NULL) + def_val = krb5_config_get_string_default(context, NULL, def_val, + "appdefaults", + appname, + realm, + option, + NULL); + } + if(def_val != NULL) + *ret_val = strdup(def_val); + else + *ret_val = NULL; +} + +void +krb5_appdefault_time(krb5_context context, const char *appname, + krb5_realm realm, const char *option, + time_t def_val, time_t *ret_val) +{ + time_t t; + char tstr[32]; + char *val; + snprintf(tstr, sizeof(tstr), "%ld", (long)def_val); + krb5_appdefault_string(context, appname, realm, option, tstr, &val); + t = parse_time (val, NULL); + free(val); + *ret_val = t; +} diff --git a/crypto/heimdal/lib/krb5/eai_to_heim_errno.c b/crypto/heimdal/lib/krb5/eai_to_heim_errno.c new file mode 100644 index 000000000000..b9272ddd6fd5 --- /dev/null +++ b/crypto/heimdal/lib/krb5/eai_to_heim_errno.c @@ -0,0 +1,69 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include <krb5_locl.h> + +RCSID("$Id: eai_to_heim_errno.c,v 1.1 2000/07/08 13:03:36 joda Exp $"); + +krb5_error_code +krb5_eai_to_heim_errno(int eai_errno) +{ + switch(eai_errno) { + case EAI_NOERROR: + return 0; + case EAI_ADDRFAMILY: + return HEIM_EAI_ADDRFAMILY; + case EAI_AGAIN: + return HEIM_EAI_AGAIN; + case EAI_BADFLAGS: + return HEIM_EAI_BADFLAGS; + case EAI_FAIL: + return HEIM_EAI_FAIL; + case EAI_FAMILY: + return HEIM_EAI_FAMILY; + case EAI_MEMORY: + return HEIM_EAI_MEMORY; + case EAI_NODATA: + return HEIM_EAI_NODATA; + case EAI_NONAME: + return HEIM_EAI_NONAME; + case EAI_SERVICE: + return HEIM_EAI_SERVICE; + case EAI_SOCKTYPE: + return HEIM_EAI_SOCKTYPE; + case EAI_SYSTEM: + return errno; + default: + return HEIM_EAI_UNKNOWN; /* XXX */ + } +} diff --git a/crypto/heimdal/lib/krb5/kerberos.8 b/crypto/heimdal/lib/krb5/kerberos.8 new file mode 100644 index 000000000000..1b2ec91e05cc --- /dev/null +++ b/crypto/heimdal/lib/krb5/kerberos.8 @@ -0,0 +1,73 @@ +.\" $Id: kerberos.8,v 1.1 2000/09/01 15:52:24 joda Exp $ +.\" +.Dd September 1, 2000 +.Dt KERBEROS 8 +.Os HEIMDAL +.Sh NAME +.Nm kerberos +.Nd introduction to the Kerberos system +.Sh DESCRIPTION +Kerberos is a network authentication system. It's purpose is to +securely authenticate users and services in an insecure network +environment. +.Pp +This is done with a Kerberos server acting as a trusted third party, +keeping a database with secret keys for all users and services +(collectively called +.Em principals ) . +.Pp +Each principal belongs to exactly one +.Em realm , +which is the administrative domain in Kerberos. A realm usually +corresponds to an organisation, and the realm should normally be +derived from that organisation's domain name. A realm is served by one +or more Kerberos servers. +.Pp +The authentication process involves exchange of +.Sq tickets +and +.Sq authenticators +which together prove the principal's identity. +.Pp +When you login to the Kerberos system, either through the normal +system login or with the +.Xr kinit 1 +program, you acquire a +.Em ticket granting ticket +which allows you to get new tickets for other services, such as +.Ic telnet +or +.Ic ftp , +without giving your password. +.Pp +For more information on how Kerberos works, and other general Kerberos +questions see the Kerberos FAQ at +.Ad http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html . + +For setup instructions see the Heimdal Texinfo manual. +.Sh SEE ALSO +.Xr ftp 1 +.Xr kdestroy 1 , +.Xr kinit 1 , +.Xr klist 1 , +.Xr kpasswd 1 , +.Xr telnet 1 +.Sh HISTORY +The Kerberos authentication system was developed in the late 1980's as +part of the Athena Project at the Massachusetts Institute of +Technology. Versions one through three never reached outside MIT, but +version 4 was (and still is) quite popular, especially in the academic +community, but is also used in commercial products like the AFS +filesystem. +.Pp +The problems with version 4 are that it has many limitations, the code +was not too well written (since it had been developed over a long +time), and it has a number of known security problems. To resolve many +of these issues work on version five started, and resulted in IETF +RFC1510 in 1993. Since then much work has been put into the further +development, and a new RFC will hopefully appear soon. +.Pp +This manual manual page is part of the +.Nm Heimdal +Kerberos 5 distribution, which has been in development at the Royal +Institute of Technology in Stockholm, Sweden, since about 1997. diff --git a/crypto/heimdal/lib/krb5/krb5_appdefault.3 b/crypto/heimdal/lib/krb5/krb5_appdefault.3 new file mode 100644 index 000000000000..3ce6fc9432bd --- /dev/null +++ b/crypto/heimdal/lib/krb5/krb5_appdefault.3 @@ -0,0 +1,57 @@ +.\" Copyright (c) 2000 Kungliga Tekniska Högskolan +.\" $Id: krb5_appdefault.3,v 1.3 2001/01/05 16:29:42 joda Exp $ +.Dd July 25, 2000 +.Dt KRB5_APPDEFAULT 3 +.Os HEIMDAL +.Sh NAME +.Nm krb5_appdefault_boolean , +.Nm krb5_appdefault_string , +.Nm krb5_appdefault_time +.Nd Get application configuration value + +.Sh SYNOPSIS +.Fd #include <krb5.h> + +.Ft void +.Fn krb5_appdefault_boolean "krb5_context context" "const char *appname" "krb5_realm realm" "const char *option" "krb5_boolean def_val" "krb5_boolean *ret_val" +.Ft void +.Fn krb5_appdefault_string "krb5_context context" "const char *appname" "krb5_realm realm" "const char *option" "const char *def_val" "char **ret_val" +.Ft void +.Fn krb5_appdefault_time "krb5_context context" "const char *appname" "krb5_realm realm" "const char *option" "time_t def_val" "time_t *ret_val" + +.Sh DESCRIPTION + +These functions get application application defaults from the +.Dv appdefaults +section of the +.Xr krb5.conf 5 +configuration file. These defaults can be specified per application, +and/or per realm. + +These values will be looked for in +.Xr krb5.conf 5 , +in order of descending importance. +.Bd -literal -offset indent +[appdefaults] + appname = { + realm = { + option = value + } + } + appname = { + option = value + } + realm = { + option = value + } + option = value +.Ed + +If the realm is omitted it will not be used for resolving values. If +no value can be found, +.Fa def_val +is returned instead. + +.Sh SEE ALSO +.Xr krb5_config 3 , +.Xr krb5.conf 5 diff --git a/crypto/heimdal/lib/krb5/krb5_auth_context.3 b/crypto/heimdal/lib/krb5/krb5_auth_context.3 new file mode 100644 index 000000000000..42a96ecac2dc --- /dev/null +++ b/crypto/heimdal/lib/krb5/krb5_auth_context.3 @@ -0,0 +1,284 @@ +.\" Copyright (c) 2001 Kungliga Tekniska Högskolan +.\" $Id: krb5_auth_context.3,v 1.1 2001/01/28 19:47:33 assar Exp $ +.Dd Jan 21, 2001 +.Dt KRB5_AUTH_CONTEXT 3 +.Os HEIMDAL +.Sh NAME +.Nm krb5_auth_context , +.Nm krb5_auth_con_init , +.Nm krb5_auth_con_free , +.Nm krb5_auth_con_setflags , +.Nm krb5_auth_con_getflags , +.Nm krb5_auth_con_setaddrs , +.Nm krb5_auth_con_setaddrs_from_fd , +.Nm krb5_auth_con_getaddrs , +.Nm krb5_auth_con_genaddrs , +.Nm krb5_auth_con_getkey , +.Nm krb5_auth_con_setkey , +.Nm krb5_auth_con_getuserkey , +.Nm krb5_auth_con_setuserkey , +.Nm krb5_auth_con_getlocalsubkey , +.Nm krb5_auth_con_setlocalsubkey , +.Nm krb5_auth_con_getremotesubkey , +.Nm krb5_auth_con_setremotesubkey , +.Nm krb5_auth_setcksumtype , +.Nm krb5_auth_getcksumtype , +.Nm krb5_auth_setkeytype , +.Nm krb5_auth_getkeytype , +.Nm krb5_auth_getlocalseqnumber , +.Nm krb5_auth_setlocalseqnumber , +.Nm krb5_auth_getremoteseqnumber , +.Nm krb5_auth_setremoteseqnumber , +.Nm krb5_auth_getauthenticator , +.Nm krb5_auth_con_getrcache , +.Nm krb5_auth_con_setrcache , +.Nm krb5_auth_con_initivector , +.Nm krb5_auth_con_setivector +.Nd manage authetication on connection level. +.Sh SYNOPSIS +.Fd #include <krb5.h> +.Ft krb5_error_code +.Fo krb5_auth_con_init +.Fa "krb5_context context" +.Fa "krb5_auth_context *auth_context" +.Fc +.Ft void +.Fo krb5_auth_con_free +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_setflags +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fa "int32_t flags" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_getflags +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fa "int32_t *flags" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_setaddrs +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fa "krb5_address *local_addr" +.Fa "krb5_address *remote_addr" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_getaddrs +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fa "krb5_address **local_addr" +.Fa "krb5_address **remote_addr" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_genaddrs +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fa "int fd" +.Fa "int flags" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_setaddrs_from_fd +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fa "void *p_fd" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_getkey +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fa "krb5_keyblock **keyblock" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_getlocalsubkey +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fa "krb5_keyblock **keyblock" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_getremotesubkey +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fa "krb5_keyblock **keyblock" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_initivector +.Fa "krb5_context context" +.Fa "krb5_auth_context auth_context" +.Fc +.Ft krb5_error_code +.Fo krb5_auth_con_setivector +.Fa "krb5_context context" +.Fa "krb5_auth_context *auth_context" +.Fa "krb5_pointer ivector" +.Fc +.Sh DESCRIPTION +The +.Nm krb5_auth_context +structure holds all context related to an authenticated connection, in +a similar way to +.Nm krb5_context +that holds the context for the thread or process. +.Nm krb5_auth_context +is used by various functions that are directly related to +authentication between the server/client. Example of data that this +structure contains are varius flags, addresses of client and server, +port numbers, keyblocks (and subkeys), sequence numbers, replay cache, +and checksum-type. +.Pp +.Fn krb5_auth_con_init +allocates and initilizes the +.Nm krb5_auth_context +structure. Default values can be changed with +.Fn krb5_auth_con_setcksumtype +and +.Fn krb5_auth_con_setflags . +The +.Nm auth_context +structure must be freed by +.Fn krb5_auth_con_free . +.Pp +.Fn krb5_auth_con_getflags +and +.Fn krb5_auth_con_setflags +gets and modifies the flags for a +.Nm krb5_auth_context +structure. Possible flags to set are: +.Bl -tag -width Ds +.It Dv KRB5_AUTH_CONTEXT_DO_TIME +check timestamp on incoming packets. +.\".It Dv KRB5_AUTH_CONTEXT_RET_TIME +.It Dv KRB5_AUTH_CONTEXT_DO_SEQUENCE +Generate and check sequence-number on each packet. +.\".It Dv KRB5_AUTH_CONTEXT_RET_SEQUENCE +.\".It Dv KRB5_AUTH_CONTEXT_PERMIT_ALL +.El +.Pp +.Fn krb5_auth_con_setaddrs , +.Fn krb5_auth_con_setaddrs_from_fd +and +.Fn krb5_auth_con_getaddrs +gets and sets the addresses that are checked when a packet is received. +It is mandatory to set an address for the remote +host. If the local address is not set, it iss deduced from the underlaying +operating system. +.Fn krb5_auth_con_getaddrs +will call +.Fn krb5_free_address +on any address that is passed in +.Fa local_addr +or +.Fa remote_addr . +.Fn krb5_auth_con_setaddr +allows passing in a +.Dv NULL +pointer as +.Fa local_addr +and +.Fa remote_addr , +in that case it will just not set that address. +.Pp +.Fn krb5_auth_con_setaddrs_from_fd +fetches the addresses from a file descriptor. +.Pp +.Fn krb5_auth_con_genaddrs +fetches the address information from the given file descriptor +.Fa fd +depending on the bitmap argument +.Fa flags . +.Pp +Possible values on +.Fa flags +are: +.Bl -tag -width Ds +.It Va KRB5_AUTH_CONTEXT_GENERATE_LOCAL_ADDR +fetches the local address from +.Fa fd . +.It Va KRB5_AUTH_CONTEXT_GENERATE_REMOTE_ADDR +fetches the remote address from +.Fa fd . +.El +.Pp +.Fn krb5_auth_con_setkey , +.Fn krb5_auth_con_setuserkey +and +.Fn krb5_auth_con_getkey +gets and sets the key used for this auth context. The keyblock returned by +.Fn krb5_auth_con_getkey +should be freed with +.Fn krb5_free_keyblock . +The keyblock send into +.Fn krb5_auth_con_setkey +is copied into the +.Nm krb5_auth_context , +and thus no special handling is needed. +.Dv NULL +is not a valid keyblock to +.Fn krb5_auth_con_setkey . +.Pp +.Fn krb5_auth_con_setuserkey +is only useful when doing user to user authentication. +.Fn krb5_auth_con_setkey +is equivalent to +.Fn krb5_auth_con_setuserkey . +.Pp +.Fn krb5_auth_con_getlocalsubkey , +.Fn krb5_auth_con_setlocalsubkey , +.Fn krb5_auth_con_getremotesubkey +and +.Fn krb5_auth_con_setremotesubkey +gets and sets the keyblock for the local and remote subkey. The keyblock returned by +.Fn krb5_auth_con_getlocalsubkey +and +.Fn krb5_auth_con_getremotesubkey +must be freed with +.Fn krb5_free_keyblock . +.Pp +.Fn krb5_auth_setcksumtype +and +.Fn krb5_auth_getcksumtype +sets and gets the checksum type that should be used for this +connection. +.Pp +.Fn krb5_auth_getremoteseqnumber +.Fn krb5_auth_setremoteseqnumber , +.Fn krb5_auth_getlocalseqnumber +and +.Fn krb5_auth_setlocalseqnumber +gets and sets the sequence-number for the local and remote +sequence-number counter. +.Pp +.Fn krb5_auth_setkeytype +and +.Fn krb5_auth_getkeytype +gets and gets the keytype of the keyblock in +.Nm krb5_auth_context . +.Pp +.Fn krb5_auth_getauthenticator +Retrieves the authenticator that was used during mutual +authentication. The +.Dv authenticator +returned should be freed by calling +.Fn krb5_free_authenticator . +.Pp +.Fn krb5_auth_con_getrcache +and +.Fn krb5_auth_con_setrcache +gets and sets the replay-cache. +.Pp +.Fn krb5_auth_con_initivector +allocates memory for and zeros the initial vector in the +.Fa auth_context +keyblock. +.Pp +.Fn krb5_auth_con_setivector +sets the i_vector portion of +.Fa auth_context +to +.Fa ivector . +.Sh SEE ALSO +.Xr krb5_context 3 , +.Xr kerberos 8 diff --git a/crypto/heimdal/lib/krb5/krb5_config.3 b/crypto/heimdal/lib/krb5/krb5_config.3 new file mode 100644 index 000000000000..b5a74db93b79 --- /dev/null +++ b/crypto/heimdal/lib/krb5/krb5_config.3 @@ -0,0 +1,71 @@ +.\" Copyright (c) 2000 Kungliga Tekniska Högskolan +.\" $Id: krb5_config.3,v 1.1 2000/07/25 10:22:46 joda Exp $ +.Dd July 25, 2000 +.Dt KRB5_CONFIG 3 +.Os HEIMDAL +.Sh NAME +.Nm krb5_config_get_bool_default , +.Nm krb5_config_get_int_default , +.Nm krb5_config_get_string_default , +.Nm krb5_config_get_time_default +.Nd Get configuration value + +.Sh SYNOPSIS +.Fd #include <krb5.h> + +.Ft krb5_boolean +.Fn krb5_config_get_bool_default "krb5_context context" "krb5_config_section *c" "krb5_boolean def_value" "..." +.Ft int +.Fn krb5_config_get_int_default "krb5_context context" "krb5_config_section *c" "int def_value" "..." +.Ft const char* +.Fn krb5_config_get_string_default "krb5_context context" "krb5_config_section *c" "const char *def_value" "..." +.Ft int +.Fn krb5_config_get_time_default "krb5_context context" "krb5_config_section *c" "int def_value" "..." + +.Sh DESCRIPTION + +These functions get values from the +.Xr krb5.conf 5 +configuration file, or another configuration database specified by the +.Fa c +parameter. + +The variable arguments should be a list of strings naming each +subsection to look for. For example: + +.Bd -literal -offset indent +krb5_config_get_bool_default(context, NULL, FALSE, "libdefaults", "log_utc", NULL) +.Ed + +gets the boolean value for the +.Dv log_utc +option, defaulting to +.Dv FALSE . + +.Fn krb5_config_get_bool_default +will convert the option value to a boolean value, where +.Sq yes , +.Sq true , +and any non-zero number means +.Dv TRUE , +and any other value +.Dv FALSE . + +.Fn krb5_config_get_int_default +will convert the value to an integer. + +.Fn krb5_config_get_time_default +will convert the value to a period of time (not a time stamp) in +seconds, so the string +.Sq 2 weeks +will be converted to +1209600 (2 * 7 * 24 * 60 * 60). + +.Sh BUGS + +Other than for the string case, there's no way to tell whether there +was a value specified or not. + +.Sh SEE ALSO +.Xr krb5_appdefault 3 , +.Xr krb5.conf 5 diff --git a/crypto/heimdal/lib/krb5/krb5_context.3 b/crypto/heimdal/lib/krb5/krb5_context.3 new file mode 100644 index 000000000000..83a768d1a6b4 --- /dev/null +++ b/crypto/heimdal/lib/krb5/krb5_context.3 @@ -0,0 +1,20 @@ +.\" Copyright (c) 2001 Kungliga Tekniska Högskolan +.\" $Id: krb5_context.3,v 1.1 2001/01/28 21:39:29 assar Exp $ +.Dd Jan 21, 2001 +.Dt KRB5_CONTEXT 3 +.Os HEIMDAL +.Sh NAME +.Nm krb5_context +.Sh DESCRIPTION +The +.Nm +structure is designed to hold all per thread state. All global +variables that are context specific are stored in this struture, +including default encryption types, credential-cache (ticket file), and +default realms. +.Pp +The internals of the structure should never be accessed directly, +functions exist for extracting information. +.Sh SEE ALSO +.Xr krb5_init_context 3 , +.Xr kerberos 8 diff --git a/crypto/heimdal/lib/krb5/krb5_init_context.3 b/crypto/heimdal/lib/krb5/krb5_init_context.3 new file mode 100644 index 000000000000..7e27ec238ba3 --- /dev/null +++ b/crypto/heimdal/lib/krb5/krb5_init_context.3 @@ -0,0 +1,38 @@ +.\" Copyright (c) 2001 Kungliga Tekniska Högskolan +.\" $Id: krb5_init_context.3,v 1.1 2001/01/28 21:39:29 assar Exp $ +.Dd Jan 21, 2001 +.Dt KRB5_CONTEXT 3 +.Os HEIMDAL +.Sh NAME +.Nm krb5_init_context , +.Nm krb5_free_context +.Sh SYNOPSIS +.Fd #include <krb5.h> +.Ft krb5_error_code +.Fn krb5_init_context "krb5_context *context" +.Ft void +.Fn krb5_free_context "krb5_context *context" +.Sh DESCRIPTION +The +.Fn krb5_init_context +function initializes the +.Fa context +structure and reads the configration file +.Pa /etc/krb5.conf . +.Pp +The structure should be freed by calling +.Fn krb5_free_context +when it is no longer being used. +.Sh RETURN VALUES +.Fn krb5_init_context +returns 0 to indicate success. +Otherwise an errno code is returned. +Failure means either that something bad happened during initialization +(typically +.Bq ENOMEM ) +or that Kerberos should not be used +.Bq ENXIO . +.Sh SEE ALSO +.Xr krb5_context 3 , +.Xr errno 2 , +.Xr kerberos 8 diff --git a/crypto/heimdal/lib/krb5/test_get_addrs.c b/crypto/heimdal/lib/krb5/test_get_addrs.c new file mode 100644 index 000000000000..96a8f89bf570 --- /dev/null +++ b/crypto/heimdal/lib/krb5/test_get_addrs.c @@ -0,0 +1,78 @@ +/* + * Copyright (c) 2000 - 2001 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of KTH nor the names of its contributors may be + * used to endorse or promote products derived from this software without + * specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY KTH AND ITS CONTRIBUTORS ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL KTH OR ITS CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, + * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR + * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF + * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ + +#include "krb5_locl.h" +#include <err.h> + +RCSID("$Id: test_get_addrs.c,v 1.3 2001/01/25 12:45:15 assar Exp $"); + +/* print all addresses that we find */ + +static void +print_addresses (krb5_context context, const krb5_addresses *addrs) +{ + int i; + char buf[256]; + size_t len; + + for (i = 0; i < addrs->len; ++i) { + krb5_print_address (&addrs->val[i], buf, sizeof(buf), &len); + printf ("%s\n", buf); + } +} + +int +main(int argc, char **argv) +{ + krb5_context context; + krb5_error_code ret; + krb5_addresses addrs; + + ret = krb5_init_context(&context); + if (ret) + errx (1, "krb5_init_context failed: %d", ret); + + ret = krb5_get_all_client_addrs (context, &addrs); + if (ret) + krb5_err (context, 1, ret, "krb5_get_all_client_addrs"); + printf ("client addresses\n"); + print_addresses (context, &addrs); + krb5_free_addresses (context, &addrs); + + ret = krb5_get_all_server_addrs (context, &addrs); + if (ret) + krb5_err (context, 1, ret, "krb5_get_all_server_addrs"); + printf ("server addresses\n"); + print_addresses (context, &addrs); + krb5_free_addresses (context, &addrs); + return 0; +} diff --git a/crypto/heimdal/lib/krb5/verify_krb5_conf.8 b/crypto/heimdal/lib/krb5/verify_krb5_conf.8 new file mode 100644 index 000000000000..55cdc92fa005 --- /dev/null +++ b/crypto/heimdal/lib/krb5/verify_krb5_conf.8 @@ -0,0 +1,33 @@ +.\" $Id: verify_krb5_conf.8,v 1.2 2000/03/04 14:07:50 assar Exp $ +.\" +.Dd March 4, 2000 +.Dt VERIFY_KRB5_CONF 8 +.Os HEIMDAL +.Sh NAME +.Nm verify_krb5_conf +.Nd +does a crude test that +.Pa krb5.conf +does not contain any obvious syntax error +.Sh SYNOPSIS +.Nm +.Ar [config-file] +.Sh DESCRIPTION +.Nm +reads the configuration file +.Pa krb5.conf , +or the file given on the command line, +and parses it, thereby verifying that the syntax is not correctly wrong. +Since that file is read by almost all Kerberos programs but most of +them have no way of notifying the user that it could not be parsed, +this program is useful. +.Sh ENVIRONMENT +.Ev KRB5_CONFIG +points to the configuration file to read. +.Sh FILES +.Xr krb5.conf 5 +.Sh SEE ALSO +.Xr krb5.conf 5 +.Sh BUGS +It should know about what variables are actually used and warn about +unknown ones. diff --git a/crypto/heimdal/lib/roken/acconfig.h b/crypto/heimdal/lib/roken/acconfig.h new file mode 100644 index 000000000000..5fbe685ce386 --- /dev/null +++ b/crypto/heimdal/lib/roken/acconfig.h @@ -0,0 +1,36 @@ +@BOTTOM@ + +#ifdef BROKEN_REALLOC +#define realloc(X, Y) isoc_realloc((X), (Y)) +#define isoc_realloc(X, Y) ((X) ? realloc((X), (Y)) : malloc(Y)) +#endif + +#ifdef VOID_RETSIGTYPE +#define SIGRETURN(x) return +#else +#define SIGRETURN(x) return (RETSIGTYPE)(x) +#endif + +#define RCSID(msg) \ +static /**/const char *const rcsid[] = { (const char *)rcsid, "\100(#)" msg } + +#undef PROTOTYPES + +/* Maximum values on all known systems */ +#define MaxHostNameLen (64+4) +#define MaxPathLen (1024+4) + +/* + * Define NDBM if you are using the 4.3 ndbm library (which is part of + * libc). If not defined, 4.2 dbm will be assumed. + */ +#if defined(HAVE_DBM_FIRSTKEY) +#define NDBM +#endif + +/* + * Defining this enables lots of useful (and used) extensions on + * glibc-based systems such as Linux + */ + +#define _GNU_SOURCE diff --git a/crypto/heimdal/lib/roken/acinclude.m4 b/crypto/heimdal/lib/roken/acinclude.m4 new file mode 100644 index 000000000000..1d0197c5ce37 --- /dev/null +++ b/crypto/heimdal/lib/roken/acinclude.m4 @@ -0,0 +1,9 @@ +dnl $Id$ +dnl +dnl Only put things that for some reason can't live in the `cf' +dnl directory in this file. +dnl + +dnl $xId: misc.m4,v 1.1 1997/12/14 15:59:04 joda Exp $ +dnl +define(upcase,`echo $1 | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`)dnl diff --git a/crypto/heimdal/lib/roken/config.h.in b/crypto/heimdal/lib/roken/config.h.in new file mode 100644 index 000000000000..b3df98912148 --- /dev/null +++ b/crypto/heimdal/lib/roken/config.h.in @@ -0,0 +1 @@ +/*autoheader*/ diff --git a/crypto/heimdal/lib/roken/environment.c b/crypto/heimdal/lib/roken/environment.c new file mode 100644 index 000000000000..62c732c5b47b --- /dev/null +++ b/crypto/heimdal/lib/roken/environment.c @@ -0,0 +1,103 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: environment.c,v 1.1 2000/06/21 02:05:03 assar Exp $"); +#endif + +#include <stdio.h> +#include <string.h> +#include "roken.h" + +/* + * return count of environment assignments from `file' and + * list of malloced strings in `env' + */ + +int +read_environment(const char *file, char ***env) +{ + int i, k; + FILE *F; + char **l; + char buf[BUFSIZ], *p, *r; + + if ((F = fopen(file, "r")) == NULL) { + return 0; + } + + i = 0; + if (*env) { + l = *env; + while (*l != NULL) { + i++; + l++; + } + } + l = *env; + /* This is somewhat more relaxed on what it accepts then + * Wietses sysv_environ from K4 was... + */ + while (fgets(buf, BUFSIZ, F) != NULL) { + if (buf[0] == '#') + continue; + + p = strchr(buf, '#'); + if (p != NULL) + *p = '\0'; + + p = buf; + while (*p == ' ' || *p == '\t' || *p == '\n') p++; + if (*p == '\0') + continue; + + k = strlen(p); + if (p[k-1] == '\n') + p[k-1] = '\0'; + + /* Here one should check that is is a 'valid' env string... */ + r = strchr(p, '='); + if (r == NULL) + continue; + + l = realloc(l, (i+1) * sizeof (char *)); + l[i++] = strdup(p); + } + fclose(F); + l = realloc(l, (i+1) * sizeof (char *)); + l[i] = NULL; + *env = l; + return i; +} diff --git a/crypto/heimdal/lib/roken/err.hin b/crypto/heimdal/lib/roken/err.hin new file mode 100644 index 000000000000..1fa7774bd0fe --- /dev/null +++ b/crypto/heimdal/lib/roken/err.hin @@ -0,0 +1,68 @@ +/* + * Copyright (c) 1995 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: err.hin,v 1.16 2000/12/11 04:40:59 assar Exp $ */ + +#ifndef __ERR_H__ +#define __ERR_H__ + +#include <errno.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <stdarg.h> + +extern const char *__progname; + +#if !defined(__GNUC__) && !defined(__attribute__) +#define __attribute__(x) +#endif + +void verr(int eval, const char *fmt, va_list ap) + __attribute__ ((noreturn, format (printf, 2, 0))); +void err(int eval, const char *fmt, ...) + __attribute__ ((noreturn, format (printf, 2, 3))); +void verrx(int eval, const char *fmt, va_list ap) + __attribute__ ((noreturn, format (printf, 2, 0))); +void errx(int eval, const char *fmt, ...) + __attribute__ ((noreturn, format (printf, 2, 3))); +void vwarn(const char *fmt, va_list ap) + __attribute__ ((format (printf, 1, 0))); +void warn(const char *fmt, ...) + __attribute__ ((format (printf, 1, 2))); +void vwarnx(const char *fmt, va_list ap) + __attribute__ ((format (printf, 1, 0))); +void warnx(const char *fmt, ...) + __attribute__ ((format (printf, 1, 2))); + +#endif /* __ERR_H__ */ diff --git a/crypto/heimdal/lib/roken/esetenv.c b/crypto/heimdal/lib/roken/esetenv.c new file mode 100644 index 000000000000..cb357527c34b --- /dev/null +++ b/crypto/heimdal/lib/roken/esetenv.c @@ -0,0 +1,48 @@ +/* + * Copyright (c) 2000, 2001 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: esetenv.c,v 1.3 2001/01/27 05:28:38 assar Exp $"); +#endif + +#include "roken.h" + +#include <err.h> + +void +esetenv(const char *var, const char *val, int rewrite) +{ + if (setenv ((char *)var, (char *)val, rewrite)) + errx (1, "failed setting environment variable %s", var); +} diff --git a/crypto/heimdal/lib/roken/fnmatch.hin b/crypto/heimdal/lib/roken/fnmatch.hin new file mode 100644 index 000000000000..95c91d600b64 --- /dev/null +++ b/crypto/heimdal/lib/roken/fnmatch.hin @@ -0,0 +1,49 @@ +/* $NetBSD: fnmatch.h,v 1.5 1994/10/26 00:55:53 cgd Exp $ */ + +/*- + * Copyright (c) 1992, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)fnmatch.h 8.1 (Berkeley) 6/2/93 + */ + +#ifndef _FNMATCH_H_ +#define _FNMATCH_H_ + +#define FNM_NOMATCH 1 /* Match failed. */ + +#define FNM_NOESCAPE 0x01 /* Disable backslash escaping. */ +#define FNM_PATHNAME 0x02 /* Slash must be matched by slash. */ +#define FNM_PERIOD 0x04 /* Period must be matched by period. */ + +int fnmatch (const char *, const char *, int); + +#endif /* !_FNMATCH_H_ */ diff --git a/crypto/heimdal/lib/roken/getifaddrs.c b/crypto/heimdal/lib/roken/getifaddrs.c new file mode 100644 index 000000000000..e8e3e5467f09 --- /dev/null +++ b/crypto/heimdal/lib/roken/getifaddrs.c @@ -0,0 +1,271 @@ +/* + * Copyright (c) 2000 - 2001 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: getifaddrs.c,v 1.4 2001/01/28 23:02:46 assar Exp $"); +#endif +#include "roken.h" + +#ifdef __osf__ +/* hate */ +struct rtentry; +struct mbuf; +#endif +#ifdef HAVE_NET_IF_H +#include <net/if.h> +#endif + +#ifdef HAVE_SYS_SOCKIO_H +#include <sys/sockio.h> +#endif /* HAVE_SYS_SOCKIO_H */ + +#ifdef HAVE_NETINET_IN6_VAR_H +#include <netinet/in6_var.h> +#endif /* HAVE_NETINET_IN6_VAR_H */ + +#include <ifaddrs.h> + +static int +getifaddrs2(struct ifaddrs **ifap, + int af, int siocgifconf, int siocgifflags, + size_t ifreq_sz) +{ + int ret; + int fd; + size_t buf_size; + char *buf; + struct ifconf ifconf; + int num, j = 0; + char *p; + size_t sz; + struct sockaddr sa_zero; + struct ifreq *ifr; + + struct ifaddrs *start, **end = &start; + + buf = NULL; + + memset (&sa_zero, 0, sizeof(sa_zero)); + fd = socket(af, SOCK_DGRAM, 0); + if (fd < 0) + return -1; + + buf_size = 8192; + for (;;) { + buf = calloc(1, buf_size); + if (buf == NULL) { + ret = ENOMEM; + goto error_out; + } + ifconf.ifc_len = buf_size; + ifconf.ifc_buf = buf; + + /* + * Solaris returns EINVAL when the buffer is too small. + */ + if (ioctl (fd, siocgifconf, &ifconf) < 0 && errno != EINVAL) { + ret = errno; + goto error_out; + } + /* + * Can the difference between a full and a overfull buf + * be determined? + */ + + if (ifconf.ifc_len < buf_size) + break; + free (buf); + buf_size *= 2; + } + + num = ifconf.ifc_len / ifreq_sz; + j = 0; + for (p = ifconf.ifc_buf; + p < ifconf.ifc_buf + ifconf.ifc_len; + p += sz) { + struct ifreq ifreq; + struct sockaddr *sa; + size_t salen; + + ifr = (struct ifreq *)p; + sa = &ifr->ifr_addr; + + sz = ifreq_sz; + salen = sizeof(struct sockaddr); +#ifdef HAVE_STRUCT_SOCKADDR_SA_LEN + salen = sa->sa_len; + sz = max(sz, sizeof(ifr->ifr_name) + sa->sa_len); +#endif +#ifdef SA_LEN + salen = SA_LEN(sa); + sz = max(sz, sizeof(ifr->ifr_name) + SA_LEN(sa)); +#endif + memset (&ifreq, 0, sizeof(ifreq)); + memcpy (ifreq.ifr_name, ifr->ifr_name, sizeof(ifr->ifr_name)); + + if (ioctl(fd, siocgifflags, &ifreq) < 0) { + ret = errno; + goto error_out; + } + + *end = malloc(sizeof(**end)); + + (*end)->ifa_next = NULL; + (*end)->ifa_name = strdup(ifr->ifr_name); + (*end)->ifa_flags = ifreq.ifr_flags; + (*end)->ifa_addr = malloc(salen); + memcpy((*end)->ifa_addr, sa, salen); + (*end)->ifa_netmask = NULL; + +#if 0 + /* fix these when we actually need them */ + if(ifreq.ifr_flags & IFF_BROADCAST) { + (*end)->ifa_broadaddr = malloc(sizeof(ifr->ifr_broadaddr)); + memcpy((*end)->ifa_broadaddr, &ifr->ifr_broadaddr, + sizeof(ifr->ifr_broadaddr)); + } else if(ifreq.ifr_flags & IFF_POINTOPOINT) { + (*end)->ifa_dstaddr = malloc(sizeof(ifr->ifr_dstaddr)); + memcpy((*end)->ifa_dstaddr, &ifr->ifr_dstaddr, + sizeof(ifr->ifr_dstaddr)); + } else + (*end)->ifa_dstaddr = NULL; +#else + (*end)->ifa_dstaddr = NULL; +#endif + + (*end)->ifa_data = NULL; + + end = &(*end)->ifa_next; + + } + *ifap = start; + free(buf); + return 0; + error_out: + free(buf); + errno = ret; + return -1; +} + +int +getifaddrs(struct ifaddrs **ifap) +{ + int ret = -1; + errno = ENXIO; +#if defined(AF_INET6) && defined(SIOCGIF6CONF) && defined(SIOCGIF6FLAGS) + if (ret) + ret = getifaddrs2 (ifap, AF_INET6, SIOCGIF6CONF, SIOCGIF6FLAGS, + sizeof(struct in6_ifreq)); +#endif +#if defined(HAVE_IPV6) && defined(SIOCGIFCONF) + if (ret) + ret = getifaddrs2 (ifap, AF_INET6, SIOCGIFCONF, SIOCGIFFLAGS, + sizeof(struct ifreq)); +#endif +#if defined(AF_INET) && defined(SIOCGIFCONF) && defined(SIOCGIFFLAGS) + if (ret) + ret = getifaddrs2 (ifap, AF_INET, SIOCGIFCONF, SIOCGIFFLAGS, + sizeof(struct ifreq)); +#endif + return ret; +} + +void +freeifaddrs(struct ifaddrs *ifp) +{ + struct ifaddrs *p, *q; + + for(p = ifp; p; ) { + free(p->ifa_name); + if(p->ifa_addr) + free(p->ifa_addr); + if(p->ifa_dstaddr) + free(p->ifa_dstaddr); + if(p->ifa_netmask) + free(p->ifa_netmask); + if(p->ifa_data) + free(p->ifa_data); + q = p; + p = p->ifa_next; + free(q); + } +} + +#ifdef TEST + +void +print_addr(const char *s, struct sockaddr *sa) +{ + int i; + printf(" %s=%d/", s, sa->sa_family); +#ifdef HAVE_STRUCT_SOCKADDR_SA_LEN + for(i = 0; i < sa->sa_len - ((long)sa->sa_data - (long)&sa->sa_family); i++) + printf("%02x", ((unsigned char*)sa->sa_data)[i]); +#else + for(i = 0; i < sizeof(sa->sa_data); i++) + printf("%02x", ((unsigned char*)sa->sa_data)[i]); +#endif + printf("\n"); +} + +void +print_ifaddrs(struct ifaddrs *x) +{ + struct ifaddrs *p; + + for(p = x; p; p = p->ifa_next) { + printf("%s\n", p->ifa_name); + printf(" flags=%x\n", p->ifa_flags); + if(p->ifa_addr) + print_addr("addr", p->ifa_addr); + if(p->ifa_dstaddr) + print_addr("dstaddr", p->ifa_dstaddr); + if(p->ifa_netmask) + print_addr("netmask", p->ifa_netmask); + printf(" %p\n", p->ifa_data); + } +} + +int +main() +{ + struct ifaddrs *a = NULL, *b; + getifaddrs2(&a, AF_INET, SIOCGIFCONF, SIOCGIFFLAGS, sizeof(struct ifreq)); + print_ifaddrs(a); + printf("---\n"); + getifaddrs(&b); + print_ifaddrs(b); + return 0; +} +#endif diff --git a/crypto/heimdal/lib/roken/glob.hin b/crypto/heimdal/lib/roken/glob.hin new file mode 100644 index 000000000000..bece48a89cd7 --- /dev/null +++ b/crypto/heimdal/lib/roken/glob.hin @@ -0,0 +1,84 @@ +/* + * Copyright (c) 1989, 1993 + * The Regents of the University of California. All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * Guido van Rossum. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)glob.h 8.1 (Berkeley) 6/2/93 + */ + +#ifndef _GLOB_H_ +#define _GLOB_H_ + +struct stat; +typedef struct { + int gl_pathc; /* Count of total paths so far. */ + int gl_matchc; /* Count of paths matching pattern. */ + int gl_offs; /* Reserved at beginning of gl_pathv. */ + int gl_flags; /* Copy of flags parameter to glob. */ + char **gl_pathv; /* List of paths matching pattern. */ + /* Copy of errfunc parameter to glob. */ + int (*gl_errfunc) (const char *, int); + + /* + * Alternate filesystem access methods for glob; replacement + * versions of closedir(3), readdir(3), opendir(3), stat(2) + * and lstat(2). + */ + void (*gl_closedir) (void *); + struct dirent *(*gl_readdir) (void *); + void *(*gl_opendir) (const char *); + int (*gl_lstat) (const char *, struct stat *); + int (*gl_stat) (const char *, struct stat *); +} glob_t; + +#define GLOB_APPEND 0x0001 /* Append to output from previous call. */ +#define GLOB_DOOFFS 0x0002 /* Use gl_offs. */ +#define GLOB_ERR 0x0004 /* Return on error. */ +#define GLOB_MARK 0x0008 /* Append / to matching directories. */ +#define GLOB_NOCHECK 0x0010 /* Return pattern itself if nothing matches. */ +#define GLOB_NOSORT 0x0020 /* Don't sort. */ + +#define GLOB_ALTDIRFUNC 0x0040 /* Use alternately specified directory funcs. */ +#define GLOB_BRACE 0x0080 /* Expand braces ala csh. */ +#define GLOB_MAGCHAR 0x0100 /* Pattern had globbing characters. */ +#define GLOB_NOMAGIC 0x0200 /* GLOB_NOCHECK without magic chars (csh). */ +#define GLOB_QUOTE 0x0400 /* Quote special chars with \. */ +#define GLOB_TILDE 0x0800 /* Expand tilde names from the passwd file. */ + +#define GLOB_NOSPACE (-1) /* Malloc call failed. */ +#define GLOB_ABEND (-2) /* Unignored error. */ + +int glob (const char *, int, int (*)(const char *, int), glob_t *); +void globfree (glob_t *); + +#endif /* !_GLOB_H_ */ diff --git a/crypto/heimdal/lib/roken/ifaddrs.hin b/crypto/heimdal/lib/roken/ifaddrs.hin new file mode 100644 index 000000000000..d2b9be8ccc6d --- /dev/null +++ b/crypto/heimdal/lib/roken/ifaddrs.hin @@ -0,0 +1,64 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: ifaddrs.hin,v 1.3 2000/12/11 00:01:13 assar Exp $ */ + +#ifndef __ifaddrs_h__ +#define __ifaddrs_h__ + +/* + * the interface is defined in terms of the fields below, and this is + * sometimes #define'd, so there seems to be no simple way of solving + * this and this seemed the best. */ + +#undef ifa_dstaddr + +struct ifaddrs { + struct ifaddrs *ifa_next; + char *ifa_name; + unsigned int ifa_flags; + struct sockaddr *ifa_addr; + struct sockaddr *ifa_netmask; + struct sockaddr *ifa_dstaddr; + void *ifa_data; +}; + +#ifndef ifa_broadaddr +#define ifa_broadaddr ifa_dstaddr +#endif + +int getifaddrs(struct ifaddrs**); + +void freeifaddrs(struct ifaddrs*); + +#endif /* __ifaddrs_h__ */ diff --git a/crypto/heimdal/lib/roken/install-sh b/crypto/heimdal/lib/roken/install-sh new file mode 100755 index 000000000000..e9de23842dcd --- /dev/null +++ b/crypto/heimdal/lib/roken/install-sh @@ -0,0 +1,251 @@ +#!/bin/sh +# +# install - install a program, script, or datafile +# This comes from X11R5 (mit/util/scripts/install.sh). +# +# Copyright 1991 by the Massachusetts Institute of Technology +# +# Permission to use, copy, modify, distribute, and sell this software and its +# documentation for any purpose is hereby granted without fee, provided that +# the above copyright notice appear in all copies and that both that +# copyright notice and this permission notice appear in supporting +# documentation, and that the name of M.I.T. not be used in advertising or +# publicity pertaining to distribution of the software without specific, +# written prior permission. M.I.T. makes no representations about the +# suitability of this software for any purpose. It is provided "as is" +# without express or implied warranty. +# +# Calling this script install-sh is preferred over install.sh, to prevent +# `make' implicit rules from creating a file called install from it +# when there is no Makefile. +# +# This script is compatible with the BSD install script, but was written +# from scratch. It can only install one file at a time, a restriction +# shared with many OS's install programs. + + +# set DOITPROG to echo to test this script + +# Don't use :- since 4.3BSD and earlier shells don't like it. +doit="${DOITPROG-}" + + +# put in absolute paths if you don't have them in your path; or use env. vars. + +mvprog="${MVPROG-mv}" +cpprog="${CPPROG-cp}" +chmodprog="${CHMODPROG-chmod}" +chownprog="${CHOWNPROG-chown}" +chgrpprog="${CHGRPPROG-chgrp}" +stripprog="${STRIPPROG-strip}" +rmprog="${RMPROG-rm}" +mkdirprog="${MKDIRPROG-mkdir}" + +transformbasename="" +transform_arg="" +instcmd="$mvprog" +chmodcmd="$chmodprog 0755" +chowncmd="" +chgrpcmd="" +stripcmd="" +rmcmd="$rmprog -f" +mvcmd="$mvprog" +src="" +dst="" +dir_arg="" + +while [ x"$1" != x ]; do + case $1 in + -c) instcmd="$cpprog" + shift + continue;; + + -d) dir_arg=true + shift + continue;; + + -m) chmodcmd="$chmodprog $2" + shift + shift + continue;; + + -o) chowncmd="$chownprog $2" + shift + shift + continue;; + + -g) chgrpcmd="$chgrpprog $2" + shift + shift + continue;; + + -s) stripcmd="$stripprog" + shift + continue;; + + -t=*) transformarg=`echo $1 | sed 's/-t=//'` + shift + continue;; + + -b=*) transformbasename=`echo $1 | sed 's/-b=//'` + shift + continue;; + + *) if [ x"$src" = x ] + then + src=$1 + else + # this colon is to work around a 386BSD /bin/sh bug + : + dst=$1 + fi + shift + continue;; + esac +done + +if [ x"$src" = x ] +then + echo "install: no input file specified" + exit 1 +else + true +fi + +if [ x"$dir_arg" != x ]; then + dst=$src + src="" + + if [ -d $dst ]; then + instcmd=: + chmodcmd="" + else + instcmd=mkdir + fi +else + +# Waiting for this to be detected by the "$instcmd $src $dsttmp" command +# might cause directories to be created, which would be especially bad +# if $src (and thus $dsttmp) contains '*'. + + if [ -f $src -o -d $src ] + then + true + else + echo "install: $src does not exist" + exit 1 + fi + + if [ x"$dst" = x ] + then + echo "install: no destination specified" + exit 1 + else + true + fi + +# If destination is a directory, append the input filename; if your system +# does not like double slashes in filenames, you may need to add some logic + + if [ -d $dst ] + then + dst="$dst"/`basename $src` + else + true + fi +fi + +## this sed command emulates the dirname command +dstdir=`echo $dst | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'` + +# Make sure that the destination directory exists. +# this part is taken from Noah Friedman's mkinstalldirs script + +# Skip lots of stat calls in the usual case. +if [ ! -d "$dstdir" ]; then +defaultIFS=' +' +IFS="${IFS-${defaultIFS}}" + +oIFS="${IFS}" +# Some sh's can't handle IFS=/ for some reason. +IFS='%' +set - `echo ${dstdir} | sed -e 's@/@%@g' -e 's@^%@/@'` +IFS="${oIFS}" + +pathcomp='' + +while [ $# -ne 0 ] ; do + pathcomp="${pathcomp}${1}" + shift + + if [ ! -d "${pathcomp}" ] ; + then + $mkdirprog "${pathcomp}" + else + true + fi + + pathcomp="${pathcomp}/" +done +fi + +if [ x"$dir_arg" != x ] +then + $doit $instcmd $dst && + + if [ x"$chowncmd" != x ]; then $doit $chowncmd $dst; else true ; fi && + if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dst; else true ; fi && + if [ x"$stripcmd" != x ]; then $doit $stripcmd $dst; else true ; fi && + if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; else true ; fi +else + +# If we're going to rename the final executable, determine the name now. + + if [ x"$transformarg" = x ] + then + dstfile=`basename $dst` + else + dstfile=`basename $dst $transformbasename | + sed $transformarg`$transformbasename + fi + +# don't allow the sed command to completely eliminate the filename + + if [ x"$dstfile" = x ] + then + dstfile=`basename $dst` + else + true + fi + +# Make a temp file name in the proper directory. + + dsttmp=$dstdir/#inst.$$# + +# Move or copy the file name to the temp name + + $doit $instcmd $src $dsttmp && + + trap "rm -f ${dsttmp}" 0 && + +# and set any options; do chmod last to preserve setuid bits + +# If any of these fail, we abort the whole thing. If we want to +# ignore errors from any of these, just make sure not to ignore +# errors from the above "$doit $instcmd $src $dsttmp" command. + + if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; else true;fi && + if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; else true;fi && + if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; else true;fi && + if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dsttmp; else true;fi && + +# Now rename the file to the real destination. + + $doit $rmcmd -f $dstdir/$dstfile && + $doit $mvcmd $dsttmp $dstdir/$dstfile + +fi && + + +exit 0 diff --git a/crypto/heimdal/lib/roken/missing b/crypto/heimdal/lib/roken/missing new file mode 100755 index 000000000000..7789652e877f --- /dev/null +++ b/crypto/heimdal/lib/roken/missing @@ -0,0 +1,190 @@ +#! /bin/sh +# Common stub for a few missing GNU programs while installing. +# Copyright (C) 1996, 1997 Free Software Foundation, Inc. +# Franc,ois Pinard <pinard@iro.umontreal.ca>, 1996. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA +# 02111-1307, USA. + +if test $# -eq 0; then + echo 1>&2 "Try \`$0 --help' for more information" + exit 1 +fi + +case "$1" in + + -h|--h|--he|--hel|--help) + echo "\ +$0 [OPTION]... PROGRAM [ARGUMENT]... + +Handle \`PROGRAM [ARGUMENT]...' for when PROGRAM is missing, or return an +error status if there is no known handling for PROGRAM. + +Options: + -h, --help display this help and exit + -v, --version output version information and exit + +Supported PROGRAM values: + aclocal touch file \`aclocal.m4' + autoconf touch file \`configure' + autoheader touch file \`config.h.in' + automake touch all \`Makefile.in' files + bison create \`y.tab.[ch]', if possible, from existing .[ch] + flex create \`lex.yy.c', if possible, from existing .c + lex create \`lex.yy.c', if possible, from existing .c + makeinfo touch the output file + yacc create \`y.tab.[ch]', if possible, from existing .[ch]" + ;; + + -v|--v|--ve|--ver|--vers|--versi|--versio|--version) + echo "missing - GNU libit 0.0" + ;; + + -*) + echo 1>&2 "$0: Unknown \`$1' option" + echo 1>&2 "Try \`$0 --help' for more information" + exit 1 + ;; + + aclocal) + echo 1>&2 "\ +WARNING: \`$1' is missing on your system. You should only need it if + you modified \`acinclude.m4' or \`configure.in'. You might want + to install the \`Automake' and \`Perl' packages. Grab them from + any GNU archive site." + touch aclocal.m4 + ;; + + autoconf) + echo 1>&2 "\ +WARNING: \`$1' is missing on your system. You should only need it if + you modified \`configure.in'. You might want to install the + \`Autoconf' and \`GNU m4' packages. Grab them from any GNU + archive site." + touch configure + ;; + + autoheader) + echo 1>&2 "\ +WARNING: \`$1' is missing on your system. You should only need it if + you modified \`acconfig.h' or \`configure.in'. You might want + to install the \`Autoconf' and \`GNU m4' packages. Grab them + from any GNU archive site." + files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' configure.in` + test -z "$files" && files="config.h" + touch_files= + for f in $files; do + case "$f" in + *:*) touch_files="$touch_files "`echo "$f" | + sed -e 's/^[^:]*://' -e 's/:.*//'`;; + *) touch_files="$touch_files $f.in";; + esac + done + touch $touch_files + ;; + + automake) + echo 1>&2 "\ +WARNING: \`$1' is missing on your system. You should only need it if + you modified \`Makefile.am', \`acinclude.m4' or \`configure.in'. + You might want to install the \`Automake' and \`Perl' packages. + Grab them from any GNU archive site." + find . -type f -name Makefile.am -print | + sed 's/\.am$/.in/' | + while read f; do touch "$f"; done + ;; + + bison|yacc) + echo 1>&2 "\ +WARNING: \`$1' is missing on your system. You should only need it if + you modified a \`.y' file. You may need the \`Bison' package + in order for those modifications to take effect. You can get + \`Bison' from any GNU archive site." + rm -f y.tab.c y.tab.h + if [ $# -ne 1 ]; then + eval LASTARG="\${$#}" + case "$LASTARG" in + *.y) + SRCFILE=`echo "$LASTARG" | sed 's/y$/c/'` + if [ -f "$SRCFILE" ]; then + cp "$SRCFILE" y.tab.c + fi + SRCFILE=`echo "$LASTARG" | sed 's/y$/h/'` + if [ -f "$SRCFILE" ]; then + cp "$SRCFILE" y.tab.h + fi + ;; + esac + fi + if [ ! -f y.tab.h ]; then + echo >y.tab.h + fi + if [ ! -f y.tab.c ]; then + echo 'main() { return 0; }' >y.tab.c + fi + ;; + + lex|flex) + echo 1>&2 "\ +WARNING: \`$1' is missing on your system. You should only need it if + you modified a \`.l' file. You may need the \`Flex' package + in order for those modifications to take effect. You can get + \`Flex' from any GNU archive site." + rm -f lex.yy.c + if [ $# -ne 1 ]; then + eval LASTARG="\${$#}" + case "$LASTARG" in + *.l) + SRCFILE=`echo "$LASTARG" | sed 's/l$/c/'` + if [ -f "$SRCFILE" ]; then + cp "$SRCFILE" lex.yy.c + fi + ;; + esac + fi + if [ ! -f lex.yy.c ]; then + echo 'main() { return 0; }' >lex.yy.c + fi + ;; + + makeinfo) + echo 1>&2 "\ +WARNING: \`$1' is missing on your system. You should only need it if + you modified a \`.texi' or \`.texinfo' file, or any other file + indirectly affecting the aspect of the manual. The spurious + call might also be the consequence of using a buggy \`make' (AIX, + DU, IRIX). You might want to install the \`Texinfo' package or + the \`GNU make' package. Grab either from any GNU archive site." + file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'` + if test -z "$file"; then + file=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'` + file=`sed -n '/^@setfilename/ { s/.* \([^ ]*\) *$/\1/; p; q; }' $file` + fi + touch $file + ;; + + *) + echo 1>&2 "\ +WARNING: \`$1' is needed, and you do not seem to have it handy on your + system. You might have modified some files without having the + proper tools for further handling them. Check the \`README' file, + it often tells you about the needed prerequirements for installing + this package. You may also peek at any GNU archive site, in case + some other package would contain this missing \`$1' program." + exit 1 + ;; +esac + +exit 0 diff --git a/crypto/heimdal/lib/roken/mkinstalldirs b/crypto/heimdal/lib/roken/mkinstalldirs new file mode 100755 index 000000000000..6b3b5fc5d4d3 --- /dev/null +++ b/crypto/heimdal/lib/roken/mkinstalldirs @@ -0,0 +1,40 @@ +#! /bin/sh +# mkinstalldirs --- make directory hierarchy +# Author: Noah Friedman <friedman@prep.ai.mit.edu> +# Created: 1993-05-16 +# Public domain + +# $Id$ + +errstatus=0 + +for file +do + set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'` + shift + + pathcomp= + for d + do + pathcomp="$pathcomp$d" + case "$pathcomp" in + -* ) pathcomp=./$pathcomp ;; + esac + + if test ! -d "$pathcomp"; then + echo "mkdir $pathcomp" + + mkdir "$pathcomp" || lasterr=$? + + if test ! -d "$pathcomp"; then + errstatus=$lasterr + fi + fi + + pathcomp="$pathcomp/" + done +done + +exit $errstatus + +# mkinstalldirs ends here diff --git a/crypto/heimdal/lib/roken/rtbl.c b/crypto/heimdal/lib/roken/rtbl.c new file mode 100644 index 000000000000..098b601f5107 --- /dev/null +++ b/crypto/heimdal/lib/roken/rtbl.c @@ -0,0 +1,278 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID ("$Id: rtbl.c,v 1.3 2000/07/20 14:42:31 assar Exp $"); +#endif +#include "roken.h" +#include "rtbl.h" + +struct column_entry { + char *data; +}; + +struct column_data { + char *header; + char *prefix; + int width; + unsigned flags; + size_t num_rows; + struct column_entry *rows; +}; + +struct rtbl_data { + char *column_prefix; + size_t num_columns; + struct column_data **columns; +}; + +rtbl_t +rtbl_create (void) +{ + return calloc (1, sizeof (struct rtbl_data)); +} + +static struct column_data * +rtbl_get_column (rtbl_t table, const char *column) +{ + int i; + for(i = 0; i < table->num_columns; i++) + if(strcmp(table->columns[i]->header, column) == 0) + return table->columns[i]; + return NULL; +} + +void +rtbl_destroy (rtbl_t table) +{ + int i, j; + + for (i = 0; i < table->num_columns; i++) { + struct column_data *c = table->columns[i]; + + for (j = 0; j < c->num_rows; j++) + free (c->rows[j].data); + free (c->header); + free (c->prefix); + free (c); + } + free (table->column_prefix); + free (table->columns); +} + +int +rtbl_add_column (rtbl_t table, const char *header, unsigned int flags) +{ + struct column_data *col, **tmp; + + tmp = realloc (table->columns, (table->num_columns + 1) * sizeof (*tmp)); + if (tmp == NULL) + return ENOMEM; + table->columns = tmp; + col = malloc (sizeof (*col)); + if (col == NULL) + return ENOMEM; + col->header = strdup (header); + if (col->header == NULL) { + free (col); + return ENOMEM; + } + col->prefix = NULL; + col->width = 0; + col->flags = flags; + col->num_rows = 0; + col->rows = NULL; + table->columns[table->num_columns++] = col; + return 0; +} + +static void +column_compute_width (struct column_data *column) +{ + int i; + + column->width = strlen (column->header); + for (i = 0; i < column->num_rows; i++) + column->width = max (column->width, strlen (column->rows[i].data)); +} + +int +rtbl_set_prefix (rtbl_t table, const char *prefix) +{ + if (table->column_prefix) + free (table->column_prefix); + table->column_prefix = strdup (prefix); + if (table->column_prefix == NULL) + return ENOMEM; + return 0; +} + +int +rtbl_set_column_prefix (rtbl_t table, const char *column, + const char *prefix) +{ + struct column_data *c = rtbl_get_column (table, column); + + if (c == NULL) + return -1; + if (c->prefix) + free (c->prefix); + c->prefix = strdup (prefix); + if (c->prefix == NULL) + return ENOMEM; + return 0; +} + + +static const char * +get_column_prefix (rtbl_t table, struct column_data *c) +{ + if (c == NULL) + return ""; + if (c->prefix) + return c->prefix; + if (table->column_prefix) + return table->column_prefix; + return ""; +} + +int +rtbl_add_column_entry (rtbl_t table, const char *column, const char *data) +{ + struct column_entry row, *tmp; + + struct column_data *c = rtbl_get_column (table, column); + + if (c == NULL) + return -1; + + row.data = strdup (data); + if (row.data == NULL) + return ENOMEM; + tmp = realloc (c->rows, (c->num_rows + 1) * sizeof (*tmp)); + if (tmp == NULL) { + free (row.data); + return ENOMEM; + } + c->rows = tmp; + c->rows[c->num_rows++] = row; + return 0; +} + +int +rtbl_format (rtbl_t table, FILE * f) +{ + int i, j; + + for (i = 0; i < table->num_columns; i++) + column_compute_width (table->columns[i]); + for (i = 0; i < table->num_columns; i++) { + struct column_data *c = table->columns[i]; + + fprintf (f, "%s", get_column_prefix (table, c)); + fprintf (f, "%-*s", (int)c->width, c->header); + } + fprintf (f, "\n"); + + for (j = 0;; j++) { + int flag = 0; + + for (i = 0; flag == 0 && i < table->num_columns; ++i) { + struct column_data *c = table->columns[i]; + + if (c->num_rows > j) { + ++flag; + break; + } + } + if (flag == 0) + break; + + for (i = 0; i < table->num_columns; i++) { + int w; + struct column_data *c = table->columns[i]; + + w = c->width; + + if ((c->flags & RTBL_ALIGN_RIGHT) == 0) + w = -w; + fprintf (f, "%s", get_column_prefix (table, c)); + if (c->num_rows <= j) + fprintf (f, "%*s", w, ""); + else + fprintf (f, "%*s", w, c->rows[j].data); + } + fprintf (f, "\n"); + } + return 0; +} + +#ifdef TEST +int +main (int argc, char **argv) +{ + rtbl_t table; + unsigned int a, b, c, d; + + table = rtbl_create (); + rtbl_add_column (table, "Issued", 0, &a); + rtbl_add_column (table, "Expires", 0, &b); + rtbl_add_column (table, "Foo", RTBL_ALIGN_RIGHT, &d); + rtbl_add_column (table, "Principal", 0, &c); + + rtbl_add_column_entry (table, a, "Jul 7 21:19:29"); + rtbl_add_column_entry (table, b, "Jul 8 07:19:29"); + rtbl_add_column_entry (table, d, "73"); + rtbl_add_column_entry (table, d, "0"); + rtbl_add_column_entry (table, d, "-2000"); + rtbl_add_column_entry (table, c, "krbtgt/NADA.KTH.SE@NADA.KTH.SE"); + + rtbl_add_column_entry (table, a, "Jul 7 21:19:29"); + rtbl_add_column_entry (table, b, "Jul 8 07:19:29"); + rtbl_add_column_entry (table, c, "afs/pdc.kth.se@NADA.KTH.SE"); + + rtbl_add_column_entry (table, a, "Jul 7 21:19:29"); + rtbl_add_column_entry (table, b, "Jul 8 07:19:29"); + rtbl_add_column_entry (table, c, "afs@NADA.KTH.SE"); + + rtbl_set_prefix (table, " "); + rtbl_set_column_prefix (table, a, ""); + + rtbl_format (table, stdout); + + rtbl_destroy (table); + +} + +#endif diff --git a/crypto/heimdal/lib/roken/rtbl.h b/crypto/heimdal/lib/roken/rtbl.h new file mode 100644 index 000000000000..16496a7fd205 --- /dev/null +++ b/crypto/heimdal/lib/roken/rtbl.h @@ -0,0 +1,57 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifndef __rtbl_h__ +#define __rtbl_h__ + +struct rtbl_data; +typedef struct rtbl_data *rtbl_t; + +#define RTBL_ALIGN_LEFT 0 +#define RTBL_ALIGN_RIGHT 1 + +rtbl_t rtbl_create (void); + +void rtbl_destroy (rtbl_t); + +int rtbl_set_prefix (rtbl_t, const char*); + +int rtbl_set_column_prefix (rtbl_t, const char*, const char*); + +int rtbl_add_column (rtbl_t, const char*, unsigned int); + +int rtbl_add_column_entry (rtbl_t, const char*, const char*); + +int rtbl_format (rtbl_t, FILE*); + +#endif /* __rtbl_h__ */ diff --git a/crypto/heimdal/lib/roken/strsep_copy.c b/crypto/heimdal/lib/roken/strsep_copy.c new file mode 100644 index 000000000000..f09702234c75 --- /dev/null +++ b/crypto/heimdal/lib/roken/strsep_copy.c @@ -0,0 +1,67 @@ +/* + * Copyright (c) 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: strsep_copy.c,v 1.3 2000/06/29 03:13:36 assar Exp $"); +#endif + +#include <string.h> + +#include "roken.h" + +#ifndef HAVE_STRSEP_COPY + +/* strsep, but with const stringp, so return string in buf */ + +ssize_t +strsep_copy(const char **stringp, const char *delim, char *buf, size_t len) +{ + const char *save = *stringp; + size_t l; + if(save == NULL) + return -1; + *stringp = *stringp + strcspn(*stringp, delim); + l = min(len, *stringp - save); + memcpy(buf, save, l); + buf[l] = '\0'; + + l = *stringp - save; + if(**stringp == '\0') + *stringp = NULL; + else + (*stringp)++; + return l; +} + +#endif diff --git a/crypto/heimdal/lib/roken/timeval.c b/crypto/heimdal/lib/roken/timeval.c new file mode 100644 index 000000000000..ea4dee861810 --- /dev/null +++ b/crypto/heimdal/lib/roken/timeval.c @@ -0,0 +1,84 @@ +/* + * Copyright (c) 1999 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* + * Timeval stuff + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: timeval.c,v 1.1 2000/03/03 09:02:42 assar Exp $"); +#endif + +#include "roken.h" + +/* + * Make `t1' consistent. + */ + +void +timevalfix(struct timeval *t1) +{ + if (t1->tv_usec < 0) { + t1->tv_sec--; + t1->tv_usec += 1000000; + } + if (t1->tv_usec >= 1000000) { + t1->tv_sec++; + t1->tv_usec -= 1000000; + } +} + +/* + * t1 += t2 + */ + +void +timevaladd(struct timeval *t1, const struct timeval *t2) +{ + t1->tv_sec += t2->tv_sec; + t1->tv_usec += t2->tv_usec; + timevalfix(t1); +} + +/* + * t1 -= t2 + */ + +void +timevalsub(struct timeval *t1, const struct timeval *t2) +{ + t1->tv_sec -= t2->tv_sec; + t1->tv_usec -= t2->tv_usec; + timevalfix(t1); +} diff --git a/crypto/heimdal/lib/roken/unvis.c b/crypto/heimdal/lib/roken/unvis.c new file mode 100644 index 000000000000..363564c04966 --- /dev/null +++ b/crypto/heimdal/lib/roken/unvis.c @@ -0,0 +1,288 @@ +/* $NetBSD: unvis.c,v 1.19 2000/01/22 22:19:13 mycroft Exp $ */ + +/*- + * Copyright (c) 1989, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#if 1 +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: unvis.c,v 1.2 2000/12/06 21:41:46 joda Exp $"); +#endif +#include <roken.h> +#ifndef _DIAGASSERT +#define _DIAGASSERT(X) +#endif +#else +#include <sys/cdefs.h> +#if defined(LIBC_SCCS) && !defined(lint) +#if 0 +static char sccsid[] = "@(#)unvis.c 8.1 (Berkeley) 6/4/93"; +#else +__RCSID("$NetBSD: unvis.c,v 1.19 2000/01/22 22:19:13 mycroft Exp $"); +#endif +#endif /* LIBC_SCCS and not lint */ + +#define __LIBC12_SOURCE__ + +#include "namespace.h" +#endif +#include <sys/types.h> + +#include <assert.h> +#include <ctype.h> +#include <stdio.h> +#include <vis.h> + +#if 0 +#ifdef __weak_alias +__weak_alias(strunvis,_strunvis) +__weak_alias(unvis,_unvis) +#endif + +__warn_references(unvis, + "warning: reference to compatibility unvis(); include <vis.h> for correct reference") +#endif + +/* + * decode driven by state machine + */ +#define S_GROUND 0 /* haven't seen escape char */ +#define S_START 1 /* start decoding special sequence */ +#define S_META 2 /* metachar started (M) */ +#define S_META1 3 /* metachar more, regular char (-) */ +#define S_CTRL 4 /* control char started (^) */ +#define S_OCTAL2 5 /* octal digit 2 */ +#define S_OCTAL3 6 /* octal digit 3 */ + +#define isoctal(c) (((u_char)(c)) >= '0' && ((u_char)(c)) <= '7') + +/* + * unvis - decode characters previously encoded by vis + */ +#ifndef HAVE_UNVIS +int +unvis(char *cp, int c, int *astate, int flag) +{ + + _DIAGASSERT(cp != NULL); + _DIAGASSERT(astate != NULL); + + if (flag & UNVIS_END) { + if (*astate == S_OCTAL2 || *astate == S_OCTAL3) { + *astate = S_GROUND; + return (UNVIS_VALID); + } + return (*astate == S_GROUND ? UNVIS_NOCHAR : UNVIS_SYNBAD); + } + + switch (*astate) { + + case S_GROUND: + *cp = 0; + if (c == '\\') { + *astate = S_START; + return (0); + } + *cp = c; + return (UNVIS_VALID); + + case S_START: + switch(c) { + case '\\': + *cp = c; + *astate = S_GROUND; + return (UNVIS_VALID); + case '0': case '1': case '2': case '3': + case '4': case '5': case '6': case '7': + *cp = (c - '0'); + *astate = S_OCTAL2; + return (0); + case 'M': + *cp = (char)0200; + *astate = S_META; + return (0); + case '^': + *astate = S_CTRL; + return (0); + case 'n': + *cp = '\n'; + *astate = S_GROUND; + return (UNVIS_VALID); + case 'r': + *cp = '\r'; + *astate = S_GROUND; + return (UNVIS_VALID); + case 'b': + *cp = '\b'; + *astate = S_GROUND; + return (UNVIS_VALID); + case 'a': + *cp = '\007'; + *astate = S_GROUND; + return (UNVIS_VALID); + case 'v': + *cp = '\v'; + *astate = S_GROUND; + return (UNVIS_VALID); + case 't': + *cp = '\t'; + *astate = S_GROUND; + return (UNVIS_VALID); + case 'f': + *cp = '\f'; + *astate = S_GROUND; + return (UNVIS_VALID); + case 's': + *cp = ' '; + *astate = S_GROUND; + return (UNVIS_VALID); + case 'E': + *cp = '\033'; + *astate = S_GROUND; + return (UNVIS_VALID); + case '\n': + /* + * hidden newline + */ + *astate = S_GROUND; + return (UNVIS_NOCHAR); + case '$': + /* + * hidden marker + */ + *astate = S_GROUND; + return (UNVIS_NOCHAR); + } + *astate = S_GROUND; + return (UNVIS_SYNBAD); + + case S_META: + if (c == '-') + *astate = S_META1; + else if (c == '^') + *astate = S_CTRL; + else { + *astate = S_GROUND; + return (UNVIS_SYNBAD); + } + return (0); + + case S_META1: + *astate = S_GROUND; + *cp |= c; + return (UNVIS_VALID); + + case S_CTRL: + if (c == '?') + *cp |= 0177; + else + *cp |= c & 037; + *astate = S_GROUND; + return (UNVIS_VALID); + + case S_OCTAL2: /* second possible octal digit */ + if (isoctal(c)) { + /* + * yes - and maybe a third + */ + *cp = (*cp << 3) + (c - '0'); + *astate = S_OCTAL3; + return (0); + } + /* + * no - done with current sequence, push back passed char + */ + *astate = S_GROUND; + return (UNVIS_VALIDPUSH); + + case S_OCTAL3: /* third possible octal digit */ + *astate = S_GROUND; + if (isoctal(c)) { + *cp = (*cp << 3) + (c - '0'); + return (UNVIS_VALID); + } + /* + * we were done, push back passed char + */ + return (UNVIS_VALIDPUSH); + + default: + /* + * decoder in unknown state - (probably uninitialized) + */ + *astate = S_GROUND; + return (UNVIS_SYNBAD); + } +} +#endif + +/* + * strunvis - decode src into dst + * + * Number of chars decoded into dst is returned, -1 on error. + * Dst is null terminated. + */ + +#ifndef HAVE_STRUNVIS +int +strunvis(char *dst, const char *src) +{ + char c; + char *start = dst; + int state = 0; + + _DIAGASSERT(src != NULL); + _DIAGASSERT(dst != NULL); + + while ((c = *src++) != '\0') { + again: + switch (unvis(dst, c, &state, 0)) { + case UNVIS_VALID: + dst++; + break; + case UNVIS_VALIDPUSH: + dst++; + goto again; + case 0: + case UNVIS_NOCHAR: + break; + default: + return (-1); + } + } + if (unvis(dst, c, &state, UNVIS_END) == UNVIS_VALID) + dst++; + *dst = '\0'; + return (dst - start); +} +#endif diff --git a/crypto/heimdal/lib/roken/vis.c b/crypto/heimdal/lib/roken/vis.c new file mode 100644 index 000000000000..82a6ba5d006e --- /dev/null +++ b/crypto/heimdal/lib/roken/vis.c @@ -0,0 +1,301 @@ +/* $NetBSD: vis.c,v 1.19 2000/01/22 22:42:45 mycroft Exp $ */ + +/*- + * Copyright (c) 1999 The NetBSD Foundation, Inc. + * Copyright (c) 1989, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + + +#if 1 +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: vis.c,v 1.3 2000/12/10 23:10:48 assar Exp $"); +#endif +#include <roken.h> +#ifndef _DIAGASSERT +#define _DIAGASSERT(X) +#endif +#else +#include <sys/cdefs.h> +#if !defined(lint) +__RCSID("$NetBSD: vis.c,v 1.19 2000/01/22 22:42:45 mycroft Exp $"); +#endif /* not lint */ +#endif + +#if 0 +#include "namespace.h" +#endif +#include <sys/types.h> + +#include <assert.h> +#include <ctype.h> +#include <limits.h> +#include <stdio.h> +#include <string.h> +#include <vis.h> + +#if 0 +#ifdef __weak_alias +__weak_alias(strsvis,_strsvis) +__weak_alias(strsvisx,_strsvisx) +__weak_alias(strvis,_strvis) +__weak_alias(strvisx,_strvisx) +__weak_alias(svis,_svis) +__weak_alias(vis,_vis) +#endif +#endif + +#undef BELL +#if defined(__STDC__) +#define BELL '\a' +#else +#define BELL '\007' +#endif + +#define isoctal(c) (((u_char)(c)) >= '0' && ((u_char)(c)) <= '7') +#define iswhite(c) (c == ' ' || c == '\t' || c == '\n') +#define issafe(c) (c == '\b' || c == BELL || c == '\r') + +#define MAXEXTRAS 5 + + +#define MAKEEXTRALIST(flag, extra) \ +do { \ + char *pextra = extra; \ + if (flag & VIS_SP) *pextra++ = ' '; \ + if (flag & VIS_TAB) *pextra++ = '\t'; \ + if (flag & VIS_NL) *pextra++ = '\n'; \ + if ((flag & VIS_NOSLASH) == 0) *pextra++ = '\\'; \ + *pextra = '\0'; \ +} while (/*CONSTCOND*/0) + +/* + * This is SVIS, the central macro of vis. + * dst: Pointer to the destination buffer + * c: Character to encode + * flag: Flag word + * nextc: The character following 'c' + * extra: Pointer to the list of extra characters to be + * backslash-protected. + */ +#define SVIS(dst, c, flag, nextc, extra) \ +do { \ + int isextra, isc; \ + isextra = strchr(extra, c) != NULL; \ + if (!isextra && isascii(c) && (isgraph(c) || iswhite(c) || \ + ((flag & VIS_SAFE) && issafe(c)))) { \ + *dst++ = c; \ + break; \ + } \ + isc = 0; \ + if (flag & VIS_CSTYLE) { \ + switch (c) { \ + case '\n': \ + isc = 1; *dst++ = '\\'; *dst++ = 'n'; \ + break; \ + case '\r': \ + isc = 1; *dst++ = '\\'; *dst++ = 'r'; \ + break; \ + case '\b': \ + isc = 1; *dst++ = '\\'; *dst++ = 'b'; \ + break; \ + case BELL: \ + isc = 1; *dst++ = '\\'; *dst++ = 'a'; \ + break; \ + case '\v': \ + isc = 1; *dst++ = '\\'; *dst++ = 'v'; \ + break; \ + case '\t': \ + isc = 1; *dst++ = '\\'; *dst++ = 't'; \ + break; \ + case '\f': \ + isc = 1; *dst++ = '\\'; *dst++ = 'f'; \ + break; \ + case ' ': \ + isc = 1; *dst++ = '\\'; *dst++ = 's'; \ + break; \ + case '\0': \ + isc = 1; *dst++ = '\\'; *dst++ = '0'; \ + if (isoctal(nextc)) { \ + *dst++ = '0'; \ + *dst++ = '0'; \ + } \ + } \ + } \ + if (isc) break; \ + if (isextra || ((c & 0177) == ' ') || (flag & VIS_OCTAL)) { \ + *dst++ = '\\'; \ + *dst++ = (u_char)(((unsigned)(u_char)c >> 6) & 03) + '0'; \ + *dst++ = (u_char)(((unsigned)(u_char)c >> 3) & 07) + '0'; \ + *dst++ = (c & 07) + '0'; \ + } else { \ + if ((flag & VIS_NOSLASH) == 0) *dst++ = '\\'; \ + if (c & 0200) { \ + c &= 0177; *dst++ = 'M'; \ + } \ + if (iscntrl(c)) { \ + *dst++ = '^'; \ + if (c == 0177) \ + *dst++ = '?'; \ + else \ + *dst++ = c + '@'; \ + } else { \ + *dst++ = '-'; *dst++ = c; \ + } \ + } \ +} while (/*CONSTCOND*/0) + + +/* + * svis - visually encode characters, also encoding the characters + * pointed to by `extra' + */ +#ifndef HAVE_SVIS +char * +svis(char *dst, int c, int flag, int nextc, const char *extra) +{ + _DIAGASSERT(dst != NULL); + _DIAGASSERT(extra != NULL); + + SVIS(dst, c, flag, nextc, extra); + *dst = '\0'; + return(dst); +} +#endif + + +/* + * strsvis, strsvisx - visually encode characters from src into dst + * + * Extra is a pointer to a \0-terminated list of characters to + * be encoded, too. These functions are useful e. g. to + * encode strings in such a way so that they are not interpreted + * by a shell. + * + * Dst must be 4 times the size of src to account for possible + * expansion. The length of dst, not including the trailing NULL, + * is returned. + * + * Strsvisx encodes exactly len bytes from src into dst. + * This is useful for encoding a block of data. + */ +#ifndef HAVE_STRSVIS +int +strsvis(char *dst, const char *src, int flag, const char *extra) +{ + char c; + char *start; + + _DIAGASSERT(dst != NULL); + _DIAGASSERT(src != NULL); + _DIAGASSERT(extra != NULL); + + for (start = dst; (c = *src++) != '\0'; /* empty */) + SVIS(dst, c, flag, *src, extra); + *dst = '\0'; + return (dst - start); +} +#endif + + +#ifndef HAVE_STRVISX +int +strsvisx(char *dst, const char *src, size_t len, int flag, const char *extra) +{ + char c; + char *start; + + _DIAGASSERT(dst != NULL); + _DIAGASSERT(src != NULL); + _DIAGASSERT(extra != NULL); + + for (start = dst; len > 0; len--) { + c = *src++; + SVIS(dst, c, flag, len ? *src : '\0', extra); + } + *dst = '\0'; + return (dst - start); +} +#endif + + +/* + * vis - visually encode characters + */ +#ifndef HAVE_VIS +char * +vis(char *dst, int c, int flag, int nextc) +{ + char extra[MAXEXTRAS]; + + _DIAGASSERT(dst != NULL); + + MAKEEXTRALIST(flag, extra); + SVIS(dst, c, flag, nextc, extra); + *dst = '\0'; + return (dst); +} +#endif + + +/* + * strvis, strvisx - visually encode characters from src into dst + * + * Dst must be 4 times the size of src to account for possible + * expansion. The length of dst, not including the trailing NULL, + * is returned. + * + * Strvisx encodes exactly len bytes from src into dst. + * This is useful for encoding a block of data. + */ +#ifndef HAVE_STRVIS +int +strvis(char *dst, const char *src, int flag) +{ + char extra[MAXEXTRAS]; + + MAKEEXTRALIST(flag, extra); + return (strsvis(dst, src, flag, extra)); +} +#endif + + +#ifndef HAVE_STRVISX +int +strvisx(char *dst, const char *src, size_t len, int flag) +{ + char extra[MAXEXTRAS]; + + MAKEEXTRALIST(flag, extra); + return (strsvisx(dst, src, len, flag, extra)); +} +#endif diff --git a/crypto/heimdal/lib/roken/vis.hin b/crypto/heimdal/lib/roken/vis.hin new file mode 100644 index 000000000000..a9d09da95829 --- /dev/null +++ b/crypto/heimdal/lib/roken/vis.hin @@ -0,0 +1,86 @@ +/* $NetBSD: vis.h,v 1.11 1999/11/25 16:55:50 wennmach Exp $ */ +/* $Id: vis.hin,v 1.1 2000/12/06 21:35:47 joda Exp $ */ + +/*- + * Copyright (c) 1990, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)vis.h 8.1 (Berkeley) 6/2/93 + */ + +#ifndef _VIS_H_ +#define _VIS_H_ + +/* + * to select alternate encoding format + */ +#define VIS_OCTAL 0x01 /* use octal \ddd format */ +#define VIS_CSTYLE 0x02 /* use \[nrft0..] where appropiate */ + +/* + * to alter set of characters encoded (default is to encode all + * non-graphic except space, tab, and newline). + */ +#define VIS_SP 0x04 /* also encode space */ +#define VIS_TAB 0x08 /* also encode tab */ +#define VIS_NL 0x10 /* also encode newline */ +#define VIS_WHITE (VIS_SP | VIS_TAB | VIS_NL) +#define VIS_SAFE 0x20 /* only encode "unsafe" characters */ + +/* + * other + */ +#define VIS_NOSLASH 0x40 /* inhibit printing '\' */ + +/* + * unvis return codes + */ +#define UNVIS_VALID 1 /* character valid */ +#define UNVIS_VALIDPUSH 2 /* character valid, push back passed char */ +#define UNVIS_NOCHAR 3 /* valid sequence, no character produced */ +#define UNVIS_SYNBAD -1 /* unrecognized escape sequence */ +#define UNVIS_ERROR -2 /* decoder in unknown state (unrecoverable) */ + +/* + * unvis flags + */ +#define UNVIS_END 1 /* no more characters */ + +char *vis (char *, int, int, int); +char *svis (char *, int, int, int, const char *); +int strvis (char *, const char *, int); +int strsvis (char *, const char *, int, const char *); +int strvisx (char *, const char *, size_t, int); +int strsvisx (char *, const char *, size_t, int, const char *); +int strunvis (char *, const char *); +int unvis (char *, int, int *, int); + +#endif /* !_VIS_H_ */ diff --git a/crypto/heimdal/lib/roken/write_pid.c b/crypto/heimdal/lib/roken/write_pid.c new file mode 100644 index 000000000000..7d4fa24626e7 --- /dev/null +++ b/crypto/heimdal/lib/roken/write_pid.c @@ -0,0 +1,95 @@ +/* + * Copyright (c) 1999 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: write_pid.c,v 1.4 2000/08/04 11:19:41 joda Exp $"); +#endif + +#include <stdio.h> +#include <sys/types.h> +#include <unistd.h> +#include <roken.h> + +#include "roken.h" + +char * +pid_file_write (const char *progname) +{ + FILE *fp; + char *ret; + + asprintf (&ret, "%s%s.pid", _PATH_VARRUN, progname); + if (ret == NULL) + return NULL; + fp = fopen (ret, "w"); + if (fp == NULL) { + free (ret); + return NULL; + } + fprintf (fp, "%u", (unsigned)getpid()); + fclose (fp); + return ret; +} + +void +pid_file_delete (char **filename) +{ + if (*filename != NULL) { + unlink (*filename); + free (*filename); + *filename = NULL; + } +} + +#ifndef HAVE_PIDFILE +static char *pidfile_path; + +static void +pidfile_cleanup(void) +{ + if(pidfile_path != NULL) + pid_file_delete(&pidfile_path); +} + +void +pidfile(const char *basename) +{ + if(pidfile_path != NULL) + return; + if(basename == NULL) + basename = __progname; + pidfile_path = pid_file_write(basename); + atexit(pidfile_cleanup); +} +#endif diff --git a/crypto/heimdal/lib/vers/ChangeLog b/crypto/heimdal/lib/vers/ChangeLog new file mode 100644 index 000000000000..459c94009ccd --- /dev/null +++ b/crypto/heimdal/lib/vers/ChangeLog @@ -0,0 +1,13 @@ +2001-01-31 Assar Westerlund <assar@sics.se> + + * Makefile.am: remove -static turning this into a convenience + library + +2000-11-15 Assar Westerlund <assar@sics.se> + + * Makefile.am: make the library static and don't install it + +2000-07-08 Assar Westerlund <assar@sics.se> + + * make-print-version.c (heimdal_version, krb4_version): const-ize, + based on thorpej@netbsd.org's change to NetBSD diff --git a/crypto/heimdal/lib/vers/Makefile.am b/crypto/heimdal/lib/vers/Makefile.am new file mode 100644 index 000000000000..87ef2467ad6e --- /dev/null +++ b/crypto/heimdal/lib/vers/Makefile.am @@ -0,0 +1,28 @@ +# $Id: Makefile.am,v 1.3 2001/01/31 03:50:48 assar Exp $ + +include $(top_srcdir)/Makefile.am.common + +CLEANFILES = print_version.h + +noinst_LTLIBRARIES = libvers.la + +build_HEADERZ = vers.h + +noinst_PROGRAMS = make-print-version + +if KRB4 +if KRB5 +## need to link with des here; otherwise, if krb4 is shared the link +## will fail with unresolved references +make_print_version_LDADD += $(LIB_krb4) -ldes +endif +endif + +libvers_la_SOURCES = print_version.c + +print_version.lo: print_version.h + +print_version.h: make-print-version$(EXEEXT) + ./make-print-version$(EXEEXT) print_version.h + +make-print-version.o: $(top_builddir)/include/version.h diff --git a/crypto/heimdal/lib/vers/Makefile.in b/crypto/heimdal/lib/vers/Makefile.in new file mode 100644 index 000000000000..8b8da036d8fd --- /dev/null +++ b/crypto/heimdal/lib/vers/Makefile.in @@ -0,0 +1,574 @@ +# Makefile.in generated automatically by automake 1.4a from Makefile.am + +# Copyright (C) 1994, 1995-9, 2000 Free Software Foundation, Inc. +# This Makefile.in is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY, to the extent permitted by law; without +# even the implied warranty of MERCHANTABILITY or FITNESS FOR A +# PARTICULAR PURPOSE. + +SHELL = @SHELL@ + +srcdir = @srcdir@ +top_srcdir = @top_srcdir@ +VPATH = @srcdir@ +prefix = @prefix@ +exec_prefix = @exec_prefix@ + +bindir = @bindir@ +sbindir = @sbindir@ +libexecdir = @libexecdir@ +datadir = @datadir@ +sysconfdir = @sysconfdir@ +sharedstatedir = @sharedstatedir@ +localstatedir = @localstatedir@ +libdir = @libdir@ +infodir = @infodir@ +mandir = @mandir@ +includedir = @includedir@ +oldincludedir = /usr/include + +pkgdatadir = $(datadir)/@PACKAGE@ +pkglibdir = $(libdir)/@PACKAGE@ +pkgincludedir = $(includedir)/@PACKAGE@ + +top_builddir = ../.. + +ACLOCAL = @ACLOCAL@ +AUTOCONF = @AUTOCONF@ +AUTOMAKE = @AUTOMAKE@ +AUTOHEADER = @AUTOHEADER@ + +INSTALL = @INSTALL@ +INSTALL_PROGRAM = @INSTALL_PROGRAM@ +INSTALL_DATA = @INSTALL_DATA@ +INSTALL_SCRIPT = @INSTALL_SCRIPT@ +INSTALL_STRIP_FLAG = +transform = @program_transform_name@ + +NORMAL_INSTALL = : +PRE_INSTALL = : +POST_INSTALL = : +NORMAL_UNINSTALL = : +PRE_UNINSTALL = : +POST_UNINSTALL = : + +@SET_MAKE@ +host_alias = @host_alias@ +host_triplet = @host@ +AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@ +AMDEP = @AMDEP@ +AMTAR = @AMTAR@ +AS = @AS@ +AWK = @AWK@ +CANONICAL_HOST = @CANONICAL_HOST@ +CATMAN = @CATMAN@ +CATMANEXT = @CATMANEXT@ +CC = @CC@ +CPP = @CPP@ +CXX = @CXX@ +CXXCPP = @CXXCPP@ +DBLIB = @DBLIB@ +DEPDIR = @DEPDIR@ +DIR_des = @DIR_des@ +DIR_roken = @DIR_roken@ +DLLTOOL = @DLLTOOL@ +EXEEXT = @EXEEXT@ +EXTRA_LIB45 = @EXTRA_LIB45@ +GROFF = @GROFF@ +INCLUDES_roken = @INCLUDES_roken@ +INCLUDE_ = @INCLUDE_@ +LEX = @LEX@ +LIBOBJS = @LIBOBJS@ +LIBTOOL = @LIBTOOL@ +LIB_ = @LIB_@ +LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@ +LIB_des = @LIB_des@ +LIB_des_appl = @LIB_des_appl@ +LIB_kdb = @LIB_kdb@ +LIB_otp = @LIB_otp@ +LIB_roken = @LIB_roken@ +LIB_security = @LIB_security@ +LN_S = @LN_S@ +LTLIBOBJS = @LTLIBOBJS@ +MAKEINFO = @MAKEINFO@ +NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@ +NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@ +NROFF = @NROFF@ +OBJDUMP = @OBJDUMP@ +OBJEXT = @OBJEXT@ +PACKAGE = @PACKAGE@ +RANLIB = @RANLIB@ +STRIP = @STRIP@ +VERSION = @VERSION@ +VOID_RETSIGTYPE = @VOID_RETSIGTYPE@ +WFLAGS = @WFLAGS@ +WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@ +WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@ +YACC = @YACC@ +dpagaix_CFLAGS = @dpagaix_CFLAGS@ +dpagaix_LDADD = @dpagaix_LDADD@ +install_sh = @install_sh@ + +# $Id: Makefile.am,v 1.3 2001/01/31 03:50:48 assar Exp $ + + +# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $ + + +# $Id: Makefile.am.common,v 1.23 2000/12/05 09:11:09 joda Exp $ + + +AUTOMAKE_OPTIONS = foreign no-dependencies + +SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x + +INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken) + +AM_CFLAGS = $(WFLAGS) + +CP = cp + +COMPILE_ET = $(top_builddir)/lib/com_err/compile_et + +buildinclude = $(top_builddir)/include + +LIB_XauReadAuth = @LIB_XauReadAuth@ +LIB_crypt = @LIB_crypt@ +LIB_dbm_firstkey = @LIB_dbm_firstkey@ +LIB_dbopen = @LIB_dbopen@ +LIB_dlopen = @LIB_dlopen@ +LIB_dn_expand = @LIB_dn_expand@ +LIB_el_init = @LIB_el_init@ +LIB_getattr = @LIB_getattr@ +LIB_gethostbyname = @LIB_gethostbyname@ +LIB_getpwent_r = @LIB_getpwent_r@ +LIB_getpwnam_r = @LIB_getpwnam_r@ +LIB_getsockopt = @LIB_getsockopt@ +LIB_logout = @LIB_logout@ +LIB_logwtmp = @LIB_logwtmp@ +LIB_odm_initialize = @LIB_odm_initialize@ +LIB_pidfile = @LIB_pidfile@ +LIB_readline = @LIB_readline@ +LIB_res_search = @LIB_res_search@ +LIB_setpcred = @LIB_setpcred@ +LIB_setsockopt = @LIB_setsockopt@ +LIB_socket = @LIB_socket@ +LIB_syslog = @LIB_syslog@ +LIB_tgetent = @LIB_tgetent@ + +LIBS = @LIBS@ + +HESIODLIB = @HESIODLIB@ +HESIODINCLUDE = @HESIODINCLUDE@ +INCLUDE_hesiod = @INCLUDE_hesiod@ +LIB_hesiod = @LIB_hesiod@ + +INCLUDE_krb4 = @INCLUDE_krb4@ +LIB_krb4 = @LIB_krb4@ + +INCLUDE_openldap = @INCLUDE_openldap@ +LIB_openldap = @LIB_openldap@ + +INCLUDE_readline = @INCLUDE_readline@ + +LEXLIB = @LEXLIB@ + +NROFF_MAN = groff -mandoc -Tascii + +@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS) + +@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \ +@KRB5_TRUE@ $(top_builddir)/lib/asn1/libasn1.la +@KRB5_TRUE@LIB_gssapi = @KRB5_TRUE@$(top_builddir)/lib/gssapi/libgssapi.la + +CHECK_LOCAL = $(PROGRAMS) + +CLEANFILES = print_version.h + +noinst_LTLIBRARIES = libvers.la + +build_HEADERZ = vers.h + +noinst_PROGRAMS = make-print-version + +@KRB4_TRUE@@KRB5_TRUE@make_print_version_LDADD = @KRB4_TRUE@@KRB5_TRUE@ $(LIB_krb4) -ldes + +libvers_la_SOURCES = print_version.c +subdir = lib/vers +mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs +CONFIG_HEADER = ../../include/config.h +CONFIG_CLEAN_FILES = +LTLIBRARIES = $(noinst_LTLIBRARIES) + + +DEFS = @DEFS@ -I. -I$(srcdir) -I../../include +CPPFLAGS = @CPPFLAGS@ +LDFLAGS = @LDFLAGS@ +X_CFLAGS = @X_CFLAGS@ +X_LIBS = @X_LIBS@ +X_EXTRA_LIBS = @X_EXTRA_LIBS@ +X_PRE_LIBS = @X_PRE_LIBS@ +libvers_la_LDFLAGS = +libvers_la_LIBADD = +am_libvers_la_OBJECTS = print_version.lo +libvers_la_OBJECTS = $(am_libvers_la_OBJECTS) +noinst_PROGRAMS = make-print-version$(EXEEXT) +PROGRAMS = $(noinst_PROGRAMS) + +make_print_version_SOURCES = make-print-version.c +make_print_version_OBJECTS = make-print-version.$(OBJEXT) +@KRB4_TRUE@@KRB5_TRUE@make_print_version_DEPENDENCIES = +make_print_version_LDFLAGS = +COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +CFLAGS = @CFLAGS@ +CCLD = $(CC) +LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ +DIST_SOURCES = $(libvers_la_SOURCES) make-print-version.c +depcomp = +DIST_COMMON = ChangeLog Makefile.am Makefile.in + + +DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) + +GZIP_ENV = --best +SOURCES = $(libvers_la_SOURCES) make-print-version.c +OBJECTS = $(am_libvers_la_OBJECTS) make-print-version.$(OBJEXT) + +all: all-redirect +.SUFFIXES: +.SUFFIXES: .1 .3 .5 .8 .c .cat1 .cat3 .cat5 .cat8 .et .h .lo .o .obj .x +$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4) $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common + cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/vers/Makefile + +Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status + cd $(top_builddir) \ + && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status + + +mostlyclean-noinstLTLIBRARIES: + +clean-noinstLTLIBRARIES: + -test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES) + +distclean-noinstLTLIBRARIES: + +maintainer-clean-noinstLTLIBRARIES: + +mostlyclean-compile: + -rm -f *.o core *.core + -rm -f *.$(OBJEXT) + +clean-compile: + +distclean-compile: + -rm -f *.tab.c + +maintainer-clean-compile: + +mostlyclean-libtool: + -rm -f *.lo + +clean-libtool: + -rm -rf .libs _libs + +distclean-libtool: + +maintainer-clean-libtool: + +libvers.la: $(libvers_la_OBJECTS) $(libvers_la_DEPENDENCIES) + $(LINK) $(libvers_la_LDFLAGS) $(libvers_la_OBJECTS) $(libvers_la_LIBADD) $(LIBS) + +mostlyclean-noinstPROGRAMS: + +clean-noinstPROGRAMS: + -test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS) + +distclean-noinstPROGRAMS: + +maintainer-clean-noinstPROGRAMS: + +make-print-version$(EXEEXT): $(make_print_version_OBJECTS) $(make_print_version_DEPENDENCIES) + @rm -f make-print-version$(EXEEXT) + $(LINK) $(make_print_version_LDFLAGS) $(make_print_version_OBJECTS) $(make_print_version_LDADD) $(LIBS) +.c.o: + $(COMPILE) -c $< +.c.obj: + $(COMPILE) -c `cygpath -w $<` +.c.lo: + $(LTCOMPILE) -c -o $@ $< + +tags: TAGS + +ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES) + list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \ + unique=`for i in $$list; do \ + if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ + done | \ + $(AWK) ' { files[$$0] = 1; } \ + END { for (i in files) print i; }'`; \ + mkid -fID $$unique $(LISP) + +TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \ + $(TAGS_FILES) $(LISP) + tags=; \ + here=`pwd`; \ + list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \ + unique=`for i in $$list; do \ + if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ + done | \ + $(AWK) ' { files[$$0] = 1; } \ + END { for (i in files) print i; }'`; \ + test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \ + || etags $(ETAGS_ARGS) $$tags $$unique $(LISP) + +mostlyclean-tags: + +clean-tags: + +distclean-tags: + -rm -f TAGS ID + +maintainer-clean-tags: + +distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir) + +distdir: $(DISTFILES) + @for file in $(DISTFILES); do \ + d=$(srcdir); \ + if test -d $$d/$$file; then \ + cp -pR $$d/$$file $(distdir) \ + || exit 1; \ + else \ + test -f $(distdir)/$$file \ + || cp -p $$d/$$file $(distdir)/$$file \ + || exit 1; \ + fi; \ + done + $(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-hook +info-am: +info: info-am +dvi-am: +dvi: dvi-am +check-am: all-am + $(MAKE) $(AM_MAKEFLAGS) check-local +check: check-am +installcheck-am: +installcheck: installcheck-am +install-exec-am: + @$(NORMAL_INSTALL) + $(MAKE) $(AM_MAKEFLAGS) install-exec-hook +install-exec: install-exec-am + +install-data-am: install-data-local +install-data: install-data-am + +install-am: all-am + @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am +install: install-am +uninstall-am: +uninstall: uninstall-am +all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) all-local +all-redirect: all-am +install-strip: + $(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install +installdirs: + + +mostlyclean-generic: + +clean-generic: + -test -z "$(CLEANFILES)" || rm -f $(CLEANFILES) + +distclean-generic: + -rm -f Makefile $(CONFIG_CLEAN_FILES) + -rm -f config.cache config.log stamp-h stamp-h[0-9]* + +maintainer-clean-generic: + -rm -f Makefile.in +mostlyclean-am: mostlyclean-noinstLTLIBRARIES mostlyclean-compile \ + mostlyclean-libtool mostlyclean-noinstPROGRAMS \ + mostlyclean-tags mostlyclean-generic + +mostlyclean: mostlyclean-am + +clean-am: clean-noinstLTLIBRARIES clean-compile clean-libtool \ + clean-noinstPROGRAMS clean-tags clean-generic \ + mostlyclean-am + +clean: clean-am + +distclean-am: distclean-noinstLTLIBRARIES distclean-compile \ + distclean-libtool distclean-noinstPROGRAMS \ + distclean-tags distclean-generic clean-am + -rm -f libtool + +distclean: distclean-am + +maintainer-clean-am: maintainer-clean-noinstLTLIBRARIES \ + maintainer-clean-compile maintainer-clean-libtool \ + maintainer-clean-noinstPROGRAMS maintainer-clean-tags \ + maintainer-clean-generic distclean-am + @echo "This command is intended for maintainers to use;" + @echo "it deletes files that may require special tools to rebuild." + +maintainer-clean: maintainer-clean-am + +.PHONY: mostlyclean-noinstLTLIBRARIES distclean-noinstLTLIBRARIES \ +clean-noinstLTLIBRARIES maintainer-clean-noinstLTLIBRARIES \ +mostlyclean-compile distclean-compile clean-compile \ +maintainer-clean-compile mostlyclean-libtool distclean-libtool \ +clean-libtool maintainer-clean-libtool mostlyclean-noinstPROGRAMS \ +distclean-noinstPROGRAMS clean-noinstPROGRAMS \ +maintainer-clean-noinstPROGRAMS tags mostlyclean-tags distclean-tags \ +clean-tags maintainer-clean-tags distdir info-am info dvi-am dvi \ +check-local check check-am installcheck-am installcheck install-exec-am \ +install-exec install-data-local install-data-am install-data install-am \ +install uninstall-am uninstall all-local all-redirect all-am all \ +install-strip installdirs mostlyclean-generic distclean-generic \ +clean-generic maintainer-clean-generic clean mostlyclean distclean \ +maintainer-clean + + +install-suid-programs: + @foo='$(bin_SUIDS)'; \ + for file in $$foo; do \ + x=$(DESTDIR)$(bindir)/$$file; \ + if chown 0:0 $$x && chmod u+s $$x; then :; else \ + echo "*"; \ + echo "* Failed to install $$x setuid root"; \ + echo "*"; \ + fi; done + +install-exec-hook: install-suid-programs + +install-build-headers:: $(include_HEADERS) $(build_HEADERZ) + @foo='$(include_HEADERS) $(build_HEADERZ)'; \ + for f in $$foo; do \ + f=`basename $$f`; \ + if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \ + else file="$$f"; fi; \ + if cmp -s $$file $(buildinclude)/$$f 2> /dev/null ; then \ + : ; else \ + echo " $(CP) $$file $(buildinclude)/$$f"; \ + $(CP) $$file $(buildinclude)/$$f; \ + fi ; \ + done + +all-local: install-build-headers +#NROFF_MAN = nroff -man +.1.cat1: + $(NROFF_MAN) $< > $@ +.3.cat3: + $(NROFF_MAN) $< > $@ +.5.cat5: + $(NROFF_MAN) $< > $@ +.8.cat8: + $(NROFF_MAN) $< > $@ + +dist-cat1-mans: + @foo='$(man1_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.1) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat3-mans: + @foo='$(man3_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.3) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat5-mans: + @foo='$(man5_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.5) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat8-mans: + @foo='$(man8_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.8) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans + +install-cat-mans: + $(SHELL) $(top_srcdir)/cf/install-catman.sh "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS) + +install-data-local: install-cat-mans + +.et.h: + $(COMPILE_ET) $< +.et.c: + $(COMPILE_ET) $< + +.x.c: + @cmp -s $< $@ 2> /dev/null || cp $< $@ + +check-local:: + @foo='$(CHECK_LOCAL)'; \ + if test "$$foo"; then \ + failed=0; all=0; \ + for i in $$foo; do \ + all=`expr $$all + 1`; \ + if ./$$i --version > /dev/null 2>&1; then \ + echo "PASS: $$i"; \ + else \ + echo "FAIL: $$i"; \ + failed=`expr $$failed + 1`; \ + fi; \ + done; \ + if test "$$failed" -eq 0; then \ + banner="All $$all tests passed"; \ + else \ + banner="$$failed of $$all tests failed"; \ + fi; \ + dashes=`echo "$$banner" | sed s/./=/g`; \ + echo "$$dashes"; \ + echo "$$banner"; \ + echo "$$dashes"; \ + test "$$failed" -eq 0; \ + fi + +print_version.lo: print_version.h + +print_version.h: make-print-version$(EXEEXT) + ./make-print-version$(EXEEXT) print_version.h + +make-print-version.o: $(top_builddir)/include/version.h + +# Tell versions [3.59,3.63) of GNU make to not export all variables. +# Otherwise a system limit (for SysV at least) may be exceeded. +.NOEXPORT: diff --git a/crypto/heimdal/lib/vers/make-print-version.c b/crypto/heimdal/lib/vers/make-print-version.c new file mode 100644 index 000000000000..6102e75abde5 --- /dev/null +++ b/crypto/heimdal/lib/vers/make-print-version.c @@ -0,0 +1,68 @@ +/* + * Copyright (c) 1998 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: make-print-version.c,v 1.2 2000/07/08 10:46:36 assar Exp $"); +#endif + +#include <stdio.h> + +#ifdef KRB5 +extern const char *heimdal_version; +#endif +#ifdef KRB4 +extern const char *krb4_version; +#endif +#include <version.h> + +int +main(int argc, char **argv) +{ + FILE *f; + if(argc != 2) + return 1; + f = fopen(argv[1], "w"); + if(f == NULL) + return 1; + fprintf(f, "#define VERSIONLIST { "); +#ifdef KRB5 + fprintf(f, "\"%s\", ", heimdal_version); +#endif +#ifdef KRB4 + fprintf(f, "\"%s\", ", krb4_version); +#endif + fprintf(f, "}\n"); + fclose(f); + return 0; +} diff --git a/crypto/heimdal/lib/vers/print_version.c b/crypto/heimdal/lib/vers/print_version.c new file mode 100644 index 000000000000..cb324d0917f9 --- /dev/null +++ b/crypto/heimdal/lib/vers/print_version.c @@ -0,0 +1,78 @@ +/* + * Copyright (c) 1998 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include <config.h> +RCSID("$Id: print_version.c,v 1.1 2000/07/01 19:47:35 assar Exp $"); +#endif +#include "roken.h" + +#include "print_version.h" + +void +print_version(const char *progname) +{ + const char *arg[] = VERSIONLIST; + const int num_args = sizeof(arg) / sizeof(arg[0]); + char *msg; + size_t len = 0; + int i; + + if(progname == NULL) + progname = __progname; + + if(num_args == 0) + msg = "no version information"; + else { + for(i = 0; i < num_args; i++) { + if(i > 0) + len += 2; + len += strlen(arg[i]); + } + msg = malloc(len + 1); + if(msg == NULL) { + fprintf(stderr, "%s: out of memory\n", progname); + return; + } + msg[0] = '\0'; + for(i = 0; i < num_args; i++) { + if(i > 0) + strcat(msg, ", "); + strcat(msg, arg[i]); + } + } + fprintf(stderr, "%s (%s)\n", progname, msg); + fprintf(stderr, "Copyright (c) 1999 - 2000 Kungliga Tekniska Högskolan\n"); + if(num_args != 0) + free(msg); +} diff --git a/crypto/heimdal/lib/vers/vers.h b/crypto/heimdal/lib/vers/vers.h new file mode 100644 index 000000000000..cc70355f42fa --- /dev/null +++ b/crypto/heimdal/lib/vers/vers.h @@ -0,0 +1,41 @@ +/* + * Copyright (c) 1995 - 2000 Kungliga Tekniska Högskolan + * (Royal Institute of Technology, Stockholm, Sweden). + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Neither the name of the Institute nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* $Id: vers.h,v 1.1 2000/07/01 19:47:36 assar Exp $ */ + +#ifndef __VERS_H__ +#define __VERS_H__ + +void print_version(const char *); + +#endif /* __VERS_H__ */ diff --git a/crypto/heimdal/tools/Makefile.am b/crypto/heimdal/tools/Makefile.am new file mode 100644 index 000000000000..4f0290495ae6 --- /dev/null +++ b/crypto/heimdal/tools/Makefile.am @@ -0,0 +1,25 @@ +# $Id: Makefile.am,v 1.5 2001/01/29 06:56:33 assar Exp $ + +include $(top_srcdir)/Makefile.am.common + +EXTRA_DIST = krb5-config.1 + +CLEANFILES = krb5-config + +bin_SCRIPTS = krb5-config + +man_MANS = krb5-config.1 + +krb5-config: krb5-config.in + sed -e "s,@PACKAGE\@,$(PACKAGE),g" \ + -e "s,@VERSION\@,$(VERSION),g" \ + -e "s,@prefix\@,$(prefix),g" \ + -e "s,@exec_prefix\@,$(exec_prefix),g" \ + -e "s,@libdir\@,$(libdir),g" \ + -e "s,@includedir\@,$(includedir),g" \ + -e "s,@LIB_crypt\@,$(LIB_crypt),g" \ + -e "s,@LIB_dbopen\@,$(LIB_dbopen),g" \ + -e "s,@LIB_des_appl\@,$(LIB_des_appl),g" \ + -e "s,@LIBS\@,$(LIBS),g" \ + $(srcdir)/krb5-config.in > $@ + chmod +x $@ diff --git a/crypto/heimdal/tools/Makefile.in b/crypto/heimdal/tools/Makefile.in new file mode 100644 index 000000000000..85afdc4d6501 --- /dev/null +++ b/crypto/heimdal/tools/Makefile.in @@ -0,0 +1,524 @@ +# Makefile.in generated automatically by automake 1.4a from Makefile.am + +# Copyright (C) 1994, 1995-9, 2000 Free Software Foundation, Inc. +# This Makefile.in is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY, to the extent permitted by law; without +# even the implied warranty of MERCHANTABILITY or FITNESS FOR A +# PARTICULAR PURPOSE. + +SHELL = @SHELL@ + +srcdir = @srcdir@ +top_srcdir = @top_srcdir@ +VPATH = @srcdir@ +prefix = @prefix@ +exec_prefix = @exec_prefix@ + +bindir = @bindir@ +sbindir = @sbindir@ +libexecdir = @libexecdir@ +datadir = @datadir@ +sysconfdir = @sysconfdir@ +sharedstatedir = @sharedstatedir@ +localstatedir = @localstatedir@ +libdir = @libdir@ +infodir = @infodir@ +mandir = @mandir@ +includedir = @includedir@ +oldincludedir = /usr/include + +pkgdatadir = $(datadir)/@PACKAGE@ +pkglibdir = $(libdir)/@PACKAGE@ +pkgincludedir = $(includedir)/@PACKAGE@ + +top_builddir = .. + +ACLOCAL = @ACLOCAL@ +AUTOCONF = @AUTOCONF@ +AUTOMAKE = @AUTOMAKE@ +AUTOHEADER = @AUTOHEADER@ + +INSTALL = @INSTALL@ +INSTALL_PROGRAM = @INSTALL_PROGRAM@ +INSTALL_DATA = @INSTALL_DATA@ +INSTALL_SCRIPT = @INSTALL_SCRIPT@ +INSTALL_STRIP_FLAG = +transform = @program_transform_name@ + +NORMAL_INSTALL = : +PRE_INSTALL = : +POST_INSTALL = : +NORMAL_UNINSTALL = : +PRE_UNINSTALL = : +POST_UNINSTALL = : + +@SET_MAKE@ +host_alias = @host_alias@ +host_triplet = @host@ +AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@ +AMDEP = @AMDEP@ +AMTAR = @AMTAR@ +AS = @AS@ +AWK = @AWK@ +CANONICAL_HOST = @CANONICAL_HOST@ +CATMAN = @CATMAN@ +CATMANEXT = @CATMANEXT@ +CC = @CC@ +CPP = @CPP@ +CXX = @CXX@ +CXXCPP = @CXXCPP@ +DBLIB = @DBLIB@ +DEPDIR = @DEPDIR@ +DIR_des = @DIR_des@ +DIR_roken = @DIR_roken@ +DLLTOOL = @DLLTOOL@ +EXEEXT = @EXEEXT@ +EXTRA_LIB45 = @EXTRA_LIB45@ +GROFF = @GROFF@ +INCLUDES_roken = @INCLUDES_roken@ +INCLUDE_ = @INCLUDE_@ +LEX = @LEX@ +LIBOBJS = @LIBOBJS@ +LIBTOOL = @LIBTOOL@ +LIB_ = @LIB_@ +LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@ +LIB_des = @LIB_des@ +LIB_des_appl = @LIB_des_appl@ +LIB_kdb = @LIB_kdb@ +LIB_otp = @LIB_otp@ +LIB_roken = @LIB_roken@ +LIB_security = @LIB_security@ +LN_S = @LN_S@ +LTLIBOBJS = @LTLIBOBJS@ +MAKEINFO = @MAKEINFO@ +NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@ +NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@ +NROFF = @NROFF@ +OBJDUMP = @OBJDUMP@ +OBJEXT = @OBJEXT@ +PACKAGE = @PACKAGE@ +RANLIB = @RANLIB@ +STRIP = @STRIP@ +VERSION = @VERSION@ +VOID_RETSIGTYPE = @VOID_RETSIGTYPE@ +WFLAGS = @WFLAGS@ +WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@ +WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@ +YACC = @YACC@ +dpagaix_CFLAGS = @dpagaix_CFLAGS@ +dpagaix_LDADD = @dpagaix_LDADD@ +install_sh = @install_sh@ + +# $Id: Makefile.am,v 1.5 2001/01/29 06:56:33 assar Exp $ + + +# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $ + + +# $Id: Makefile.am.common,v 1.23 2000/12/05 09:11:09 joda Exp $ + + +AUTOMAKE_OPTIONS = foreign no-dependencies + +SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x + +INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken) + +AM_CFLAGS = $(WFLAGS) + +CP = cp + +COMPILE_ET = $(top_builddir)/lib/com_err/compile_et + +buildinclude = $(top_builddir)/include + +LIB_XauReadAuth = @LIB_XauReadAuth@ +LIB_crypt = @LIB_crypt@ +LIB_dbm_firstkey = @LIB_dbm_firstkey@ +LIB_dbopen = @LIB_dbopen@ +LIB_dlopen = @LIB_dlopen@ +LIB_dn_expand = @LIB_dn_expand@ +LIB_el_init = @LIB_el_init@ +LIB_getattr = @LIB_getattr@ +LIB_gethostbyname = @LIB_gethostbyname@ +LIB_getpwent_r = @LIB_getpwent_r@ +LIB_getpwnam_r = @LIB_getpwnam_r@ +LIB_getsockopt = @LIB_getsockopt@ +LIB_logout = @LIB_logout@ +LIB_logwtmp = @LIB_logwtmp@ +LIB_odm_initialize = @LIB_odm_initialize@ +LIB_pidfile = @LIB_pidfile@ +LIB_readline = @LIB_readline@ +LIB_res_search = @LIB_res_search@ +LIB_setpcred = @LIB_setpcred@ +LIB_setsockopt = @LIB_setsockopt@ +LIB_socket = @LIB_socket@ +LIB_syslog = @LIB_syslog@ +LIB_tgetent = @LIB_tgetent@ + +LIBS = @LIBS@ + +HESIODLIB = @HESIODLIB@ +HESIODINCLUDE = @HESIODINCLUDE@ +INCLUDE_hesiod = @INCLUDE_hesiod@ +LIB_hesiod = @LIB_hesiod@ + +INCLUDE_krb4 = @INCLUDE_krb4@ +LIB_krb4 = @LIB_krb4@ + +INCLUDE_openldap = @INCLUDE_openldap@ +LIB_openldap = @LIB_openldap@ + +INCLUDE_readline = @INCLUDE_readline@ + +LEXLIB = @LEXLIB@ + +NROFF_MAN = groff -mandoc -Tascii + +@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS) + +@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \ +@KRB5_TRUE@ $(top_builddir)/lib/asn1/libasn1.la +@KRB5_TRUE@LIB_gssapi = @KRB5_TRUE@$(top_builddir)/lib/gssapi/libgssapi.la + +CHECK_LOCAL = $(PROGRAMS) + +EXTRA_DIST = krb5-config.1 + +CLEANFILES = krb5-config + +bin_SCRIPTS = krb5-config + +man_MANS = krb5-config.1 +subdir = tools +mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs +CONFIG_HEADER = ../include/config.h +CONFIG_CLEAN_FILES = +SCRIPTS = $(bin_SCRIPTS) + +CFLAGS = @CFLAGS@ +COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +CCLD = $(CC) +LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ +DIST_SOURCES = +man1dir = $(mandir)/man1 +MANS = $(man_MANS) +depcomp = +DIST_COMMON = Makefile.am Makefile.in + + +DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) + +GZIP_ENV = --best +all: all-redirect +.SUFFIXES: +.SUFFIXES: .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .et .h .x +$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4) $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common + cd $(top_srcdir) && $(AUTOMAKE) --foreign tools/Makefile + +Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status + cd $(top_builddir) \ + && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status + + +install-binSCRIPTS: $(bin_SCRIPTS) + @$(NORMAL_INSTALL) + $(mkinstalldirs) $(DESTDIR)$(bindir) + @list='$(bin_SCRIPTS)'; for p in $$list; do \ + f="`echo $$p|sed '$(transform)'`"; \ + if test -f $$p; then \ + echo " $(INSTALL_SCRIPT) $$p $(DESTDIR)$(bindir)/$$f"; \ + $(INSTALL_SCRIPT) $$p $(DESTDIR)$(bindir)/$$f; \ + elif test -f $(srcdir)/$$p; then \ + echo " $(INSTALL_SCRIPT) $(srcdir)/$$p $(DESTDIR)$(bindir)/$$f"; \ + $(INSTALL_SCRIPT) $(srcdir)/$$p $(DESTDIR)$(bindir)/$$f; \ + else :; fi; \ + done + +uninstall-binSCRIPTS: + @$(NORMAL_UNINSTALL) + @list='$(bin_SCRIPTS)'; for p in $$list; do \ + f="`echo $$p|sed '$(transform)'`"; \ + echo " rm -f $(DESTDIR)$(bindir)/$$f"; \ + rm -f $(DESTDIR)$(bindir)/$$f; \ + done + +install-man1: + $(mkinstalldirs) $(DESTDIR)$(man1dir) + @list='$(man1_MANS)'; \ + l2='$(man_MANS)'; for i in $$l2; do \ + case "$$i" in \ + *.1*) list="$$list $$i" ;; \ + esac; \ + done; \ + for i in $$list; do \ + if test -f $(srcdir)/$$i; then file=$(srcdir)/$$i; \ + else file=$$i; fi; \ + ext=`echo $$i | sed -e 's/^.*\\.//'`; \ + inst=`echo $$i | sed -e 's/\\.[0-9a-z]*$$//'`; \ + inst=`echo $$inst | sed -e 's/^.*\///'`; \ + inst=`echo $$inst | sed '$(transform)'`.$$ext; \ + echo " $(INSTALL_DATA) $$file $(DESTDIR)$(man1dir)/$$inst"; \ + $(INSTALL_DATA) $$file $(DESTDIR)$(man1dir)/$$inst; \ + done + +uninstall-man1: + @list='$(man1_MANS)'; \ + l2='$(man_MANS)'; for i in $$l2; do \ + case "$$i" in \ + *.1*) list="$$list $$i" ;; \ + esac; \ + done; \ + for i in $$list; do \ + ext=`echo $$i | sed -e 's/^.*\\.//'`; \ + inst=`echo $$i | sed -e 's/\\.[0-9a-z]*$$//'`; \ + inst=`echo $$inst | sed -e 's/^.*\///'`; \ + inst=`echo $$inst | sed '$(transform)'`.$$ext; \ + echo " rm -f $(DESTDIR)$(man1dir)/$$inst"; \ + rm -f $(DESTDIR)$(man1dir)/$$inst; \ + done +install-man: $(MANS) + @$(NORMAL_INSTALL) + $(MAKE) $(AM_MAKEFLAGS) install-man1 +uninstall-man: + @$(NORMAL_UNINSTALL) + $(MAKE) $(AM_MAKEFLAGS) uninstall-man1 +tags: TAGS +TAGS: + + +distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir) + +distdir: $(DISTFILES) + @for file in $(DISTFILES); do \ + d=$(srcdir); \ + if test -d $$d/$$file; then \ + cp -pR $$d/$$file $(distdir) \ + || exit 1; \ + else \ + test -f $(distdir)/$$file \ + || cp -p $$d/$$file $(distdir)/$$file \ + || exit 1; \ + fi; \ + done + $(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-hook +info-am: +info: info-am +dvi-am: +dvi: dvi-am +check-am: all-am + $(MAKE) $(AM_MAKEFLAGS) check-local +check: check-am +installcheck-am: +installcheck: installcheck-am +install-exec-am: install-binSCRIPTS + @$(NORMAL_INSTALL) + $(MAKE) $(AM_MAKEFLAGS) install-exec-hook +install-exec: install-exec-am + +install-data-am: install-man install-data-local +install-data: install-data-am + +install-am: all-am + @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am +install: install-am +uninstall-am: uninstall-binSCRIPTS uninstall-man +uninstall: uninstall-am +all-am: Makefile $(SCRIPTS) $(MANS) all-local +all-redirect: all-am +install-strip: + $(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install +installdirs: + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(mandir)/man1 + + +mostlyclean-generic: + +clean-generic: + -test -z "$(CLEANFILES)" || rm -f $(CLEANFILES) + +distclean-generic: + -rm -f Makefile $(CONFIG_CLEAN_FILES) + -rm -f config.cache config.log stamp-h stamp-h[0-9]* + +maintainer-clean-generic: + -rm -f Makefile.in +mostlyclean-am: mostlyclean-generic + +mostlyclean: mostlyclean-am + +clean-am: clean-generic mostlyclean-am + +clean: clean-am + +distclean-am: distclean-generic clean-am + -rm -f libtool + +distclean: distclean-am + +maintainer-clean-am: maintainer-clean-generic distclean-am + @echo "This command is intended for maintainers to use;" + @echo "it deletes files that may require special tools to rebuild." + +maintainer-clean: maintainer-clean-am + +.PHONY: uninstall-binSCRIPTS install-binSCRIPTS install-man1 \ +uninstall-man1 install-man uninstall-man tags distdir info-am info \ +dvi-am dvi check-local check check-am installcheck-am installcheck \ +install-exec-am install-exec install-data-local install-data-am \ +install-data install-am install uninstall-am uninstall all-local \ +all-redirect all-am all install-strip installdirs mostlyclean-generic \ +distclean-generic clean-generic maintainer-clean-generic clean \ +mostlyclean distclean maintainer-clean + + +install-suid-programs: + @foo='$(bin_SUIDS)'; \ + for file in $$foo; do \ + x=$(DESTDIR)$(bindir)/$$file; \ + if chown 0:0 $$x && chmod u+s $$x; then :; else \ + echo "*"; \ + echo "* Failed to install $$x setuid root"; \ + echo "*"; \ + fi; done + +install-exec-hook: install-suid-programs + +install-build-headers:: $(include_HEADERS) $(build_HEADERZ) + @foo='$(include_HEADERS) $(build_HEADERZ)'; \ + for f in $$foo; do \ + f=`basename $$f`; \ + if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \ + else file="$$f"; fi; \ + if cmp -s $$file $(buildinclude)/$$f 2> /dev/null ; then \ + : ; else \ + echo " $(CP) $$file $(buildinclude)/$$f"; \ + $(CP) $$file $(buildinclude)/$$f; \ + fi ; \ + done + +all-local: install-build-headers +#NROFF_MAN = nroff -man +.1.cat1: + $(NROFF_MAN) $< > $@ +.3.cat3: + $(NROFF_MAN) $< > $@ +.5.cat5: + $(NROFF_MAN) $< > $@ +.8.cat8: + $(NROFF_MAN) $< > $@ + +dist-cat1-mans: + @foo='$(man1_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.1) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat3-mans: + @foo='$(man3_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.3) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat5-mans: + @foo='$(man5_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.5) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-cat8-mans: + @foo='$(man8_MANS)'; \ + bar='$(man_MANS)'; \ + for i in $$bar; do \ + case $$i in \ + *.8) foo="$$foo $$i";; \ + esac; done ;\ + for i in $$foo; do \ + x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \ + echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \ + $(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \ + done + +dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans + +install-cat-mans: + $(SHELL) $(top_srcdir)/cf/install-catman.sh "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS) + +install-data-local: install-cat-mans + +.et.h: + $(COMPILE_ET) $< +.et.c: + $(COMPILE_ET) $< + +.x.c: + @cmp -s $< $@ 2> /dev/null || cp $< $@ + +check-local:: + @foo='$(CHECK_LOCAL)'; \ + if test "$$foo"; then \ + failed=0; all=0; \ + for i in $$foo; do \ + all=`expr $$all + 1`; \ + if ./$$i --version > /dev/null 2>&1; then \ + echo "PASS: $$i"; \ + else \ + echo "FAIL: $$i"; \ + failed=`expr $$failed + 1`; \ + fi; \ + done; \ + if test "$$failed" -eq 0; then \ + banner="All $$all tests passed"; \ + else \ + banner="$$failed of $$all tests failed"; \ + fi; \ + dashes=`echo "$$banner" | sed s/./=/g`; \ + echo "$$dashes"; \ + echo "$$banner"; \ + echo "$$dashes"; \ + test "$$failed" -eq 0; \ + fi + +krb5-config: krb5-config.in + sed -e "s,@PACKAGE\@,$(PACKAGE),g" \ + -e "s,@VERSION\@,$(VERSION),g" \ + -e "s,@prefix\@,$(prefix),g" \ + -e "s,@exec_prefix\@,$(exec_prefix),g" \ + -e "s,@libdir\@,$(libdir),g" \ + -e "s,@includedir\@,$(includedir),g" \ + -e "s,@LIB_crypt\@,$(LIB_crypt),g" \ + -e "s,@LIB_dbopen\@,$(LIB_dbopen),g" \ + -e "s,@LIB_des_appl\@,$(LIB_des_appl),g" \ + -e "s,@LIBS\@,$(LIBS),g" \ + $(srcdir)/krb5-config.in > $@ + chmod +x $@ + +# Tell versions [3.59,3.63) of GNU make to not export all variables. +# Otherwise a system limit (for SysV at least) may be exceeded. +.NOEXPORT: diff --git a/crypto/heimdal/tools/krb5-config.1 b/crypto/heimdal/tools/krb5-config.1 new file mode 100644 index 000000000000..1eb2e09054d2 --- /dev/null +++ b/crypto/heimdal/tools/krb5-config.1 @@ -0,0 +1,60 @@ +.\" $Id: krb5-config.1,v 1.3 2000/12/01 04:59:53 assar Exp $ +.\" +.Dd November 30, 2000 +.Dt KRB5-CONFIG 1 +.Os HEIMDAL +.Sh NAME +.Nm krb5-config +.Nd +give information on how to link code against Heimdal libraries +.Sh SYNOPSIS +.Nm +.Op Fl -prefix Ns Op = Ns Ar dir +.Op Fl -exec-prefix Ns Op = Ns Ar dir +.Op Fl -libs +.Op Fl -cflags +.Op Ar libraries +.Sh DESCRIPTION +.Nm +tells the application programmer what special flags to use to compile +and link programs against the libraries installed by Heimdal. +.Pp +Options supported: +.Bl -tag -width Ds +.It Fl -prefix Ns Op = Ns Ar dir +Print the prefix if no +.Ar dir +is specified, otherwise set prefix to +.Ar dir . +.It Fl -exec-prefix Ns Op = Ns Ar dir +Print the exec-prefix if no +.Ar dir +is specified, otherwise set exec-prefix to +.Ar dir . +.It Fl -libs +Output the set of libraries that should be linked against. +.It Fl -cflags +Output the set of flags to give to the C compiler when using the +Heimdal libraries. +.El +.Pp +By default +.Nm +will output the set of flags and libraries to be used by a normal +program using the krb5 API. The user can also supply a library to be +used, the supported ones are: +.Bl -tag -width Ds +.It krb5 +(the default) +.It gssapi +use the krb5 gssapi mechanism +.It kadm-client +use the client-side kadmin libraries +.It kadm-server +use the server-side kadmin libraries +.El +.Sh SEE ALSO +.Xr cc 1 +.Sh HISTORY +.Nm +appeared in Heimdal 0.3d. diff --git a/crypto/heimdal/tools/krb5-config.in b/crypto/heimdal/tools/krb5-config.in new file mode 100755 index 000000000000..e1235ac31730 --- /dev/null +++ b/crypto/heimdal/tools/krb5-config.in @@ -0,0 +1,110 @@ +#!/bin/sh +# $Id: krb5-config.in,v 1.8 2001/01/29 06:56:51 assar Exp $ + +do_libs=no +do_cflags=no +do_usage=no +print_prefix=no +print_exec_prefix=no +library=krb5 + +if test $# -eq 0; then + do_usage=yes + usage_exit=1 +fi + +for i in $*; do + case $i in + --help) + do_usage=yes + usage_exit=0 + ;; + --version) + echo "@PACKAGE@ @VERSION@" + echo '$Id: krb5-config.in,v 1.8 2001/01/29 06:56:51 assar Exp $' + exit 0 + ;; + --prefix=*) + prefix=`echo $i | sed 's/^--prefix=//'` + ;; + --prefix) + print_prefix=yes + ;; + --exec-prefix=*) + exec_prefix=`echo $i | sed 's/^--exec-prefix=//'` + ;; + --exec-prefix) + print_exec_prefix=yes + ;; + --libs) + do_libs=yes + ;; + --cflags) + do_cflags=yes + ;; + krb5) + library=krb5 + ;; + gssapi) + library=gssapi + ;; + kadm-client) + library=kadm-client + ;; + kadm-server) + library=kadm-server + ;; + *) + echo "unknown option: $i" + exit 1 + ;; + esac +done + +if test "$do_usage" = "yes"; then + echo "usage: $0 [options] [libraries]" + echo "options: [--prefix[=dir]] [--exec-prefix[=dir]] [--libs] [--cflags]" + echo "libraries: krb5 gssapi kadm-client kadm-server" + exit $usage_exit +fi + +if test "$prefix" = ""; then + prefix=@prefix@ +fi +if test "$exec_prefix" = ""; then + exec_prefix=@exec_prefix@ +fi + +libdir=@libdir@ +includedir=@includedir@ + +if test "$print_prefix" = "yes"; then + echo $prefix +fi + +if test "$print_exec_prefix" = "yes"; then + echo $exec_prefix +fi + +if test "$do_libs" = "yes"; then + lib_flags="-L${libdir}" + case $library in + gssapi) + lib_flags="$lib_flags -lgssapi" + ;; + kadm-client) + lib_flags="$lib_flags -lkadm5clnt" + ;; + kadm-server) + lib_flags="$lib_flags -lkadm5srv" + ;; + esac + lib_flags="$lib_flags -lkrb5 -lasn1 @LIB_des_appl@ -lroken" + lib_flags="$lib_flags @LIB_crypt@ @LIB_dbopen@ @LIBS@" + echo $lib_flags +fi +if test "$do_cflags" = "yes"; then + echo "-I${includedir}" +fi + +exit 0 diff --git a/crypto/openssl/STATUS b/crypto/openssl/STATUS new file mode 100644 index 000000000000..028abb85abea --- /dev/null +++ b/crypto/openssl/STATUS @@ -0,0 +1,92 @@ + + OpenSSL STATUS Last modified at + ______________ $Date: 2000/09/24 15:42:34 $ + + DEVELOPMENT STATE + + o OpenSSL 0.9.6: Released on September 24th, 2000 + o OpenSSL 0.9.5a: Released on April 1st, 2000 + o OpenSSL 0.9.5: Released on February 28th, 2000 + o OpenSSL 0.9.4: Released on August 09th, 1999 + o OpenSSL 0.9.3a: Released on May 29th, 1999 + o OpenSSL 0.9.3: Released on May 25th, 1999 + o OpenSSL 0.9.2b: Released on March 22th, 1999 + o OpenSSL 0.9.1c: Released on December 23th, 1998 + + RELEASE SHOWSTOPPERS + + AVAILABLE PATCHES + + o CA.pl patch (Damien Miller) + + IN PROGRESS + + o Steve is currently working on (in no particular order): + ASN1 code redesign, butchery, replacement. + EVP cipher enhancement. + Proper (or at least usable) certificate chain verification. + Private key, certificate and CRL API and implementation. + Developing and bugfixing PKCS#7 (S/MIME code). + Various X509 issues: character sets, certificate request extensions. + o Geoff and Richard are currently working on: + ENGINE (the new code that gives hardware support among others). + o Richard is currently working on: + UTIL (a new set of library functions to support some higher level + functionality that is currently missing). + Dynamic thread-lock support. + Shared library support for VMS. + + NEEDS PATCH + + o non-blocking socket on AIX + o $(PERL) in */Makefile.ssl + o "Sign the certificate?" - "n" creates empty certificate file + + OPEN ISSUES + + o internal_verify doesn't know about X509.v3 (basicConstraints + CA flag ...) + + o The Makefile hierarchy and build mechanism is still not a round thing: + + 1. The config vs. Configure scripts + It's the same nasty situation as for Apache with APACI vs. + src/Configure. It confuses. + Suggestion: Merge Configure and config into a single configure + script with a Autoconf style interface ;-) and remove + Configure and config. Or even let us use GNU Autoconf + itself. Then we can avoid a lot of those platform checks + which are currently in Configure. + + o Support for Shared Libraries has to be added at least + for the major Unix platforms. The details we can rip from the stuff + Ralf has done for the Apache src/Configure script. Ben wants the + solution to be really simple. + + Status: Ralf will look how we can easily incorporate the + compiler PIC and linker DSO flags from Apache + into the OpenSSL Configure script. + + Ulf: +1 for using GNU autoconf and libtool (but not automake, + which apparently is not flexible enough to generate + libcrypto) + + + o The perl/ stuff needs a major overhaul. Currently it's + totally obsolete. Either we clean it up and enhance it to be up-to-date + with the C code or we also could replace it with the really nice + Net::SSLeay package we can find under + http://www.neuronio.pt/SSLeay.pm.html. Ralf uses this package for a + longer time and it works fine and is a nice Perl module. Best would be + to convince the author to work for the OpenSSL project and create a + Net::OpenSSL or Crypt::OpenSSL package out of it and maintains it for + us. + + Status: Ralf thinks we should both contact the author of Net::SSLeay + and look how much effort it is to bring Eric's perl/ stuff up + to date. + Paul +1 + + WISHES + + o diff --git a/crypto/openssl/TABLE b/crypto/openssl/TABLE new file mode 100644 index 000000000000..35421ceed48f --- /dev/null +++ b/crypto/openssl/TABLE @@ -0,0 +1,2301 @@ +Output of `Configure TABLE': + +*** BC-16 +$cc = bcc +$cflags = +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR RC4_INDEX SIXTEEN_BIT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** BC-32 +$cc = bcc32 +$cflags = +$unistd = +$thread_cflag = +$lflags = +$bn_ops = BN_LLONG DES_PTR RC4_INDEX +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = win32 +$shared_target= +$shared_cflag = + +*** BS2000-OSD +$cc = c89 +$cflags = -O -XLLML -XLLMK -XL -DB_ENDIAN -DTERMIOS -DCHARSET_EBCDIC +$unistd = +$thread_cflag = (unknown) +$lflags = -lsocket -lnsl +$bn_ops = THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** CygWin32 +$cc = gcc +$cflags = -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall +$unistd = +$thread_cflag = +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = win32 +$shared_target= +$shared_cflag = + +*** FreeBSD +$cc = gcc +$cflags = -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-out.o asm/co86-out.o +$des_obj = asm/dx86-out.o asm/yx86-out.o +$bf_obj = asm/bx86-out.o +$md5_obj = asm/mx86-out.o +$sha1_obj = asm/sx86-out.o +$cast_obj = asm/cx86-out.o +$rc4_obj = asm/rx86-out.o +$rmd160_obj = asm/rm86-out.o +$rc5_obj = asm/r586-out.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** FreeBSD-alpha +$cc = gcc +$cflags = -DTERMIOS -O -fomit-frame-pointer +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_PTR DES_RISC2 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** FreeBSD-elf +$cc = gcc +$cflags = -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** MPE/iX-gcc +$cc = gcc +$cflags = -D_ENDIAN -DBN_DIV2W -O3 -DMPE -D_POSIX_SOURCE -D_SOCKET_SOURCE -I/SYSLOG/PUB +$unistd = +$thread_cflag = (unknown) +$lflags = -L/SYSLOG/PUB -lsyslog -lsocket -lcurses +$bn_ops = BN_LLONG DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** Mingw32 +$cc = gcc +$cflags = -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall +$unistd = +$thread_cflag = +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = win32 +$shared_target= +$shared_cflag = + +*** NetBSD-m68 +$cc = gcc +$cflags = -DTERMIOS -O3 -fomit-frame-pointer -Wall -DB_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG MD2_CHAR RC4_INDEX DES_UNROLL +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** NetBSD-sparc +$cc = gcc +$cflags = -DTERMIOS -O3 -fomit-frame-pointer -mv8 -Wall -DB_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG MD2_CHAR RC4_INDEX DES_UNROLL +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** NetBSD-x86 +$cc = gcc +$cflags = -DTERMIOS -O3 -fomit-frame-pointer -m486 -Wall +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** OpenBSD +$cc = gcc +$cflags = -DTERMIOS -O3 -fomit-frame-pointer +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG RC2_CHAR RC4_INDEX DES_UNROLL +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** OpenBSD-alpha +$cc = gcc +$cflags = -DTERMIOS -O3 -fomit-frame-pointer +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG DES_INT DES_PTR DES_RISC2 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** OpenBSD-mips +$cc = gcc +$cflags = -O2 -DL_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = BN_LLONG MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC2 DES_PTR BF_PTR +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** OpenBSD-x86 +$cc = gcc +$cflags = -DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer -m486 +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-out.o asm/co86-out.o +$des_obj = asm/dx86-out.o asm/yx86-out.o +$bf_obj = asm/bx86-out.o +$md5_obj = asm/mx86-out.o +$sha1_obj = asm/sx86-out.o +$cast_obj = asm/cx86-out.o +$rc4_obj = asm/rx86-out.o +$rmd160_obj = asm/rm86-out.o +$rc5_obj = asm/r586-out.o +$dso_scheme = dlfcn +$shared_target= +$shared_cflag = + +*** ReliantUNIX +$cc = cc +$cflags = -KPIC -g -DSNI -DTERMIOS -DB_ENDIAN +$unistd = +$thread_cflag = -Kthread +$lflags = -lsocket -lnsl -lc -L/usr/ucblib -lucb +$bn_ops = BN_LLONG DES_PTR DES_RISC2 DES_UNROLL BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** SINIX +$cc = cc +$cflags = -O -DSNI +$unistd = +$thread_cflag = (unknown) +$lflags = -lsocket -lnsl -lc -L/usr/ucblib -lucb +$bn_ops = RC4_INDEX RC4_CHAR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** SINIX-N +$cc = /usr/ucb/cc +$cflags = -O2 -misaligned +$unistd = +$thread_cflag = (unknown) +$lflags = -lucb +$bn_ops = RC4_INDEX RC4_CHAR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** VC-MSDOS +$cc = cl +$cflags = +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG MD2_CHAR DES_UNROLL DES_PTR RC4_INDEX SIXTEEN_BIT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** VC-NT +$cc = cl +$cflags = +$unistd = +$thread_cflag = +$lflags = +$bn_ops = BN_LLONG RC4_INDEX RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = win32 +$shared_target= +$shared_cflag = + +*** VC-W31-16 +$cc = cl +$cflags = +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG MD2_CHAR DES_UNROLL DES_PTR RC4_INDEX SIXTEEN_BIT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** VC-W31-32 +$cc = cl +$cflags = +$unistd = +$thread_cflag = +$lflags = +$bn_ops = BN_LLONG MD2_CHAR DES_UNROLL DES_PTR RC4_INDEX THIRTY_TWO_BIT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** VC-WIN16 +$cc = cl +$cflags = +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = MD2_CHAR DES_UNROLL DES_PTR RC4_INDEX THIRTY_TWO_BIT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** VC-WIN32 +$cc = cl +$cflags = +$unistd = +$thread_cflag = +$lflags = +$bn_ops = BN_LLONG RC4_INDEX RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = win32 +$shared_target= +$shared_cflag = + +*** aix-cc +$cc = cc +$cflags = -O -DAIX -DB_ENDIAN -qmaxmem=16384 +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG RC4_CHAR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** aix-gcc +$cc = gcc +$cflags = -O3 -DAIX -DB_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG RC4_CHAR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** alpha-cc +$cc = cc +$cflags = -std1 -tune host -O4 -readonly_strings +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHUNK +$bn_obj = asm/alpha.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= true64-shared +$shared_cflag = + +*** alpha-gcc +$cc = gcc +$cflags = -O3 +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_UNROLL DES_RISC1 +$bn_obj = asm/alpha.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= true64-shared +$shared_cflag = + +*** alpha164-cc +$cc = cc +$cflags = -std1 -tune host -fast -readonly_strings +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHUNK +$bn_obj = asm/alpha.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= true64-shared +$shared_cflag = + +*** bsdi-elf-gcc +$cc = gcc +$cflags = -DPERL5 -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** bsdi-gcc +$cc = gcc +$cflags = -O3 -ffast-math -DL_ENDIAN -DPERL5 -m486 +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = RSA_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86bsdi.o asm/co86bsdi.o +$des_obj = asm/dx86bsdi.o asm/yx86bsdi.o +$bf_obj = asm/bx86bsdi.o +$md5_obj = asm/mx86bsdi.o +$sha1_obj = asm/sx86bsdi.o +$cast_obj = asm/cx86bsdi.o +$rc4_obj = asm/rx86bsdi.o +$rmd160_obj = asm/rm86bsdi.o +$rc5_obj = asm/r586bsdi.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** cc +$cc = cc +$cflags = -O +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** cray-t3e +$cc = cc +$cflags = -DBIT_FIELD_LIMITS -DTERMIOS +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** cray-t90-cc +$cc = cc +$cflags = -DBIT_FIELD_LIMITS -DTERMIOS +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG DES_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** debug +$cc = gcc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -ggdb -g2 -Wformat -Wshadow -Wmissing-prototypes -Wmissing-declarations -Werror +$unistd = +$thread_cflag = (unknown) +$lflags = -lefence +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** debug-ben +$cc = gcc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DPEDANTIC -DDEBUG_SAFESTACK -O2 -pedantic -Wall -Wshadow -Werror -pipe +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** debug-ben-debug +$cc = gcc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DPEDANTIC -DDEBUG_SAFESTACK -g3 -O2 -pedantic -Wall -Wshadow -Werror -pipe +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** debug-ben-strict +$cc = gcc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DCONST_STRICT -O2 -Wall -Wshadow -Werror -Wpointer-arith -Wcast-qual -Wwrite-strings -pipe +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** debug-bodo +$cc = gcc +$cflags = -DL_ENDIAN -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG_ALL -DBIO_PAIR_DEBUG -g -m486 -pedantic -Wshadow -Wall +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** debug-levitte-linux-elf +$cc = gcc +$cflags = -DUSE_ALLOCATING_PRINT -DRL_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DNO_ASM -DL_ENDIAN -DTERMIO -D_POSIX_SOURCE -ggdb -g3 -m486 -pedantic -ansi -Wall -Wshadow -Wid-clash-31 -pipe +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldl +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= +$shared_cflag = + +*** debug-linux-elf +$cc = gcc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -m486 -Wall +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lefence -ldl +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = dlfcn +$shared_target= +$shared_cflag = + +*** debug-linux-elf-noefence +$cc = gcc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -m486 -Wall +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldl +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = dlfcn +$shared_target= +$shared_cflag = + +*** debug-rse +$cc = cc +$cflags = -DTERMIOS -DL_ENDIAN -pipe -O -g -ggdb3 -Wall +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** debug-solaris-sparcv8-cc +$cc = cc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG_ALL -xarch=v8 -g -O -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_PTR DES_RISC1 DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -KPIC + +*** debug-solaris-sparcv8-gcc +$cc = gcc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG_ALL -O -g -mv8 -Wall -DB_ENDIAN +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -fPIC + +*** debug-solaris-sparcv9-cc +$cc = cc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG_ALL -xtarget=ultra -xarch=v8plus -g -O -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W -DULTRASPARC +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK_LL DES_PTR DES_RISC1 DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8plus.o +$des_obj = +$bf_obj = +$md5_obj = asm/md5-sparcv8plus.o +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -KPIC + +*** debug-solaris-sparcv9-gcc +$cc = gcc +$cflags = -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG_ALL -O -g -mcpu=ultrasparc -Wall -DB_ENDIAN +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8plus.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -fPIC + +*** debug-steve +$cc = gcc +$cflags = -DL_ENDIAN -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DDEBUG_SAFESTACK -DCRYPTO_MDEBUG_ALL -DPEDANTIC -g -O2 -m486 -pedantic -Wall -Werror -Wshadow -pipe +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** debug-ulf +$cc = gcc +$cflags = -DL_ENDIAN -DREF_CHECK -DCONF_DEBUG -DBN_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG_ALL -g -O2 -m486 -Wall -Werror -Wshadow -pipe +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** dgux-R3-gcc +$cc = gcc +$cflags = -O3 -fomit-frame-pointer +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = RC4_INDEX DES_UNROLL +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** dgux-R4-gcc +$cc = gcc +$cflags = -O3 -fomit-frame-pointer +$unistd = +$thread_cflag = (unknown) +$lflags = -lnsl -lsocket +$bn_ops = RC4_INDEX +$bn_obj = RC4_INDEX DES_UNROLL +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** dgux-R4-x86-gcc +$cc = gcc +$cflags = -O3 -fomit-frame-pointer -DL_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = -lnsl -lsocket +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** dist +$cc = cc +$cflags = -O +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** gcc +$cc = gcc +$cflags = -O3 +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** hpux-brokencc +$cc = cc +$cflags = -DB_ENDIAN -DBN_DIV2W -Ae +ESlit +O2 -z +$unistd = +$thread_cflag = (unknown) +$lflags = -ldld +$bn_ops = DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux-brokengcc +$cc = gcc +$cflags = -DB_ENDIAN -DBN_DIV2W -O3 +$unistd = +$thread_cflag = (unknown) +$lflags = -ldld +$bn_ops = DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux-cc +$cc = cc +$cflags = -DB_ENDIAN -DBN_DIV2W -DMD32_XARRAY -Ae +ESlit +O3 -z +$unistd = +$thread_cflag = (unknown) +$lflags = -ldld +$bn_ops = BN_LLONG DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux-gcc +$cc = gcc +$cflags = -DB_ENDIAN -DBN_DIV2W -O3 +$unistd = +$thread_cflag = (unknown) +$lflags = -ldld +$bn_ops = BN_LLONG DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux-parisc-cc +$cc = cc +$cflags = +O3 +Optrs_strongly_typed +Olibcalls -Ae +ESlit -DB_ENDIAN -DBN_DIV2W -DMD32_XARRAY +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldld +$bn_ops = MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux-parisc-cc-o4 +$cc = cc +$cflags = -Ae +O4 +ESlit -z -DB_ENDIAN -DBN_DIV2W -DMD32_XARRAY +$unistd = +$thread_cflag = +$lflags = -ldld +$bn_ops = BN_LLONG DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux-parisc-gcc +$cc = gcc +$cflags = -O3 -DB_ENDIAN -DBN_DIV2W +$unistd = +$thread_cflag = +$lflags = -ldld +$bn_ops = BN_LLONG DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux-parisc1_1-cc +$cc = cc +$cflags = +DA1.1 +DS1.1 +O3 +Optrs_strongly_typed +Olibcalls -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldld +$bn_ops = MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux-parisc2-cc +$cc = cc +$cflags = +DA2.0 +DS2.0 +O3 +Optrs_strongly_typed +Olibcalls -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldld +$bn_ops = SIXTY_FOUR_BIT MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT +$bn_obj = asm/pa-risc2.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux10-brokencc +$cc = cc +$cflags = -DB_ENDIAN -DBN_DIV2W -Ae +ESlit +O2 -z +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldld +$bn_ops = BN_LLONG DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux10-brokengcc +$cc = gcc +$cflags = -DB_ENDIAN -DBN_DIV2W -O3 +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldld +$bn_ops = DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux10-cc +$cc = cc +$cflags = -DB_ENDIAN -DBN_DIV2W -DMD32_XARRAY -Ae +ESlit +O3 -z +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldld +$bn_ops = BN_LLONG DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux10-gcc +$cc = gcc +$cflags = -DB_ENDIAN -DBN_DIV2W -O3 +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldld +$bn_ops = BN_LLONG DES_PTR DES_UNROLL DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dl +$shared_target= +$shared_cflag = + +*** hpux64-parisc-cc +$cc = cc +$cflags = -Ae +DD64 +O3 +ESlit -z -DB_ENDIAN -DMD32_XARRAY +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldl +$bn_ops = SIXTY_FOUR_BIT_LONG MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= +$shared_cflag = + +*** hpux64-parisc2-cc +$cc = cc +$cflags = +DD64 +O3 +Optrs_strongly_typed +Olibcalls -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldl +$bn_ops = SIXTY_FOUR_BIT_LONG MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT +$bn_obj = asm/pa-risc2W.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= +$shared_cflag = + +*** irix-cc +$cc = cc +$cflags = -O2 -use_readonly_const -DTERMIOS -DB_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_PTR DES_RISC2 DES_UNROLL BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** irix-gcc +$cc = gcc +$cflags = -O3 -DTERMIOS -DB_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG MD2_CHAR RC4_INDEX RC4_CHAR RC4_CHUNK DES_UNROLL DES_RISC2 DES_PTR BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** irix-mips3-cc +$cc = cc +$cflags = -n32 -O2 -use_readonly_const -DTERMIOS -DB_ENDIAN -DBN_DIV3W +$unistd = +$thread_cflag = -D_SGI_MP_SOURCE +$lflags = +$bn_ops = DES_PTR RC4_CHAR RC4_CHUNK_LL DES_RISC2 DES_UNROLL BF_PTR SIXTY_FOUR_BIT +$bn_obj = asm/mips3.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** irix-mips3-gcc +$cc = gcc +$cflags = -mabi=n32 -mmips-as -O3 -DTERMIOS -DB_ENDIAN -DBN_DIV3W +$unistd = +$thread_cflag = -D_SGI_MP_SOURCE +$lflags = +$bn_ops = MD2_CHAR RC4_INDEX RC4_CHAR RC4_CHUNK_LL DES_UNROLL DES_RISC2 DES_PTR BF_PTR SIXTY_FOUR_BIT +$bn_obj = asm/mips3.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** irix64-mips4-cc +$cc = cc +$cflags = -64 -mips4 -O2 -use_readonly_const -DTERMIOS -DB_ENDIAN -DBN_DIV3W +$unistd = +$thread_cflag = -D_SGI_MP_SOURCE +$lflags = +$bn_ops = RC4_CHAR RC4_CHUNK DES_RISC2 DES_UNROLL SIXTY_FOUR_BIT_LONG +$bn_obj = asm/mips3.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** irix64-mips4-gcc +$cc = gcc +$cflags = -mabi=64 -mips4 -mmips-as -O3 -DTERMIOS -DB_ENDIAN -DBN_DIV3W +$unistd = +$thread_cflag = -D_SGI_MP_SOURCE +$lflags = +$bn_ops = RC4_CHAR RC4_CHUNK DES_RISC2 DES_UNROLL SIXTY_FOUR_BIT_LONG +$bn_obj = asm/mips3.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-alpha+bwx-ccc +$cc = ccc +$cflags = -fast -readonly_strings -DL_ENDIAN -DTERMIO +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL +$bn_obj = asm/alpha.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-alpha+bwx-gcc +$cc = gcc +$cflags = -O3 -DL_ENDIAN -DTERMIO +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldl +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_RISC1 DES_UNROLL +$bn_obj = asm/alpha.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= linux-shared +$shared_cflag = -fPIC + +*** linux-alpha-ccc +$cc = ccc +$cflags = -fast -readonly_strings -DL_ENDIAN -DTERMIO +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL +$bn_obj = asm/alpha.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-alpha-gcc +$cc = gcc +$cflags = -O3 -DL_ENDIAN -DTERMIO +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldl +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 DES_UNROLL +$bn_obj = asm/alpha.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= linux-shared +$shared_cflag = -fPIC + +*** linux-aout +$cc = gcc +$cflags = -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-out.o asm/co86-out.o +$des_obj = asm/dx86-out.o asm/yx86-out.o +$bf_obj = asm/bx86-out.o +$md5_obj = asm/mx86-out.o +$sha1_obj = asm/sx86-out.o +$cast_obj = asm/cx86-out.o +$rc4_obj = asm/rx86-out.o +$rmd160_obj = asm/rm86-out.o +$rc5_obj = asm/r586-out.o +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-elf +$cc = gcc +$cflags = -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -ldl +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-elf.o asm/co86-elf.o +$des_obj = asm/dx86-elf.o asm/yx86-elf.o +$bf_obj = asm/bx86-elf.o +$md5_obj = asm/mx86-elf.o +$sha1_obj = asm/sx86-elf.o +$cast_obj = asm/cx86-elf.o +$rc4_obj = asm/rx86-elf.o +$rmd160_obj = asm/rm86-elf.o +$rc5_obj = asm/r586-elf.o +$dso_scheme = dlfcn +$shared_target= linux-shared +$shared_cflag = -fPIC + +*** linux-elf-arm +$cc = gcc +$cflags = -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = BN_LLONG +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= linux-shared +$shared_cflag = -fPIC + +*** linux-ia64 +$cc = gcc +$cflags = -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = SIXTY_FOUR_BIT_LONG +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-m68k +$cc = gcc +$cflags = -DB_ENDIAN -DTERMIO -O2 -fomit-frame-pointer -Wall +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = BN_LLONG +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-mips +$cc = gcc +$cflags = -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-ppc +$cc = gcc +$cflags = -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = BN_LLONG +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-sparcv7 +$cc = gcc +$cflags = -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-sparcv8 +$cc = gcc +$cflags = -mv8 -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DBN_DIV2W +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** linux-sparcv9 +$cc = gcc +$cflags = -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -Wa,-Av8plus -DULTRASPARC -DBN_DIV2W +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8plus.o +$des_obj = +$bf_obj = +$md5_obj = asm/md5-sparcv8plus.o +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** ncr-scde +$cc = cc +$cflags = -O6 -Xa -Hoff=BEHAVED -686 -Hwide -Hiw +$unistd = +$thread_cflag = (unknown) +$lflags = -lsocket -lnsl +$bn_ops = DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** newsos4-gcc +$cc = gcc +$cflags = -O -DB_ENDIAN -DNEWS4 +$unistd = +$thread_cflag = (unknown) +$lflags = -lmld -liberty +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_PTR DES_RISC1 DES_UNROLL BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** nextstep +$cc = cc +$cflags = -O -Wall +$unistd = <libc.h> +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** nextstep3.3 +$cc = cc +$cflags = -O3 -Wall +$unistd = <libc.h> +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** purify +$cc = purify gcc +$cflags = -g -DPURIFY -Wall +$unistd = +$thread_cflag = (unknown) +$lflags = -lsocket -lnsl +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** qnx4 +$cc = cc +$cflags = -DL_ENDIAN -DTERMIO +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** rhapsody-ppc-cc +$cc = cc +$cflags = -O3 -DB_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** sco5-cc +$cc = cc +$cflags = +$unistd = +$thread_cflag = (unknown) +$lflags = -lsocket +$bn_ops = DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** sco5-gcc +$cc = gcc +$cflags = -O3 -fomit-frame-pointer +$unistd = +$thread_cflag = (unknown) +$lflags = -lsocket +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** solaris-sparc-sc3 +$cc = cc +$cflags = -fast -O -Xa -DB_ENDIAN +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_PTR DES_UNROLL BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -KPIC + +*** solaris-sparcv7-cc +$cc = cc +$cflags = -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_PTR DES_RISC1 DES_UNROLL BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -KPIC + +*** solaris-sparcv7-gcc +$cc = gcc +$cflags = -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -fPIC + +*** solaris-sparcv8-cc +$cc = cc +$cflags = -xarch=v8 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_PTR DES_RISC1 DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -KPIC + +*** solaris-sparcv8-gcc +$cc = gcc +$cflags = -mv8 -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8.o +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -fPIC + +*** solaris-sparcv9-cc +$cc = cc +$cflags = -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DULTRASPARC +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK_LL DES_PTR DES_RISC1 DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8plus.o +$des_obj = +$bf_obj = +$md5_obj = asm/md5-sparcv8plus.o +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -KPIC + +*** solaris-sparcv9-gcc +$cc = gcc +$cflags = -mcpu=ultrasparc -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -DULTRASPARC +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8plus.o +$des_obj = +$bf_obj = +$md5_obj = asm/md5-sparcv8plus.o +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -fPIC + +*** solaris-sparcv9-gcc27 +$cc = gcc +$cflags = -mv8 -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -DULTRASPARC +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR +$bn_obj = asm/sparcv8plus-gcc27.o +$des_obj = +$bf_obj = +$md5_obj = asm/md5-sparcv8plus-gcc27.o +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -fPIC + +*** solaris-x86-gcc +$cc = gcc +$cflags = -O3 -fomit-frame-pointer -m486 -Wall -DL_ENDIAN -DNO_INLINE_ASM +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = asm/bn86-sol.o asm/co86-sol.o +$des_obj = asm/dx86-sol.o asm/yx86-sol.o +$bf_obj = asm/bx86-sol.o +$md5_obj = asm/mx86-sol.o +$sha1_obj = asm/sx86-sol.o +$cast_obj = asm/cx86-sol.o +$rc4_obj = asm/rx86-sol.o +$rmd160_obj = asm/rm86-sol.o +$rc5_obj = asm/r586-sol.o +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -fPIC + +*** solaris64-sparcv9-cc +$cc = cc +$cflags = -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DULTRASPARC +$unistd = +$thread_cflag = -D_REENTRANT +$lflags = -lsocket -lnsl -ldl +$bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL BF_PTR +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = asm/md5-sparcv9.o +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = dlfcn +$shared_target= solaris-shared +$shared_cflag = -KPIC + +*** sunos-gcc +$cc = gcc +$cflags = -O3 -mv8 -Dssize_t=int +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL DES_PTR DES_RISC1 +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** ultrix-cc +$cc = cc +$cflags = -std1 -O -Olimit 1000 -DL_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** ultrix-gcc +$cc = gcc +$cflags = -O3 -DL_ENDIAN +$unistd = +$thread_cflag = (unknown) +$lflags = +$bn_ops = +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** unixware-2.0 +$cc = cc +$cflags = -O -DFILIO_H +$unistd = +$thread_cflag = (unknown) +$lflags = -lsocket -lnsl +$bn_ops = DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** unixware-2.0-pentium +$cc = cc +$cflags = -O -DFILIO_H -Kpentium -Kthread +$unistd = +$thread_cflag = (unknown) +$lflags = -lsocket -lnsl +$bn_ops = MD2_CHAR RC4_INDEX DES_PTR DES_RISC1 DES_UNROLL +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = + +*** unixware-7 +$cc = cc +$cflags = -O -DFILIO_H -Kalloca +$unistd = +$thread_cflag = -Kthread +$lflags = -lsocket -lnsl +$bn_ops = MD2_CHAR RC4_INDEX DES_PTR DES_RISC1 DES_UNROLL +$bn_obj = +$des_obj = +$bf_obj = +$md5_obj = +$sha1_obj = +$cast_obj = +$rc4_obj = +$rmd160_obj = +$rc5_obj = +$dso_scheme = +$shared_target= +$shared_cflag = diff --git a/crypto/openssl/certs/expired/rsa-ssca.pem b/crypto/openssl/certs/expired/rsa-ssca.pem new file mode 100644 index 000000000000..c9403212d183 --- /dev/null +++ b/crypto/openssl/certs/expired/rsa-ssca.pem @@ -0,0 +1,19 @@ +subject=/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority +issuer= /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority +notBefore=941109235417Z +notAfter =991231235417Z +-----BEGIN X509 CERTIFICATE----- + +MIICKTCCAZYCBQJBAAABMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMSAw +HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEuMCwGA1UECxMlU2VjdXJl +IFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NDExMDkyMzU0MTda +Fw05OTEyMzEyMzU0MTdaMF8xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0 +YSBTZWN1cml0eSwgSW5jLjEuMCwGA1UECxMlU2VjdXJlIFNlcnZlciBDZXJ0aWZp +Y2F0aW9uIEF1dGhvcml0eTCBmzANBgkqhkiG9w0BAQEFAAOBiQAwgYUCfgCSznrB +roM+WqqJg1esJQF2DK2ujiw3zus1eGRUA+WEQFHJv48I4oqCCNIWhjdV6bEhAq12 +aIGaBaJLyUslZiJWbIgHj/eBWW2EB2VwE3F2Ppt3TONQiVaYSLkdpykaEy5KEVmc +HhXVSVQsczppgrGXOZxtcGdI5d0t1sgeewIDAQABMA0GCSqGSIb3DQEBAgUAA34A +iNHReSHO4ovo+MF9NFM/YYPZtgs4F7boviGNjwC4i1N+RGceIr2XJ+CchcxK9oU7 +suK+ktPlDemvXA4MRpX/oRxePug2WHpzpgr4IhFrwwk4fia7c+8AvQKk8xQNMD9h +cHsg/jKjn7P0Z1LctO6EjJY2IN6BCINxIYoPnqk= +-----END X509 CERTIFICATE----- diff --git a/crypto/openssl/doc/ssl/SSL_CTX_add_extra_chain_cert.pod b/crypto/openssl/doc/ssl/SSL_CTX_add_extra_chain_cert.pod new file mode 100644 index 000000000000..21a9db0e2a40 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_add_extra_chain_cert.pod @@ -0,0 +1,38 @@ +=pod + +=head1 NAME + +SSL_CTX_add_extra_chain_cert - add certificate to chain + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + long SSL_CTX_add_extra_chain_cert(SSL_CTX ctx, X509 *x509) + +=head1 DESCRIPTION + +SSL_CTX_add_extra_chain_cert() adds the certificate B<x509> to the certificate +chain presented together with the certificate. Several certificates +can be added one after the other. + +=head1 NOTES + +When constructing the certificate chain, the chain will be formed from +these certificates explicitly specified. If no chain is specified, +the library will try to complete the chain from the available CA +certificates in the trusted CA storage, see +L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>. + +=head1 RETURN VALUES + +SSL_CTX_add_extra_chain_cert() returns 1 on success. Check out the +error stack to find out the reason for failure otherwise. + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>, +L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_CTX_add_session.pod b/crypto/openssl/doc/ssl/SSL_CTX_add_session.pod new file mode 100644 index 000000000000..af326c2f7340 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_add_session.pod @@ -0,0 +1,65 @@ +=pod + +=head1 NAME + +SSL_CTX_add_session, SSL_add_session, SSL_CTX_remove_session, SSL_remove_session - manipulate session cache + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + int SSL_CTX_add_session(SSL_CTX *ctx, SSL_SESSION *c); + int SSL_add_session(SSL_CTX *ctx, SSL_SESSION *c); + + int SSL_CTX_remove_session(SSL_CTX *ctx, SSL_SESSION *c); + int SSL_remove_session(SSL_CTX *ctx, SSL_SESSION *c); + +=head1 DESCRIPTION + +SSL_CTX_add_session() adds the session B<c> to the context B<ctx>. The +reference count for session B<c> is incremented by 1. If a session with +the same session id already exists, the old session is removed by calling +L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>. + +SSL_CTX_remove_session() removes the session B<c> from the context B<ctx>. +L<SSL_SESSION_free(3)|SSL_SESSION_free(3)> is called once for B<c>. + +SSL_add_session() and SSL_remove_session() are synonyms for their +SSL_CTX_*() counterparts. + +=head1 NOTES + +When adding a new session to the internal session cache, it is examined +whether a session with the same session id already exists. In this case +it is assumed that both sessions are identical. If the same session is +stored in a different SSL_SESSION object, The old session is +removed and replaced by the new session. If the session is actually +identical (the SSL_SESSION object is identical), SSL_CTX_add_session() +is a no-op, and the return value is 0. + + +=head1 RETURN VALUES + +The following values are returned by all functions: + +=over 4 + +=item 0 + + The operation failed. In case of the add operation, it was tried to add + the same (identical) session twice. In case of the remove operation, the + session was not found in the cache. + +=item 1 + + The operation succeeded. + +=back + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>, +L<SSL_SESSION_free(3)|SSL_SESSION_free(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_CTX_flush_sessions.pod b/crypto/openssl/doc/ssl/SSL_CTX_flush_sessions.pod new file mode 100644 index 000000000000..148c36c87151 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_flush_sessions.pod @@ -0,0 +1,49 @@ +=pod + +=head1 NAME + +SSL_CTX_flush_sessions, SSL_flush_sessions - remove expired sessions + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + void SSL_CTX_flush_sessions(SSL_CTX *ctx, long tm); + void SSL_flush_sessions(SSL_CTX *ctx, long tm); + +=head1 DESCRIPTION + +SSL_CTX_flush_sessions() causes a run through the session cache of +B<ctx> to remove sessions expired at time B<tm>. + +SSL_flush_sessions() is a synonym for SSL_CTX_flush_sessions(). + +=head1 NOTES + +If enabled, the internal session cache will collect all sessions established +up to the specified maximum number (see SSL_CTX_sess_set_cache_size()). +As sessions will not be reused ones they are expired, they should be +removed from the cache to save resources. This can either be done + automatically whenever 255 new sessions were established (see +L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>) +or manually by calling SSL_CTX_flush_sessions(). + +The parameter B<tm> specifies the time which should be used for the +expiration test, in most cases the actual time given by time(0) +will be used. + +SSL_CTX_flush_sessions() will only check sessions stored in the internal +cache. When a session is found and removed, the remove_session_cb is however +called to synchronize with the external cache (see +L<SSL_CTX_sess_set_get_cb(3)|SSL_CTX_sess_set_get_cb(3)>). + +=head1 RETURN VALUES + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>, +L<SSL_CTX_set_timeout(3)|SSL_CTX_set_timeout(3)>, +L<SSL_CTX_sess_set_get_cb(3)|SSL_CTX_sess_set_get_cb(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_CTX_get_ex_new_index.pod b/crypto/openssl/doc/ssl/SSL_CTX_get_ex_new_index.pod new file mode 100644 index 000000000000..15067438c82d --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_get_ex_new_index.pod @@ -0,0 +1,53 @@ +=pod + +=head1 NAME + +SSL_CTX_get_ex_new_index, SSL_CTX_set_ex_data, SSL_CTX_get_ex_data - internal application specific data functions + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + int SSL_CTX_get_ex_new_index(long argl, void *argp, + CRYPTO_EX_new *new_func, + CRYPTO_EX_dup *dup_func, + CRYPTO_EX_free *free_func); + + int SSL_CTX_set_ex_data(SSL_CTX *ctx, int idx, void *arg); + + void *SSL_CTX_get_ex_data(SSL_CTX *ctx, int idx); + + typedef int new_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, + int idx, long argl, void *argp); + typedef void free_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, + int idx, long argl, void *argp); + typedef int dup_func(CRYPTO_EX_DATA *to, CRYPTO_EX_DATA *from, void *from_d, + int idx, long argl, void *argp); + +=head1 DESCRIPTION + +Several OpenSSL structures can have application specific data attached to them. +These functions are used internally by OpenSSL to manipulate application +specific data attached to a specific structure. + +SSL_CTX_get_ex_new_index() is used to register a new index for application +specific data. + +SSL_CTX_set_ex_data() is used to store application data at B<arg> for B<idx> +into the B<ctx> object. + +SSL_CTX_get_ex_data() is used to retrieve the information for B<idx> from +B<ctx>. + +A detailed description for the B<*_get_ex_new_index()> functionality +can be found in L<RSA_get_ex_new_index.pod(3)|RSA_get_ex_new_index.pod(3)>. +The B<*_get_ex_data()> and B<*_set_ex_data()> functionality is described in +L<CRYPTO_set_ex_data(3)|CRYPTO_set_ex_data(3)>. + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<RSA_get_ex_new_index(3)|RSA_get_ex_new_index(3)>, +L<CRYPTO_set_ex_data(3)|CRYPTO_set_ex_data(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_CTX_get_verify_mode.pod b/crypto/openssl/doc/ssl/SSL_CTX_get_verify_mode.pod new file mode 100644 index 000000000000..7f10c6e94509 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_get_verify_mode.pod @@ -0,0 +1,50 @@ +=pod + +=head1 NAME + +SSL_CTX_get_verify_mode, SSL_get_verify_mode, SSL_CTX_get_verify_depth, SSL_get_verify_depth, SSL_get_verify_callback, SSL_CTX_get_verify_callback - get currently set verification parameters + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + int SSL_CTX_get_verify_mode(SSL_CTX *ctx); + int SSL_get_verify_mode(SSL *ssl); + int SSL_CTX_get_verify_depth(SSL_CTX *ctx); + int SSL_get_verify_depth(SSL *ssl); + int (*SSL_CTX_get_verify_callback(SSL_CTX *ctx))(int, X509_STORE_CTX *); + int (*SSL_get_verify_callback(SSL *ssl))(int, X509_STORE_CTX *); + +=head1 DESCRIPTION + +SSL_CTX_get_verify_mode() returns the verification mode currently set in +B<ctx>. + +SSL_get_verify_mode() returns the verification mode currently set in +B<ssl>. + +SSL_CTX_get_verify_depth() returns the verification depth limit currently set +in B<ctx>. If no limit has been explicitly set, -1 is returned and the +default value will be used. + +SSL_get_verify_depth() returns the verification depth limit currently set +in B<ssl>. If no limit has been explicitly set, -1 is returned and the +default value will be used. + +SSL_CTX_get_verify_callback() returns a function pointer to the verification +callback currently set in B<ctx>. If no callback was explicitly set, the +NULL pointer is returned and the default callback will be used. + +SSL_get_verify_callback() returns a function pointer to the verification +callback currently set in B<ssl>. If no callback was explicitly set, the +NULL pointer is returned and the default callback will be used. + +=head1 RETURN VALUES + +See DESCRIPTION + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_CTX_sess_set_get_cb.pod b/crypto/openssl/doc/ssl/SSL_CTX_sess_set_get_cb.pod new file mode 100644 index 000000000000..b6f15b440425 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_sess_set_get_cb.pod @@ -0,0 +1,81 @@ +=pod + +=head1 NAME + +SSL_CTX_sess_set_new_cb, SSL_CTX_sess_set_remove_cb, SSL_CTX_sess_set_get_cb, SSL_CTX_sess_get_new_cb, SSL_CTX_sess_get_remove_cb, SSL_CTX_sess_get_get_cb - provide callback functions for server side external session caching + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx, + int (*new_session_cb)(SSL *, SSL_SESSION *)); + void SSL_CTX_sess_set_remove_cb(SSL_CTX *ctx, + void (*remove_session_cb)(SSL_CTX *ctx, SSL_SESSION *)); + void SSL_CTX_sess_set_get_cb(SSL_CTX *ctx, + SSL_SESSION (*get_session_cb)(SSL *, unsigned char *, int, int *)); + + int (*SSL_CTX_sess_get_new_cb(SSL_CTX *ctx))(struct ssl_st *ssl, SSL_SESSION *sess); + void (*SSL_CTX_sess_get_remove_cb(SSL_CTX *ctx))(struct ssl_ctx_st *ctx, SSL_SESSION *sess); + SSL_SESSION *(*SSL_CTX_sess_get_get_cb(SSL_CTX *ctx))(struct ssl_st *ssl, unsigned char *data, int len, int *copy); + + int (*new_session_cb)(struct ssl_st *ssl, SSL_SESSION *sess); + void (*remove_session_cb)(struct ssl_ctx_st *ctx, SSL_SESSION *sess); + SSL_SESSION *(*get_session_cb)(struct ssl_st *ssl, unsigned char *data, + int len, int *copy); + +=head1 DESCRIPTION + +SSL_CTX_sess_set_new_cb() sets the callback function, which is automatically +called whenever a new session was negotiated. + +SSL_CTX_sess_set_remove_cb() sets the callback function, which is +automatically called whenever a session is removed by the SSL engine, +because it is considered faulty or the session has become obsolete because +of exceeding the timeout value. + +SSL_CTX_sess_set_get_cb() sets the callback function which is called, +whenever a SSL/TLS client proposed to resume a session but the session +could not be found in the internal session cache (see +L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>). +(SSL/TLS server only.) + +SSL_CTX_sess_get_new_cb(), SSL_CTX_sess_get_remove_cb(), and +SSL_CTX_sess_get_get_cb() allow to retrieve the function pointers of the +provided callback functions. If a callback function has not been set, +the NULL pointer is returned. + +=head1 NOTES + +In order to allow external session caching, synchronization with the internal +session cache is realized via callback functions. Inside these callback +functions, session can be saved to disk or put into a database using the +L<d2i_SSL_SESSION(3)|d2i_SSL_SESSION(3)> interface. + +The new_session_cb() is called, whenever a new session has been negotiated +and session caching is enabled (see +L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>). +The new_session_cb() is passed the B<ssl> connection and the ssl session +B<sess>. If the callback returns B<0>, the session will be immediately +removed again. + +The remove_session_cb() is called, whenever the SSL engine removes a session +from the internal cache. This happens if the session is removed because +it is expired or when a connection was not shutdown cleanly. The +remove_session_cb() is passed the B<ctx> and the ssl session B<sess>. +It does not provide any feedback. + +The get_session_cb() is only called on SSL/TLS servers with the session id +proposed by the client. The get_session_cb() is always called, also when +session caching was disabled. The get_session_cb() is passed the +B<ssl> connection, the session id of length B<length> at the memory location +B<data>. With the parameter B<copy> the callback can require the +SSL engine to increment the reference count of the SSL_SESSION object. + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, L<d2i_SSL_SESSION(3)|d2i_SSL_SESSION(3)>, +L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>, +L<SSL_CTX_flush_sessions(3)|<SSL_CTX_flush_sessions(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_CTX_set_default_passwd_cb.pod b/crypto/openssl/doc/ssl/SSL_CTX_set_default_passwd_cb.pod new file mode 100644 index 000000000000..a5343a1cf398 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_set_default_passwd_cb.pod @@ -0,0 +1,70 @@ +=pod + +=head1 NAME + +SSL_CTX_set_default_passwd_cb, SSL_CTX_set_default_passwd_cb_userdata - set passwd callback for encrypted PEM file handling + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + void SSL_CTX_set_default_passwd_cb(SSL_CTX *ctx, pem_password_cb *cb); + void SSL_CTX_set_default_passwd_cb_userdata(SSL_CTX *ctx, void *u); + + int pem_passwd_cb(char *buf, int size, int rwflag, void *userdata); + +=head1 DESCRIPTION + +SSL_CTX_set_default_passwd_cb() sets the default password callback called +when loading/storing a PEM certificate with encryption. + +SSL_CTX_set_default_passwd_cb_userdata() sets a pointer to B<userdata> which +will be provided to the password callback on invocation. + +The pem_passwd_cb(), which must be provided by the application, hands back the +password to be used during decryption. On invocation a pointer to B<userdata> +is provided. The pem_passwd_cb must write the password into the provided buffer +B<buf> which is of size B<size>. The actual length of the password must +be returned to the calling function. B<rwflag> indicates whether the +callback is used for reading/decryption (rwflag=0) or writing/encryption +(rwflag=1). + +=head1 NOTES + +When loading or storing private keys, a password might be supplied to +protect the private key. The way this password can be supplied may depend +on the application. If only one private key is handled, it can be practical +to have pem_passwd_cb() handle the password dialog interactively. If several +keys have to be handled, it can be practical to ask for the password once, +then keep it in memory and use it several times. In the last case, the +password could be stored into the B<userdata> storage and the +pem_passwd_cb() only returns the password already stored. + +Other items in PEM formatting (certificates) can also be encrypted, it is +however not usual, as certificate information is considered public. + +=head1 RETURN VALUES + +SSL_CTX_set_default_passwd_cb() and SSL_CTX_set_default_passwd_cb_userdata() +do not provide diagnostic information. + +=head1 EXAMPLES + +The following example returns the password provided as B<userdata> to the +calling function. The password is considered to be a '\0' terminated +string. If the password does not fit into the buffer, the password is +truncated. + + int pem_passwd_cb(char *buf, int size, int rwflag, void *password) + { + strncpy(buf, (char *)(password), size); + buf[size - 1] = '\0'; + return(strlen(buf)); + } + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_CTX_set_session_id_context.pod b/crypto/openssl/doc/ssl/SSL_CTX_set_session_id_context.pod new file mode 100644 index 000000000000..5949395159e7 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_set_session_id_context.pod @@ -0,0 +1,82 @@ +=pod + +=head1 NAME + +SSL_CTX_set_session_id_context, SSL_set_session_id_context - set context within which session can be reused (server side only) + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + int SSL_CTX_set_session_id_context(SSL_CTX *ctx, const unsigned char *sid_ctx, + unsigned int sid_ctx_len); + int SSL_set_session_id_context(SSL *ssl, const unsigned char *sid_ctx, + unsigned int sid_ctx_len); + +=head1 DESCRIPTION + +SSL_CTX_set_session_id_context() sets the context B<sid_ctx> of length +B<sid_ctx_len> within which a session can be reused for the B<ctx> object. + +SSL_set_session_id_context() sets the context B<sid_ctx> of length +B<sid_ctx_len> within which a session can be reused for the B<ssl> object. + +=head1 NOTES + +Sessions are generated within a certain context. When exporting/importing +sessions with B<i2d_SSL_SESSION>/B<d2i_SSL_SESSION> it would be possible, +to re-import a session generated from another context (e.g. another +application), which might lead to malfunctions. Therefore each application +must set its own session id context B<sid_ctx> which is used to distinguish +the contexts and is stored in exported sessions. The B<sid_ctx> can be +any kind of binary data with a given length, it is therefore possible +to use e.g. the name of the application and/or the hostname and/or service +name ... + +The session id context becomes part of the session. The session id context +is set by the SSL/TLS server. The SSL_CTX_set_session_id_context() and +SSL_set_session_id_context() functions are therefore only useful on the +server side. + +OpenSSL clients will check the session id context returned by the server +when reusing a session. + +The maximum length of the B<sid_ctx> is limited to +B<SSL_MAX_SSL_SESSION_ID_LENGTH>. + +=head1 WARNINGS + +If the session id context is not set on an SSL/TLS server, stored sessions +will not be reused but a fatal error will be flagged and the handshake +will fail. + +If a server returns a different session id context to an OpenSSL client +when reusing a session, an error will be flagged and the handshake will +fail. OpenSSL servers will always return the correct session id context, +as an OpenSSL server checks the session id context itself before reusing +a session as described above. + +=head1 RETURN VALUES + +SSL_CTX_set_session_id_context() and SSL_set_session_id_context() +return the following values: + +=over 4 + +=item 0 + +The length B<sid_ctx_len> of the session id context B<sid_ctx> exceeded +the maximum allowed length of B<SSL_MAX_SSL_SESSION_ID_LENGTH>. The error +is logged to the error stack. + +=item 1 + +The operation succeeded. + +=back + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_CTX_set_timeout.pod b/crypto/openssl/doc/ssl/SSL_CTX_set_timeout.pod new file mode 100644 index 000000000000..21faed12d425 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_set_timeout.pod @@ -0,0 +1,55 @@ +=pod + +=head1 NAME + +SSL_CTX_set_timeout, SSL_CTX_get_timeout - manipulate timeout values for session caching + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + long SSL_CTX_set_timeout(SSL_CTX *ctx, long t); + long SSL_CTX_get_timeout(SSL_CTX *ctx); + +=head1 DESCRIPTION + +SSL_CTX_set_timeout() sets the timeout for newly created sessions for +B<ctx> to B<t>. The timeout value B<t> must be given in seconds. + +SSL_CTX_get_timeout() returns the currently set timeout value for B<ctx>. + +=head1 NOTES + +Whenever a new session is created, it is assigned a maximum lifetime. This +lifetime is specified by storing the creation time of the session and the +timeout value valid at this time. If the actual time is later than creation +time plus timeout, the session is not reused. + +Due to this realization, all sessions behave according to the timeout value +valid at the time of the session negotiation. Changes of the timeout value +do not affect already established sessions. + +The expiration time of a single session can be modified using the +L<SSL_SESSION_get_time(3)|SSL_SESSION_get_time(3)> family of functions. + +Expired sessions are removed from the internal session cache, whenever +L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)> is called, either +directly by the application or automatically (see +L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>) + +The default value for session timeout is 300 seconds. + +=head1 RETURN VALUES + +SSL_CTX_set_timeout() returns the previously set timeout value. + +SSL_CTX_get_timeout() returns the currently set timeout value. + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>, +L<SSL_SESSION_get_time(3)|SSL_SESSION_get_time(3)>, +L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_CTX_set_verify.pod b/crypto/openssl/doc/ssl/SSL_CTX_set_verify.pod new file mode 100644 index 000000000000..fc0b76118fd1 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_CTX_set_verify.pod @@ -0,0 +1,284 @@ +=pod + +=head1 NAME + +SSL_CTX_set_verify, SSL_set_verify, SSL_CTX_set_verify_depth, SSL_set_verify_depth - set peer certificate verification parameters + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + void SSL_CTX_set_verify(SSL_CTX *ctx, int mode, + int (*verify_callback)(int, X509_STORE_CTX *)); + void SSL_set_verify(SSL *s, int mode, + int (*verify_callback)(int, X509_STORE_CTX *)); + void SSL_CTX_set_verify_depth(SSL_CTX *ctx,int depth); + void SSL_set_verify_depth(SSL *s, int depth); + + int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx); + +=head1 DESCRIPTION + +SSL_CTX_set_verify() sets the verification flags for B<ctx> to be B<mode> and +specifies the B<verify_callback> function to be used. If no callback function +shall be specified, the NULL pointer can be used for B<verify_callback>. + +SSL_set_verify() sets the verification flags for B<ssl> to be B<mode> and +specifies the B<verify_callback> function to be used. If no callback function +shall be specified, the NULL pointer can be used for B<verify_callback>. In +this case last B<verify_callback> set specifically for this B<ssl> remains. If +no special B<callback> was set before, the default callback for the underlying +B<ctx> is used, that was valid at the the time B<ssl> was created with +L<SSL_new(3)|SSL_new(3)>. + +SSL_CTX_set_verify_depth() sets the maximum B<depth> for the certificate chain +verification that shall be allowed for B<ctx>. (See the BUGS section.) + +SSL_set_verify_depth() sets the maximum B<depth> for the certificate chain +verification that shall be allowed for B<ssl>. (See the BUGS section.) + +=head1 NOTES + +The verification of certificates can be controlled by a set of logically +or'ed B<mode> flags: + +=over 4 + +=item SSL_VERIFY_NONE + +B<Server mode:> the server will not send a client certificate request to the +client, so the client will not send a certificate. + +B<Client mode:> if not using an anonymous cipher (by default disabled), the +server will send a certificate which will be checked. The result of the +certificate verification process can be checked after the TLS/SSL handshake +using the L<SSL_get_verify_result(3)|SSL_get_verify_result(3)> function. +The handshake will be continued regardless of the verification result. + +=item SSL_VERIFY_PEER + +B<Server mode:> the server sends a client certificate request to the client. +The certificate returned (if any) is checked. If the verification process +fails as indicated by B<verify_callback>, the TLS/SSL handshake is +immediately terminated with an alert message containing the reason for +the verification failure. +The behaviour can be controlled by the additional +SSL_VERIFY_FAIL_IF_NO_PEER_CERT and SSL_VERIFY_CLIENT_ONCE flags. + +B<Client mode:> the server certificate is verified. If the verification process +fails as indicated by B<verify_callback>, the TLS/SSL handshake is +immediately terminated with an alert message containing the reason for +the verification failure. If no server certificate is sent, because an +anonymous cipher is used, SSL_VERIFY_PEER is ignored. + +=item SSL_VERIFY_FAIL_IF_NO_PEER_CERT + +B<Server mode:> if the client did not return a certificate, the TLS/SSL +handshake is immediately terminated with a "handshake failure" alert. +This flag must be used together with SSL_VERIFY_PEER. + +B<Client mode:> ignored + +=item SSL_VERIFY_CLIENT_ONCE + +B<Server mode:> only request a client certificate on the initial TLS/SSL +handshake. Do not ask for a client certificate again in case of a +renegotiation. This flag must be used together with SSL_VERIFY_PEER. + +B<Client mode:> ignored + +=back + +Exactly one of the B<mode> flags SSL_VERIFY_NONE and SSL_VERIFY_PEER must be +set at any time. + +SSL_CTX_set_verify_depth() and SSL_set_verify_depth() set the limit up +to which depth certificates in a chain are used during the verification +procedure. If the certificate chain is longer than allowed, the certificates +above the limit are ignored. Error messages are generated as if these +certificates would not be present, most likely a +X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY will be issued. +The depth count is "level 0:peer certificate", "level 1: CA certificate", +"level 2: higher level CA certificate", and so on. Setting the maximum +depth to 2 allows the levels 0, 1, and 2. The default depth limit is 9, +allowing for the peer certificate and additional 9 CA certificates. + +The B<verify_callback> function is used to control the behaviour when the +SSL_VERIFY_PEER flag is set. It must be supplied by the application and +receives two arguments: B<preverify_ok> indicates, whether the verification of +the certificate in question was passed (preverify_ok=1) or not +(preverify_ok=0). B<x509_ctx> is a pointer to the complete context used +for the certificate chain verification. + +The certificate chain is checked starting with the deepest nesting level +(the root CA certificate) and worked upward to the peer's certificate. +At each level signatures and issuer attributes are checked. Whenever +a verification error is found, the error number is stored in B<x509_ctx> +and B<verify_callback> is called with B<preverify_ok>=0. By applying +X509_CTX_store_* functions B<verify_callback> can locate the certificate +in question and perform additional steps (see EXAMPLES). If no error is +found for a certificate, B<verify_callback> is called with B<preverify_ok>=1 +before advancing to the next level. + +The return value of B<verify_callback> controls the strategy of the further +verification process. If B<verify_callback> returns 0, the verification +process is immediately stopped with "verification failed" state. If +SSL_VERIFY_PEER is set, a verification failure alert is sent to the peer and +the TLS/SSL handshake is terminated. If B<verify_callback> returns 1, +the verification process is continued. If B<verify_callback> always returns +1, the TLS/SSL handshake will never be terminated because of this application +experiencing a verification failure. The calling process can however +retrieve the error code of the last verification error using +L<SSL_get_verify_result(3)|SSL_get_verify_result(3)> or by maintaining its +own error storage managed by B<verify_callback>. + +If no B<verify_callback> is specified, the default callback will be used. +Its return value is identical to B<preverify_ok>, so that any verification +failure will lead to a termination of the TLS/SSL handshake with an +alert message, if SSL_VERIFY_PEER is set. + +=head1 BUGS + +In client mode, it is not checked whether the SSL_VERIFY_PEER flag +is set, but whether SSL_VERIFY_NONE is not set. This can lead to +unexpected behaviour, if the SSL_VERIFY_PEER and SSL_VERIFY_NONE are not +used as required (exactly one must be set at any time). + +The certificate verification depth set with SSL[_CTX]_verify_depth() +stops the verification at a certain depth. The error message produced +will be that of an incomplete certificate chain and not +X509_V_ERR_CERT_CHAIN_TOO_LONG as may be expected. + +=head1 RETURN VALUES + +The SSL*_set_verify*() functions do not provide diagnostic information. + +=head1 EXAMPLES + +The following code sequence realizes an example B<verify_callback> function +that will always continue the TLS/SSL handshake regardless of verification +failure, if wished. The callback realizes a verification depth limit with +more informational output. + +All verification errors are printed, informations about the certificate chain +are printed on request. +The example is realized for a server that does allow but not require client +certificates. + +The example makes use of the ex_data technique to store application data +into/retrieve application data from the SSL structure +(see L<SSL_get_ex_new_index(3)|SSL_get_ex_new_index(3)>, +L<SSL_get_ex_data_X509_STORE_CTX_idx(3)|SSL_get_ex_data_X509_STORE_CTX_idx(3)>). + + ... + typedef struct { + int verbose_mode; + int verify_depth; + int always_continue; + } mydata_t; + int mydata_index; + ... + static int verify_callback(int preverify_ok, X509_STORE_CTX *ctx) + { + char buf[256]; + X509 *err_cert; + int err, depth; + SSL *ssl; + mydata_t *mydata; + + err_cert = X509_STORE_CTX_get_current_cert(ctx); + err = X509_STORE_CTX_get_error(ctx); + depth = X509_STORE_CTX_get_error_depth(ctx); + + /* + * Retrieve the pointer to the SSL of the connection currently treated + * and the application specific data stored into the SSL object. + */ + ssl = X509_STORE_CTX_get_ex_data(ctx, SSL_get_ex_data_X509_STORE_CTX_idx()); + mydata = SSL_get_ex_data(ssl, mydata_index); + + X509_NAME_oneline(X509_get_subject_name(err_cert), buf, 256); + + /* + * Catch a too long certificate chain. The depth limit set using + * SSL_CTX_set_verify_depth() is by purpose set to "limit+1" so + * that whenever the "depth>verify_depth" condition is met, we + * have violated the limit and want to log this error condition. + * We must do it here, because the CHAIN_TOO_LONG error would not + * be found explicitly; only errors introduced by cutting off the + * additional certificates would be logged. + */ + if (depth > mydata->verify_depth) { + preverify_ok = 0; + err = X509_V_ERR_CERT_CHAIN_TOO_LONG; + X509_STORE_CTX_set_error(ctx, err); + } + if (!preverify_ok) { + printf("verify error:num=%d:%s:depth=%d:%s\n", err, + X509_verify_cert_error_string(err), depth, buf); + } + else if (mydata->verbose_mode) + { + printf("depth=%d:%s\n", depth, buf); + } + + /* + * At this point, err contains the last verification error. We can use + * it for something special + */ + if (!preverify_ok && (err == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT) + { + X509_NAME_oneline(X509_get_issuer_name(ctx->current_cert), buf, 256); + printf("issuer= %s\n", buf); + } + + if (mydata->always_continue) + return 1; + else + return preverify_ok; + } + ... + + mydata_t mydata; + + ... + mydata_index = SSL_get_ex_new_index(0, "mydata index", NULL, NULL, NULL); + + ... + SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER|SSL_VERIFY_CLIENT_ONCE, + verify_callback); + + /* + * Let the verify_callback catch the verify_depth error so that we get + * an appropriate error in the logfile. + */ + SSL_CTX_set_verify_depth(verify_depth + 1); + + /* + * Set up the SSL specific data into "mydata" and store it into th SSL + * structure. + */ + mydata.verify_depth = verify_depth; ... + SSL_set_ex_data(ssl, mydata_index, &mydata); + + ... + SSL_accept(ssl); /* check of success left out for clarity */ + if (peer = SSL_get_peer_certificate(ssl)) + { + if (SSL_get_verify_result(ssl) == X509_V_OK) + { + /* The client sent a certificate which verified OK */ + } + } + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>, +L<SSL_CTX_get_verify_mode(3)|SSL_CTX_get_verify_mode(3)>, +L<SSL_get_verify_result(3)|SSL_get_verify_result(3)>, +L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>, +L<SSL_get_peer_certificate(3)|SSL_get_peer_certificate(3)>, +L<SSL_get_ex_data_X509_STORE_CTX_idx(3)|SSL_get_ex_data_X509_STORE_CTX_idx(3)>, +L<SSL_get_ex_new_index(3)|SSL_get_ex_new_index(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_SESSION_get_ex_new_index.pod b/crypto/openssl/doc/ssl/SSL_SESSION_get_ex_new_index.pod new file mode 100644 index 000000000000..dd5cb4f04bba --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_SESSION_get_ex_new_index.pod @@ -0,0 +1,61 @@ +=pod + +=head1 NAME + +SSL_SESSION_get_ex_new_index, SSL_SESSION_set_ex_data, SSL_SESSION_get_ex_data - internal application specific data functions + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + int SSL_SESSION_get_ex_new_index(long argl, void *argp, + CRYPTO_EX_new *new_func, + CRYPTO_EX_dup *dup_func, + CRYPTO_EX_free *free_func); + + int SSL_SESSION_set_ex_data(SSL_SESSION *session, int idx, void *arg); + + void *SSL_SESSION_get_ex_data(SSL_SESSION *session, int idx); + + typedef int new_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, + int idx, long argl, void *argp); + typedef void free_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, + int idx, long argl, void *argp); + typedef int dup_func(CRYPTO_EX_DATA *to, CRYPTO_EX_DATA *from, void *from_d, + int idx, long argl, void *argp); + +=head1 DESCRIPTION + +Several OpenSSL structures can have application specific data attached to them. +These functions are used internally by OpenSSL to manipulate application +specific data attached to a specific structure. + +SSL_SESSION_get_ex_new_index() is used to register a new index for application +specific data. + +SSL_SESSION_set_ex_data() is used to store application data at B<arg> for B<idx> +into the B<session> object. + +SSL_SESSION_get_ex_data() is used to retrieve the information for B<idx> from +B<session>. + +A detailed description for the B<*_get_ex_new_index()> functionality +can be found in L<RSA_get_ex_new_index.pod(3)|RSA_get_ex_new_index.pod(3)>. +The B<*_get_ex_data()> and B<*_set_ex_data()> functionality is described in +L<CRYPTO_set_ex_data(3)|CRYPTO_set_ex_data(3)>. + +=head1 WARNINGS + +The application data is only maintained for sessions held in memory. The +application data is not included when dumping the session with +i2d_SSL_SESSION() (and all functions indirectly calling the dump functions +like PEM_write_SSL_SESSION() and PEM_write_bio_SSL_SESSION()) and can +therefore not be restored. + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<RSA_get_ex_new_index(3)|RSA_get_ex_new_index(3)>, +L<CRYPTO_set_ex_data(3)|CRYPTO_set_ex_data(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_SESSION_get_time.pod b/crypto/openssl/doc/ssl/SSL_SESSION_get_time.pod new file mode 100644 index 000000000000..cd33b73aa359 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_SESSION_get_time.pod @@ -0,0 +1,63 @@ +=pod + +=head1 NAME + +SSL_SESSION_get_time, SSL_SESSION_set_time, SSL_SESSION_get_timeout, SSL_SESSION_get_timeout - retrieve and manipulate session time and timeout settings + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + long SSL_SESSION_get_time(SSL_SESSION *s); + long SSL_SESSION_set_time(SSL_SESSION *s, long tm); + long SSL_SESSION_get_timeout(SSL_SESSION *s); + long SSL_SESSION_set_timeout(SSL_SESSION *s, long tm); + + long SSL_get_time(SSL_SESSION *s); + long SSL_set_time(SSL_SESSION *s, long tm); + long SSL_get_timeout(SSL_SESSION *s); + long SSL_set_timeout(SSL_SESSION *s, long tm); + +=head1 DESCRIPTION + +SSL_SESSION_get_time() returns the time at which the session B<s> was +established. The time is given in seconds since the Epoch and therefore +compatible to the time delivered by the time() call. + +SSL_SESSION_set_time() replaces the creation time of the session B<s> with +the chosen value B<tm>. + +SSL_SESSION_get_timeout() returns the timeout value set for session B<s> +in seconds. + +SSL_SESSION_set_timeout() sets the timeout value for session B<s> in seconds +to B<tm>. + +The SSL_get_time(), SSL_set_time(), SSL_get_timeout(), and SSL_set_timeout() +functions are synonyms for the SSL_SESSION_*() counterparts. + +=head1 NOTES + +Sessions are expired by examining the creation time and the timeout value. +Both are set at creation time of the session to the actual time and the +default timeout value at creation, respectively, as set by +L<SSL_CTX_set_timeout(3)|SSL_CTX_set_timeout(3)>. +Using these functions it is possible to extend or shorten the lifetime +of the session. + +=head1 RETURN VALUES + +SSL_SESSION_get_time() and SSL_SESSION_get_timeout() return the currently +valid values. + +SSL_SESSION_set_time() and SSL_SESSION_set_timeout() return 1 on success. + +If any of the function is passed the NULL pointer for the session B<s>, +0 is returned. + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<SSL_CTX_set_timeout(3)|SSL_CTX_set_timeout(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_get_ex_data_X509_STORE_CTX_idx.pod b/crypto/openssl/doc/ssl/SSL_get_ex_data_X509_STORE_CTX_idx.pod new file mode 100644 index 000000000000..165c6a5b2cae --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_get_ex_data_X509_STORE_CTX_idx.pod @@ -0,0 +1,61 @@ +=pod + +=head1 NAME + +SSL_get_ex_data_X509_STORE_CTX_idx - get ex_data index to access SSL structure +from X509_STORE_CTX + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + int SSL_get_ex_data_X509_STORE_CTX_idx(void); + +=head1 DESCRIPTION + +SSL_get_ex_data_X509_STORE_CTX_idx() returns the index number under which +the pointer to the SSL object is stored into the X509_STORE_CTX object. + +=head1 NOTES + +Whenever a X509_STORE_CTX object is created for the verification of the +peers certificate during a handshake, a pointer to the SSL object is +stored into the X509_STORE_CTX object to identify the connection affected. +To retrieve this pointer the X509_STORE_CTX_get_ex_data() function can +be used with the correct index. This index is globally the same for all +X509_STORE_CTX objects and can be retrieved using +SSL_get_ex_data_X509_STORE_CTX_idx(). The index value is set when +SSL_get_ex_data_X509_STORE_CTX_idx() is first called either by the application +program directly or indirectly during other SSL setup functions or during +the handshake. + +The value depends on other index values defined for X509_STORE_CTX objects +before the SSL index is created. + +=head1 RETURN VALUES + +=over 4 + +=item E<gt>=0 + +The index value to access the pointer. + +=item E<lt>0 + +An error occurred, check the error stack for a detailed error message. + +=back + +=head1 EXAMPLES + +The index returned from SSL_get_ex_data_X509_STORE_CTX_idx() allows to +access the SSL object for the connection to be accessed during the +verify_callback() when checking the peers certificate. Please check +the example in L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>, + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>, +L<CRYPTO_set_ex_data(3)|CRYPTO_set_ex_data(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_get_ex_new_index.pod b/crypto/openssl/doc/ssl/SSL_get_ex_new_index.pod new file mode 100644 index 000000000000..2b69bb105003 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_get_ex_new_index.pod @@ -0,0 +1,59 @@ +=pod + +=head1 NAME + +SSL_get_ex_new_index, SSL_set_ex_data, SSL_get_ex_data - internal application specific data functions + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + int SSL_get_ex_new_index(long argl, void *argp, + CRYPTO_EX_new *new_func, + CRYPTO_EX_dup *dup_func, + CRYPTO_EX_free *free_func); + + int SSL_set_ex_data(SSL *ssl, int idx, void *arg); + + void *SSL_get_ex_data(SSL *ssl, int idx); + + typedef int new_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, + int idx, long argl, void *argp); + typedef void free_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, + int idx, long argl, void *argp); + typedef int dup_func(CRYPTO_EX_DATA *to, CRYPTO_EX_DATA *from, void *from_d, + int idx, long argl, void *argp); + +=head1 DESCRIPTION + +Several OpenSSL structures can have application specific data attached to them. +These functions are used internally by OpenSSL to manipulate application +specific data attached to a specific structure. + +SSL_get_ex_new_index() is used to register a new index for application +specific data. + +SSL_set_ex_data() is used to store application data at B<arg> for B<idx> into +the B<ssl> object. + +SSL_get_ex_data() is used to retrieve the information for B<idx> from +B<ssl>. + +A detailed description for the B<*_get_ex_new_index()> functionality +can be found in L<RSA_get_ex_new_index.pod(3)|RSA_get_ex_new_index.pod(3)>. +The B<*_get_ex_data()> and B<*_set_ex_data()> functionality is described in +L<CRYPTO_set_ex_data(3)|CRYPTO_set_ex_data(3)>. + +=head1 EXAMPLES + +An example on how to use the functionality is included in the example +verify_callback() in L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>. + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<RSA_get_ex_new_index(3)|RSA_get_ex_new_index(3)>, +L<CRYPTO_set_ex_data(3)|CRYPTO_set_ex_data(3)>, +L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)> + +=cut diff --git a/crypto/openssl/doc/ssl/SSL_load_client_CA_file.pod b/crypto/openssl/doc/ssl/SSL_load_client_CA_file.pod new file mode 100644 index 000000000000..02527dc2edc8 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_load_client_CA_file.pod @@ -0,0 +1,62 @@ +=pod + +=head1 NAME + +SSL_load_client_CA_file - load certificate names from file + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + STACK_OF(X509_NAME) *SSL_load_client_CA_file(const char *file); + +=head1 DESCRIPTION + +SSL_load_client_CA_file() reads certificates from B<file> and returns +a STACK_OF(X509_NAME) with the subject names found. + +=head1 NOTES + +SSL_load_client_CA_file() reads a file of PEM formatted certificates and +extracts the X509_NAMES of the certificates found. While the name suggests +the specific usage as support function for +L<SSL_CTX_set_client_CA_list(3)|SSL_CTX_set_client_CA_list(3)>, +it is not limited to CA certificates. + +=head1 EXAMPLES + +Load names of CAs from file and use it as a client CA list: + + SSL_CTX *ctx; + STACK_OF(X509_NAME) *cert_names; + + ... + cert_names = SSL_load_client_CA_file("/path/to/CAfile.pem"); + if (cert_names != NULL) + SSL_CTX_set_client_CA_list(ctx, cert_names); + else + error_handling(); + ... + +=head1 RETURN VALUES + +The following return values can occur: + +=over 4 + +=item NULL + +The operation failed, check out the error stack for the reason. + +=item Pointer to STACK_OF(X509_NAME) + +Pointer to the subject names of the successfully read certificates. + +=back + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<SSL_CTX_set_client_CA_list(3)|SSL_CTX_set_client_CA_list(3)> + +=cut diff --git a/etc/periodic/daily/500.queuerun b/etc/periodic/daily/500.queuerun new file mode 100755 index 000000000000..2a8b2a170d14 --- /dev/null +++ b/etc/periodic/daily/500.queuerun @@ -0,0 +1,34 @@ +#!/bin/sh +# +# $FreeBSD$ +# + +# If there is a global system configuration file, suck it in. +# +if [ -r /etc/defaults/periodic.conf ] +then + . /etc/defaults/periodic.conf + source_periodic_confs +fi + +case "$daily_queuerun_enable" in + [Yy][Ee][Ss]) + if [ ! -x /usr/sbin/sendmail ] + then + echo '$daily_queuerun_enable is set but /usr/sbin/sendmail' \ + "isn't executable" + rc=2 + elif [ ! -d /var/spool/mqueue ] + then + echo '$daily_queuerun_enable is set but /var/spool/mqueue' \ + "doesn't exist" + rc=2 + else + /usr/sbin/sendmail -q >/dev/null 2>&1 & + rc=0 + fi;; + + *) rc=0;; +esac + +exit $rc diff --git a/kerberos5/lib/libgssapi/Makefile b/kerberos5/lib/libgssapi/Makefile new file mode 100644 index 000000000000..86878e472d46 --- /dev/null +++ b/kerberos5/lib/libgssapi/Makefile @@ -0,0 +1,59 @@ +# $FreeBSD$ + +LIB= gssapi +CFLAGS+=-I${KRB5DIR}/lib/gssapi \ + -I${KRB5DIR}/lib/krb5 \ + -I${KRB5DIR}/lib/asn1 \ + -I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/des \ + -I${KRB5DIR}/include \ + -I${ASN1OBJDIR} \ + -I${.OBJDIR} + +SRCS= \ + 8003.c \ + accept_sec_context.c \ + acquire_cred.c \ + add_oid_set_member.c \ + canonicalize_name.c \ + compare_name.c \ + context_time.c \ + copy_ccache.c \ + create_emtpy_oid_set.c \ + decapsulate.c \ + delete_sec_context.c \ + display_name.c \ + display_status.c \ + duplicate_name.c \ + encapsulate.c \ + export_sec_context.c \ + export_name.c \ + external.c \ + get_mic.c \ + gssapi.h \ + gssapi_locl.h \ + import_name.c \ + import_sec_context.c \ + indicate_mechs.c \ + init.c \ + init_sec_context.c \ + inquire_context.c \ + inquire_cred.c \ + release_buffer.c \ + release_cred.c \ + release_name.c \ + release_oid_set.c \ + test_oid_set_member.c \ + unwrap.c \ + v1.c \ + verify_mic.c \ + wrap.c \ + address_to_krb5addr.c + +INCLUDES=${KRB5DIR}/lib/gssapi/gssapi.h heim_err.h krb5_err.h + +.include <bsd.lib.mk> + +.PATH: ${KRB5DIR}/lib/gssapi + +beforedepend all: heim_err.h krb5_err.h diff --git a/kerberos5/lib/libvers/Makefile b/kerberos5/lib/libvers/Makefile new file mode 100644 index 000000000000..a3bc7266035f --- /dev/null +++ b/kerberos5/lib/libvers/Makefile @@ -0,0 +1,34 @@ +# $FreeBSD$ + +LIB= vers + +CFLAGS+= -I${KRB5DIR}/include \ + -I${ROKENOBJDIR} \ + -I${KRB5DIR}/lib/roken \ + -I${.OBJDIR} + +SRCS= \ + print_version.c \ + print_version.h + +install: + +__initialized__: + +.include "../../Makefile.inc" + +.include <bsd.lib.mk> + +beforedepend all: print_version.h + +.PATH: ${KRB5DIR}/lib/vers + +build-tools: make-print-version + +print_version.h: make-print-version + ./make-print-version print_version.h + +make-print-version: make-print-version.c + ${CC} ${CFLAGS} -static -o ${.TARGET} ${.OODATE} + +CLEANFILES+= make-print-version print_version.h diff --git a/lib/libc/db/man/dbm.3 b/lib/libc/db/man/dbm.3 new file mode 100644 index 000000000000..64ef4b6ef00d --- /dev/null +++ b/lib/libc/db/man/dbm.3 @@ -0,0 +1,196 @@ +.\" Copyright (c) 1999 Tim Singletary +.\" No copyright is claimed. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.\" Note: The date here should be updated whenever a non-trivial +.\" change is made to the manual page. +.Dd July 7, 1999 +.Dt DBM 3 +.Os +.Sh NAME +.Nm dbm_clearerr , +.Nm dbm_close , +.Nm dbm_delete , +.Nm dbm_dirfno , +.Nm dbm_error , +.Nm dbm_fetch , +.Nm dbm_firstkey , +.Nm dbm_nextkey , +.Nm dbm_open , +.Nm dbm_store +.Nd database access functions +.Sh SYNOPSIS +.Fd #include <fcntl.h> +.Fd #include <ndbm.h> +.Ft DBM * +.Fn dbm_open "const char *base" "int flags" "int mode" +.Ft void +.Fn dbm_close "DBM *db" +.Ft int +.Fn dbm_store "DBM *db" "datum key" "datum data" "int flags" +.Ft datum +.Fn dbm_fetch "DBM *db" "datum key" +.Ft int +.Fn dbm_delete "DBM *db" "datum key" +.Ft datum +.Fn dbm_firstkey "DBM *db" +.Ft datum +.Fn dbm_nextkey "DBM *db" +.Ft int +.Fn dbm_error "DBM *db" +.Ft int +.Fn dbm_clearerr "DBM *db" +.Ft int +.Fn dbm_dirfno "DBM *db" +.Sh DESCRIPTION +Database access functions. +These functions are implemented using +.Xr dbopen 3 +with a +.Xr hash 3 +database. +.Pp +.Vt datum +is declared in +.Aq Pa ndbm.h : +.Bd -literal +typedef struct { + char *dptr; + int dsize; +} datum; +.Ed +.Pp +.Fn dbm_open base flags mode +opens or creates a database. +.Fa base +is the basename of the file containing +the database; the actual database has a +.Pa .db +suffix. +I.e., if +.Fa base +is +.Qq Li /home/me/mystuff +then the actual database is in the file +.Pa /home/me/mystuff.db . +.Fa flags +and +.Fa mode +are passed to +.Xr open 2 . +.Pq Dv O_RDWR \*(Ba O_CREAT +is a typical value for +.Fa flags ; +.Li 0660 +is a typical value for +.Fa mode . +.Dv O_WRONLY +is not allowed in +.Fa flags . +The pointer returned by +.Fn dbm_open +identifies the database and is the +.Fa db +argument to the other functions. +.Fn dbm_open +returns +.Dv NULL +and sets +.Va errno +if there were any errors. +.Pp +.Fn dbm_close db +closes the database. +.Fn dbm_close +normally returns zero. +.Pp +.Fn dbm_store db key data flags +inserts or replaces an entry in the database. +.Fa flags +is either +.Dv DBM_INSERT +or +.Dv DBM_REPLACE . +If +.Fa flags +is +.Dv DBM_INSERT +and the database already contains an entry for +.Fa key , +that entry is not replaced. +Otherwise the entry is replaced or inserted. +.Fn dbm_store +normally returns returns zero but returns 1 if the entry could not be +inserted (because +.Fa flags +is +.Dv DBM_INSERT , +and an entry with +.Fa key +already exists) or returns -1 and sets +.Va errno +if there were any errors. +.Pp +.Fn dbm_fetch db key +returns +.Dv NULL +or the +.Fa data +corresponding to +.Fa key . +.Pp +.Fn dbm_delete db key +deletes the entry for +.Fa key . +.Fn dbm_delete +normally returns zero but returns 1 if there was no entry with +.Fa key +in the database or returns -1 and sets +.Va errno +if there were any errors. +.Pp +.Fn dbm_firstkey db +returns the first key in the database. +.Fn dbm_nextkey db +returns subsequent keys. +.Fn db_firstkey +must be called before +.Fn dbm_nextkey . +The order in which keys are returned is unspecified and may appear +random. +.Fn dbm_nextkey +returns +.Dv NULL +after all keys have been returned. +.Pp +.Fn dbm_error db +returns the +.Va errno +value of the most recent error. +.Fn dbm_clearerr db +resets this value to 0 and returns 0. +.Pp +.Fn dbm_dirfno db +returns the file descriptor to the database. +.Sh SEE ALSO +.Xr open 2 , +.Xr dbopen 3 , +.Xr hash 3 +.Sh STANDARDS +These functions (except +.Fn dbm_dirfno ) +are included in the +.St -susv2 . diff --git a/share/examples/BSD_daemon/FreeBSD.pfa b/share/examples/BSD_daemon/FreeBSD.pfa new file mode 100644 index 000000000000..bcd7c70aff63 --- /dev/null +++ b/share/examples/BSD_daemon/FreeBSD.pfa @@ -0,0 +1,32 @@ +%!PS-AdobeFont-1.0: (FreeBSD) 001.003 +%$FreeBSD$ +%Created by NRB Systems +10 dict begin +/FontInfo 9 dict dup begin +/version (001.003) readonly def +/FullName (FreeBSD Bold) readonly def +/FamilyName (FreeBSD) readonly def +/Weight (Bold) readonly def +/ItalicAngle 0 def +/isFixedPitch false def +/UnderlinePosition -113 def +/UnderlineThickness 96 def +/Notice (Free font with FreeBSD.) readonly def +end readonly def +/FontName /FreeBSD def +/PaintType 0 def +/FontType 1 def +/FontMatrix [0.001 0 0 0.001 0 0] readonly def +/FontBBox {-167 -236 1410 963 }readonly def +/Encoding StandardEncoding def +currentdict end +currentfile eexec +f0f0f0f011ee838241a0cec525a60ce01562fd01753ef17c08b804c2190d1aa4d3d7a12f3062687674aa2a92cf8242c0f344f7c7ff68f4dfea2890ffb217b7cfa0dc6862b09b5ec7382b9d9919be8dfa2ad48e471b50ed4f50092fd1b56974c018419c73755c5dd5db8b4a67edc9172c690e4d9554f8e038edbdaeca3f244f0f3f6f82fe5413751afdc1ff2ef33bc43f20a9b5db88ca37c067e2579f6237b5a64aff20041d5aa4a925c9f299ba942510249706a455aeb0441beb17ff67c90c618b823b3b9293fe399139c747d6675013b85dd4d7d53e532028c93e07edc9c1735332b79106ae1f6f0a2a421d2a10dfe430cc505331f5285400bac5b960c568e46bc60424cc7556af3ab80eed5068afa949d01aefa15a3635553b4d965c83f5321a0bab542b3ad3f05ca5a4e80771ea7dac758b3fb0281cd6473439050c4f3e7885bcdef7ed3d9be1528d2c035f25cda0ff44ab6d715cfa66af54087cdcc7cbcc8e92b3336acffc0486603c1bed8575b54104fb7aa35a3468aa96e14575833f832bd9c8ac4b41547fd5611878fba5911a73e2d96ed3d59abef1f0a250f0cefcee604733a7f538e5cda3c343401c6ca1bcc4948dd1d4cd045021df7ea5210a5f251a26202a24a16b6ae59ea7ef139883199bd2a490557aa0c2390283e10c826084239c39f6ea1b1e72f374ef7a6ce53480ddb967b2b2324834fe0419ea2c384b5e78ca3cc603cd05e18747fa2ca764904b60244cedc0fa74e54798785f812417c1770b4957ec91a2a25409bdb6f0b0af166f49d28f9c0774a589ba28526bbd0f665c339dd6cdb25e642beb864e1662f9ace50434fb76cd5546a78f8194f802b0ea4ce5f70e3b3dc05f80449b6f10bd78e3fae5a72f5428080e27bc58bc9905b8484973d53e6a6a41e0ca8e436629e4f649775d7e8a0a88c81940e22e332300b9475c66f25369840e0f72cd01c070c8667d5c0f8c8112af0f1aa6db12206b0722787891641c1e727c2e87cc401fa57340ae78e592ad8e2bc3b53657faf641973565fbaf90a44eab3388c0600dbf26a8d3405ec28f0fb9b82a4d3542000663d09224b7796d5881643cfb04bbee1b1c42528bdb2050b07c5a069a38d9dccdede2403dcd9b4573f53c4b37bb400c5f8f09c48e0edf917b1b38ee8871f61f289a4953b529adc4a2215f25770d0a4a2042a0fa54aca3afc4e6d4160ab84621f15c186c054169bcda02740d0a75201a68dc12f774826fe6fecde716fae9aafecbe5a10d0a732027439113c180e348426805353eb7448230c4611b0d0a7420949fb81757802e694b71a36a3f4d7235720d0a20204bf97720c2077fd1f95f57638711e28c333fda3ef2715c3329fc0d0a6b206238bf6952f35dd90c1a82c221915394abc594c83725697b35e3fdb00e6d5249bfe459a56f9b92fa8f0d0a65204b9711ad986dcdad852ce1b3fee159a7bd1bc1b8d4d40f800d0a65209ca7a2e007d4c7baf438865a2e88246978e9b1770d0a7020c396208dc65cb425042298200de19882b5a30db439654e06b1190d0a2020711958391b2c7f46c3adfb6e97b42a679029d8912ad08cc15fbd810215967e4fd40d0a6520fc7afc363bd4fd6bebce2630021597309113785b7dc875a0e71958b00d0a7820cc40b6c2e94a5977ebae9525a0f64d98a0d0401ad315690d4b9f6d550fe60d0a61209db21491114b877e71a69d674a6ea17eb8110d0a6d20289e64fa978047f8bd11704c674e0adf52624a7974f93ead75fc26b7c15ee0ea5b9a3ff90d0a6920ca27e2872590202d9e6e099ea9facbc85ead0964f8b737d0db9a5dc7384f5cbc6d79fe0d0a6e206bcc41e1962873d6c7f74453c82f5f25f7b311683dfd6f145d930d0a69205b0bd00c62cb912b1ce63f83dc6331456da0aeb62bf9f89d2f003cecad652e6d0d0a6e20d5af618d1e41770b42b9a269a587593874c4b35e31e6f1e40c7f0d0a6720714b7e71ab6e47018b51ed68c2bd71e4c491c6c99ebde984af511ec5fe31379ae9ec40920f7e0d0a2020beb1bdde2adef7119a3e9eeea099a51232af8e99613b84d3efeb0ae280268130de65ac30e90d0a6520ea14ee07dbee79a7012a045ff72e07a6aada6252690d0a7620c755ad4338be2fd18651a9d59bcae5b796dd0d0a652034cddd542863a58c6206b1eeaef9ff6645372af3f12872a0d18df926b5c0e69337b68e1bbb0d0a7220edc4e7f756f1d3be73aba324ad4ccdce0cd13f54f0f6fa6cfd46a4849d900d0a79207c571000f99aa9868eadfca224c4256a7cec0d0a2020ceddbb7223bce0d304d061286369a7305c696ae58d19d8317b77dcb77f7619eedabeab560d0a6c208b55bb029cfc67ec7b00cd034d2f82c1d450a5ec384e9b78fa5a7a611d88f9a856e64b0d0a6f20d2f751deba1aeb0a213347487f00081a0c911f1eee6bb7537935a10f4d0d0a772078a005da145704f706e9b46496e6d4530e353e5270d5fa6599b8d532625a2d0d0a20206ef91fbfe46fcb9dcf84d90b96ed207bdde15164357c900c9724010d0a6220681e686171539643482a58049f71949a181fa5e76b01c282fe0d0a69204e253812773456c004e417b9df2607b03971671426567a6aaa2eff0d0a642096817660b4418060acb4d05c25dbf155221dc14f9c9d582ecc0d0a2020401b77185cfecda1a53e81c8846980ec5c1483030f68f5a508330d0a71200f91ce6d9bdea78b2dff4a307354bef1b3f1b828f05bf3cb50c3c6e5f571a5469cd4d86874f0d4020d0a75207e73563dc4e2094c7d30749f93af8ef33485035bd4c4788a6af06a0c0cbae60d0a6f209efdbc6cff3aca5f89463ef6d0cdd24db08ad0716603d80d0a74203c4d00ee3f42b3bb134b62fcd6ca9744270fbe2879fefac07d2da7decbd612e1931ec9198b0d0a6520617f2a7e967646965e5b1ff71f130c31ed8eee2707268900c878160d0a642044af9dd9b1a5673f929db0b130e9f217ed926d3c7739e2ee3d0d0a20204e6bafd2d4e82b074ad64010ef0d1a0c716b559a93ff1f34fd30c6a7ed4b0d0a6620c06cdf04a317aa801a46bca9e0ae096546ea03e3ed75650d0a6f2064675d5c812a37771bb20adcfa37c13eee756870a340c251373f0d0a722020f707cdac1ba6f97723db63fea574cbe1d268bc7ced3522a6031e0d0a20203e442d77f6f3317c610da752063cd81e9dfed1533d2d2e65e322d148dc010d177b13c552efa8389b1af013ebcbff2cf16df3f7322a8a210d0a7a2064aa30c077b23638ccb725d4ab0c34044dee581c375598b6c439a2e90bae42b9102a77305b0d0a6920a28fdc09e4ca1b0f9675755a34d5e82516c126b833389426702996af7158d205862f670d0a6e20238224b151c8f2a2fa481dfdf6327ee29107319d27f74411dbf04b2d213c0d0a63205808f3022b12a49af53e8860eaacba07e9ae56ab54d683c2409564bb0d0a202054832f18a697a20e14fa1570f35ac823df21a5eeba2f510fcbade4fbe09b0d0a6520236c97f67cb16f5ddfc1d597f36e8f834e7fcc4c523d9411aa8091d5b8840d0a74209b6858fe1699fd9be7654683a71df52411e11b9948e08a8d95120d0a63206f111b8a97eb1d4a853769204cb0e85e66c882c0aab0e95e2885e9683ecd0d0a682029e71b2021a94e5bdd6463981c89f3ecdc31ced1210b5f052cec0d0a6920bcb172b7c7994a2095cf040c623904f7532f2e9bac4f5d247ca12e0f53320d0a6e205dcd3a1e9e199c8d90d16426cc72060175b779f7de91ae16475d750d0a6720b62a0b4b00f7d31388b33cae14e14eca3dcf7dc05e387525a1cc57f5487d49230d0a7320775879199c3fe2b076be7853626f8ffe3b37117cd9df45307e3bd40d0a2e20fb4c5d75432834b6bd2a8470fc28d07872f48fed69c952c161e78d92b60d0a2020f30a96881a9f8578430ffe17198f61b19cb6c0d61eadf947422dc17116fb0d0a4a20705c2c50d222e0f0708be5292433ccdcc16facbc63298523e06a0d0a75209749d4125822a56a992e6f5ec0c552439fc2e9f2adb1ee82359d110d0a73207590a638f70ae3b506f1f32ad76bed42d978a47b6b18bf044389c3a82e0879c50d0a7420b985b62542b9d3e4407c96840957e36a27e1e0990a63dfed6d0d0a2020b2cfba0c9408786d9eecd33897a2efe1d3ce7310630d01c326dc041bfc4ef4c0e9650d0a6b20db3c72d9c54a158d0f1ca934928ed76911c7c46ceaf94cf4ba24fd9579482aba98160d0a6520415f99b810ce393c53f0576ccb3a9636b29e7b01a6e258d28d885ea9330568e486db0d0a6520b9e74020f8363590ddb460084a67efe6eab1bab95a33180b0aebe5cfe6f77353b0780d0a7020f729a94c445f285cf40dc3c8276325ce6eeba334e42e05c376cc230448c72fb8cd0f0d0a202036249a76565ab7b261fb1af10ac8db6380dd6d146116acef6302e40ad309b8f2973ab871820d0a65203c2af0303b49f5b8013486e63805c16af5cbe8b1a574bb0d0a782050069303613b18697460a67772278c68c7caa60c3a169ef902f42b299118f95ac90d0a6120375c5338d58fc253b045a426a8c15ae4cfe14d7ad4f72a7be90332536712c259fe6777d60d0a6d20cd106f121b002f9ee47af6b37f6befbcdc93093ac6516f43e6c280fdde30941fe8cbd37e0d0a6920cebeb84dc4505d5a811722b5af2d0609b888cf8adc8e402f8a7548ae2717694177f8fdd40d0a6e20d8cf4836f492ca7f8c8cfc43a6f6081ee0a2d9e59a4a3b90ee6ad37be7f2e2b0ad90ec600d0a692075dc3ce64ef0cb4913e9167fd54b8ecc37eaf5f56c8b079945873eddd60d0a6e206b037f2573baa6c8687aee0bd2fb6d547ed3d559049ed04c64151184db0d0a6720b419249d4614a01a57524e2b163ac9894c524d7abead0ad5e00b395fbe0d0a2020e72499b2b9ad2575c7429be917246d4c8c41d27cd8ffe37c47987a445a0d0a65202f4f07ee4d49d554f3e75180b0f8c99ea6e6074df497a0a78c628fb8104b5cbfb20ce20d0a7620d5ce376f1995cca71984202c6ff0d58f7b27354234dee2c2587b4f6fb4beff43a9e26c290d0a652044a84169c41a31436886ed52cefd2b2e09eef40671adf319aa50f05d76fc79eeddd98b550d0a72202a4ba5beb4aba03e5bd7dabef1e75cba34bb5739e1deff4db50714e34feb33ace1eb3e340d0a7920cab3c3192a3236c0265f1b2b02d50df6c80ca1c15a096749f478b3b69a5b56e8b4c75eb70d0a20205cbaab4ffda32a87348bf3d85f168ad49171edb42a4bc5d8ccbb2812e2699c9b20a80b440d0a6c20937dbc6457ad6302e87945148cf96df25b01c042c98a8f7c911b616de1c9280bdeb064bb5e0d0a6f2096153950a73c0dc0c9956c0046d8422a41a6d2305b2e4947877eb1f3ac4d8a8f26a262ae0e0d0a7720e6a03e3d2cae6fc6200e53a0d4d5c0b0940737aceb48e6f7656db91671360d0a2020a8e8be9c80d64a1c12f01f591763f16fe1d94057dc01a0e23fa20d0a6220c9c050dd5f91c2bdbc4c188092d603730e6a7b729380bef8aaed7ade46b227a0c18d0d0a6920ebbf9670981bbb142957ae40a1dec346201908a1cfc28178b036ac8106a2a6ff81dcf0f7022c0d0a642085a7defa9a767cde5e1b2e9b6b52f036404675bbee155e86f09efa9f768e20c425b7ee1d90b00d0a2020028887e96da15a4529efdb2e203788196ddb821f2d44f5afac1cc00f6cb39226bf15091c9b890d0a71209a592827dbb280c2cb90df58e318ac0a183f0f6ef54f5687ce3fbe72992d996ee766b490133d0d0a7520b8aeeb47e68d9e5edcbe7652c21f1a2e2960392a61656397f0fb0d9f6d1d84049b6e0c091a7a0d0a6f2024624a82df9ad6a43434dc7510d3aba86dcfb98dc8888051eda7c92639d3c027920d0a742039d54073eb456a2c3b4984d3ae8d72560247b4d041902fe70e9da0e045cb80270d0a6520ff501dc22e9344f07fc5f7f4a698f82fc1672593365bd95d620ca9436fd81908a37d12f2c862270d0a6420ef494b5976d137e30d5fffa04705f470f48236ef3e0ea8446be6f8bc46ad9f076493dad0dc4fc1e20d0a20201e3aea24f0ab348f8c0513078e0ff81937678bf61595b5efc3a96e559d73541805da9d82d32b76d80d0a66209f400278ddd1f549e7e55e24848252393f0e66eaad40a59afe302efdc971e3d23ffc0e262debd6430d0a6f20028595d51f8b68f2ef83ce2cc8900d6346957b84caa3790981f852daa01d0d0a722037a2a4b7b5f6560384c5ae4271ca953316830481497f215d5f584d1370dd0d0a2020b4cbb202c5a9606050b8e064a4db8f69d76c3bbb41ec4ce53ed9625ef5cc0d0a7a20a83eab5609873ca3614858f9fcf642b945a85944a0248f31839e4a5f752e0d0a69200dd663a24042f0a6a6618b7b3f1d4a55272712d7dee63c22ce05df489428421c0106de0d0a6e2070ac1208aaf2ebed0819e8cca4daf7d623eab02132ab246522eec2280d0a6320d670756672aa7826ca4b637d403806bcdf318e6fae0c263d604e0d0a202085e153ba77648acfdc241096ecbe085932da2d3f540a8f49487216d483d86ae791ee5762020d0a652057dbcfad9c4e6f45cb6aca49bfb8afe9ec89c1af2133a00a362456fc9034adaffb95c829ba0d0a7420a7d20fd33af595b94d5616ef95bc08cfaf8f2ced5734080b57e132599d7f1d39ecae014c260d0a63203e2864fc552f48c4cf532630fe186f67ed5fbe644c10a722a014371dc44607bc8b9476d0630d0a682090db3f64fcf979f22fbf341a53ba241fc311c95dfd27aec3abc7b173aca6d6269dcb0489100d0a692031709c8432a44e1f158fdbbe7b328d31e19e9357ad63f032ae8668dfba741f0d0a6e20488e0f642668a35505017f8190b7e53d1ff320ebf19bd44dfae5dc9a7404930d0a6720de728173e284bd4618d916a30ec7084a0282e85fe32f98480d0a7320ed2b5cf2e589a14f0b4d9316e882c1d449cb46ee4e8a5542a96df79ed2c0e70d0a2e20be7c05bd4057c32eb1770df804f83e7c0f58421a0c367b7bd67e5f88d8ab730d0a2020a7cddc1c77ce5d83ee6af31befb5c5f4ae737ed9ad6445d20d0a4a20d48e8e8a4659250cdb50be64b2c7f710232e7e9df8620a41dfbeaf485f34f8970d0a7520f8b5fe2a8f5264a3c3a397d74dbd95cb51be7ff107e4c4641db7ca0e55abacca0d0a7320077fde251da7ec82e1f5ce6a4a9d6548d87316170a909c01cf4bbe1260b6a5a40d0a7420925c5ceed7d521a7841d140ad73e199ee437fb9426b3e0b0da099434d7fe957deee67f726c9f052d0d0a2020332781d61f01f6e6874f88c6135b4aa8db2d6abfef53638c065ef056061afe58389ea9000334d2130d0a6b20dafd87cb69dda55ab7d32c1133f8e1545359fca44a65a4d2fbf20e0d0a6520ff4ae7a28a5ed011c877bb0b175ea87dd3836d107d823e3385aad19f4e0d0a652016054f393dbb34ff565e188a64d400ba670a5110d8770d968df2720730b79153b07236eaf2b2df72a23802616dfc31696051edf2a7e602d3b466dab1190cf5bf869e0ceff0280d0d0a5420f69e6b0a456124addb2cf41806cc9d8a1180cf082ed0990d0a68204292ebee557183698938fcaae5b83a1764c38e76e9e093bb6c5b04b4902c945c55df64937da01e133549bb496aa04191cd3a9d66bd71a5e2da79657af875ebf7508146f47789836cf1a823b63cf314c295799f11430287f9d6c72df4f75b35fe1821397770ecb7c62a28ea0d0a65208c4ea4caf3776d82c6fdec9eacfcc6e7ea62639d0f71d6298cf233f92930aaa0c6efa85ecd563ca9da6f24db43f71669fd2a9dc30cda309933b569369ac51fa462badf760d0a202045c24f0e039f0f6573d84589510a36a00cab6fa1282c09c905d0bed077bc783f4d42d00cccce6cc4516f621e28d70e50e21ab052891ad25eea6eeede07f82a3c71bdb3bd147aaab617a6773542bb247a89fa01717cd2754ebba640da94964d6c521ed65aa1e4d6b7d63a53f1fe0141fb5efa5b1a3700d9c78be08c5fa7a6457a913e07f51e686b59c1518071b79d58b46de5e1a6039ce3965ef4132ce90865160d0a6d2029c38412a72b52bfa82fdd33b56b4848735d96cae2eb409c2b7b58dfada1766b7068178dbcc71e9fd96877e02452e4b1f774da425bafe6f89b7ea5684f3a2905f2ca3c5d98ccc3891420f4ead0d985ef232b880fda400151d484d86b6e0ca41938e3455d14e797ab2a66060a0838f51d6025020d4414d939d13418f0951eca9802f11ab7da52ef7474f515bfe73f578edcc1ad33562d05b7cc11517fe238556b0809c9af560938dbed27b6ccf33ba4e3f973e53292c8742999b955e0c9d6102f0d0a61204d8d9924fca6d40b7b9c35b9adb0b41dc10a4f750a36f1fa13aa8bcc624d2bc0a6e391a2b8541f5976bd95dca3dcbdbf0c72af08cc632efa811bc7945ca6073cd236af52aef868bae1f521e0d0633f6e813b59ed2479a8b9d748ccdab92cd5f92f1ceef0e96d6b84f4593168b750b73dafd419d087c62355bad1965be357d8bfc5275ebf360565a8edfcaf28e26ed7605b146a27d4594ef8f6f66e1e146679f484b4e3a40faeb10893db86c810a62dc3241612720e49edc5de5257780d0a69200b2379c14c4a8ae0c4a18aeaf1394b6fb6beae15d7ced918e24632482c9ce8a6a2b3b5c93b75fb3f66995a865d1445473dae7f6b6c500bb3bc48fd5cb02f2e9057005c82d1fe9faf70c51d2f994102ed725ab12512dd159ff947cd7113f2b048a6aecc846a3b2f43ff4c0b9e0fef72026196e3beffd11aa00922aed7e4567d22326a8a42c915aec64c85846f624dd227908d5b51d60c2f07dd720d4bceae7241729ed797b9bdb3c6f49058c1713612886def731a2e3c8e024705707937a19bcbf4f19e6cbab387f03ea32be529afb285706aca103a0d0a6e2052d47eeb2892d03c2a271f5c0653c010fa4e0188739295b39b2dc4ff05414f68068c109a988a506ecd91b4e9212797bb0d0a2020501ec10488391a2f7579465405dfca54b3c9e017ceeb6a3b12c25bd198afdbe88409e807df692d5955dab71b044fa8e9137e62ba4b7bfd9b2eeca5afe3f9ad28246b74b006ab41f590365155dd41c0656c4a4c8a50837b2d55996f60a11b850d0a61205b433512163a92c04c0012c2062ce734bca8dfc56096f34fe215786e28b897423a24dd6c3ab9550140c814b1c1ebb1b208c6d5c37e6888546af8cbe0f6b968c2c12dcff5404f8760614189fb731d55a89c2e7c1f24d16e4f4cb1a11235280d0a6420b2535c884be264b645c6c83af14749bf58372d5eec3a10f2e9f84ffd8f130ec429cc0f0d68309a771e9846f8ee78bb586c6478064d65155458a77d9bb8e6b75a727c9fa109955da6541950d1cd79873879acc79879266f64aba43f5a5d5e9cfc69bc400e173e206c33b1f206112701c57326d1e79def9c03f80d0a7620fa1fd7dfe04cb709fc4da7e35032e4d32db2140c8caddbc28c8498d840bab6b47c42ed8141a599bd95e5d19e5c94a959b1f17faefeac50f09952306fedd5a197d9990dd9b40d0a6120a6a313f738bddc30c0a1b117153f685258a87b83c798b5758ad94d4b2165da94ace23605ec7e5fa7341c50d3987226b7d5b66932ac28af6569c64b9cb8c495d2c5a00218cb9944962e0d0a6e202320bf2038fd3a186b6724f4dd1d5f6a3d592c00e70cd24a999c15703c9f52d0bd8b613428376e16f86d69541a27d6670d0a7420ff870c92b8e58e12f8bb83fdcc2984eb7c339c19145c5fbbf002386dd3f65f81254f31fb8635578b79266b08391191249c93e2ceac0d0a61209be4f9b198830b431b2657b211b470e2c5c869f2af5dec7363279024ed7795a7fa93f25d8aebc395dd3178b30ec3f00013bf0d0a6720f2fe0b0e82b8731889a4f1574470989c6125e932e1a6617045b6b36a4555136d32e389301b6a31d04c4ce58c83dbc881f70376b66ba213afd65e609a3e2985907e7ec38cd42fe431f84e2473492ee38d9331101cdf9f58cf7066413059cae726ea13e021ed660d0a6520e2e86c939cc58cbdc7f45f5597d1efa2a17587d06c95bcfa96d2ee0a0d72f0c7b9a6b45eee1da7cd1319bf8471d2e90d0a7320ff3bbf9a4d7ed10415a353c252e8a762687439500b2d13c0b0c7d04934332404163b1d89264f340bf1ba2f6adc50f8e5aa2c6a9c3fcf2bb2a55ec888ca10b8931b782eefc957c86b33ed68854ce4265f1ddcf2123c6109450ae17f5038d88531ff601db30d0a20202f95dfca5f7e4b8854fe2227100e2b91e80595dc147e8e095e9adf380fdc70e240e90fd7fa27c62c9e0b386ab458dcf4fce9197f6c22ebb1c342397e0eba1f82bd23b8ffc7e1d468e5dfd664b455dd2dc468b04c787dc725f11d29a41db99d8c003f873c01bc463b8b515298f3840d9299a5b257c2e35bf1bbd995cf004b54ecab22a41552c07117d70d0a6f2011b08bdaed6101ef6d0541d189e0ed88d188840db164d9e58e464ed904970ca81fb89b401a5ae830ec595bd7ad8f13e7a9400e3730ee72b8a5748ba72a090780fde5cbcee46b1c20d93190e51e4936514aa12b2f6086180f110d0a662053aa125db3464ae890fbd4843177c43d93460be33a42bedd50b214f6cb4371176c86209fdc3b9795e74f3b350389538db53c8a908db5ac0d6293752e80d49e935ee8dee4bdb66dbf2d844cb22f62451d3ce669e2623bc7e3a039aeea8cfc86f9169721f6929b6346ae14336abd78841c182d26e160e65d0d0a2020bfbc006e4f845c4f2fcf482e4b28e09fd20e2fee0855d6f6448d9362fcd8f896c8d7badda6d5551f3beea144619b5114fcd127b90a6c348bff10f5a0d7989ddcadf40211557114da12d742bff155ae56c0374ee92d2a1f5ae0e61c9f74fc7c62915b1d289687b6be28ac3ff81275ad56ec080520642f310ca9d8fde025a33ddb021a40b44a0d0a6120d5eb639120cb3b060782a0e95b5fea2d7354d6ffa0044df25a0b7e1ffc5693a2b472c762937b12ed5a93a61557afd2f75d43bff12f88801b23ba424ace821d0d0a202050084cf2ab7a590434882bc714cbc1d254175c60ee807f4b80302a948a720bb787d8d82c7747e6420a84e0fa62cc528a70c182802d293c3872275559661852b533e336805a0ddbd98ea554188eb529d2395641fe1c6ddd9fa9076e0fb3b91b8bc6a0457f05ac678ef32d24d6fac7461aca7d3a32f65457c34395a93fc87dc1b4336007f60e264400e76a93154928b65a6698f824d9eb596061fb1e5ffbdf2a5b52e3fcdd84cd735ef7591691d2db518d010d0a6420276acc70e256104396fe961964d62830e6aaee75da7ae9a71e26a264c26df317644afc91920d46b146bbe440e7db0dc7bcac65a5c16ace7a7ff23e37045b36f9d83d6a46457c4b30f5d365a274e35aad051873138ef50861d18c2d9eb5fb294f3a85d2c2b483e7557cb2b7f2f7ffbd4a651b5cddd277ec66f5404e87c2fad4e8c442f9c4c00d0a6920ab28736f70f02d27ee108fe3e752c846dfec15ee4e8d7b73278d96141f625dd76f0fc148ef06f9b4ae4ed971a255dcf8ecf0260a64586d781b25836a620dddf7817a773dd8484f7263564c48b091ffaf9d7f52e1c1d20d0a6720729021fa1722d3b929b88b76b787577c4eb52e5f704649053763dbbea06cb0036a0cc70514ebcbbb4a595380f7ab7a8211ed0cb3430a1230d896e0219fe9087d0c6c5e94da4bba82ddbd012291bcfd1b3f8f9dbd85a0a646952d24a64dc1ec3d0cc1cfcf0d0a6920b562ff2484e0f03dc0754dcbd4ad92cabcb3056ea49b639a76df7fe06dd4d8d20236b7001d9b398ee5e96627d39e45f8cf29b2a4721e50880de18af3871a6801020d0a7420ba5afa2d563accb973b7b5b5e9dbec290678a21ad7a75f13ed0e1089f129cd4b788f262242c703df0f7dcc6748404647e026411143e8f08d0ad5742c7941a9c9a40d0a6120ed61c4724be086144cd4394127879f18f6c3ae2a1517a18745a567d4df32a9fa0abb2d2377b69cda25eedc22bce867e7332502658cb298e481b7ddbff2f32ee884540d0a6c20afc1d7dcb2a7473bf006ac50f8788def7d188ff00c9e0360baa6245d73ad42db74a2706558bea5733707a718cd550c38d4c5dbc4c39543ad5bb1e1a58d5049d551a5c11279ec0d0ad893162ac5c51a74c2aa410f25b3feec0dfce33dc9366ffd3c4f47f6bcb8195bab6a4212b9532f973dee1d720a6f390478167d3bfa8601960fe0f453e08cfbf00d0a202038f7859cb5cc0bb441658695df18d5109589d4423e0ef71a00be32ca90fc255197848065d87c566caa01446bb4f4c65a523f8fec878f72106d9505800c028818bc0c099f9f1755728a3a29ae6b7371b21011d5ac6a0e2ed6a4ee5a559433f9ccbe300d2eb0dd3a9fa602d5a7726ab1df0b917ab399829469938d98bd0cc0d3e82a6c898d61e5a67b04abc2e324031738db2280727242a1a3d8b383743a3da83d94e1a5a14a8ffb4386d900be9868150b1f528f0002b8006f20423ce5b2c6aca801a8507322e5171dd9d3996f6f88275306f6706b70f210f45fa76043ba1af53f0e09f28e77d2db6aa1aaade541611bf9d1b612c89cf9a529e48f9229f850735c542f414c388d54f605ecc00b582f30c6df0d0a64207918079bd8033c5c6d88858dc110c6ddcdc4d515f9961c1a9f54a5b653eb1b4640b5cc2a7af730f4db53be1f8ecaa4d7c992cfa79172f8601625a79ca7ca309593bae51037ce07ce87044bd4c152414be99bb4116c0d0a6120c926c4b086ef2dff3c38b15ea858c758ae3dd38dea8d1fac44270fa7354ccf2708f2b8ec1d9a93f446e64c466f371aea6cf60c298a0a5bb4c888b01d33b6d4b2ac7508ae2c591ed624618151d589436777c19183f0e95abfd92c927a266e4757764568d716826d2c6a7d260ebb3ce4817f7c5020596ef54469a6a42fbb0d5046d4a333a00a763d99e2ee37965b3505ddbe0d0a74208e29ab773e3d625ec81ab4acd1b46a6a7cadd8d6ffa6660895bc825f8594063e5ca6bbb33eeb90698c3ce1d826b81fd361f6e6616c516fc8966cbc0134dce50bffd9503438bf81328704d9ad1c884ed223bb8f790c8393f978aa69c291e5035c9d9aa548772a8d012b7f858600c70d0a6120d50c8e685776c6c46f551900090a66a26ca0d1daf761ac6b96215dcc4d850c134d2fcd13f500f9e22a4695bc8d819ae8ee078dc70d42a2b6d10b5e2d92474ebfac22748d49f59ebeea6928cba19942cd1cc85a57b146ebdc50cb1c2a778ec08d314e94e90c2701c4ccd931490d0a2020c9398326471525c772bd912fe207caa074ee330f83c1e6f76290c70a98b29ea35b49b743dfb6ca74a31d65c4c42b0fbff46027941542885b22ca577e65238bb91c663c55e74007df616fa00d0a7320158b710b661e877329726b8c71527e3e28e52bf13f2e25f176ab5bc34f228ca4ed007c8c80adb5b4aaa80868cc3bd07132b4e88d15fa6e26c6b26e3d73753447accf34c3400d0a742048f70c877e5040fa8798518637ba040cc17effe536ca576cf71f7ed2f69365a980052d57772af07d48c551fc328729e8b5764a9331eeaea9d562c09b2f709fc372eaac3a874c9b4a9869f865ffd6b094147ff1214e3f7111ff408dd4eef6b28b3eafc5b5289083341a0b8987ff0e527ee7487a95ab3800ccf3efb2be480bb726d61e550d0a722062cc68235cb0ccb2103491922cf5cf1198c62fabb39507932ce4adc3bb98e129616027b7d7a562d6a89605c7fec45423515211da7426abcadef59c16cef33215a2ae407623b1969597bc310080cd0d0a652052946808d22f61742b7f8f277dcac79c497e655f8512203f56f054bc0db2e642ad43a1385c717099d9ec60160d0a612075862a576494ff79ba653eec778ad0cf0cb071ed87b7acbafea90c113536a3cca3c99f8b17c997960a5c8defda1d972cd21b46e554f96bad17cc22f42736a00d0a6d200184707d3aa2901b59336c71276dbbd599db6d5b3a4849300cfed57cf370be84c240114e1ec05d620a6b8e98942985575e0f5bf27a1b904f9b99a40d875e1797d1f3e54c13ef1b88970d0a20204956b8172c834398f56760c11531331fb876a0f1a5a3e3bd29a76bc26a16370d8deb3ad404c404544e752b046f2a4787386ccd0d0a6120a99b45f0f43139aa5e003337b4d211e0840b57fd4af34474247494dd02f8441d6c7ada218bc380450b3fb9abf5dcaeb4613eba492ab55d854a165027f6ff35ef7446d5a886605d57fd7987993422a5eaa00d0a722024bfde2ccbad9d06af42a88a77bb97c490d4ea880c9284b014f9ccb55a442c301b42abf2878780cef0096d021c323273f9ca91da60549e8a93f99b12b20c578f7250d29a545c674a73b8b7860d0a652032bcb294bb63f24cf1e31bb163ebc4cdaea3586a2d915e9502d732c25c2fe738c4456c77d1f4530c1613bd7595d3583bc971731c39d0924d7887ea75ec4848e49fa8afe410ff02e9f751ef1234b3414b0f8a4aab4ab6859418b0c6919109fc8a8583ac1b89afa01ab6536b9cb3a5fe37b8bd930fc34365580fe15e73d81df053016cbc620d0a202021fadd888abb83894fbb84707e333a6af2447302c3ace25d1eb8cc379a705ba8add551815117bd632983bd4f43c694768e661da35e88c29c688445c91652c1d9ffaa9f3658df567332c7c531a0074a56ee635c74a8e1db9fea90af489f03f90d0a63208488f03d3eb6c514fa3d94066ab684f260cca5506f4d7f99c599536bb5c242f38ed97f209c1b52845872249d80e337c73dec051137bf0e2741a4d4a4af4dd387d22d69e2f7cc1cc91f6ba1d334b8a8923c67491d69f60460c8b0791a314fa5dfc25c1b54c031095a8234b36589d0a7ad317952f78857cf2323e7cd53ff61dac3e7d8a00bd9e6c3333009e22da75410121a62c9945e91655bda6dd76eb1acc00d0a6c200415be4058093de9aa2316cceed4e1e31f33b352df0f3a5665e4b82a18ed60711eeb3a0ca53a942ace3aaafaee9ec442cd4549c0779dbb354a10c3882bed259c749b268e7028d21fbc13bf9464541edd8d7c960617303c1648dc28e63e665a6671885a136b67fdf2ba67f3a50e806d9a53f0ccbb7f7225aaad5838f4d4f30d0a61207e720f01fc9c5f0fa38d35a1063bfd5127fb36de943cc5d0e3cbcd3d617ba56369e49f49bb240cd65bd20894e7bc3115035a2009f5d3ac1efef14a4ba758d2f78854eb2ae878a4c8be93583f800f49238ce507c75d51a708ab4484f765ba416571abc98fb038e03556aa19cb30ccaf803ae0332eef25df23eb4306452a4e92ef530b4968ab7e1f3b0d0a7220cb744f6b008094d69881af23c7e33d3506a3405a20487d17aa51a679cf734f91aea14a5a7c1a0337878dc28d06130f795d52822f715d5986f0126a0d0a692024f94ea80b80b9fbc33778f8bc82cb60a5c6892edb8102041ab3ea236692e1583709f096f18a4a1e8e8e534ba1c1908a5ccdfb588e080a239212eeff33ca0763a0183be73ea3d8bb9d62303e7bf49fbf593d719863f52d09cd85a90d0a74208d3ebe4fddd8dd9979094c906c85a5a96cb240e5be6c36a9e3de5768c0dbede0707ad6ea1df5c8f907f1d65982a3b9b8d1c20ac781c2f9198dcee68bfa77530d0a79200c3ab52318b338558f737e0a14283d4a08c2c0e9745f46cb57f1d7e68057543175dbeccaab8de82a8983fc48231a97f761edff290046a58dcfa5b78d912702778b6300954f5500f2544c48654170300f82be7254dc152b2c0d0a2c2031804cffee53e36ef173067f30170bf95a73096321d91ff86b303303b8875394d480710dbf8269e74adb8830380c53aea2caa50039b6a3cbc10bfaed05bd67b186d9c3ebcdcb619a571c6504ac3b2a29439fdc8f0d0a2020c6699929db1bb745c643eff9f51e8f65ec5f211c70e713228df39295dbe2ca9c2efecaab338d77095a081ace85fc72cb444e8e0d9fc1ae30fab92dcef43e8445f108eddb1b0d0a7220ecf1826f5d96c901c62726d9e141eeff8a2a410dab110a6286aaa706a5f53ec1f0168d69f3e6168ca9527cd3f2068abb5138c96540981bfde3a2581e7fd2e2b273241e2f44b4d6e40d0a6520d00509576abd328e2e715698997ab82b6070fbc94ce9d17921d57ad65684f5bdff26ff0d7e10b3a9728c3588f2d7f4975d83d852133b1dbc21ce46c9a1085d6e805a23070d0a6120ae79995e1ca0a1a0008d34a50b9f28bbb37ec71b32bce14bb0af83a919abe1fafb54c24e42800b8046e13f909ea588a3336a296cd7171bd9aa0d0a642017ea3593bcd590f325779a69e597a4c7ab9b8030ee4714578470a4b7085e8dbae56031b94cef069855a3a4b86d5965ac1e1f1fd81c9d481e3cddeaaf1d3e2d2a12b39e0de7417f26090d0a61202ad7433c150e0613d7d5067ca205502505663f5bf781037e42ea9c649962225173bb20819df4b984205ad6359ce4d7e7937c4a1fae3859a5c13decdff428a794800fb0fdec62467e0d0a6220ce16e26b0aad61c694c26178a2cc086c249b609595ac2834233cb27e92c9c7146f44ca4e557533bf99ca64a80d0a69200202da67e274a694c6202b46d601e79ed784bfa7c3d068ba44d23a6c4821d659e9346760c73cc2a8bd502ebb6b3274d5cd2d0d0a6c20e87a875e9e430ca30e536d2db39f665f9b07cfcfb7a64456e7c72c5bc49893fe86a29be8ff769cdc0d1f8dc1a366fc407ba65d1222e6d4e316d853c02770d2e7a7d71204827690429c0facd704145d445206b597a503c4c77181e2e05d82b92b2d9f7fadd14af71ffa2eb684eac3b6596e30c9e9a5d855a6d66ff074651ca4d411ea97756338e5f7171a12497fc9b5e023a88723fd17fae998be0ddbd3960d0a69201048b3cc3544e7ac0fc23ecb356de1a4369050c5f0e0b20b127fa3cfd99e4f64ba775987a6c5aba8cf032ec1dda95ef0758f81e5b4c19e252285b62b89e4077c033a90fd5cadb5d9515de054d94a941d8cbe15d8ba19b7ee99c7f21ce7d080e010aa7ea3590a0b19320e0eb3ee52466d0d0a74201c64f425bb2169df311a2f5597270edf99ca9649e0e7b309d11a30647342f61aaf5293858da0bf69b3279470faf7267088b9914ce3dfe9b24eb9196f0f18cc91b9c3559555c48510971ffe8a7b8ef129a01829d8dce55afd03b470e6ab06e89b0d0a79209083a1c2bdf8e16aa3165c310cfbbecaf18b5fa1eba09f16cc06358001374bb3b3ee06af037d43421e99a19d33ba4088ba999c8cd207a74c737bf32490902b7730ce78b4ca848dc2534277781312298eb0e2f2887747195363b57fb951429bcd95888ffce4359a5cb9ae6a8b7ecd6ee67a4935974ced934d36d52333553cd08c3570c3f68c1da63a495464ebdb1f0d0a202003e91a62346717298bff3cbdf1ecc18a9e53867aeb9b9f19106fc20b843836e419e299f98a3c9ce0d93084d90d7aa8cdc81fa25766a17b659aa2e52985ab19c99322483d840c04d6c2d029195c235af6fe0771e7df0899b84968a861e0f150fd62b31f02a8891464fb126177223c0c93b27d15d6c70d0a6120252fbc5de63dc9375766a4b2073005eadf1995705bfb3d7de706ce838e1540ebb4a25c989990f0b41ffa7909f10fe3e0d90f99082543bd7341d812a413a6bd015bf2ca372f9070f5e18d7e009847e3cf514bc9abefb147567c2703370d0a6e2020a8d4ac234409caa1c9d598dd328e229bd10365903a7504cd8997b23dcd06e503468ef2115e7ba397ddcc82ad81d267a8ed08ca80ca7b7b3cc1a3f4ca12d572d9e4a32c2ad17550efd3ce38e840bf1dd736c25bbf8ae87dad30018040bf4bc6575b26b2775b28d7d722d5f293bc856cfd437bcec2023907e8dba2f02ae69261ecc065397d1768acfea754bd351e55d3cbf3cd3b76271636e173359da81b0aa4e7b1716e2321c49a800ee30a3537533cec680c3030292128152da97e2c9757834c1c04fb21152fe267803685abca8839bd9b5dc81527b90d0a642088b4640b8a707a89ac671452912fbe5cab38fd866fc1fceea9232f739bdc46eb3123fde09cf62d45c8bafebed615057d1d6c74eaa8ff08e2bc7da50dd88462e13986493974fbb6446ea692e364208675f8f2ab161c73469dd7f60d0a2020fdd0622da8333890bcfad4720eed78eac5861fbcf77b270595c1e30d49d86599910d7fc96a369a14ec23aa1ea6c4f6431175fe792ee93e48f6c279dc3aa3152113b0c16134872cb1c1a7e9460d0a652096e05b928c62d916ace0271d7328a119fe165496ca0cfb3ed544864093cfcd48e53ad5c2ebfd70fa4dc9269f2087a43052f2e93fb122d9d4fc0dad4e6c98c8bc9d40831497b059fbc98b9fb37314ab6589c45a4edab176f362cc6ce5caa30d0a61201b2067c0706ade699715ae36027e3812c721b10a3c54d05af56f6f6c9136e8cab69b1d268649baa4f97ed3cea1ae8b96400d797cb9e391931189c607a9f653b10058773a3c4a7f4ba5af600c4ded0d0a7320080bbef2729d0dd4bdaca4c6f133545062f55e3abd13c04924dcd0614e7bdd1c99eac038a1f0ae7fa0789b74a80d0a652025a9ba65e4484c4ca9261b30a5d0d2c9581ecde45ee60fe6819920556e46d449d281acf686d4bf3ee16091d3b3d5e4dbe82307044006938d43b84e4bdfa4c8746e1ad97dcc9ae61c95b3bbb47fc4ccd06ee15c04f0091998b1a176d8c8181a435b05465469d4d1334aa28af892d28569afe26c02228a52a59a0bed56d76c87446fe27139d732d993e487df38e40d0a20205d1c4ae4d90b7576d6f5dfd6cf58a2b23aba655c320cf8ab28506e3b0277f054cd77ef6540b5f09bfe59e8a52d4c2432db40b23dd93b506c897249f08488994985b720eeb7458e268366eeb89b2f9c7b457a80cc99b0c91788c3712579e04b874eff0f41bf0d0a6f20cecf59d0237445adef1e61090a1c63533780e25f252998333986c0a7f44eb262c7767f28fc41a51856b360e724973c3f0a8c70b4c24e6933eecb17240a1ca579e803391ccd01a304c17595e27df95a8251d1a57a467ea7eb1ea6117d660d0a66202dedf71f7a6457cca206d9d9f8198119acaedc29a521ea4a25509ac49ebb93cb17ed252097ea4083a01907175923d0616bcbd57f31fed51c0b68534f06840707265caf28798a70fb9f8eb82bb703ebdcceaa210eacacb6f847bcfd1420ee66a87a8c251e00dec80ea4183c1cbb14a430a97fcc6f45cd091d9e76b4bedb4660c476c8748a150cef520d0a2020687b4b93f6c1a7361ae79e082698197fe451fcb7c3e08b7cd645b82a8b7d2464e29a69f95b476c92fabf4b9aecf1a305dd94b90d1fc71b1632506572eb2a7209ea4b10fb3e55ef63f79b947980d02cc219de590e0f1d171a88cfdaa8213868cdeafb6b2c7dc5f8974c8039fc841ae34de1108966a0a6f33273018d307d81ccb3e650509fb60d0a752068e1658613d75b5c49086484aa8f476276daa4cf09ca2d2eec45a333340cd3a3aa712ef4b4e82de51e1aeeb207687a3aec203dc2af65e610010038ba92579ac4c61f36e3e5d3a914ff6befce08ad736486b87501b6f0b5d4d9669da9e829bdf6220d0a6e206c46d50506eac42ad6b3196d0d0e04ab75df8bb59984fdede47f75cb94a96497502a7ab6ce82175b56598bf7ebdef99680eeebee4c9cbd9cd1dbc1ba6f682ac8891d84d068453dd95a32d1f8ee714e9fe588890687ee061ae65cdbff7e8bb6947c8e63c5376e8e0673c7a5aa9e5315c952610a32a7ffe6e3260d0a642086a9ad508b454d43295a12c340b3839c5c19061fd89e245acd14492ad55df9f27214907a5a2fba2932fa1023ee8fe2edef76c89642ee24aaf2e9048039eaafb17e549de90586848ae39ba3095c9e75583b1a45fd8cbd46606be46e7e210d0a6520d5cbc5f346e18c96491593531b24894075e56e80a05ecfebe0d1d35dcc0c587a4dd451b73d9740ecd10794be5b371ea9d23639fd756bc7578c064e73bda35d2faf544cc3602f0071ae637bf000b73b28e36127465780f78de0c9d9e247864b66c94e840d0a7220b383911d102ca8b133cf60788955143b1a22ba5cd4aeadac73f40776e5e8543138db4f5b0c59e9d5896d12f8c1a139f0ddaa8c4536d66274c55d5519590d0a73205c7f46b8618dc52191ccd43a56ec9cbfbb35345acc94b172c888d79b7b967bb9ab7df03f7f2242a6670b50fbc8ffb4270b772978ecdfb6554242b34d13295aa433dccf35ceb9ae1bcfcb9b0eb701393cf2c2f4870d0a74205e256914c56201bade90466be9a34e8fb97025e744f29e9f661029af0037ec83208571ae9d13c9666cda67692fa88a5d89ecc934e346760f96b9f081b03a8134980e6a60761224df65b7944e538eefba0d0a6120157b667be8e539a57b7a29dad22480022634a628d5bc33d6bf91186ee569af513cf20228187ebdea378e780498e0e0f4d6f632c7c0b0e57910d0c955653de703e65b9ba0d70d0a6e2010dd198922365136f8c873a18a504077cc2c5ec6448c8f5bdc89907f0df22ac6375c84fd07936a02032874ef78bda9c29706131e1bacecadf889139a98965a7b787b492b50f8b70d0a6420b792faa3ff43a09849069c6a22dcf047b34f696e790483a88b0ca602b91ebb172a1ec56c4a3aef090a58f5859fc5a4c91fa7d9eccf7a228fa6899a17572e3d6e1db1ed51ed018529f94e28e26ee194896d95b52776f228fa59c1365999c6d33fe3d2ecc5f9b96545f2d869e63d599548142d565612c06a49e0c9a568a49abb22825038add6260e8d97dd80cc6717e59700f038be4afc7970b5ed765cb1efee6579755c4cbd0d0a692028ff62d0979d36cdad5432ef66900a6ae16c5cb3d91191ec142d36f8c4fb51ddc1b3700f249ce50a6a85e3f1f15f986de69c6e87ae9b0d0a6e20a46063cc6f01188ac466ae7495560199061bc621b53ff30c321c28c14874f7f796a2913ae36b7ddba7bf759419b3cebfea71bc8ad5bb9d65b9ba06c21400f844172300c8dad123fad55fa64809e61ce05b22b51a7f4467bc55eab3e7f958730a2bb6c04af4a49f606faf0aca8ecaf4fb9cf1c85c0fd99e8b53671f0ed8f78d95b933b496e930bf9e314a38fad611ea418007326b537de3ea7d316a8893950d0a6720a6aa83643d6fc8e800d7c94cf2783123de5fbb187ce581a87d1a357b9aaa94641df0334d28fc54dada438913ce69e7da968e5f4ac240b6e915a907d770b3118a9ffb18bb5a5edd39b31e6f27732a3b1556daee5fca110ac3436116483f31e5dc4d59aad60120fb9e20e21159ae626c1b0f87025e6e64360d0a2e202df8d388f4a98eda8dfd74c40b4ae1b3573bf1eab3b9ec161c7d2d5f25ebfd6abcfe0033832779c8439d4b64e0d3f2cbf5731a635a9d551347d1520c3df31a4442581337f5271267beed0d0a20201e444f2e6ae5c5a075fec3e0fcae8a87953265037502055a972bfa716206514b4e1a37e80976d4f60ccd4a2745ae98a239967b7fc52c70048133086b3316f4da819e44e0ea68afdb291951f14d5b33c0d0170727f2592319cce3e0069a5cf1eddf898a40188993833306282e7a357efe033b04d55e0d3992262d48a20be64483c333865ad7329c19c62e49f19caaa37c0d0a4c202feded620f8653b2d06c9b816dd80518c9d1dce1cbcc0875f928821471fee26472ad6cc2ae2a4b75f05dfae4a9654f1625301fbb2784d9080e85c7448551cc1ade66fd97329581f9e1b36fe1287cdeee645f87e416901062cea4e3bdb042f5d9c17a0e511b66f378fa3dccf3f809d5dad2164d00ab271cc20d0a692069f06059fa598ea32d104e014219ae8ccc3e14788fb79b35dcfff963df6ed228fbe22f4573b6f042c55497d70b7e90c1bc6d610fabdb83e0e53f1626815884f580dce278024a6ca81d62598e947e6bed51bd41764462a14441046d4fc436cd44f9fc3c0d4cd9af41ae7e7239cd79e139640d0a6b20202a6ff2bbb3241e3ff1199145a803f734acacf1c0cf3394b2a3f7349ff46d37e16248d5048fee5f26a4386e7fba4f35df18a431be05ebcccc89b16c310acde47f9b2541a380b6adcac07f02d539d76bb1fa56cb34482caf857bf97a9c53de2c383b0d0a6520b68f0dfb8f8f5c401b8fcc5c2533cf7f926f63a7785ab6f1e52de7a92667da9e4cb5162b2234469e2cd77427e9421d0b5ce3d90a545765a8662bd1ff043743234ffeb36d50f0e46d9d9095bc69bfb66b3f091c88b443da23a9c6ec36d021c55e2e48e0ccc9f10bea5c0d831b3ca20b7c6051346e7015ed7bbec794854b63b1511b4e7617c734cb9d91854cfd0d0a20204ed12678159bb0e870122a76c4694a76a913a56eb23cb21ad2f6283f52953356903c5ff32430042ffb50ac84674c52937dc7a3aff7a588ac830b9c9432af0d0a7420f3e9ada42cc8665f85fce50b09b94da70b38e887b26026c9dee1615529519bc4379b404bb94e2b10bdd1502a861bca1c39a838ef4674d9ae3f65171ee93b9510baa05546ae773584205f60589a5ca6be5005d61d5cbd2cb4ebefd3e20fdd7d5b3dd0e5a1483a2bec0bcc0f0ba58af57ce12eb8962f093d1316d645e8a37b9963cf1c46331f2a3f9a91e1a3dfbb4d496628e405a767b1e5c1e530eb7eb3fae099b5f375860fcabd00ce4c0cefa36484299a64579b1aec880d89496d0dc5bed8b00352c982a9c75f13f909df2300c9e6c79305ad19a32637d19207fe58530969433948307dbf812a82201112564fd52dffd8ea200d0a6820423ed19773461c4afead5daccb42a2e266538660d147e77f3450d8237eaa708fe49b6d9481ec5dc7121da411f11f4a0685812e84d6a9d7b5b740abcac0bd7953d0789bc2fc21354c369f7f9323882b5688368829894010230644e816e3dc41e98c341da3c2c1cc719b42d4b3f3e9ba8fe16dbf26f6bed22a3ca0aef9d07d93d92067719ad7a58fd63489a1637b5752011f579aaeb74e58dc5f08270e553793d26914f9d96180872677c1e3027a59d60d0a692049aee780f7781691ca0c0751d677f481addb0ab637864b92f9fdb962e7f4f45b6bb0488e8e0a2729d93a40323b8a11d5a58e33a57ea02c69a271d5e4922e000d0a73209ec862189cba31549faf7f8a92c1ce32773aae6cb940f6f7c67c961573a9cd4ff965a2d87f2fb0f4ef8e03c50ab1ebac0ec0cf6d09f57654cc795dfda8afe912bc4b011a4c47598fb7963df1302e75bcad5a4a41e50e6dd0191978af5cd60f1325bc1d4e7a8e6d8416cb0585194509eadfec9096d989ad676157d7d0913d51a063b1b479935ef888fb22036fc3fc7293b3b4bc3320f4a15e8ffc1af9f693d40d0a2e20c549c228021255f3ffa568da1de61d9e9918dd9ffd678de224671ce11ee7f0ccc1edff459ba94e4e32586355fa674fff47d484d8c7e4cec9a197266ececb882272047f38886716abbd413b176d760d0a2020b58940833421df4bbf670f91236063f2580937a825b43c386b50df0fb6a2d2195ba8e2c6c51563303d3c35bf3d687bff1fd6b6ffb9dddf72286ae8a015a434cfc02c1f8686ba53d56fbecf1132923ace050d0a3a29bd6b6e4ef6b489fee76441feb12d389e7cb40c0d257b13f194f7e4fc384351174c378b85a5252147e951ae8411bea60899bab63314777932c83e1270437a0b67373fceecd96a280d1045856715eaadcee254110b3b7aca46c41914f2d21654272d124de275b59729024d47ff8ab89b22fe7852477c2cbe8bac525ad9518eaa0d0a20208dd25ae30a86b787a86dfdcb430078d74ec3267a243791881ecc0b5bead8cae9b4178322240882f56dabebf7c661515dc38229a1381ecf2194884f9127a12d96c29af1f3f94962748b42be9896a62ee3e5ef808a5b66a3fa1f33f2e5b338c2cb8f60184394f6f2efe9ae1f48a639b15cf5034df7b7687f0d0a5420ed5c6e5dded93b7310a645ecf311ab939c3a486d511ece8bfb2be92fab60403d249e62f06fddf17753c454ab14b80ac4761de0bb9cef9f5c3f0d0a68204b53388a72e04c61be8f19db704a23e64df9bdabe4d704cf081c16a9c577675462b736eecb27ad8575a861f64c0d0a6520444386efd170fad91d8d9d8936ed576c7554d5cebbf18191d858e0417a874a99ef45613b1f80326b40b4a6be0d0a2020644d21522c5ad49c6f06d75270f0c599066b4708e324ff499e5ab5d321742aaf33b36685e7dd9735ed1815c54c159db55f34eeed1bab87d4bef941677f439b048f559a997f8941b76d52bc3b2b63d5f1b21f227ac9c264314bd327037d00b8c7338b472b59ffaaa242d8c2d80d0a6d20d531096696d128efc37f518d9e9e6aa4699686751bd26fb3beecd352f49664e77d84cb2b362eccd159bf981b4a8114494f33164c90e94aa50dc7540fdc0a8cbd372be4bcc8054b6568c971bf920acf39dc73e64200365382698454d18ae894c75544855d658779e10d0a6120c86cfaebccd9cc3838d447652063382df27807a6f805a3725a60b84aa121ec23a8d2cf2d8da27975c9a60afbda150864bba9d37804ac8f4338b801ef6c5bac3852f4e84048c6f72564345668501dce6b7dd6ef76f11471e7456b501e8b258b4f72e649b45dd8c2bacd04b1c299c422ccafa0f3c00e470a70c56a978297e49a072ce4b235a9a7d41a64c760c1163af16bfdb2712dffcc255bb9df4123f57ea45f944ca20d0a6920c322cefe8772fefe54881cbf0041b7851c6b93d678c4575e18243381eb714e242e2d272ac7d101a0d53f1ad82d6c00bb8d99d9065c58cc1078a969a50d0a6e20a12d37ce4348fcfd601188d842da25855b2188fe46c86dd4ad962abe6327f3423f2d51febdf7aeb0323df97f42682c0693186aa043ecd18dc1496cc1f0b78bad4a22beead3db4659b34abd7fec095eebb6c96a8e766482a887d7ceca3f67d1f938eb2d8eccbf5dfc5774f792d4d4f8179ce17991303dc511782861056675386e2e948149e98042560120b7eea7185296ccff114364269114430e1548fb97ab5f05c0b903a32bdadf4d9a9a5bd2fbf54df5707d58ee14b7390d0a2020a2b082febb143fc54d0fb300401517b70a81a3c523b20e552b076edccf4d50eb41abd68df4e5d973dec9e5bad5338640e93c73ce0896b72028dc7ff4a0e4bc1f198ffb19d10b3dfe847cdec453bd02882d115a29e657c7b5e0564e0f377f2fb20a8dddc18d360299e440efa4b60145219d2ae07fb8b150be6cd68b00f2f624d69a5be89b9aba6c3b0a3f10080c0d0a6120cb8fbc85c160203f39649d36eb817bd7d53081f3a838e4761bfa94f04f58d1e431f2276e411608db6b59f31d96ecde3e818b489ee1489ff9fd558e124856857a7bc5270b26896b1721749ce1b5a0c922b7ce4413603d1b749173bbdc191411fa4ab542def6644c499bc60d0a64209a301e1b9cdecf4ec29afc1a407d688236ce6b6ecdc311f88e3da601d720174700f66d28646480a6db83d7a9eed22e0dde0e4458a7db1b8467ee46285a4a93cfdc10f21d4dd64afef123e87a11113786de50668bfd979f93b7aae014e3f309eb6489aa0b58d9c291e17af7d6ad72b65b69b6d4bee849fa358fba208407e051f80f24d07d45b7fd41a0b9771da1caa7cc77bffe995a2e2c0dbc1b9e0e0b73a514a84ddb2f6194b77a0e400d0a7620c3ee56f272667f9d49dfa1bdd9020b738f4cb57995b999eef66c5104432a00616d23249bfafa4001e1669fcc25dbf997508a4a701c8c631fb74b20c58e2e91532c628726aa2973f73c8ddf31f01082584f85692ea5212451ab1de77232ee85d2e6d487b2585fa635cd911ae389ea51930aea15e32a54feab22c7e1462dc58f38705ed4a922dc969f463cff60bca6e5139ce54d544e0d0a6120acc62baf053e52ec5df71ea2f3f7dbc443b8e9529243880b4376f51160baaffdcfb33e1e9658a20ad2c5adc447793439020db0ac7f001459c7f65c382191bc16b54d4b3f7a38445e57337111d9fbdd1c9383ac280451b03d52e416b39a5ff91bb66bb4925f7c5bdb7bfa62def65b5f21a3bc34b8ba335e88c50fb6a4afd8bbccd874b961a6d4aec278b3ca7fd4fdfede0f69e4a410f1279ce11c8b6a20247b0d0a6e207eb70bb633a6f1d6d8efb853b7a02b729a9a2e2f5520e953dfb10928614a53063aeba01674d82bda97e8d12e41ec15c4ed2b8ea6892f696e8b9e2d0becc6c9b18d87be6f9134d3ce964b928af7ba8606b83ae3d314ff1d61048dbfeaa3893f86279f272b1c247df2fefaaf286154af8aa1458cb2f2a2456a870d0a74209763b352d43543781c8abc626a642a923e41dca0a3099c7a6bad5042a4f472f28ff1c56e8dcfa149257be840573d62e17b9355785d52d57ed42c92743ebdab64fd37e42b64f10d0a61203b634d9c6bd4ad654dd9a46d90478c1c378eb877c66e82d4751a1d53284a867b7b1f5441f160fdcff3f6735979f26d8529a0fb9ecd6368e4956c082bbd623ece0645dabb6f49fde66dcc9f1432e3c18d569baacc2a429d5109fd77d135de797ca7c805760af594938293ddaf711b991ada1a39adc06c4c62e4b6be39da7c4b1dde1120898af64d7fe2f43f4d42541c76b9b0de9365d0aeb4a2f4d20d0fc41630ec032334e07c0cb51fcb67daadc920bde27f5189b289c730196bdf99c59c9ed4a2d9131bee88e98c0d0a6720362ce1ea9c95ae5ed7b7ee5e9366355aefbf1c9d2d590adf113ed2ade0ac99739da03a21579e4151c55f972e510ca6a283456e8d779b18ae427554aea9f4083aa39bf85d1a356bc5a8a830c4c3ecc7c233f99815d552c3ed6a0d0a652009faec42d61bcc1089187b4f311111cefef0daca7131395e9d79012f3d1dd3cd848e80c81e5c36a4cef5019d9fd6b32a75dda4988fd2e3ff9cefa66a17382f800158472e0c2e182852d0a2fe5869361a574c70f397b10201908090f69581789418a2fe58f9bd3bd82217dfd34f5392b2bb182106efc458c19f878a76c08dd8c5238ba325744e5b40dd1ced6548e4ea36e896bf4c84ff3d9fe6b2e33eed1be4755ef99c02490c76708ce9694a939c5266a0773d6d39c33c8500a1745325299ad27ed8e995dd4a1878398b928c7842e05debf3823906b5c45550f22046bbb5c72181c0a19e82adf12f40326fa60ff9418332f2350d0a73204ad1d75dccca2b189073b340e724a7400431ebfa565493bfa299abd71e1906dff641fc45552f41b89695bdfb2cb8edcffab810c4a065f1d9afd2e13197a959501a9a4be65e0de7d00e300a3b848d359464b852897508beb6c84272b56ba994c4b5fba0eaee1a740316c1cae1b2c7cbc9a1551fbf51a2806789cef7602dc0bd09a03b3cc5c88f019e70e06c677fc1695165737bccf8cb150cd52438b39c21ef790b40aa376c080e0d0a20201f89710ac2330a7155bd332883260401ec8b82679b862c5caf37bf3e7f643c93e3dc7638019d6d712f3dfb4e1a33ab846120a29401ed9cce2f04c7e6b632727b1ff5a63e64a41dc043b8c22c4898f79b10a87a1eff12463ed7ab279374d454a61ef18d2eede31bbf9a6bda0d0a6f20952e6bff47e012a5b57039af3aedbb3423302c1ef445652d6728212138e46338abccd0103fb6f8039609f68e432723fa57c0bd0d0a66207e8cee6b0d534c26329f93b6148eb4ccfef411547ba1f743285c007c998cc7814d7ffbe36cdc59b60d026139c1fb4e28e32fb30d0a20209c8c71041ac5e70c9d376442ca65745dc5dd9b02203db168a3ca53d31b9649104976be6e1e2d8d6a703306413035e857029f9486fc970016f2e1f89de52b737402e354e258cbb6d45c0c6c1952d6b92aedd025e0e4c52fa5f88527bfea82970bb659a03a2d5b0c81d5123d1867a69d77bdbb1fca950676d82ce3755300a10df309407305829ef2d80d9cf602ee7d6f41fdb541b99d42e98489b24d614162bbbd8fffd08b2d18a220fc3d113b9f1f50e25ab782f53c40e58cfc5e59e6bdd66a21e3986e5e5c4f31e43d90c809c8abf8c6b4754bce3d5b1a663f200e328e8c710a599d636599847188b4e47f190ed198b7d00d0a612091e5f33a11a04e689f9d649caa1b9a90da7f557de136a8e61653a0aa104eaf330ac6367a87f99d48d8db517431690d0a202084ffd16c7c24c0fbdda88692a46f93a66e9b9cbab4aeae5c090dd61be08e7b3ba38727e94eae2bd889e2e5c6a8c3b0ed9fcdea8aba91736a452010d5096f30ac4cb9a2998ca85bbbc2bc132f76cafa531429fc8eb7561e63d8380d0a6420c3659b0977fe471d026d28bb331d1bf2247a1e99d9f9d48b00f61e0473c06290d0cc1adfa569ab7dad0730395d07f3a849e185e4fc8b2de97df2ed374b133c947ed6e5bddcb0689f7d17580adec68bc21d57d77d0a449426cdea7e7ac8e90d0a692066e62a5566731d67d8d6bcc43bf81905c7d7e8c97f1b5a196b3e98c712f4b651fa85136f9c1f7a2529806235b89346b00207af3877db29208ddaafd17e9243eed830fa80d45fd8f99063a3799adeeb06001fb6b88e9bac523dcaa8a5d9a26f7aacd46df7130d0a6720a6a45d20e2b21a34b22c17759fe3a1ff1d5928b87333a201fd005e3e43657247064b37a360b2a3a2628bc376e5778b0697f321cd15ad2a85c6a5ef9ea33219e784a64e917b6ec63e1c3a29f4b50ec40e91d5cc3157dbaee9a9309e0526617264f46a911b8eb5c193b44f1ff7d8acbb5a51e86738dbb1f42fde8f2714dbb7ab65d6f1417ebd0d0a6920848ca071dcd66a149fc305f9f1f0c3634a3f3b9b24bb980e85e60683561c5db783c76eea3bf704c4ae71598d76f4b9e40d0a7420413b2daa0a25d83a46bf55e20f64c7157887f02705e1c551f53a3197290fad606b5b0214c3cca613b3df3043f7da2b8abbd5996a6e847c701b86bb1f4a7633f2b958260da722c76425e77b962567cea6bc2c94450fc6a09b1170e4b53cc0249f67431290586ad7e07bb8528c70e25f3134b929016886c9a468ce271be5fb2c6b47070d0a6120af85faef8e71447b6b90a10ccc17cd8962b33c093b0928508c6e6186fea923e78c430d5e00e7d4d7217d01d1fdb651415f573e7bf472249055ac017c4afd86718cece36859f316981dc0222562650a681a8f503bfebe8a162c7fa80d0a6c203a3587ef3312427a1f33244412c74368acb4f00b26ff8e9cdaa0f89658fda195f31f37e3b16a292ff33a46cff8ce9fab623a0932a70c3b94700d0a2020983efc342f3e9ddb7b84c902b62dc3a71d3f0388f4859a03b1537881f36fd02ecc0bdda9f7009c0dd8e7877448c2c23cc07766e57cc0e84786780ac62187088e6185fd938f667d37c067fab76495f85c80aa5ff08e26ddcbc72cdcfd87c163765f589b4bee1a0d0a6420b01f522bbd57144fa04f6bc2b8b6c6a07a3822429525bfa14be94c442f7e6d9c945807a09708e84170b36d8dce7f4652a6cc4e84f452f5610d0a6120c0bd8ea00e1a2cbecf3466d9f5826a35bf0e8d77471bfa7d348e87613e4279e848646dc7593d8b761dc27f854a5244e7ece059f6dec39632dff07aa7df53dc39f0ad61ac31c12d806f9c1a7a5e786909e47b702b89f640cb8447a9139185367fc947743fdd0d0a74209df964bde9e9d401dc6c4b3ea5dee2b99433cfbf55db5c72c4bd30ccb19714dfd27898609c05cfc913c8531a4645b36d470a97e78a7edb17e80e69814db4815d5b8abac67485cd578a1c14c9e21fba771471ec828d16078fc810caa791e82e606f24eb3cebdf2279dfb15b310d0a61200999c496ae6b2beea515a9c27070a80c88c4cb94372225ef73bd969a6b864db7344a4710b8a0a4fce1e7a6f6b942b8298748407507db695e05c7c36673794ce9e8ff89c9d5b16b3930ae3989bc29d597b79eaecfb3f05e883fd00ed3f3ff41006421023d16a263d55a6e4e163b062232ac2b4aee521e96d90f46a5d5f4287775259c6e7484630d0a2020ee75b750481297393144bf444adac55b3513fbc15cb463365774e511d150ae908aeb505e65df7b6c71fff120512e61c15c526ce50a08d63387bd02a794d8b08edf2eda3a30869a2a74e6491b740c44f2df51d8757bdf91e12616b9e2b3e5d40df4d4337c2fa5f92d2f107f36163b52bf3cbca4b5284af1cfb3b1f5d21936c92b7260625c08d631cd8b659a678d327c38b1a1ab2accaa630d0a73204e34c9aed34ee564ebc974430327796ace0632eb4c861815cfeecc69946ffca904af8b761d7da78bdd0653bc3aef44f996518c5838851249d6abfe2a5a946f05a7733f906624be72df50a23da61f13b539d87baf6f9bdfd672c45be6c585d7e5f9c082c7b877ef1abb2be00b55b8c03cb265503d201126f7088b6117da28a301418fbf42fe0a7c8dfe8f7a629382c526c6899e0d3d45e947dc4aaf961539b1be3ce59a6793d3bda358725d527964a1a9a50313a590328ff78ccbc15e1abd63bf1dae75d3892a9bc5072f0bbbffac8621e7ab661e33e8f868e91a782f0cbd350d0a7420f6555fe503464d09267f2db9328d7521e0fca7eb1d32d5cd459c3b609d1aff4574d72a247b2463fc0ecdae1928a0e6bc0c8dffb5e290285942224ed6e348aea98c3d35a15a18310602365ac81315824cafb3c351ae3f0b7030759ff36abd135d3958b1e83928b2176bae93ac396888bd6eb64fb418ca037efc0975f095251aa5aa3ce767495400e5801adea52e0d0a72207a4ea0f8256dd47d3d40ccf6fe1cad20df157ad3f15b15fbc076f3144631cee25c5c1a98f168555bab6a55bab90d8cdeacb9afe724f9bb16c6cd771ffe9893f0ff0324892c45f6360e25cf169523bd393fc9e829eb872d70595619a5cc8cfaa4aacf13bbdd7e086aae2886b8cec116a13e707e0d0a65207b97550659ff4decc16d143a53afbae032c4375d62437045ceaf14ec6f1d0c6dcc7b666e9db69c528a7afa15da8ed657c050ae662c16a09eb9c1845f27f238f79960faaae677b6f9f3e23d20250be482291b9873d49c3cf50aa279ca952fc96882177eb3e5d9f1a994545f90592cca1f589b4080a377db2d0d0a61203a568dc3c64de5d828033e1d39a1cc97b6a07476273afe70e855599115af6ff242f712f9f14256a59d934bf17fbc84b17f0015694e6f5eb9fcf727349a0eaa0a15b94499206e3f2f8fb40f3db3230d6ad1aebd7865671d8ec3a1f0bc1b2f9afea019560b8d03b46d46be344ae52a610d6421edfc0cecfcab9a0d0a6d208978679f49857f4700fb49fbf3b5cc679a54887e5b47a4be889a85e2f367dc8a6ca9ba3f32ac1a9f23ea95799ed3654b978bdbef4660fad214a2d72d7404943ee24f795d6290673aea995ce0e65a9effbacc5b6aa31f3b3bbaadbf3830426f44cd814346e9e24e0fccf47fb506000a919f51a9b0abef9d617a2ef11736b102ee53b2b4d384b74f53d64adb5afbabf8a2ee8993fa4c10e0fa73263c6f31f1f909f6e4e245cfed6a289c010d0a202006a7bd4e663e2245d613628077aa10cec85eb8c16f1b18e6419734f84b3af451b166ad2c254642823b544a6edc144e6c26482b9b7518a8dc0783cc35d2b649fce24254d0a31951f11a0ba5ae310b67265b7468ef163d65ee44b15a4b1e2311a385289401ba4360576109c8bd9e5d63aee055017b9029618efd5b5775c8e4b0de809ac5266fc57dc2decb2d19e936178239f5665a9e0d0a6120077510931dcd7d855bb461c608ddb07fb111abb97496e47b192fa02cc24d679f9896222d96d188ad204afc5a2e701cdf6fdd59e38a6d0921d09c7cffd210464603bcf025a918b1e75998211aff991e0faa3b1d0209de83e505a5f18fd27838fca08eaa57451d4d66edb2d140b568bcf7965cea8e762d759f4c95db1a6be6dccab9bb3cb67387a49adeb719d52c334690315848f1a808f1dd0d0a7220567d92751dd5a270f46d92be6616d649a1ce1fdd36226c5f810d4dc72f6ee0c5ad1e8b2230173ff8a534ab87303e36db11ad54b90ae9036e85888567aead28f17aca48ff09bb4327c596f9ce8b0027184aae005d8b847494c883905600054573e31e1d09348fe37a5482617dc252bb0a936a7d7785ac76bca94294948ef30b0d5ef70d0a6520ce7a6132c19e77238d007bcc30737306f57f58a5542f8554c82dba91d8f1622cabb50bd9e6fd9722e7cd4cd690ccc343ea8eb6fb4d05246f87e457f8f635220acdf8bd373fbc4fd72bf9bc607557ac0a0a4f5858b6f36990bd113d66178af836aca98c4b48f83d89b124cf7602a7c795f43b162ebf9908e4d708505a26cb177e204a07ff940fc8a0c850d27692708145295983a7c931d07383cd079132755019d735890e6b4bc7493b847df2615f4076b53cbc82db00febb0d0a2020c4118525613e87b5bf89fdf7b89aa3c6c57db937cbc65528afa1d0fe0e7b39f9b0dbf8243dfcc8df6c76ea192d5e4f74df147f9796724f13a5fba24641877d3848f4864eaa04689b230639aecc7f667b801514a0e1d28cca2481a64df89c584c9225e52e971f6a0d0a63203f8ae53b47209a24359517bfb2dd4034e86ad73dacd1e0806a252169a62fb9914345a38cdf6e5227f755fa2e415df05e62ecd76a17f7666645019a36011498f3a479bdbd1104e7264d7ed1d83007a6c34621dc853c48491c1fa25c63b9279c401a67a51878ffbb7a232ea5940d0a6c20c0054b7a036bd92aea66c07fdd1e18d6a7c4895522d179ec444ea2cfb647f019963e2904d243c72a159bd6800b81a1f79a984d30ae4066a8ad9df1acecad0240e57e3c9ae04254e86e41f28687c62668cac4d27f98e120ddabed76502f0ba22b2ab9f9e721eb1f6b420c7856d5400d0a6120e4832be3558b5ec9a426eb798e50b50cf3c905c5c3461584796b17bf69087f09f85f77f354ad25e5424673f2662f117061f179259eabd1f6c4678cf42e22adb31e17e65009b9cc5e159b1aa9ca8fe16fc2c52b57a2d170bd2ee91ccb99dda9d78b48b623b611a7c70f7eb9f83c28ca8d3a39cd78699bc65cf9518f6959d522d2c5e46efc479350b20d0a7220ba97ccd6b5c159b8a44635855c860c0c4a718584fc60a1a50391862d9be3645dfee5fa9d71c6cf6646299d3888b88bf4723c5d98a1a3adbae1ea8b675e73b48540bc72762a7511393eb8e3231dd1e10d0a692062fa25468d4c7d0296517b9cdb5691e31857af79fac43522101e210915e1b84f09a9ecc05e355c6c2da603e4d172a7512fa5c6d438987185300cc349c6819f69fa2976352dfe7b431867807d63873189ad0d0a742029a137ea0756b4d411c2e7b048cc0465a185915e735592075697bdb048fc9f97a33a17d824b8b7521effcb86504237363429682305058be85166b8a3cc6e6a7d34b534da92ddc5df4a76cb5f799ce418d7920dabd20d0a79208510cdf6fc33c67d4114dd161e64b5f1c85f02b55e1a5cc8bef6d0bf705f98fec4be34ce38f25c27d61e1403eb59acf65e6e3b9ac0d508c4fc7dc9c2bc3a192c12c9b967b888722c2bbfc621ec88aedf0e4151f6ea6700974031e3d0475035b442ecba202c498434b9977f8fffa80d0a2c200ce15b24ba56eea5884e1ded5d64b9dafe0f978e93ed8c37901c21af4f63697f19493dae37a4289b08f9beaf56d45fbc40559c9de7b02828c7456ff219e9a0b90822e32004447f90819ee810dfa999d08c1f0ee395a3de3b5a7341ec577f18f7e3263a51b774d4c10677e964951195d152aa0330d50e2eaeb4dbd48e6244640ff057ca19235d46495d182e0c12e8430d0a202005f4c66bc6c871a67ca42a5682a793077d67676319d3941e4495fe5c5553f78f285fe0e1384ac9220f77b772adade6a618d095e86fc1e2f7511ccfe51acc4c8f6fed2703c2827122b412e435a3eba575db63190f4a015677e33bd815f102712ccdc9ef199496187b6198032be829ebd52d6c48163b87bbe7247251138e77ace60c1f9668ba39116b24d1c2eb2e18b82528ff712b6f76b59de1a90d0a722060fbd6549fba215c5519cc58a494f0b51c1ce1e5ca2474eab509365e490c03794103c496446f524fa7ff55b89a0113de0d673ce2f73846e606713819ac52aec59bc7910f88eb7e4a5a51de35187176f64a1d266de5f336c2694c3d975bd4bebda548fb3460ffadd3aa4c2e8df6bf440731e6bafac8dc5c76bf64d9e91e69e1efd57e0712a4d5246b28a09d9175f7268bcb751835e7ac76351d3bd5de472490620d0a6520d368bf687d6942fe025ab4258b403dee8b4f458056a6650d93c508383629d65b5103675130b50c6da685088990a8ba89b877808aac4a78225cd9300b4f56813925a7fd3454c40b1e69f7233e9ff00ca3ab2a9a5dfcc78d191cbc534f8442974a22be04d00a43eb6749edcb342ffd24a1dc9dc2f770f066c73e2b3a5d233969f2928e401064f1c9e8a420efd1a628d4a56008b29b53987e2bccfd7253b5d4ac4ebe46ba45090d0a6120f5c3068758c2f30599e9947c5ebbf02e8f7f5321d8acfeb2ba0f6e7644466ce85a624e17edabda187022ae3dcee937b95a19869d0f575735fc982a445da0cb18eb63965bb15e9bc00df46d927d70ce1fbe26e2fbfed19cb352a35d480ec73a87f6dc05c33f5c5c75d07d27227cd5c32ca267de3951a318e8fd4e40d1fd35c27d272403d96445b0dcc4f8bb057286467ebcbab76ad52ce372cac94bc1e2484ec0ee5aac00aa0c0d0a64207ab408a47ac6a643c2153baa19af7a166c4174d24cbfa4d572cd7d086828de49b655d00710595bf06d0ce848ef4c1ed7b9603245e0e21210bc43870ce792842b5b97ae0f426df9e57221ce68f174b2c9d857fb119288a51a4328fb9a8e0d92bb862e42348db78a02d5c49ce65bed181ac578551e67eca5ba3f2d94858378a53a31375fdbbfad5d4a4bda0f08a398b779ca4449cc7d47c892621035307705ae13ed326a83102958fae85af00d83d6fa4040ed7d10017bd88705e11434318b31b7c379615acb0c6423a206f5d1851528057eb91a52fc3ff10d0a61203ab9bde3659650bb7d4f2392c8a9b8be1bee7543f9d176b9082c3311e0a1d9845b7a0b3ebb40928f83a916fff58ae81fdd4dc27afc9960251ab8485ed97937f214a4e60caaf2639fa71139b1d7558a1411903ffca31ef1df61d8d81e18d2b720d200db314e9d74ed79044ac463ff4eeb27daa31bb0b7e22a0ec0e9225d8f0980009df47627105d51208c6edfa718c894d7ea92ef6e06fbad37985952038e240f3943f09e9eacab84797f0468215640f5a9f3f4b0092b374f2cdc60200fff98c513c9f61c0d0a62203e2292df4d03f1b4b7c7dc7da08cc4f73ddf99002cfc72b9ddf545b2e256dbda08167290732305d4bd42eba3d366c182e4b1714bc6ef1b9b687c5bf36090cbde3e1867d901e4e483e34005732410bc882aa45d55c87c85d243b72b0d0a69204f7a0facb3c7fd8667203faba600a0754aa13f01c2fdef444ca7d6eb456b62ea36dd8fdf9eb85cd0fea7f92931f901245b2256b71f06403b231f3a3693a6acf8d5b9bf3e1151326337aae294a0b823910aa2935cf75954eac6c67b8a1be39845d753ba61fcaba66b2cbc6155c85d867e353c62653995fe4faae5a8559b783199b7805287fc9ae1e12d0fa61a3e3bdf19e9eb6767f3324f922c6e62c0d3ca99f2867331b1fffa4aa383da4510eb78fa82213b70b07a0d0a6c20c22d550dddb53a9de08f3a4c8c5caa7e85c00dac045715c80f5331125ffc4ea6582bc008cd5a7d94efa94d0cf158d059b2109f7cb21e2df6ff42c03af7b47113017965423983a5c532637f124ae9cc4001d357a62991de2876567569aa7e058696725ce1cf977579f10c7ce3561bb34f9c93780d0a69204984c3fc7922aaa9b443000c5c898f08bd2ca34a8ac5a78a1ca9de20396ba00ae6e3161739c32cef663d9d55edb0fa82e8cf06c2c6dd7ad981e2cdbb0bb2759511a9e465fee4b0c9c6a6e39d30ec0d373f67476dea79a41a3ed7b658a98588adf06c0ff6729a0cd3d06e07e1baa5fc1a26b424ff722bb5ce303b2d41288a37a1bb1390bbc0b70d0a7420633b1a45cf71df1da79d2b7347a6d74f2203f688a9769bcb6debee88a4dd333b51550ea57afd98ea3b2ccd117d86b41b53a45574d0e98588b1a3b2d3dd570259851896eeede3e61eb4527577d36d37eea91ffdfe9513c2cea1594c3cc16e33df8dcc3e6d91ed7eff4ecc14cd41919926bff2b90d0a79208f71dfb91623d5eaa9a453a05e7f48bee3dd09267b37358b6cf1df16c9be20bcb38954b541fc9f6488d3049046027013fc11c129c8fa1fc6c942bb1568113f5285ac0c00c4ee9ec95e41e5e3e55a23c2e65abaaa0d71c71eef6e3fbf00299d86abd587d415ff2d8d66b96b99d68438fce8345a9bb792105fb5243ee10bb0900c95b352f028c4b6100b35e1b52b4dfd475a140d55d1860d0a2020d900cdd1b3a97e3b1d0f7b1f714e43649f5075c5634a8fcd54c0b846ee285a224cfac5e674a697be7c575c7c66fc611384d447f86813bd602c4abca2351e8f1413eb4f10273101c1f398eef224a9dd0dd5cf49273bb4811f17f1dc9381cce27012c6d4590d0a6120823b838f94a4b71bab513e9ae4b36f9724d0c9694db74ca546671c14deed786ff63c502aff3396b8ad576bcd76d84aeb26f68c72e8635b4ba6ea9ac6a8cdb8b4769beddeb10862b316359aa93c95a08dc7105eb74b7ef02c7bde86a1b8c8b3a41738676779978ee1f0abbcb9daf0f7022c0d0a6e2012c6853733da2cddb7c7a58f79c77a9bb2358fbb170ec124834f0c4bd55eaaf0cc1109bd0aae1bfd0d85524742a818d0b1baee8e49de15b26d0233ce050221f9e07e2f75b676a67ceca104429ddc76dbef9053e4c9f935fe865a49eb232c98568e74ab2eae757fd122ab58629289b9b2387bad7302c5b0604b27e5e4c411f0c884196d9f419998652259ea2f0bd6ef1f822efa660d0a64205e35abb814d0a87de631fcf0770dc873b1ac7533be34b4743e8b3f7e890299299c057ea5fa7bc38ff767fe9c46ebe5ab62bb29463208e239797e3353bf559b81b551d8890ba97eba5318321f288f4b3d047a49a391407929faf7e94d4d91239de55bbbdb00a140d01fc9e60f18a07b42331f759e1b10355bcfef57c9e83b397d5205a3e4b80860cc4ab712bff37a90c5234ecc941bc46c58f86c7694f1835daeee77b207b47d96b658c1d1801b3ab6fb1a9e1c54a10d0a2020894e5b722dc3d1f3a0bd306de6afd137dbb463990e773a6c9f6cc087af6845ca68e5e815006309c3f2360831c3175148b1ef65e4cec0354df0037146a8ca49201fdadbab4be559e3aa2e6ca07dc97ba73e31753f2b7325df8dff461a8350bc80f277d75f37c2c2eb80ed7f85c13e33f057200635c397668b579171415d1dd58b4561b2df2c61fab3172f61ef832ac2405f57517e1922dee8ba0f70f77450b6c1bb863f6a62ec05dc4e9aa0669e0b8d6c53a31fa2c55b223ca2d7ac0d0a65202d52efe9c927413205fe447b055d8d3f5ab36fe0bdfd85bd2a418f11ceb5b0f9180e08db00e4852ae063e5b37d30eb5ebd969709ef9d71f5f6878d56f38072e865310fbe7db01df412f700625da7fb7442055098252a2d2f8ff9d3fb984f4ebc1c1480de5a39b5a807c5392362537b724935ad92b77b841ee3cc6f102299ecdf32fde87651972444d908f8483ea071d99f865c1e47e5861e53577d32ace31ae093ea8360ce5debbe53df1ddabb460c08fbf36052523978c47bf80d0a612027c752b38854e93e460c3f8966ba3662ee1874338638f12dddae70ea9cc5be2f80c90ee4abc2286e64e1cc8789ed7ba29129b20fabbd3f6a3e1cdad4cabf09206605b3969ed8f574565e9557bdef47556cfc5d34e36e097268699d0fa5004ad84de530bd99b8acbf046de63636772944d285921aeb3d7c8b0bea2505981f453da101d2e6fdfe2a527e5fc28ab87fb52347982863086f4cf4a8b2262ff5b96ceab6fbcde257abd6c2e7eaf76b0f2b40cae11628ae72aff2ed172e727897bedf5c51fa8bc6219571fe01523e5ec882a62e1e6a15a7d0e87e2c1a02297ba1a06356e8476d1af04eea0d884877d00d0a732011d45f56e22fbe0795930925c5e643a72cf701d4b348779f3a7b03c5e6984631f7afc76bc11b599cb1f698e8abc69c8081c3fdb8c26827ab698b15ed4daace45b8930a83e86cafa4be2a974f92e5ffd684b38e11fca2d6ee43ec5d4204d1504b390c3be4f95e9f4edb754ae649ef7b06dc65f3210c8d621200498c905760a75c09445a6ee361cbed1d6d5e90a3fd497d4da9e024993e01f88cd9359488007779f8470ca381d6ce49128256ce88ad27ad949a7ff0e25b6839e09ee7e803dd2648912c002600a08af49aed472c5b31bac47a6f9f7bb80d0a65206af63cd5e96f774041e85a40d85f085ff647639ec907e6facc4998b3201591cbacc1c3527d05b8d0233f4b7dba2c542d66ad9c401f845f587a553938116165642c572b032a2111e809d9138816fed5eb722dcd02c730685516d8067b91403af5a776e0a056219595750e7b915f6f11c5d1eb1bb6a8f89726ae0efc82521736d53cf9c2587961844faa7a10acb00267ffe95845871c1e2130dbb64b74d0a2ef55b95b61f99137d4d2c1b78f18cccd8d5f490090749f780d672b9103acfc92188c06d79997fdd023924a0df69cbf5b647ee336461a3f0b28f471170d0a2020e722cffe1ea849b5aaa80ba7f1f26ad7bb0ded862ad99c4c15b1478c91f76f83f82154175acd033999e2b64ce5f805f301118abfb76f13ee2fdadf9becd2685da928732ffc094209c5e096504c5fcce0d8485735b47d548544178efae1aaf9a56e53003170c9eabc906a619c6467fda8c811b161aaecf2dc98f1255599c7104692e401b6eece678e552e228e781f9670e374a0de8fc8f15e354bc5bbcf9bfbdbcda316d1c84844a4b67a4424bd3d731938af334ea097c067106a9eb210008cb6afd258eee097084e4da11d4b57dc32854871210d0a6f20b16c8ee7abec8854d61cba7ee4bb60a69ba1e2a2c5adc3313c6e9fbbc9ba440ff315a4b9c07936790a975d57e90440374ddabfd14467395b8969dd68dd7eaf341c9510735b757ca7ffa5e3228ff0ac42a8a1af8fdd645efcd07a463c3eb681e7779e970b80092343d15aa93d5ac35d94bfbf597aeae2fe5da2f4517152fde8d4090baa3cfa6fd9f593ae112166f0dc384eb0fd13d0267750648799555f0804d555385f3de31e2edc39ff0d0a66206704b4ba924132a3e0c7ade69964c58d1b0e559767efc0e3ac73a47100095a11ee0091a0a88885293ea76be5b8427613205568f18c039e8be1d67b545c1ad31275ad780a52ee5be8afde7823e2636be5fb73098614716d98a8515dbe758cd1f67edd30d33264fb8c216957837b34f7fa818d603d5b4bc5f73076db3b1b1a48c6b37f9cce8953ae7f67f613380d0a2020f03904b8054c357ae60ec837e4eb1a9d152a0c7597e8bb99e3df4f59efa3c486b8e551e403fb267b967573a3377bcfe5c6005f6f865673889d8d8c7f6a0376f8afbcf39e78227261c116a832b5fe52d001612a36107162f81147b8a172ef2599a9376d475a98eeca6d48bc49a30d83ea935c7cae8b875186a3d12b8be6688090d061d4f6a1e5b14fe71891d973e898030d0a752099c07a05826c9eaa0f00e94268b8b4d76f2746725bb319c0041874a704dbd08cff37eced6f2d1a2c397ca36d49697b210b63a969405e88fef16c58fd6832a89255291de37aa4cc72c2a73d6157b86a5b779112ddc39382edd9333ba36d0ee96c7a859594c704ec5c290c6dd4fb86e6db7f4bff57660554e7138b7d6188bb4b77996f9e8225e02cb5fe6d109b6370fed27e3d0d0a6e20469c411026fe9816cf9ed22fb7b20b31ec11b964a508fbf099296771952baffdf597d90438e4e53714926d971aca68ca83a459eaabae572a5f7dcd37a452ef4c171ae492293454a97d21f5378a5903c086c4b692749214f25857d6849544ef12b10230b087b395348f615a044c165df80649f1ea46de553b82389ad307df29edc8d94a94a648964461edc693f86d47ffa9a81b3cbdf7e6e2e96136c1f6d5a231be03844d624d59e33b37fdf80d0a6420509801d74c88442dea5290ccaecfb341de0a0f33bedffabf2c91113cf8570db02720603423890f7b834e2dd0c8dc6f90da816eaceb1c7dd684214fe6a3bf3af22ae70539f4fb3b2f41911030371ffa0d0a652026fcc39b3a037ee05b72d5104e22081aa303754ef3afc157dd48dd9e18c1c889c3556033e3ea385b05fa28c49c3b0783b8af685b02063ce4b145d124659b8ec52f07159e302135e7f5cd237e5b19f525180d0a722057b98f5841dd11e9a7ee56cff9293bb382d082b78918c59a3934e78889d7ed3f8828930bf6e9deee084eba8caa9bf589a5acab305d9eb07cc8c3e765570ac78fa3a5098e484f9610083b1ce23ecbb01f629c29348a0d0a73201162c1601cde400947fd52913ea8401f06c03402593dd35b01652fafa547836dde6a94bff5166d07e06e4ebc760648660687a38118d540e7cc7464f221fa9f8000bf593a585c2dc3e07f084c4facca98d0701c227b67ee0ed302569c493b5660c421ae17062f81c38b50ddf90d0a7420c4d02934e558b3e19e1c7cd1ab61578e494e0f0bd3448a4a3c9de3465eb5b4ce71b9555443918320446263890d26b7c494b21447c013edaccf1d7ddbc1a25f38f21398bb36547c1c976a472c3b733014cff09b176fb8bbd1360f2f57b1da5509b09689b3b6845b65843516e418873c9fa1271a7c622d6f9d3b3d7b49f2ca3cb466fe76da3bed0b7597fdfebefc4b5c0cef015081a4d1ae3518348210060d0a6120fef0e6eaa94a61588e8403d09b4f233e1aa1e5ec82ab24c3594524e0ea21e473896a2414a8df276d712a45525f263aeff0c0a85dc01ad631dd00093151ea9f89be5045cd1b1a1b96ba2b38b1d7cc89972f9dcf570ca700d97e3828ba5f33c922f130b9382fedea2c54e0652c0a51da7e3dd6ed6e42a1150f86b18e62eff03d715b86e5052afcdf3d4dd294d99eee841b90a26d9268b73232fe8bf556071f2a0f7f88fe0a13d948adf1dbdb9d6910d43fa9739e751050953fac0d0a6e20318b7ed1cd842378e41e5ef5c0ac515c7366345e7c430458857eec676e55550cf4d7450a296928b98fa03fa75281e18f08c3b4c63620b64e431f53a5712f3c9cf7b864e2ce9aef1413b72f1f28391b90308a7e06503fea894763abf65ce0e36bdfd0a71b039684506f7c22c31f8f5b58f7e9e2bc6e9d1546480d0a6420e1f39b229f140387977acf2defad5d687e5199a25fc7e3e54dd2023036df7e68746bf1bf923d6e44d9bc581ae99bb28d0b3ad0fbdf0fd54914a6826fa12d07ff49fc539d11e90cab9fb2812b09ba3626a0a5a8d2cb02482a747e14587e6ec6f66a854ebcf754112d5d66772651786eec2fb87102fbdfe3dbc672263c4c2d0d0a69203376b674f634c799ec83ee3b1fd5a73284d66fec50447fba32c8b70ff2d136a3205c83dc2fda0e37a0e9f97713630d94d569e5400031629514cad66da8ad2cff1a07b0a7c73365a686e8771477275096707b3af22e614a4d7720237350e28d674410c753f211abad545e8a1a276b8ddd2966f46e5a0d01d80d267cbf2f6c660d0a6e2069effc528ae49e4112ce0881ae09339024667d4431ddfa0a968bef88505de574d01ebe2870e2bd68c368e29285f41a6834cff7a0b5d794f447d6ab005211a759bc98af052578cd944a3f10b62582d4a9c3a0820750eb4b9fb05562054a5cc23344dbbaf8bca6c7ec5f0962682e0873755b1962eeeed4b1204c64cfa755f7901042429e88c1c2b610f47090cf07bc86d55841c41544a1c8dda414f42db0736e9dbc019dd46e18126d0bb79a88c67e58ab0d0a6720a4a7b983c1d3fe4808911c0130c210a3ba0019c4ac9a0470afd48d688eebfab00647a1c865572e54ce89b2b9905456d4baa83eae45be83709d0473ea5b3e80f89f4d0ccf9d929c31b5ce3531d3bff2e540eb0967e974874c0f3dbd144fa55233337a7740b57f2044886c947bde4330c446a12f5a81a06c8fb26fd789f359b7ddc3716c2199e7d45e75332f1c89e518bf71e339219351ef2a4a0d0a2e20e4ef514ef69eb2cc196ebf8611334ec1aff587371a8e91e21d640cfec661c27ba31e0db979109ce958e9187bc31a9a3f51d176d56b6c5b10f1691f2bb6b4a8c41a55e1d9b3c1712c83131d3ef6cfb1cf5ee61eaefd203d0988d5d88fa410c61ce48f3d05a60065915f089f0db66e6cad0d0a20203e7cc17ff531668a03e8ba840e5440a992bce538f94ddbb81e8c4966383468329c0fc689e65e46d4b18488be8b00b7f14d29ef53761a516dd741157a80b9609dfd78c3f0b219d22bfe1cdc617e2dd194e5807eef68cd9caf6ac7c059bb6c5f26b7cd81614d5be7f82030c8450489ed9eef4ad5e335466e4e76315e40a6cbafaa7e9dfcd7e0b87394a3817ba3fca9fc4a09f2b84b280bc184fb96e78357027a24d36ba2e11f0d0a4c20b93445f22110cda9200b54daaf1f0bfad67b3ec2470b8f205213fc864fa82e12b14992b64dd8232e9ea3953c410bbd9642162df9938d644b25111a8368e8cb757ce26b4ba700e51e3d1afae490a7f7e6e4d9af9b282a834455ca2cc87b6c577c0cf72846b222f561982919c0276a2066cf13184024e40cb5965b6678f2e1328f1e067ec47fb00d0a6920554ca17873089acb6d298dcc0a99504e527fa35710343ae378a332c28542f316b9076aaee0ff9f5b61683d31022740e4e47e5c200ac2d32376dd043d6f47d8e0b583e9947ae06da7e337a456273e0acdf59d23263d7974411008162e49aa62bc06abdbf848ea47b534715758c042c18709f49c701ce7c48b3a32361696fedc4749dc0d0a6b20f7916ea5374052277b8473d149459fd49b42ce04d0e3c84db44eb15db4ca420381279f3326db892f24608929619f8bc76007a77b1cf9b6567eee5f1d76d8abe84ea5de64654a5f409d36f4fc9f24fc9c846928250ec917b930e47aa073b717bba66521c58e75a8ffff43c31dcab3080d0a65207eede4f65df954a2d57ebb2ffe290ec1d32b9c7e71004349161cd7c2e227265597fdf6ca0eae35058cc2d8e964bb81a750339aa600574095b4dbf0091a6e57146069c76f2df30178fd81f54bef9b2a1b11d912f9dc1f0638e55f68388ebf29d4a017bfd265106eaea8b3e68fa023338604bd9d7b3a776981dbbc83d699c8c8bcad7dfc6df86a7ac247484d6288e9a8e376428063b3f51b92aa19e841fba12859863e9fe6b5410d0a2020257c4b62f1e51555ffb134087a11acd287a4b8d033590240faf1cf857a79d5da73115118621869bcaf30953e02044097344db0f749b7cd3df6a5f65f2db35ffffe198ced24412a5e61ec3b3b30bbcca94d45b371f1a8bf5961db810ced1a078e5c8ec90d0a74206903e7d157671c18a0aeded00e387b64e629856732d487903ea7e5ee8e15045d4201b2907efc298e952983e27ccda2824e6f74a6e84eeda9cd1aa39e39eb9b4470ee92e184b7d1d8330461e4af0f233c4dd5b20ffc3364464db8625fd5904211c4b677f79a5c29f6d785ef0ab3df70069a791a4e1c3902b71d2214a33eabb1e90ca9125a3b0d0a6820f88f524fd0323808d6855c4c2f71c5db2f2af7fb4c8d3d33c09d3fc734963051213604dfee03b313e5208fdb740d186c193c6967c8a88aecb8a2822dc60c1b008d87f1542f0854edc33c47861442d79f8d556b903a1e689e536fbf2142f24407ba4222d8d7a9868412a9a9aa74fa0aed6b1ac8167eb08347cdc00389ccb29c6debce71f80d0a69208c23c1f0b8d92eb72b7c25b7239f24e6d4d467b26758180d0a7320690c5772a50f6dca26bfab7d1c168953fa9d5dae1cdbf6c89cc93f45a2faf6078b5348ef8081943cf005b8f6a5f5860750baa81a45f2befdc40e8dd064b3b029c8cd823fb2e53a18c0251f65bc26b7064eaa0d0a2e20489119e7391040a09191d70ff16dd52961a73fbb74913b1fbf29fc344ed575ae8994f070f14485c1da28371a823050ada4cc03a318f28f1f9ca98d467840bf71dd9b1746489442aa05de87b1780971c74b0f35e7bfe6f1ccdf29c1378ee6b7462ddaf5e2610d0a202050a69b7d9ce2d67914c85e92ecc72c1e1097235cee395b02257f175259ac93730ea2becd4f1895282fc14aa0f98806c2155624633364dae4277305ce483104d0e76ed59f3e0d0a3a290e917bf68aade88056316e361684e59ad4925b7e3cd675aa61836027e1c056f555a117d2bd4fd45cf507760abd6363f94149c566eb86b180e3498ae8e4ed0d0a2020b74016ba601b19300f6f6dd300f0b4d7119db0fe263ad3ee9f7dc4175b36a843d6b983cbfb5c381d781ea61d27102576ed07330a1cc9923f93bebf0d0a54208ae7ab43255173c03ad0bbd41a8fa6348d1ddeb9114a8463871308448fd0384bbac154aec1e4a4efe433c4ee8a4a0d0a6820df01f7578cb080f588cf6b3141867094c9765f3b1245bbebfe185581c80dfb7ab002ca47cef7e9ea5c5a1b9a65db4defcce1c9a6bbb41ed1b78bc3c6cf84fb1b38aff6712201ee69b58280337da9d2ede8868bc371359ebe10aaa681d460f375d08295a3038a28b4e6846f5c9de34aaf9aa8e4a75cb78c19a7db607bd97b96c8a79cfe10ef942743e068118f330d0a65208c63706d10716f3a638556dca971e905fafe65fb046c8da4bd5ab88517da789501f4a9f23e655154a053df358068de90deb919c0a74a5cfc74f632e6ff1f0772ee570a76d2431b8c0735431462de5bedcaed963e97cb7cbad2324a52408d91cccf8a6730ad281b3d1940ff933d93efe37dcbe1cfa00218c86ec92fa90d0a2020e6b2d2c1e783954de27288e778e76b835ce72d922bb5143c860f7c964bdcc2ad1cce4c8d65d9a6c9815ee38c6058b03bef18b8b3dd88e268700d0a6d205c52a0dc69c8cb3b736f0ca20f3ae6b78049c47268d3a777266b2f0b21480f59fcb5d9870be4e7d2e07b4c0d60d9970f79d81b03444fbd2477e60d71e86ed656749e89239710c610d73673710d0a6120d2bdcad090f6f9a0b4e0b030d233e0287a1d8593d75dc9f0b986fbdead4568b524815cb03074f76b4881badcd4976f4e420ad93bd350589d6003aa02e9d6e54cfc73018df041280d0a6920f24b22af03b00b2a61d577e3b9688cdecea331fcb5409a8edda7952899692a88c88e15521ff4ef30c25363efd03618ed432c326477e81424db17ee63175b9d3fa2d3a7c70d0a6e20632fa8c0376c0e15e278e8ab2dfa992c6946826c534e7897175529d8e8677cf44d46cb9f725ad428f40f2842059310f155e5124e1ae7f1f803b04b01033b0cf8d3b071b616bda9fb3a3896d78d239361c8efc436173d5d0d0a202063a50c95d4f103448a782e167218c45a68ae44ab75c3c19367ab89df6c6159f20ab9562ef87fc35739bacd07b44d6edc951afd019f82d1bee874f4eef7f33eaf8055affa89948e74b514591ce348c0304f8738ec4a0538a65c2cc18bc6ec102e3ed360ff5857b625481947d4857060e12a97e214273df03f7de2d1e9b79231afbe1c5a8cc90934cadefe9b600fb36febd71f107b9275b22c130af4723a92a00c2a67b2583d1b4d5c03a6721bab338631cc34c7465015af934c57da63c10000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000 +0000000000000000000000000000000000000000000000000000000000000000 +cleartomark diff --git a/share/examples/BSD_daemon/poster.sh b/share/examples/BSD_daemon/poster.sh new file mode 100644 index 000000000000..c7a21216cb0d --- /dev/null +++ b/share/examples/BSD_daemon/poster.sh @@ -0,0 +1,65 @@ +#!/bin/sh +# ---------------------------------------------------------------------------- +# "THE BEER-WARE LICENSE" (Revision 42): +# <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you +# can do whatever you want with this stuff. If we meet some day, and you think +# this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp +# ---------------------------------------------------------------------------- +# +# $FreeBSD$ +# + +echo '%!' +echo '/beastie {' +cat beastie.eps +echo '} def' +cat FreeBSD.pfa + +echo ' + +/mm {25.4 div 72 mul} def +/FreeBSD findfont 120 scalefont setfont +/center 210 mm 2 div def +/top 297 mm def +/cshow { dup stringwidth pop 2 div neg 0 rmoveto show } def + +% "FreeBSD" across the top. +% 691 is "top - height of caps - (left - X("F"))" +center 691 moveto +(FreeBSD) cshow + +% Put beastie in the center +/sc 1.25 def +center 125 moveto +384 sc mul 2 div neg 0 rmoveto +gsave currentpoint translate sc sc scale beastie grestore + +% A box for the bottom text +gsave +10 10 moveto +210 mm 20 sub 0 rlineto +0 70 rlineto +210 mm 20 sub neg 0 rlineto +closepath +.7 .7 .9 setrgbcolor +fill +grestore + +% Bottom text +center 70 moveto +/NRBWelshGillianBold findfont 50 scalefont setfont + +center 30 moveto +(http://www.FreeBSD.org) cshow + +% Do not forget Kirks copyright string. +10 10 moveto +/Times-Roman findfont 8 scalefont setfont +(BSD Daemon ) show +/Symbol findfont 8 scalefont setfont +(\343 ) show +/Times-Roman findfont 8 scalefont setfont +(Copyright 1988 by Marshall Kirk McKusick. All Rights Reserved.) show + +showpage +' diff --git a/share/man/man5/make.conf.5 b/share/man/man5/make.conf.5 new file mode 100644 index 000000000000..dfe45fcdfb2d --- /dev/null +++ b/share/man/man5/make.conf.5 @@ -0,0 +1,772 @@ +.\" Copyright (c) 2000 +.\" Mike W. Meyer +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd November 3, 2000 +.Dt MAKE.CONF 5 +.Os +.Sh NAME +.Nm make.conf +.Nd system build information +.Sh DESCRIPTION +The file +.Nm +contains settings that control the compilation of the +.Fx +sources +and ported applications. +The file +.Nm +is generally created by the system administrator when the values need +to be changed from their defaults. +.Pp +The purpose of +.Nm +is not to run commands or perform compilation actions +directly. +Instead, it is included by the +various makefiles in +.Pa /usr/src , +.Pa /usr/ports +and +.Pa /usr/doc +which conditionalize their +internal actions according to the settings found there. +.Pp +The +.Pa /etc/make.conf +file is included from the the appropriate +.Pa Makefile +which specifies the default settings for all the available options. +Options need only be specified in +.Pa /etc/make.conf +when the system administrator wishes to override these defaults. +.Pp +The build procedures occur in four broad areas: the world, the kernel, +documentations and ports. +Variables set in +.Nm +may be applicable during builds in one, two, or all four of these +areas. +They may be specified for a particular build via the +.Fl D +option of +.Xr make 1 . +.Pp +The following lists provide a name and short description for each +variable you can use during the indicated builds. +The values of +variables flagged as +.Vt bool +are ignored; the variable being +set at all (even to +.Dq Li FALSE +or +.Dq Li NO ) +cause it to +be treated as if it were set. +.Pp +The following list provides a name and short description for variables +that are used for all builds, or are used by the +.Pa makefiles +for things other than builds. +.Bl -tag -width Ar +.It Va CFLAGS +.Vt ( str ) +Controls the compiler setting when compiling C code. +Optimization levels above +.Oo Fl O ( O2 , No ...\& ) Oc +are not supported. +.Va BDECFLAGS +is provided as a set of +.Xr gcc 1 +settings suggested by +.An "Bruce Evans" Aq bde@FreeBSD.org +for developing and testing changes. +They can be used by: +.Pp +.Bd -literal -offset indent +CXFLAGS+=${BDECFLAGS} +.Ed +.It Va CVS_UPDATE +.Vt ( bool ) +Set this to use +.Xr cvs 1 +to update your ports with +.Dq Li "make update" . +.It Va CXXFLAGS +.Vt ( str ) +Controls the compiler settings when compiling C++ code. +.Va CXXFLAGS +is initially set to the value of +.Va CFLAGS . +If you want to +add to the +.Va CXXFLAGS +value, use +.Dq Li += +instead of +.Dq Li = . +.It Va INSTALL +.Vt ( str ) +the default install command. +To have commands compared before doing +the install, use +.Bd -literal -offset indent +INSTALL="install -C" +.Ed +.It Va LOCAL_DIRS +.Vt ( str ) +List any directories that should be entered when doing +make's in +.Pa /usr/src +in this variable. +.It Va MTREE_FOLLOWS_SYMLINKS +.Vt ( str ) +Set this to +.Dq Fl L +to cause +.Xr mtree 8 +to follow symlinks. +.It Va NO_DOCUPDATE +.Vt ( bool ) +Set this to not update the doc tree during +.Dq Li "make update" . +.It Va NO_PORTSUPDATE +.Vt ( bool ) +Set this to not update the ports tree during +.Dq Li "make update" . +.It Va SUP_UPDATE +.Vt ( bool ) +Set this to use +.Xr cvsup 1 +to update your ports with +.Dq Li "make update" . +.It Va SUP +.Vt ( str ) +The location of the +.Xr cvsup 1 +command for +.Dq Li "make update" . +.It Va SUPFLAGS +.Vt ( str ) +The flag for the +.Xr sup 1 +command when doing +.Dq Li "make update" . +This defaults to +.Op Fl g L Ar 2 . +.It Va SUPHOST +.Vt ( str ) +The hostname of the sup server to use when doing +.Dq Li "make update" . +.It Va SUPFILE +.Vt ( str ) +The first +.Ar supfile +to use when doing a +.Dq Li "make update" . +This defaults to +.Pa /usr/share/examples/cvsup/standard\-supfile . +.It Va SUPFILE1 +.Vt ( str ) +The second +.Ar supfile +to use when doing a +.Dq Li "make update" . +This defaults to +.Pa /usr/share/examples/cvsup/secure\-supfile . +.It Va SUPFILE2 +.Vt ( str ) +The third +.Ar supfile +to use when doing a +.Dq Li "make update" . +This defaults to +.Pa /usr/share/examples/cvsup/secure\-supfile . +.It Va PORTSSUPFILE +.Vt ( str ) +The ports +.Ar supfile +to use when doing a +.Dq Li "make update" . +This defaults to +.Pa /usr/share/examples/cvsup/ports\-supfile . +.It Va DOCSUPFILE +.Vt ( str ) +The documentation +.Ar supfile +to use when doing a +.Dq Li "make update" . +This defaults to +.Pa /usr/share/examples/cvsup/doc\-supfile . +.El +.Pp +The following list provides a name and short description for variables +that are only used doing a kernel build: +.Bl -tag -width Ar +.It Va BOOT_COMCONSOLE_PORT +.Vt ( str ) +The port address to use for the console if the boot blocks have +been configured to use a serial console instead of the keyboard/video card. +.It Va BOOT_COMCONSOLE_SPEED +.Vt ( int ) +The baud rate to use for the console if the boot blocks have +been configured to use a serial console instead of the keyboard/video card. +.It Va BOOTWAIT +.Vt ( int ) +Controls the amount of time the kernel waits for a console keypress +before booting the default kernel. +The value is approximately milliseconds. +Keypresses are accepted by the BIOS before booting from disk, +making it possible to give custom boot parameters even when this is +set to 0. +.It Va COPTFLAGS +.Vt ( str ) +Controls the compiler settings when building the +kernel. +Optimization levels above +.Oo Fl O ( O2 , No ...\& ) Oc +are not supported. +.It Va KERNEL +.Vt ( str ) +Controls which kernel configurations will be +built by +.Dq Li "${MAKE} buildkernel" +and installed by +.Dq Li "${MAKE} installkernel" . +For example, +.Bd -literal -offset indent +KERNEL=MINE DEBUG GENERIC OTHERMACHINE +.Ed +.Pp +will build the the kernels specified by the config files +.Pa MINE , DEBUG , GENERIC , +and +.Pa OTHERMACHINE , +and install the kernel specified by the config file +.Pa MINE . +It defaults to +.Pa GENERIC . +.It Va NO_KERNELCONFIG +.Vt ( bool ) +Set this to skip running +.Xr config 8 +during +.Dq Li "${MAKE} buildkernel" . +.It Va NO_KERNELDEPEND +.Vt ( bool ) +Set this to skip running +.Dq Li "${MAKE} depend" +during +.Dq Li "${MAKE} buildkernel" . +.It Va NO_MODULES +.Vt ( bool ) +Set to not build modules with the kernel. +.El +.Pp +The following list provides a name and short description for variables +that are used during the world build: +.Bl -tag -width Ar +.It Va COMPAT1X +.Vt ( bool ) +Set to install the +.Fx +1 compatibility libraries. +.It Va COMPAT20 +.Vt ( bool ) +Set to install the +.Fx 2.0 +compatibility libraries. +.It Va COMPAT21 +.Vt ( bool ) +Set to install the +.Fx 2.1 +compatibility libraries. +.It Va COMPAT22 +.Vt ( bool ) +Set to install the +.Fx 2.2 +compatibility libraries. +.It Va COMPAT3X +.Vt ( bool ) +Set to install the +.Fx +3 +compatibility libraries. +.It Va ENABLE_SUIDPERL +.Vt ( bool ) +Set to enable the installation of an suid +.Xr perl 1 +binary. +.It Va FETCH_CMD +.Vt ( str ) +Command to use to fetch files. +Normally +.Xr fetch 1 . +.It Va MAKE_IDEA +.Vt ( bool ) +Set to build the IDEA encryption code. +This code is patented in the USA and many European countries. +It is +.Em "YOUR RESPONSIBILITY" +to determine if you can legally use IDEA. +.It Va MAKE_KERBEROS4 +.Vt ( bool ) +Set this to build KerberosIV (KTH eBones). +.It Va MAKE_KERBEROS5 +.Vt ( bool ) +Set this to build Kerberos5 (KTH Heimdal). +.Em WARNING ! +This is still experimental code. +If you need stable Kerberos5, use the +port(s). +.It Va MODULES_WITH_WORLD +.Vt ( bool ) +Set to build modules with the system instead of the kernel. +.It Va NO_CVS +.Vt ( bool ) +Set to not build CVS. +.It Va NO_BIND +.Vt ( bool ) +Set to not build BIND. +.It Va NO_FORTRAN +.Vt ( bool ) +Set to not build +.Xr g77 1 +and related libraries. +.It Va NO_LPR +.Vt ( bool ) +Set to not build +.Xr lpr 1 +and related programs. +.It Va NO_MAILWRAPPER +.Vt ( bool ) +Set to not build the +.Xr mailwrapper 8 +MTA selector. +.It Va NO_MAKEDEV +.Vt ( bool ) +Set to avoid running +.Dq Li "MAKEDEV all" +on +.Pa /dev +during install. +.It Va NO_OBJC +.Vt ( bool ) +Set to not build Objective C support. +.It Va NO_OPENSSH +.Vt ( bool ) +Set to not build OpenSSH. +.It Va NO_OPENSSL +.Vt ( bool ) +Set to not build OpenSSL (implies +.Va NO_OPENSSH ) . +.It Va NO_SENDMAIL +.Vt ( bool ) +Set to not build +.Xr sendmail 8 +and related programs. +.It Va NO_SHAREDOCS +.Vt ( bool ) +Set to not build the +.Bx 4.4 +legacy docs. +.It Va NO_TCSH +.Vt ( bool ) +Set to not build and install +.Pa /bin/csh +(which is +.Xr tcsh 1 ) . +.It Va NO_X +.Vt ( bool ) +Set to not compile in X\-Windows support (e.g.\& +.Xr doscmd 1 ) . +.It Va NOCLEAN +.Vt ( bool ) +Set this to disable cleaning during +.Dq Li "make buildworld" . +This should not be set unless you know what you are doing. +.It Va NOCLEANDIR +.Vt ( bool ) +Set this to run +.Dq Li "${MAKE} clean" +instead of +.Dq Li "${MAKE} cleandir" . +.It Va NOCRYPT +.Vt ( bool ) +Set to not build any crypto code. +.It Va NOGAMES +.Vt ( bool ) +Set to not build games. +.It Va NOINFO +.Vt ( bool ) +Set to not make or install +.Xr info 5 +files. +.It Va NOLIBC_R +.Vt ( bool ) +Set to not build +.Nm libc_r +(reentrant version of +.Nm libc ) . +.It Va NOMANCOMPRESS +.Vt ( bool ) +Set to install man pages uncompressed. +.It Va NOPERL +.Vt ( bool ) +Set to avoid building +.Xr perl 1 . +.It Va NOPROFILE +.Vt ( bool ) +Set to avoid compiling profiled libraries. +.It Va NOSECURE +.Vt ( bool ) +set to not build crypto code in +.Pa secure +subdir. +.It Va NOSHARE +.Vt ( bool ) +Set to not build in the +.Pa share +subdir. +.It Va NOUUCP +.Vt ( bool ) +Set to not build +.Xr uucp 1 +related programs. +.It Va PERL_THREADED +.Vt ( bool ) +Set to enable the building and installation of +.Xr perl 1 +with thread +support. +.It Va PPP_NOSUID +.Vt ( bool ) +Set to disable the installation of +.Xr ppp 8 +as an suid root program. +.It Va SENDMAIL_MC +.Vt ( str ) +The default m4 configuration file to use at install time. +The value should include the full path to the .mc file, e.g., +.Pa /etc/mail/myconfig.mc . +Use with caution as a make install will overwrite any existing +.Pa /etc/mail/sendmail.cf . +Note that +.Va SENDMAIL_CF +is now deprecated. +.It Va SENDMAIL_ADDITIONAL_MC +.Vt ( str ) +Additional .mc files which should be built into .cf files at build time. +The value should include the full path to the .mc file(s), e.g., +.Pa /etc/mail/foo.mc +.Pa /etc/mail/bar.mc . +.It Va SENDMAIL_CFLAGS +.Vt ( str ) +Flags to pass to the compile command when building +.Xr sendmail 8 . +The +.Va SENDMAIL_* +flags can be used to provide SASL support with setting such as: +.Bd -literal -offset indent +SENDMAIL_CFLAGS=-I/usr/local/include -DSASL +SENDMAIL_LDFLAGS=-L/usr/local/lib +SENDMAIL_LDADD=-lsasl +.Ed +.It Va SENDMAIL_LDFLAGS +.Vt ( str ) +Flags to pass to the +.Xr ld 1 +command when building +.Xr sendmail 8 . +.It Va SENDMAIL_LDADD +.Vt ( str ) +Flags to add to the end of the +.Xr ld 1 +command when building +.Xr sendmail 8 . +.It Va SENDMAIL_DPADD +.Vt ( str ) +This variable is undocumented. +.El +.Pp +The following list provides a name and short description for variables +that are used when building documentation. +.Bl -tag -width Ar +.It Va DISTDIR +.Vt ( str ) +Where distfiles are kept. +Normally, this is +.Pa distfiles +in +.Va PORTSDIR . +.It Va DOC_LANG +.Vt ( str ) +The list of languages and encodings to build and install. +.It Va PRINTERDEVICE +.Vt ( str ) +The default format for system documentation, depends on your +printer. +This can be set to +.Dq Li ascii +for simple printers or +.Dq Li ps +for postscript or graphics printers with a ghostscript +filter. +.El +.Pp +The following list provides a name and short description for variables +that are used when building ports: +.Bl -tag -width Ar +.It Va FORCE_PKG_RESIDENT +.Vt ( bool ) +Set this to override any existing package registration. +.It Va HAVE_MOTIF +.Vt ( bool ) +Set this if you have Motif on your system. +.It Va KRB5_HOME +.Vt ( str ) +Set this if you want to install the MIT Kerberos5 port somewhere +other than +.Pa /usr/local . +.It Va LOCALBASE +.Vt ( str ) +Set this to the base directory that non\-X ports should be +installed in. +It provides the default for +.Va PREFIX +when building in +.Pa /usr/ports . +.It Va MASTER_SITE_AFTERSTEP +.Vt ( str ) +Set this to change the master site for AfterStep ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MASTER_SITE_BACKUP +.Vt ( str ) +Controls the site location that ports check for distfiles if the +locations listed in their +.Pa Makefile +do not work. +The last part of the path must be +.Dq Li /${DIST_SUBDIR}/ . +.It Va MASTER_SITE_COMP_SOURCES +.Vt ( str ) +Controls the master site location for +.Pa comp.sources +ports. +The +last part of the path must be +.Dq Li %SUBDIR%/ +.It Va MASTER_SITE_GNOME +.Vt ( str ) +Controls the master site location for GNOME ports. +The +last part of the path must be +.Dq Li /%SUBDIR%/ +.It Va MASTER_SITE_GNU +.Vt ( str ) +Controls the master site location for GNU ports. +The +last part of the path must be +.Dq Li /%SUBDIR%/ +.It Va MASTER_SITE_KDE +.Vt ( str ) +Controls the master site location for KDE ports. +The +last part of the path must be +.Dq Li /%SUBDIR%/ +.It Va MASTER_SITE_FREEBSD +.Vt ( bool ) +If set, go to the master +.Fx +site for all files. +.It Va MASTER_SITE_MOZILLA +.Vt ( str ) +Controls the master site location for Mozilla ports. +The +last part of the path must be +.Dq Li /%SUBDIR%/ +.It Va MASTER_SITE_OVERRIDE +.Vt ( str ) +If set, this site is checked before the sites listed in the ports +.Pa Makefile . +You can have it check the backup site first by like so: +.Bd -literal -offset indent +MASTER_SITE_OVERRIDE?= ${MASTER_SITE_BACKUP} +.Ed +.It Va MASTER_SITE_PERL_CPAN +.Vt ( str ) +Controls the master site location for Perl ports. +The +last part of the path must be +.Bd -literal -offset indent +/%SUBDIR%/ +.Ed +.It Va MASTER_SORT_REGEX +.Vt ( str ) +Set this to control the sort order for mirror sets. +To set it to +prefer mirrors in the +.Pa .jp +domain, use: +.Bd -literal -offset indent +MASTER_SORT_REGEX?= ^file: ^ftp://ftp\.FreeBSD\.org/pub/FreeBSD/ports/local-distfiles/ ://[^/]*\.jp/ ://[^/]*\.jp\. +.Ed +.Pp +Users of other ccTLD domains should change the +.Dq Li jp +to the +appropriate domain. +.It Va MASTER_SITE_RINGSERVER +.Vt ( str ) +Controls the master site location for Ringserver ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MASTER_SITE_RUBY +.Vt ( str ) +Controls the master site location for Ruby ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MASTER_SITE_SUNSITE +.Vt ( str ) +Controls the master site location for Sunsite ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MASTER_SITE_TCLTK +.Vt ( str ) +Controls the master site location for Tcl and Tk ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MASTER_SITE_TEX_CTAN +.Vt ( str ) +Controls the master site location for TeX ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MASTER_SITE_WINDOWMAKER +.Vt ( str ) +Controls the master site location for WindowMaker ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MASTER_SITE_XCONTRIB +.Vt ( str ) +Controls the master site location for contributed X ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MASTER_SITE_XEMACS +.Vt ( str ) +Controls the master site location for Xemacs ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MASTER_SITE_XFREE +.Vt ( str ) +Controls the master site location for XFree ports. +The last +part of the path must be +.Dq Li /%SUBDIR%/ . +.It Va MOTIFLIB +.Vt ( str ) +Location of +.Pa libXm.a +and +.Pa libXm.so . +.It Va MOTIF_STATIC +.Vt ( bool ) +Set this if you want ports that use Motif to be built so they +can be run on systems without the Motif shared libraries. +.It Va NOCLEANDEPENDS +.Vt ( bool ) +Set this to prevent +.Dq Li "make clean" +from cleaning the ports that the one being cleaned depends on. +.It Va NOPORTDOCS +.Vt ( bool ) +Set this to disable installing additional documentation with ports. +.It Va PACKAGES +.Vt ( str ) +Used only for the package target; the directory for the package tree. +.It Va PATCH_SITES +.Vt ( str ) +Primary location(s) for the distribution of patch files. +.It Va PORTSDIR +.Vt ( str ) +The location of the ports tree. +.It Va USA_RESIDENT +.Vt ( bool ) +Set this if you are a resident of the USA so that ports that +need to can attempt to comply with U.S. export regulations. +.It Va WRKDIRPREFIX +.Vt ( str ) +Where to create temporary files used when building ports. +.It Va X11BASE +.Vt ( str ) +Should be set to where the X11 distribution has been +installed if it is installed anywhere other than +.Pa /usr/X11R6 . +.El +.Sh FILES +.Bl -tag -width /etc/defaults/make.conf -compact +.It Pa /etc/defaults/make.conf +.It Pa /etc/make.conf +.It Pa /usr/doc/Makefile +.It Pa /usr/src/Makefile +.It Pa /usr/src/Makefile.inc1 +.It Pa /usr/ports/Mk/bsd.port.mk +.It Pa /usr/ports/Mk/bsd.sites.mk +.El +.Sh SEE ALSO +.Xr gcc 1 , +.Xr install 1 , +.Xr lpd 8 , +.Xr make 1 , +.Xr make 7 , +.Xr ports 7 , +.Xr sendmail 8 +.Sh HISTORY +The +.Nm +file appeared sometime before +.Fx 4.0 . +.Sh AUTHORS +This +manual page was written by +.An Mike W. Meyer Aq mwm@mired.org . +.Sh BUGS +This manual page may occasionally be out of date with respect to +the options currently available for use in +.Nm . +Please check the +.Pa /etc/defaults/make.conf +file for the latest options which are available. diff --git a/share/monetdef/af_ZA.ISO8859-1.src b/share/monetdef/af_ZA.ISO8859-1.src new file mode 100644 index 000000000000..4a17750e0a0f --- /dev/null +++ b/share/monetdef/af_ZA.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +ZAR +# currency_symbol +R +# mon_decimal_point +, +# mon_thousands_sep +. +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/da_DK.ISO8859-1.src b/share/monetdef/da_DK.ISO8859-1.src new file mode 100644 index 000000000000..a18b4cb4b014 --- /dev/null +++ b/share/monetdef/da_DK.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +DKK +# currency_symbol +kr +# mon_decimal_point +, +# mon_thousands_sep +. +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +2 +# n_cs_precedes +1 +# n_sep_by_space +2 +# p_sign_posn +4 +# n_sign_posn +4 +# EOF diff --git a/share/monetdef/en_AU.ISO8859-1.src b/share/monetdef/en_AU.ISO8859-1.src new file mode 100644 index 000000000000..826108915d36 --- /dev/null +++ b/share/monetdef/en_AU.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +AUD +# currency_symbol +$ +# mon_decimal_point +. +# mon_thousands_sep +, +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/en_CA.ISO8859-1.src b/share/monetdef/en_CA.ISO8859-1.src new file mode 100644 index 000000000000..75e31f60cc5d --- /dev/null +++ b/share/monetdef/en_CA.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +CAD +# currency_symbol +$ +# mon_decimal_point +. +# mon_thousands_sep +, +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/en_GB.ISO8859-1.src b/share/monetdef/en_GB.ISO8859-1.src new file mode 100644 index 000000000000..a0472d307968 --- /dev/null +++ b/share/monetdef/en_GB.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +GBP +# currency_symbol +£ +# mon_decimal_point +. +# mon_thousands_sep +, +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/en_NZ.ISO8859-1.src b/share/monetdef/en_NZ.ISO8859-1.src new file mode 100644 index 000000000000..1cb82617599f --- /dev/null +++ b/share/monetdef/en_NZ.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +NZD +# currency_symbol +$ +# mon_decimal_point +. +# mon_thousands_sep +, +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/en_US.ISO8859-1.src b/share/monetdef/en_US.ISO8859-1.src new file mode 100644 index 000000000000..faf42e5ae780 --- /dev/null +++ b/share/monetdef/en_US.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +USD +# currency_symbol +$ +# mon_decimal_point +. +# mon_thousands_sep +, +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/fr_CA.ISO8859-1.src b/share/monetdef/fr_CA.ISO8859-1.src new file mode 100644 index 000000000000..64ff444dae09 --- /dev/null +++ b/share/monetdef/fr_CA.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +CAD +# currency_symbol +$ +# mon_decimal_point +, +# mon_thousands_sep + +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +0 +# p_sep_by_space +1 +# n_cs_precedes +0 +# n_sep_by_space +1 +# p_sign_posn +1 +# n_sign_posn +2 +# EOF diff --git a/share/monetdef/hu_HU.ISO8859-2.src b/share/monetdef/hu_HU.ISO8859-2.src new file mode 100644 index 000000000000..183f155d2c3e --- /dev/null +++ b/share/monetdef/hu_HU.ISO8859-2.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +HUF +# currency_symbol +Ft +# mon_decimal_point +, +# mon_thousands_sep + +# mon_grouping +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +2 +# n_cs_precedes +1 +# n_sep_by_space +2 +# p_sign_posn +4 +# n_sign_posn +4 +# EOF diff --git a/share/monetdef/is_IS.ISO8859-1.src b/share/monetdef/is_IS.ISO8859-1.src new file mode 100644 index 000000000000..66a80374e449 --- /dev/null +++ b/share/monetdef/is_IS.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +ISK +# currency_symbol +kr +# mon_decimal_point +, +# mon_thousands_sep +. +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +0 +# p_sep_by_space +1 +# n_cs_precedes +0 +# n_sep_by_space +1 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/ja_JP.eucJP.src b/share/monetdef/ja_JP.eucJP.src new file mode 100644 index 000000000000..462a88dc286c --- /dev/null +++ b/share/monetdef/ja_JP.eucJP.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +JPY +# currency_symbol +\ +# mon_decimal_point +. +# mon_thousands_sep +, +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +0 +# frac_digits +0 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +4 +# EOF diff --git a/share/monetdef/ko_KR.eucKR.src b/share/monetdef/ko_KR.eucKR.src new file mode 100644 index 000000000000..0723dfa24596 --- /dev/null +++ b/share/monetdef/ko_KR.eucKR.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +KRW +# currency_symbol +\ +# mon_decimal_point +. +# mon_thousands_sep +, +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +0 +# frac_digits +0 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +4 +# EOF diff --git a/share/monetdef/no_NO.ISO8859-1.src b/share/monetdef/no_NO.ISO8859-1.src new file mode 100644 index 000000000000..181953389aa1 --- /dev/null +++ b/share/monetdef/no_NO.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +NOK +# currency_symbol +kr +# mon_decimal_point +, +# mon_thousands_sep +. +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +4 +# n_sign_posn +4 +# EOF diff --git a/share/monetdef/pl_PL.ISO8859-2.src b/share/monetdef/pl_PL.ISO8859-2.src new file mode 100644 index 000000000000..b749031e9960 --- /dev/null +++ b/share/monetdef/pl_PL.ISO8859-2.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +PLN +# currency_symbol +z³ +# mon_decimal_point +, +# mon_thousands_sep + +# mon_grouping +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +1 +# p_sep_by_space +2 +# n_cs_precedes +1 +# n_sep_by_space +2 +# p_sign_posn +4 +# n_sign_posn +4 +# EOF diff --git a/share/monetdef/ru_RU.CP866.src b/share/monetdef/ru_RU.CP866.src new file mode 100644 index 000000000000..cae485aa7d8f --- /dev/null +++ b/share/monetdef/ru_RU.CP866.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +RUR +# currency_symbol +àã¡. +# mon_decimal_point +, +# mon_thousands_sep + +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +0 +# p_sep_by_space +1 +# n_cs_precedes +0 +# n_sep_by_space +1 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/ru_RU.ISO8859-5.src b/share/monetdef/ru_RU.ISO8859-5.src new file mode 100644 index 000000000000..0f14f0e8ba0d --- /dev/null +++ b/share/monetdef/ru_RU.ISO8859-5.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +RUR +# currency_symbol +àãÑ. +# mon_decimal_point +, +# mon_thousands_sep + +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +0 +# p_sep_by_space +1 +# n_cs_precedes +0 +# n_sep_by_space +1 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/ru_RU.KOI8-R.src b/share/monetdef/ru_RU.KOI8-R.src new file mode 100644 index 000000000000..e4064bc19693 --- /dev/null +++ b/share/monetdef/ru_RU.KOI8-R.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +RUR +# currency_symbol +ÒÕÂ. +# mon_decimal_point +, +# mon_thousands_sep + +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +0 +# p_sep_by_space +1 +# n_cs_precedes +0 +# n_sep_by_space +1 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/sv_SE.ISO8859-1.src b/share/monetdef/sv_SE.ISO8859-1.src new file mode 100644 index 000000000000..a835567ef9be --- /dev/null +++ b/share/monetdef/sv_SE.ISO8859-1.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +SEK +# currency_symbol +kr +# mon_decimal_point +, +# mon_thousands_sep + +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +0 +# p_sep_by_space +1 +# n_cs_precedes +0 +# n_sep_by_space +1 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/uk_UA.KOI8-U.src b/share/monetdef/uk_UA.KOI8-U.src new file mode 100644 index 000000000000..5464d142d093 --- /dev/null +++ b/share/monetdef/uk_UA.KOI8-U.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +UAH +# currency_symbol +ÇÒÎ. +# mon_decimal_point +, +# mon_thousands_sep + +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +2 +# frac_digits +2 +# p_cs_precedes +0 +# p_sep_by_space +1 +# n_cs_precedes +0 +# n_sep_by_space +1 +# p_sign_posn +1 +# n_sign_posn +1 +# EOF diff --git a/share/monetdef/zh_CN.eucCN.src b/share/monetdef/zh_CN.eucCN.src new file mode 100644 index 000000000000..3f5fc2409c1e --- /dev/null +++ b/share/monetdef/zh_CN.eucCN.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +CNY +# currency_symbol +£¤ +# mon_decimal_point +. +# mon_thousands_sep +, +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +0 +# frac_digits +0 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +4 +# EOF diff --git a/share/monetdef/zh_TW.Big5.src b/share/monetdef/zh_TW.Big5.src new file mode 100644 index 000000000000..1e86417df204 --- /dev/null +++ b/share/monetdef/zh_TW.Big5.src @@ -0,0 +1,36 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# int_curr_symbol (last character always SPACE) +TWD +# currency_symbol +NT$ +# mon_decimal_point +. +# mon_thousands_sep +, +# mon_grouping, separated by ; +3;3 +# positive_sign + +# negative_sign +- +# int_frac_digits +0 +# frac_digits +0 +# p_cs_precedes +1 +# p_sep_by_space +0 +# n_cs_precedes +1 +# n_sep_by_space +0 +# p_sign_posn +1 +# n_sign_posn +4 +# EOF diff --git a/share/msgdef/cs_CZ.ISO8859-2.src b/share/msgdef/cs_CZ.ISO8859-2.src new file mode 100644 index 000000000000..a6fc83634397 --- /dev/null +++ b/share/msgdef/cs_CZ.ISO8859-2.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[aAyY].* +# noexpr +^[nN].* +# yesstr +ano +# nostr +ne +# EOF diff --git a/share/msgdef/el_GR.ISO8859-7.src b/share/msgdef/el_GR.ISO8859-7.src new file mode 100644 index 000000000000..85d433e990cf --- /dev/null +++ b/share/msgdef/el_GR.ISO8859-7.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[íÍyY].* +# noexpr +^[ïÏnN].* +# yesstr +ÍÁÉ +# nostr +Ï×É +# EOF diff --git a/share/msgdef/hu_HU.ISO8859-2.src b/share/msgdef/hu_HU.ISO8859-2.src new file mode 100644 index 000000000000..4f009c700567 --- /dev/null +++ b/share/msgdef/hu_HU.ISO8859-2.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[iIyY].* +# noexpr +^[nN].* +# yesstr +igen +# nostr +nem +# EOF diff --git a/share/msgdef/ja_JP.eucJP.src b/share/msgdef/ja_JP.eucJP.src new file mode 100644 index 000000000000..2f06e015abae --- /dev/null +++ b/share/msgdef/ja_JP.eucJP.src @@ -0,0 +1,10 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[yY£ù£Ù¤Ï¥Ï].* +# noexpr +^[nN£î£Î¤¤¥¤].* +# EOF diff --git a/share/msgdef/ko_KR.eucKR.src b/share/msgdef/ko_KR.eucKR.src new file mode 100644 index 000000000000..e839a0a217ba --- /dev/null +++ b/share/msgdef/ko_KR.eucKR.src @@ -0,0 +1,10 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[sSyY].* +# noexpr +^[nN].* +# EOF diff --git a/share/msgdef/pl_PL.ISO8859-2.src b/share/msgdef/pl_PL.ISO8859-2.src new file mode 100644 index 000000000000..a7acd2adf1f0 --- /dev/null +++ b/share/msgdef/pl_PL.ISO8859-2.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[tTyY].* +# noexpr +^[nN].* +# yesstr +tak +# nostr +nie +# EOF diff --git a/share/msgdef/ru_RU.CP866.src b/share/msgdef/ru_RU.CP866.src new file mode 100644 index 000000000000..df2b035bb4b6 --- /dev/null +++ b/share/msgdef/ru_RU.CP866.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[¤„yY].* +# noexpr +^[nN].* +# yesstr +¤ +# nostr +½â +# EOF diff --git a/share/msgdef/ru_RU.ISO8859-5.src b/share/msgdef/ru_RU.ISO8859-5.src new file mode 100644 index 000000000000..360485e980e4 --- /dev/null +++ b/share/msgdef/ru_RU.ISO8859-5.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[Ô´yY].* +# noexpr +^[ݽnN].* +# yesstr +ÔÐ +# nostr +ÝÕâ +# EOF diff --git a/share/msgdef/ru_RU.KOI8-R.src b/share/msgdef/ru_RU.KOI8-R.src new file mode 100644 index 000000000000..465cfa69f259 --- /dev/null +++ b/share/msgdef/ru_RU.KOI8-R.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[ÄäyY].* +# noexpr +^[ÎînN].* +# yesstr +ÄÁ +# nostr +ÎÅÔ +# EOF diff --git a/share/msgdef/uk_UA.KOI8-U.src b/share/msgdef/uk_UA.KOI8-U.src new file mode 100644 index 000000000000..5eec97264d5d --- /dev/null +++ b/share/msgdef/uk_UA.KOI8-U.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[ÔôyY].* +# noexpr +^[ÎînN].* +# yesstr +ÔÁË +# nostr +Φ +# EOF diff --git a/share/msgdef/zh_CN.eucCN.src b/share/msgdef/zh_CN.eucCN.src new file mode 100644 index 000000000000..6e9cd83e04e3 --- /dev/null +++ b/share/msgdef/zh_CN.eucCN.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[yY£ù£ÙÊÇ].* +# noexpr +^[nN£î£Î²»·ñ].* +# yesstr +ÊÇ +# nostr +·ñ +# EOF diff --git a/share/msgdef/zh_TW.Big5.src b/share/msgdef/zh_TW.Big5.src new file mode 100644 index 000000000000..cc1bfce72027 --- /dev/null +++ b/share/msgdef/zh_TW.Big5.src @@ -0,0 +1,14 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# yesexpr +^[yY£B¢ç¬O].* +# noexpr +^[nN¢ö¢Ü¤£§_].* +# yesstr +¬O +# nostr +§_ +# EOF diff --git a/share/numericdef/af_ZA.ISO8859-1.src b/share/numericdef/af_ZA.ISO8859-1.src new file mode 100644 index 000000000000..9c48fd3b1593 --- /dev/null +++ b/share/numericdef/af_ZA.ISO8859-1.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep +. +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/cs_CZ.ISO8859-2.src b/share/numericdef/cs_CZ.ISO8859-2.src new file mode 100644 index 000000000000..68677812c355 --- /dev/null +++ b/share/numericdef/cs_CZ.ISO8859-2.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep + +# grouping +3;3 +# EOF diff --git a/share/numericdef/da_DK.ISO8859-1.src b/share/numericdef/da_DK.ISO8859-1.src new file mode 100644 index 000000000000..9c48fd3b1593 --- /dev/null +++ b/share/numericdef/da_DK.ISO8859-1.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep +. +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/el_GR.ISO8859-7.src b/share/numericdef/el_GR.ISO8859-7.src new file mode 100644 index 000000000000..ee9ee5b4d15e --- /dev/null +++ b/share/numericdef/el_GR.ISO8859-7.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep +. +# grouping +-1 +# EOF diff --git a/share/numericdef/en_US.ISO8859-1.src b/share/numericdef/en_US.ISO8859-1.src new file mode 100644 index 000000000000..cd49d3608dc5 --- /dev/null +++ b/share/numericdef/en_US.ISO8859-1.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +. +# thousands_sep +, +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/fi_FI.ISO8859-1.src b/share/numericdef/fi_FI.ISO8859-1.src new file mode 100644 index 000000000000..9c48fd3b1593 --- /dev/null +++ b/share/numericdef/fi_FI.ISO8859-1.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep +. +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/hu_HU.ISO8859-2.src b/share/numericdef/hu_HU.ISO8859-2.src new file mode 100644 index 000000000000..68677812c355 --- /dev/null +++ b/share/numericdef/hu_HU.ISO8859-2.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep + +# grouping +3;3 +# EOF diff --git a/share/numericdef/is_IS.ISO8859-1.src b/share/numericdef/is_IS.ISO8859-1.src new file mode 100644 index 000000000000..4ebc899962aa --- /dev/null +++ b/share/numericdef/is_IS.ISO8859-1.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep + +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/ja_JP.eucJP.src b/share/numericdef/ja_JP.eucJP.src new file mode 100644 index 000000000000..cd49d3608dc5 --- /dev/null +++ b/share/numericdef/ja_JP.eucJP.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +. +# thousands_sep +, +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/ko_KR.eucKR.src b/share/numericdef/ko_KR.eucKR.src new file mode 100644 index 000000000000..cd49d3608dc5 --- /dev/null +++ b/share/numericdef/ko_KR.eucKR.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +. +# thousands_sep +, +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/no_NO.ISO8859-1.src b/share/numericdef/no_NO.ISO8859-1.src new file mode 100644 index 000000000000..9c48fd3b1593 --- /dev/null +++ b/share/numericdef/no_NO.ISO8859-1.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep +. +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/pl_PL.ISO8859-2.src b/share/numericdef/pl_PL.ISO8859-2.src new file mode 100644 index 000000000000..68677812c355 --- /dev/null +++ b/share/numericdef/pl_PL.ISO8859-2.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep + +# grouping +3;3 +# EOF diff --git a/share/numericdef/ru_RU.CP866.src b/share/numericdef/ru_RU.CP866.src new file mode 100644 index 000000000000..4ebc899962aa --- /dev/null +++ b/share/numericdef/ru_RU.CP866.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep + +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/ru_RU.ISO8859-5.src b/share/numericdef/ru_RU.ISO8859-5.src new file mode 100644 index 000000000000..4ebc899962aa --- /dev/null +++ b/share/numericdef/ru_RU.ISO8859-5.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep + +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/ru_RU.KOI8-R.src b/share/numericdef/ru_RU.KOI8-R.src new file mode 100644 index 000000000000..4ebc899962aa --- /dev/null +++ b/share/numericdef/ru_RU.KOI8-R.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep + +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/sv_SE.ISO8859-1.src b/share/numericdef/sv_SE.ISO8859-1.src new file mode 100644 index 000000000000..4ebc899962aa --- /dev/null +++ b/share/numericdef/sv_SE.ISO8859-1.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep + +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/uk_UA.KOI8-U.src b/share/numericdef/uk_UA.KOI8-U.src new file mode 100644 index 000000000000..4ebc899962aa --- /dev/null +++ b/share/numericdef/uk_UA.KOI8-U.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +, +# thousands_sep + +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/zh_CN.eucCN.src b/share/numericdef/zh_CN.eucCN.src new file mode 100644 index 000000000000..cd49d3608dc5 --- /dev/null +++ b/share/numericdef/zh_CN.eucCN.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +. +# thousands_sep +, +# grouping, separated by ; +3;3 +# EOF diff --git a/share/numericdef/zh_TW.Big5.src b/share/numericdef/zh_TW.Big5.src new file mode 100644 index 000000000000..cd49d3608dc5 --- /dev/null +++ b/share/numericdef/zh_TW.Big5.src @@ -0,0 +1,12 @@ +# $FreeBSD$ +# +# WARNING: spaces may be essential at the end of lines +# WARNING: empty lines are essential too +# +# decimal_point +. +# thousands_sep +, +# grouping, separated by ; +3;3 +# EOF diff --git a/sys/dev/mly/mlyio.h b/sys/dev/mly/mlyio.h new file mode 100644 index 000000000000..949b071c487e --- /dev/null +++ b/sys/dev/mly/mlyio.h @@ -0,0 +1,72 @@ +/*- + * Copyright (c) 2001 Michael Smith + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/******************************************************************************** + * Control structures exchanged through the GAM interface with userland + * management tools. + * + * The member naming here is consistent with the Linux driver, with which this + * interface is basically compatible. + */ +struct mly_user_command +{ + unsigned char ControllerNumber; + union mly_command_packet CommandMailbox; + int DataTransferLength; + int RequestSenseLength; + void *DataTransferBuffer; + void *RequestSenseBuffer; + int CommandStatus; /* not in the Linux structure */ +}; + +#define MLYIO_COMMAND _IOWR('M', 200, struct mly_user_command) + +struct mly_user_health +{ + unsigned char ControllerNumber; + void *HealthStatusBuffer; +}; + +#define MLYIO_HEALTH _IOW('M', 201, struct mly_user_health) + +/* + * Command queue statistics + */ + +#define MLYQ_FREE 0 +#define MLYQ_CCB 1 +#define MLYQ_READY 2 +#define MLYQ_BUSY 3 +#define MLYQ_COMPLETE 4 +#define MLYQ_COUNT 5 + +struct mly_qstat +{ + u_int32_t q_length; + u_int32_t q_max; +}; diff --git a/sys/dev/sound/pci/cs4281.c b/sys/dev/sound/pci/cs4281.c new file mode 100644 index 000000000000..41eb8104c687 --- /dev/null +++ b/sys/dev/sound/pci/cs4281.c @@ -0,0 +1,971 @@ +/* + * Copyright (c) 2000 Orion Hodson <O.Hodson@cs.ucl.ac.uk> + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHERIN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THEPOSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + * + * The order of pokes in the initiation sequence is based on Linux + * driver by Thomas Sailer, gw boynton (wesb@crystal.cirrus.com), tom + * woller (twoller@crystal.cirrus.com). Shingo Watanabe (nabe@nabechan.org) + * contributed towards power management. + */ + +#include <dev/sound/pcm/sound.h> +#include <dev/sound/pcm/ac97.h> + +#include <pci/pcireg.h> +#include <pci/pcivar.h> + +#include <dev/sound/pci/cs4281.h> + +#define CS4281_BUFFER_SIZE 16384 + +/* Max fifo size for full duplex is 64 */ +#define CS4281_FIFO_SIZE 15 + +/* DMA Engine Indices */ +#define CS4281_DMA_PLAY 0 +#define CS4281_DMA_REC 1 + +/* Misc */ + +#define MIN(x,y) (x) < (y) ? (x) : (y) +#define MAX(x,y) (x) > (y) ? (x) : (y) + +#define inline __inline + +#ifndef DEB +#define DEB(x) /* x */ +#endif /* DEB */ + +/* ------------------------------------------------------------------------- */ +/* Structures */ + +struct sc_info; + +/* channel registers */ +struct sc_chinfo { + struct sc_info *parent; + + snd_dbuf *buffer; + pcm_channel *channel; + + u_int32_t spd, fmt, bps, blksz; + + int dma_setup, dma_active, dma_chan; +}; + +/* device private data */ +struct sc_info { + device_t dev; + u_int32_t type; + + bus_space_tag_t st; + bus_space_handle_t sh; + bus_dma_tag_t parent_dmat; + + struct resource *reg, *irq, *mem; + int regtype, regid, irqid, memid; + void *ih; + + int power; + struct sc_chinfo pch; + struct sc_chinfo rch; +}; + +/* -------------------------------------------------------------------- */ +/* prototypes */ + +/* ADC/DAC control */ +static u_int32_t adcdac_go(struct sc_chinfo *ch, u_int32_t go); +static void adcdac_prog(struct sc_chinfo *ch); + +/* power management and interrupt control */ +static void cs4281_intr(void *); +static int cs4281_power(struct sc_info *, int); +static int cs4281_init(struct sc_info *); + +/* talk to the card */ +static u_int32_t cs4281_rd(struct sc_info *, int); +static void cs4281_wr(struct sc_info *, int, u_int32_t); + +/* misc */ +static u_int8_t cs4281_rate_to_rv(u_int32_t); +static u_int32_t cs4281_format_to_dmr(u_int32_t); +static u_int32_t cs4281_format_to_bps(u_int32_t); + +/* -------------------------------------------------------------------- */ +/* formats (do not add formats without editing cs_fmt_tab) */ + +static u_int32_t cs4281_fmts[] = { + AFMT_U8, + AFMT_U8 | AFMT_STEREO, + AFMT_S8, + AFMT_S8 | AFMT_STEREO, + AFMT_S16_LE, + AFMT_S16_LE | AFMT_STEREO, + AFMT_U16_LE, + AFMT_U16_LE | AFMT_STEREO, + AFMT_S16_BE, + AFMT_S16_BE | AFMT_STEREO, + AFMT_U16_BE, + AFMT_U16_BE | AFMT_STEREO, + 0 +}; + +static pcmchan_caps cs4281_caps = {6024, 48000, cs4281_fmts, 0}; + +/* -------------------------------------------------------------------- */ +/* Hardware */ + +static inline u_int32_t +cs4281_rd(struct sc_info *sc, int regno) +{ + return bus_space_read_4(sc->st, sc->sh, regno); +} + +static inline void +cs4281_wr(struct sc_info *sc, int regno, u_int32_t data) +{ + bus_space_write_4(sc->st, sc->sh, regno, data); + DELAY(100); +} + +static inline void +cs4281_clr4(struct sc_info *sc, int regno, u_int32_t mask) +{ + u_int32_t r; + r = cs4281_rd(sc, regno); + cs4281_wr(sc, regno, r & ~mask); +} + +static inline void +cs4281_set4(struct sc_info *sc, int regno, u_int32_t mask) +{ + u_int32_t v; + v = cs4281_rd(sc, regno); + cs4281_wr(sc, regno, v | mask); +} + +static int +cs4281_waitset(struct sc_info *sc, int regno, u_int32_t mask, int tries) +{ + u_int32_t v; + + while(tries > 0) { + DELAY(100); + v = cs4281_rd(sc, regno); + if ((v & mask) == mask) break; + tries --; + } + return tries; +} + +static int +cs4281_waitclr(struct sc_info *sc, int regno, u_int32_t mask, int tries) +{ + u_int32_t v; + + while(tries > 0) { + DELAY(100); + v = ~ cs4281_rd(sc, regno); + if (v & mask) break; + tries --; + } + return tries; +} + +/* ------------------------------------------------------------------------- */ +/* Register value mapping functions */ + +static u_int32_t cs4281_rates[] = {48000, 44100, 22050, 16000, 11025, 8000}; +#define CS4281_NUM_RATES sizeof(cs4281_rates)/sizeof(cs4281_rates[0]) + +static u_int8_t +cs4281_rate_to_rv(u_int32_t rate) +{ + u_int32_t v; + + for (v = 0; v < CS4281_NUM_RATES; v++) { + if (rate == cs4281_rates[v]) return v; + } + + v = 1536000 / rate; + if (v > 255 || v < 32) v = 5; /* default to 8k */ + return v; +} + +static u_int32_t +cs4281_rv_to_rate(u_int8_t rv) +{ + u_int32_t r; + + if (rv < CS4281_NUM_RATES) return cs4281_rates[rv]; + r = 1536000 / rv; + return r; +} + +static inline u_int32_t +cs4281_format_to_dmr(u_int32_t format) +{ + u_int32_t dmr = 0; + if (AFMT_8BIT & format) dmr |= CS4281PCI_DMR_SIZE8; + if (!(AFMT_STEREO & format)) dmr |= CS4281PCI_DMR_MONO; + if (AFMT_BIGENDIAN & format) dmr |= CS4281PCI_DMR_BEND; + if (!(AFMT_SIGNED & format)) dmr |= CS4281PCI_DMR_USIGN; + return dmr; +} + +static inline u_int32_t +cs4281_format_to_bps(u_int32_t format) +{ + return ((AFMT_8BIT & format) ? 1 : 2) * ((AFMT_STEREO & format) ? 2 : 1); +} + +/* -------------------------------------------------------------------- */ +/* ac97 codec */ + +static u_int32_t +cs4281_rdcd(kobj_t obj, void *devinfo, int regno) +{ + struct sc_info *sc = (struct sc_info *)devinfo; + int codecno; + + codecno = regno >> 8; + regno &= 0xff; + + /* Remove old state */ + cs4281_rd(sc, CS4281PCI_ACSDA); + + /* Fill in AC97 register value request form */ + cs4281_wr(sc, CS4281PCI_ACCAD, regno); + cs4281_wr(sc, CS4281PCI_ACCDA, 0); + cs4281_wr(sc, CS4281PCI_ACCTL, CS4281PCI_ACCTL_ESYN | + CS4281PCI_ACCTL_VFRM | CS4281PCI_ACCTL_DCV | + CS4281PCI_ACCTL_CRW); + + /* Wait for read to complete */ + if (cs4281_waitclr(sc, CS4281PCI_ACCTL, CS4281PCI_ACCTL_DCV, 250) == 0) { + device_printf(sc->dev, "cs4281_rdcd: DCV did not go\n"); + return 0xffffffff; + } + + /* Wait for valid status */ + if (cs4281_waitset(sc, CS4281PCI_ACSTS, CS4281PCI_ACSTS_VSTS, 250) == 0) { + device_printf(sc->dev,"cs4281_rdcd: VSTS did not come\n"); + return 0xffffffff; + } + + return cs4281_rd(sc, CS4281PCI_ACSDA); +} + +static void +cs4281_wrcd(kobj_t obj, void *devinfo, int regno, u_int32_t data) +{ + struct sc_info *sc = (struct sc_info *)devinfo; + int codecno; + + codecno = regno >> 8; + regno &= 0xff; + + cs4281_wr(sc, CS4281PCI_ACCAD, regno); + cs4281_wr(sc, CS4281PCI_ACCDA, data); + cs4281_wr(sc, CS4281PCI_ACCTL, CS4281PCI_ACCTL_ESYN | + CS4281PCI_ACCTL_VFRM | CS4281PCI_ACCTL_DCV); + + if (cs4281_waitclr(sc, CS4281PCI_ACCTL, CS4281PCI_ACCTL_DCV, 250) == 0) { + device_printf(sc->dev,"cs4281_wrcd: DCV did not go\n"); + } +} + +static kobj_method_t cs4281_ac97_methods[] = { + KOBJMETHOD(ac97_read, cs4281_rdcd), + KOBJMETHOD(ac97_write, cs4281_wrcd), + { 0, 0 } +}; +AC97_DECLARE(cs4281_ac97); + +/* ------------------------------------------------------------------------- */ +/* shared rec/play channel interface */ + +static void * +cs4281chan_init(kobj_t obj, void *devinfo, snd_dbuf *b, pcm_channel *c, int dir) +{ + struct sc_info *sc = devinfo; + struct sc_chinfo *ch = (dir == PCMDIR_PLAY) ? &sc->pch : &sc->rch; + + ch->buffer = b; + if (sndbuf_alloc(ch->buffer, sc->parent_dmat, CS4281_BUFFER_SIZE) != 0) { + return NULL; + } + ch->parent = sc; + ch->channel = c; + + ch->fmt = AFMT_U8; + ch->spd = DSP_DEFAULT_SPEED; + ch->bps = 1; + ch->blksz = sndbuf_getsize(ch->buffer); + + ch->dma_chan = (dir == PCMDIR_PLAY) ? CS4281_DMA_PLAY : CS4281_DMA_REC; + ch->dma_setup = 0; + + adcdac_go(ch, 0); + adcdac_prog(ch); + + return ch; +} + +static int +cs4281chan_setblocksize(kobj_t obj, void *data, u_int32_t blocksize) +{ + struct sc_chinfo *ch = data; + u_int32_t go; + + go = adcdac_go(ch, 0); + + /* 2 interrupts are possible and used in buffer (half-empty,empty), + * hence factor of 2. */ + ch->blksz = MIN(blocksize, CS4281_BUFFER_SIZE / 2); + sndbuf_resize(ch->buffer, 2, ch->blksz); + ch->dma_setup = 0; + adcdac_prog(ch); + adcdac_go(ch, go); + + DEB(printf("cs4281chan_setblocksize: bufsz %d Setting %d\n", blocksize, ch->blksz)); + + return sndbuf_getsize(ch->buffer); +} + +static int +cs4281chan_setspeed(kobj_t obj, void *data, u_int32_t speed) +{ + struct sc_chinfo *ch = data; + struct sc_info *sc = ch->parent; + u_int32_t go, v, r; + + go = adcdac_go(ch, 0); /* pause */ + r = (ch->dma_chan == CS4281_DMA_PLAY) ? CS4281PCI_DACSR : CS4281PCI_ADCSR; + v = cs4281_rate_to_rv(speed); + cs4281_wr(sc, r, v); + adcdac_go(ch, go); /* unpause */ + + ch->spd = cs4281_rv_to_rate(v); + return ch->spd; +} + +static int +cs4281chan_setformat(kobj_t obj, void *data, u_int32_t format) +{ + struct sc_chinfo *ch = data; + struct sc_info *sc = ch->parent; + u_int32_t v, go; + + go = adcdac_go(ch, 0); /* pause */ + + if (ch->dma_chan == CS4281_DMA_PLAY) + v = CS4281PCI_DMR_TR_PLAY; + else + v = CS4281PCI_DMR_TR_REC; + v |= CS4281PCI_DMR_DMA | CS4281PCI_DMR_AUTO; + v |= cs4281_format_to_dmr(format); + cs4281_wr(sc, CS4281PCI_DMR(ch->dma_chan), v); + + adcdac_go(ch, go); /* unpause */ + + ch->fmt = format; + ch->bps = cs4281_format_to_bps(format); + ch->dma_setup = 0; + + return 0; +} + +static int +cs4281chan_getptr(kobj_t obj, void *data) +{ + struct sc_chinfo *ch = data; + struct sc_info *sc = ch->parent; + u_int32_t dba, dca, ptr; + int sz; + + sz = sndbuf_getsize(ch->buffer); + dba = cs4281_rd(sc, CS4281PCI_DBA(ch->dma_chan)); + dca = cs4281_rd(sc, CS4281PCI_DCA(ch->dma_chan)); + ptr = (dca - dba + sz) % sz; + + return ptr; +} + +static int +cs4281chan_trigger(kobj_t obj, void *data, int go) +{ + struct sc_chinfo *ch = data; + + switch(go) { + case PCMTRIG_START: + adcdac_prog(ch); + adcdac_go(ch, 1); + break; + case PCMTRIG_ABORT: + adcdac_go(ch, 0); + break; + default: + break; + } + + /* return 0 if ok */ + return 0; +} + +static pcmchan_caps * +cs4281chan_getcaps(kobj_t obj, void *data) +{ + return &cs4281_caps; +} + +static kobj_method_t cs4281chan_methods[] = { + KOBJMETHOD(channel_init, cs4281chan_init), + KOBJMETHOD(channel_setformat, cs4281chan_setformat), + KOBJMETHOD(channel_setspeed, cs4281chan_setspeed), + KOBJMETHOD(channel_setblocksize, cs4281chan_setblocksize), + KOBJMETHOD(channel_trigger, cs4281chan_trigger), + KOBJMETHOD(channel_getptr, cs4281chan_getptr), + KOBJMETHOD(channel_getcaps, cs4281chan_getcaps), + { 0, 0 } +}; +CHANNEL_DECLARE(cs4281chan); + +/* -------------------------------------------------------------------- */ +/* ADC/DAC control */ + +/* adcdac_go enables/disable DMA channel, returns non-zero if DMA was + * active before call */ + +static u_int32_t +adcdac_go(struct sc_chinfo *ch, u_int32_t go) +{ + struct sc_info *sc = ch->parent; + u_int32_t going; + + going = !(cs4281_rd(sc, CS4281PCI_DCR(ch->dma_chan)) & CS4281PCI_DCR_MSK); + + if (go) + cs4281_clr4(sc, CS4281PCI_DCR(ch->dma_chan), CS4281PCI_DCR_MSK); + else + cs4281_set4(sc, CS4281PCI_DCR(ch->dma_chan), CS4281PCI_DCR_MSK); + + cs4281_wr(sc, CS4281PCI_HICR, CS4281PCI_HICR_EOI); + + return going; +} + +static void +adcdac_prog(struct sc_chinfo *ch) +{ + struct sc_info *sc = ch->parent; + u_int32_t go; + + if (!ch->dma_setup) { + go = adcdac_go(ch, 0); + cs4281_wr(sc, CS4281PCI_DBA(ch->dma_chan), + vtophys(sndbuf_getbuf(ch->buffer))); + cs4281_wr(sc, CS4281PCI_DBC(ch->dma_chan), + sndbuf_getsize(ch->buffer) / ch->bps - 1); + ch->dma_setup = 1; + adcdac_go(ch, go); + } +} + +/* -------------------------------------------------------------------- */ +/* The interrupt handler */ + +static void +cs4281_intr(void *p) +{ + struct sc_info *sc = (struct sc_info *)p; + u_int32_t hisr; + + hisr = cs4281_rd(sc, CS4281PCI_HISR); + + if (hisr == 0) return; + + if (hisr & CS4281PCI_HISR_DMA(CS4281_DMA_PLAY)) { + chn_intr(sc->pch.channel); + cs4281_rd(sc, CS4281PCI_HDSR(CS4281_DMA_PLAY)); /* Clear interrupt */ + } + + if (hisr & CS4281PCI_HISR_DMA(CS4281_DMA_REC)) { + chn_intr(sc->rch.channel); + cs4281_rd(sc, CS4281PCI_HDSR(CS4281_DMA_REC)); /* Clear interrupt */ + } + + /* Signal End-of-Interrupt */ + cs4281_wr(sc, CS4281PCI_HICR, CS4281PCI_HICR_EOI); +} + +/* -------------------------------------------------------------------- */ +/* power management related */ + +static int +cs4281_power(struct sc_info *sc, int state) +{ + + switch (state) { + case 0: + /* Permit r/w access to all BA0 registers */ + cs4281_wr(sc, CS4281PCI_CWPR, CS4281PCI_CWPR_MAGIC); + /* Power on */ + cs4281_clr4(sc, CS4281PCI_EPPMC, CS4281PCI_EPPMC_FPDN); + break; + case 3: + /* Power off card and codec */ + cs4281_set4(sc, CS4281PCI_EPPMC, CS4281PCI_EPPMC_FPDN); + cs4281_clr4(sc, CS4281PCI_SPMC, CS4281PCI_SPMC_RSTN); + break; + } + + DEB(printf("cs4281_power %d -> %d\n", sc->power, state)); + sc->power = state; + + return 0; +} + +static int +cs4281_init(struct sc_info *sc) +{ + u_int32_t i, v; + + /* (0) Blast clock register and serial port */ + cs4281_wr(sc, CS4281PCI_CLKCR1, 0); + cs4281_wr(sc, CS4281PCI_SERMC, 0); + + /* (1) Make ESYN 0 to turn sync pulse on AC97 link */ + cs4281_wr(sc, CS4281PCI_ACCTL, 0); + DELAY(50); + + /* (2) Effect Reset */ + cs4281_wr(sc, CS4281PCI_SPMC, 0); + DELAY(100); + cs4281_wr(sc, CS4281PCI_SPMC, CS4281PCI_SPMC_RSTN); + /* Wait 50ms for ABITCLK to become stable */ + DELAY(50000); + + /* (3) Enable Sound System Clocks */ + cs4281_wr(sc, CS4281PCI_CLKCR1, CS4281PCI_CLKCR1_DLLP); + DELAY(50000); /* Wait for PLL to stabilize */ + cs4281_wr(sc, CS4281PCI_CLKCR1, + CS4281PCI_CLKCR1_DLLP | CS4281PCI_CLKCR1_SWCE); + + /* (4) Power Up - this combination is essential. */ + cs4281_set4(sc, CS4281PCI_SSPM, + CS4281PCI_SSPM_ACLEN | CS4281PCI_SSPM_PSRCEN | + CS4281PCI_SSPM_CSRCEN | CS4281PCI_SSPM_MIXEN); + + /* (5) Wait for clock stabilization */ + if (cs4281_waitset(sc, + CS4281PCI_CLKCR1, + CS4281PCI_CLKCR1_DLLRDY, + 250) == 0) { + device_printf(sc->dev, "Clock stabilization failed\n"); + return -1; + } + + /* (6) Enable ASYNC generation. */ + cs4281_wr(sc, CS4281PCI_ACCTL,CS4281PCI_ACCTL_ESYN); + + /* Wait to allow AC97 to start generating clock bit */ + DELAY(50000); + + /* Set AC97 timing */ + cs4281_wr(sc, CS4281PCI_SERMC, CS4281PCI_SERMC_PTC_AC97); + + /* (7) Wait for AC97 ready signal */ + if (cs4281_waitset(sc, CS4281PCI_ACSTS, CS4281PCI_ACSTS_CRDY, 250) == 0) { + device_printf(sc->dev, "codec did not avail\n"); + return -1; + } + + /* (8) Assert valid frame signal to begin sending commands to + * AC97 codec */ + cs4281_wr(sc, + CS4281PCI_ACCTL, + CS4281PCI_ACCTL_VFRM | CS4281PCI_ACCTL_ESYN); + + /* (9) Wait for codec calibration */ + for(i = 0 ; i < 1000; i++) { + DELAY(10000); + v = cs4281_rdcd(0, sc, AC97_REG_POWER); + if ((v & 0x0f) == 0x0f) { + break; + } + } + if (i == 1000) { + device_printf(sc->dev, "codec failed to calibrate\n"); + return -1; + } + + /* (10) Set AC97 timing */ + cs4281_wr(sc, CS4281PCI_SERMC, CS4281PCI_SERMC_PTC_AC97); + + /* (11) Wait for valid data to arrive */ + if (cs4281_waitset(sc, + CS4281PCI_ACISV, + CS4281PCI_ACISV_ISV(3) | CS4281PCI_ACISV_ISV(4), + 10000) == 0) { + device_printf(sc->dev, "cs4281 never got valid data\n"); + return -1; + } + + /* (12) Start digital data transfer of audio data to codec */ + cs4281_wr(sc, + CS4281PCI_ACOSV, + CS4281PCI_ACOSV_SLV(3) | CS4281PCI_ACOSV_SLV(4)); + + /* Set Master and headphone to max */ + cs4281_wrcd(0, sc, AC97_MIX_PHONES, 0); + cs4281_wrcd(0, sc, AC97_MIX_MASTER, 0); + + /* Power on the DAC */ + v = cs4281_rdcd(0, sc, AC97_REG_POWER) & 0xfdff; + cs4281_wrcd(0, sc, AC97_REG_POWER, v); + + /* Wait until DAC state ready */ + for(i = 0; i < 320; i++) { + DELAY(100); + v = cs4281_rdcd(0, sc, AC97_REG_POWER); + if (v & 0x02) break; + } + + /* Power on the ADC */ + v = cs4281_rdcd(0, sc, AC97_REG_POWER) & 0xfeff; + cs4281_wrcd(0, sc, AC97_REG_POWER, v); + + /* Wait until ADC state ready */ + for(i = 0; i < 320; i++) { + DELAY(100); + v = cs4281_rdcd(0, sc, AC97_REG_POWER); + if (v & 0x01) break; + } + + /* FIFO configuration (driver is DMA orientated, implicit FIFO) */ + /* Play FIFO */ + + v = CS4281PCI_FCR_RS(CS4281PCI_RPCM_PLAY_SLOT) | + CS4281PCI_FCR_LS(CS4281PCI_LPCM_PLAY_SLOT) | + CS4281PCI_FCR_SZ(CS4281_FIFO_SIZE)| + CS4281PCI_FCR_OF(0); + cs4281_wr(sc, CS4281PCI_FCR(CS4281_DMA_PLAY), v); + + cs4281_wr(sc, CS4281PCI_FCR(CS4281_DMA_PLAY), v | CS4281PCI_FCR_FEN); + + /* Record FIFO */ + v = CS4281PCI_FCR_RS(CS4281PCI_RPCM_REC_SLOT) | + CS4281PCI_FCR_LS(CS4281PCI_LPCM_REC_SLOT) | + CS4281PCI_FCR_SZ(CS4281_FIFO_SIZE)| + CS4281PCI_FCR_OF(CS4281_FIFO_SIZE + 1); + cs4281_wr(sc, CS4281PCI_FCR(CS4281_DMA_REC), v | CS4281PCI_FCR_PSH); + cs4281_wr(sc, CS4281PCI_FCR(CS4281_DMA_REC), v | CS4281PCI_FCR_FEN); + + /* Match AC97 slots to FIFOs */ + v = CS4281PCI_SRCSA_PLSS(CS4281PCI_LPCM_PLAY_SLOT) | + CS4281PCI_SRCSA_PRSS(CS4281PCI_RPCM_PLAY_SLOT) | + CS4281PCI_SRCSA_CLSS(CS4281PCI_LPCM_REC_SLOT) | + CS4281PCI_SRCSA_CRSS(CS4281PCI_RPCM_REC_SLOT); + cs4281_wr(sc, CS4281PCI_SRCSA, v); + + /* Set Auto-Initialize and set directions */ + cs4281_wr(sc, + CS4281PCI_DMR(CS4281_DMA_PLAY), + CS4281PCI_DMR_DMA | + CS4281PCI_DMR_AUTO | + CS4281PCI_DMR_TR_PLAY); + cs4281_wr(sc, + CS4281PCI_DMR(CS4281_DMA_REC), + CS4281PCI_DMR_DMA | + CS4281PCI_DMR_AUTO | + CS4281PCI_DMR_TR_REC); + + /* Enable half and empty buffer interrupts keeping DMA paused */ + cs4281_wr(sc, + CS4281PCI_DCR(CS4281_DMA_PLAY), + CS4281PCI_DCR_TCIE | CS4281PCI_DCR_HTCIE | CS4281PCI_DCR_MSK); + cs4281_wr(sc, + CS4281PCI_DCR(CS4281_DMA_REC), + CS4281PCI_DCR_TCIE | CS4281PCI_DCR_HTCIE | CS4281PCI_DCR_MSK); + + /* Enable Interrupts */ + cs4281_clr4(sc, + CS4281PCI_HIMR, + CS4281PCI_HIMR_DMAI | + CS4281PCI_HIMR_DMA(CS4281_DMA_PLAY) | + CS4281PCI_HIMR_DMA(CS4281_DMA_REC)); + + /* Set playback volume */ + cs4281_wr(sc, CS4281PCI_PPLVC, 7); + cs4281_wr(sc, CS4281PCI_PPRVC, 7); + + return 0; +} + +/* -------------------------------------------------------------------- */ +/* Probe and attach the card */ + +static int +cs4281_pci_probe(device_t dev) +{ + char *s = NULL; + + switch (pci_get_devid(dev)) { + case CS4281_PCI_ID: + s = "Crystal Semiconductor CS4281"; + break; + } + + if (s) + device_set_desc(dev, s); + return s ? 0 : ENXIO; +} + +static int +cs4281_pci_attach(device_t dev) +{ + struct sc_info *sc; + struct ac97_info *codec = NULL; + u_int32_t data; + char status[SND_STATUSLEN]; + + if ((sc = malloc(sizeof(*sc), M_DEVBUF, M_NOWAIT)) == NULL) { + device_printf(dev, "cannot allocate softc\n"); + return ENXIO; + } + + bzero(sc, sizeof(*sc)); + sc->dev = dev; + sc->type = pci_get_devid(dev); + + data = pci_read_config(dev, PCIR_COMMAND, 2); + data |= (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN | PCIM_CMD_BUSMASTEREN); + pci_write_config(dev, PCIR_COMMAND, data, 2); + + data = pci_read_config(dev, PCIR_COMMAND, 2); + + if (pci_get_powerstate(dev) != PCI_POWERSTATE_D0) { + /* Reset the power state. */ + device_printf(dev, "chip is in D%d power mode " + "-- setting to D0\n", pci_get_powerstate(dev)); + + pci_set_powerstate(dev, PCI_POWERSTATE_D0); + } + + sc->regid = PCIR_MAPS; + sc->regtype = SYS_RES_MEMORY; + sc->reg = bus_alloc_resource(dev, sc->regtype, &sc->regid, + 0, ~0, CS4281PCI_BA0_SIZE, RF_ACTIVE); + if (!sc->reg) { + sc->regtype = SYS_RES_IOPORT; + sc->reg = bus_alloc_resource(dev, sc->regtype, &sc->regid, + 0, ~0, CS4281PCI_BA0_SIZE, RF_ACTIVE); + if (!sc->reg) { + device_printf(dev, "unable to allocate register space\n"); + goto bad; + } + } + sc->st = rman_get_bustag(sc->reg); + sc->sh = rman_get_bushandle(sc->reg); + + sc->memid = PCIR_MAPS + 4; + sc->mem = bus_alloc_resource(dev, SYS_RES_MEMORY, &sc->memid, 0, + ~0, CS4281PCI_BA1_SIZE, RF_ACTIVE); + if (sc->mem == NULL) { + device_printf(dev, "unable to allocate fifo space\n"); + goto bad; + } + + sc->irqid = 0; + sc->irq = bus_alloc_resource(dev, SYS_RES_IRQ, &sc->irqid, + 0, ~0, 1, RF_ACTIVE | RF_SHAREABLE); + if (!sc->irq) { + device_printf(dev, "unable to allocate interrupt\n"); + goto bad; + } + + if (bus_setup_intr(dev, sc->irq, INTR_TYPE_TTY, cs4281_intr, sc, &sc->ih)) { + device_printf(dev, "unable to setup interrupt\n"); + goto bad; + } + + if (bus_dma_tag_create(/*parent*/NULL, /*alignment*/2, /*boundary*/0, + /*lowaddr*/BUS_SPACE_MAXADDR_32BIT, + /*highaddr*/BUS_SPACE_MAXADDR, + /*filter*/NULL, /*filterarg*/NULL, + /*maxsize*/CS4281_BUFFER_SIZE, /*nsegments*/1, + /*maxsegz*/0x3ffff, + /*flags*/0, &sc->parent_dmat) != 0) { + device_printf(dev, "unable to create dma tag\n"); + goto bad; + } + + /* power up */ + cs4281_power(sc, 0); + + /* init chip */ + if (cs4281_init(sc) == -1) { + device_printf(dev, "unable to initialize the card\n"); + goto bad; + } + + /* create/init mixer */ + codec = AC97_CREATE(dev, sc, cs4281_ac97); + if (codec == NULL) + goto bad; + + mixer_init(dev, ac97_getmixerclass(), codec); + + if (pcm_register(dev, sc, 1, 1)) + goto bad; + + pcm_addchan(dev, PCMDIR_PLAY, &cs4281chan_class, sc); + pcm_addchan(dev, PCMDIR_REC, &cs4281chan_class, sc); + + snprintf(status, SND_STATUSLEN, "at %s 0x%lx irq %ld", + (sc->regtype == SYS_RES_IOPORT)? "io" : "memory", + rman_get_start(sc->reg), rman_get_start(sc->irq)); + pcm_setstatus(dev, status); + + return 0; + + bad: + if (codec) + ac97_destroy(codec); + if (sc->reg) + bus_release_resource(dev, sc->regtype, sc->regid, sc->reg); + if (sc->mem) + bus_release_resource(dev, SYS_RES_MEMORY, sc->memid, sc->mem); + if (sc->ih) + bus_teardown_intr(dev, sc->irq, sc->ih); + if (sc->irq) + bus_release_resource(dev, SYS_RES_IRQ, sc->irqid, sc->irq); + if (sc->parent_dmat) + bus_dma_tag_destroy(sc->parent_dmat); + free(sc, M_DEVBUF); + + return ENXIO; +} + +static int +cs4281_pci_detach(device_t dev) +{ + int r; + struct sc_info *sc; + + r = pcm_unregister(dev); + if (r) + return r; + + sc = pcm_getdevinfo(dev); + + /* power off */ + cs4281_power(sc, 3); + + bus_release_resource(dev, sc->regtype, sc->regid, sc->reg); + bus_release_resource(dev, SYS_RES_MEMORY, sc->memid, sc->mem); + bus_teardown_intr(dev, sc->irq, sc->ih); + bus_release_resource(dev, SYS_RES_IRQ, sc->irqid, sc->irq); + bus_dma_tag_destroy(sc->parent_dmat); + free(sc, M_DEVBUF); + + return 0; +} + +static int +cs4281_pci_suspend(device_t dev) +{ + struct sc_info *sc; + + sc = pcm_getdevinfo(dev); + + sc->rch.dma_active = adcdac_go(&sc->rch, 0); + sc->pch.dma_active = adcdac_go(&sc->pch, 0); + + cs4281_power(sc, 3); + + return 0; +} + +static int +cs4281_pci_resume(device_t dev) +{ + struct sc_info *sc; + + sc = pcm_getdevinfo(dev); + + /* power up */ + cs4281_power(sc, 0); + + /* initialize chip */ + if (cs4281_init(sc) == -1) { + device_printf(dev, "unable to reinitialize the card\n"); + return ENXIO; + } + + /* restore mixer state */ + if (mixer_reinit(dev) == -1) { + device_printf(dev, "unable to reinitialize the mixer\n"); + return ENXIO; + } + + /* restore chip state */ + cs4281chan_setspeed(NULL, &sc->rch, sc->rch.spd); + cs4281chan_setblocksize(NULL, &sc->rch, sc->rch.blksz); + cs4281chan_setformat(NULL, &sc->rch, sc->rch.fmt); + adcdac_go(&sc->rch, sc->rch.dma_active); + + cs4281chan_setspeed(NULL, &sc->pch, sc->pch.spd); + cs4281chan_setblocksize(NULL, &sc->pch, sc->pch.blksz); + cs4281chan_setformat(NULL, &sc->pch, sc->pch.fmt); + adcdac_go(&sc->pch, sc->pch.dma_active); + + return 0; +} + +static device_method_t cs4281_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, cs4281_pci_probe), + DEVMETHOD(device_attach, cs4281_pci_attach), + DEVMETHOD(device_detach, cs4281_pci_detach), + DEVMETHOD(device_suspend, cs4281_pci_suspend), + DEVMETHOD(device_resume, cs4281_pci_resume), + { 0, 0 } +}; + +static driver_t cs4281_driver = { + "pcm", + cs4281_methods, + sizeof(snddev_info), +}; + +static devclass_t pcm_devclass; + +DRIVER_MODULE(snd_cs4281, pci, cs4281_driver, pcm_devclass, 0, 0); +MODULE_DEPEND(snd_cs4281, snd_pcm, PCM_MINVER, PCM_PREFVER, PCM_MAXVER); +MODULE_VERSION(snd_cs4281, 1); diff --git a/sys/dev/sound/pci/cs4281.h b/sys/dev/sound/pci/cs4281.h new file mode 100644 index 000000000000..09802ac316c7 --- /dev/null +++ b/sys/dev/sound/pci/cs4281.h @@ -0,0 +1,204 @@ +/* + * Copyright (c) 2000 Orion Hodson <O.Hodson@cs.ucl.ac.uk> + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHERIN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THEPOSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _CS4281_H_ +#define _CS4281_H_ + +#define CS4281_PCI_ID 0x60051013 + +/* Ball Parks */ +#define CS4281PCI_BA0_SIZE 4096 +#define CS4281PCI_BA1_SIZE 65536 + +/* Register values */ +#define CS4281PCI_HISR 0x000 +# define CS4281PCI_HISR_DMAI 0x00040000 +# define CS4281PCI_HISR_DMA(x) (0x0100 << (x)) + +#define CS4281PCI_HICR 0x008 +# define CS4281PCI_HICR_EOI 0x00000003 + +#define CS4281PCI_HIMR 0x00c +# define CS4281PCI_HIMR_DMAI 0x00040000 +# define CS4281PCI_HIMR_DMA(x) (0x0100 << (x)) + +#define CS4281PCI_IIER 0x010 + +#define CS4281PCI_HDSR(x) (0x0f0 + (x)*0x004) +# define CS4281PCI_HDSR_CH1P 0x02000000 +# define CS4281PCI_HDSR_CH2P 0x01000000 +# define CS4281PCI_HDSR_HDTC 0x00020000 +# define CS4281PCI_HDSR_DTC 0x00010000 +# define CS4281PCI_HDSR_DRUN 0x00008000 +# define CS4281PCI_HDSR_RQ 0x00000080 + +#define CS4281PCI_DCA(x) (0x110 + (x) * 0x010) +#define CS4281PCI_DCC(x) (0x114 + (x) * 0x010) +#define CS4281PCI_DBA(x) (0x118 + (x) * 0x010) +#define CS4281PCI_DBC(x) (0x11c + (x) * 0x010) + +#define CS4281PCI_DMR(x) (0x150 + (x) * 0x008) +# define CS4281PCI_DMR_DMA 0x20000000 +# define CS4281PCI_DMR_POLL 0x10000000 +# define CS4281PCI_DMR_TBC 0x02000000 +# define CS4281PCI_DMR_CBC 0x01000000 +# define CS4281PCI_DMR_SWAPC 0x00400000 +# define CS4281PCI_DMR_SIZE20 0x00100000 +# define CS4281PCI_DMR_USIGN 0x00080000 +# define CS4281PCI_DMR_BEND 0x00040000 +# define CS4281PCI_DMR_MONO 0x00020000 +# define CS4281PCI_DMR_SIZE8 0x00010000 +# define CS4281PCI_DMR_TYPE_DEMAND 0x00000000 +# define CS4281PCI_DMR_TYPE_SINGLE 0x00000040 +# define CS4281PCI_DMR_TYPE_BLOCK 0x00000080 +# define CS4281PCI_DMR_TYPE_CASCADE 0x000000c0 +# define CS4281PCI_DMR_DEC 0x00000020 +# define CS4281PCI_DMR_AUTO 0x00000010 +# define CS4281PCI_DMR_TR_PLAY 0x00000008 +# define CS4281PCI_DMR_TR_REC 0x00000004 + +#define CS4281PCI_DCR(x) (0x154 + (x) * 0x008) +# define CS4281PCI_DCR_HTCIE 0x00020000 +# define CS4281PCI_DCR_TCIE 0x00010000 +# define CS4281PCI_DCR_MSK 0x00000001 + +#define CS4281PCI_FCR(x) (0x180 + (x) * 0x004) +# define CS4281PCI_FCR_FEN 0x80000000 +# define CS4281PCI_FCR_DACZ 0x40000000 +# define CS4281PCI_FCR_PSH 0x20000000 +# define CS4281PCI_FCR_RS(x) ((x) << 24) +# define CS4281PCI_FCR_LS(x) ((x) << 16) +# define CS4281PCI_FCR_SZ(x) ((x) << 8) +# define CS4281PCI_FCR_OF(x) (x) + +#define CS4281PCI_FPDR(x) (0x190 + (x) * 0x004) + +#define CS4281PCI_FCHS 0x20c +#define CS4281PCI_FSIC(x) (0x210 + (x) * 0x004) + +#define CS4281PCI_PMCS 0x344 +# define CS4281PCI_PMCS_PS_MASK 0x00000003 + +#define CS4281PCI_CWPR 0x3e0 +# define CS4281PCI_CWPR_MAGIC 0x00004281 + +#define CS4281PCI_EPPMC 0x3e4 +# define CS4281PCI_EPPMC_FPDN 0x00004000 +#define CS4281PCI_GPIOR 0x3e8 + +#define CS4281PCI_SPMC 0x3ec +# define CS4281PCI_SPMC_RSTN 0x00000001 +# define CS4281PCI_SPMC_ASYN 0x00000002 +# define CS4281PCI_SPMC_WUP1 0x00000004 +# define CS4281PCI_SPMC_WUP2 0x00000008 +# define CS4281PCI_SPMC_ASDO 0x00000080 +# define CS4281PCI_SPMC_ASDI2E 0x00000100 +# define CS4281PCI_SPMC_EESPD 0x00000200 +# define CS4281PCI_SPMC_GISPEN 0x00004000 +# define CS4281PCI_SPMC_GIPPEN 0x00008000 + +#define CS4281PCI_CFLR 0x3f0 +#define CS4281PCI_IISR 0x3f4 +#define CS4281PCI_TMS 0x3f8 +#define CS4281PCI_SSVID 0x3fc + +#define CS4281PCI_CLKCR1 0x400 +# define CS_4281PCI_CLKCR1_DLLSS_MASK 0x0000000c +# define CS_4281PCI_CLKCR1_DLLSS_AC97 0x00000004 +# define CS4281PCI_CLKCR1_DLLP 0x00000010 +# define CS4281PCI_CLKCR1_SWCE 0x00000020 +# define CS4281PCI_CLKCR1_DLLOS 0x00000040 +# define CS4281PCI_CLKCR1_CKRA 0x00010000 +# define CS4281PCI_CLKCR1_DLLRDY 0x01000000 +# define CS4281PCI_CLKCR1_CLKON 0x02000000 + +#define CS4281PCI_FRR 0x410 + +#define CS4281PCI_SLT12O 0x41c +#define CS4281PCI_SERMC 0x420 +# define CS4281PCI_SERMC_PTC_AC97 0x00000002 +# define CS4281PCI_SERMC_PTC_MASK 0x0000000e +# define CS4281PCI_SERMC_ODSEN1 0x01000000 +# define CS4281PCI_SERMC_ODSEN2 0x02000000 +#define CS4281PCI_SERC1 0x428 +#define CS4281PCI_SERC2 0x42c + +#define CS4281PCI_SLT12M 0x45c +#define CS4281PCI_ACCTL 0x460 +# define CS4281PCI_ACCTL_ESYN 0x00000002 +# define CS4281PCI_ACCTL_VFRM 0x00000004 +# define CS4281PCI_ACCTL_DCV 0x00000008 +# define CS4281PCI_ACCTL_CRW 0x00000010 +# define CS4281PCI_ACCTL_TC 0x00000040 + +#define CS4281PCI_ACSTS 0x464 +# define CS4281PCI_ACSTS_CRDY 0x00000001 +# define CS4281PCI_ACSTS_VSTS 0x00000002 + +#define CS4281PCI_ACOSV 0x468 +# define CS4281PCI_ACOSV_SLV(x) (1 << (x - 3)) +#define CS4281PCI_ACCAD 0x46c +#define CS4281PCI_ACCDA 0x470 +#define CS4281PCI_ACISV 0x474 +# define CS4281PCI_ACISV_ISV(x) (1 << (x - 3)) +#define CS4281PCI_ACSAD 0x478 +#define CS4281PCI_ACSDA 0x47c +#define CS4281PCI_JSPT 0x480 +#define CS4281PCI_JSCTL 0x484 + +#define CS4281PCI_SSPM 0x740 +# define CS4281PCI_SSPM_MIXEN 0x00000040 +# define CS4281PCI_SSPM_CSRCEN 0x00000020 +# define CS4281PCI_SSPM_PSRCEN 0x00000010 +# define CS4281PCI_SSPM_JSEN 0x00000008 +# define CS4281PCI_SSPM_ACLEN 0x00000004 +# define CS4281PCI_SSPM_FMEN 0x00000002 + +#define CS4281PCI_DACSR 0x744 +#define CS4281PCI_ADCSR 0x748 +#define CS4281PCI_SSCR 0x74c + +#define CS4281PCI_SRCSA 0x75c +# define CS4281PCI_SRCSA_PLSS(x) (x) +# define CS4281PCI_SRCSA_PRSS(x) ((x) << 8) +# define CS4281PCI_SRCSA_CLSS(x) ((x) << 16) +# define CS4281PCI_SRCSA_CRSS(x) ((x) << 24) + +#define CS4281PCI_PPLVC 0x760 +#define CS4281PCI_PPRVC 0x764 + +/* Slot definitions (minimal) */ +#define CS4281PCI_LPCM_PLAY_SLOT 0x00 +#define CS4281PCI_RPCM_PLAY_SLOT 0x01 + +#define CS4281PCI_LPCM_REC_SLOT 0x0a +#define CS4281PCI_RPCM_REC_SLOT 0x0b + +#define CS4281PCI_DISABLED_SLOT 0x1f + +#endif /* _CS4281_H_ */ diff --git a/sys/kern/subr_mchain.c b/sys/kern/subr_mchain.c new file mode 100644 index 000000000000..3020f56f9162 --- /dev/null +++ b/sys/kern/subr_mchain.c @@ -0,0 +1,547 @@ +/* + * Copyright (c) 2000, 2001 Boris Popov + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Boris Popov. + * 4. Neither the name of the author nor the names of any co-contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + + +#include <sys/param.h> +#include <sys/systm.h> +#include <sys/errno.h> +#include <sys/mbuf.h> +#include <sys/module.h> +#include <sys/uio.h> + +#include <sys/mchain.h> + +MODULE_VERSION(libmchain, 1); + +#define MBERROR(format, args...) printf("%s(%d): "format, __FUNCTION__ , \ + __LINE__ ,## args) + +#define MBPANIC(format, args...) printf("%s(%d): "format, __FUNCTION__ , \ + __LINE__ ,## args) + +/* + * Various helper functions + */ +int +m_fixhdr(struct mbuf *m0) +{ + struct mbuf *m = m0; + int len = 0; + + while (m) { + len += m->m_len; + m = m->m_next; + } + m0->m_pkthdr.len = len; + return len; +} + +int +mb_init(struct mbchain *mbp) +{ + struct mbuf *m; + + m = m_gethdr(M_TRYWAIT, MT_DATA); + if (m == NULL) + return ENOBUFS; + m->m_len = 0; + mb_initm(mbp, m); + return 0; +} + +void +mb_initm(struct mbchain *mbp, struct mbuf *m) +{ + bzero(mbp, sizeof(*mbp)); + mbp->mb_top = mbp->mb_cur = m; + mbp->mb_mleft = M_TRAILINGSPACE(m); +} + +void +mb_done(struct mbchain *mbp) +{ + if (mbp->mb_top) { + m_freem(mbp->mb_top); + mbp->mb_top = NULL; + } +} + +struct mbuf * +mb_detach(struct mbchain *mbp) +{ + struct mbuf *m; + + m = mbp->mb_top; + mbp->mb_top = NULL; + return m; +} + +int +mb_fixhdr(struct mbchain *mbp) +{ + return mbp->mb_top->m_pkthdr.len = m_fixhdr(mbp->mb_top); +} + +/* + * Check if object of size 'size' fit to the current position and + * allocate new mbuf if not. Advance pointers and increase length of mbuf(s). + * Return pointer to the object placeholder or NULL if any error occured. + * Note: size should be <= MLEN + */ +caddr_t +mb_reserve(struct mbchain *mbp, int size) +{ + struct mbuf *m, *mn; + caddr_t bpos; + + if (size > MLEN) + panic("mb_reserve: size = %d\n", size); + m = mbp->mb_cur; + if (mbp->mb_mleft < size) { + mn = m_get(M_TRYWAIT, MT_DATA); + if (mn == NULL) + return NULL; + mbp->mb_cur = m->m_next = mn; + m = mn; + m->m_len = 0; + mbp->mb_mleft = M_TRAILINGSPACE(m); + } + mbp->mb_mleft -= size; + mbp->mb_count += size; + bpos = mtod(m, caddr_t) + m->m_len; + m->m_len += size; + return bpos; +} + +int +mb_put_uint8(struct mbchain *mbp, u_int8_t x) +{ + return mb_put_mem(mbp, (caddr_t)&x, sizeof(x), MB_MSYSTEM); +} + +int +mb_put_uint16be(struct mbchain *mbp, u_int16_t x) +{ + x = htobes(x); + return mb_put_mem(mbp, (caddr_t)&x, sizeof(x), MB_MSYSTEM); +} + +int +mb_put_uint16le(struct mbchain *mbp, u_int16_t x) +{ + x = htoles(x); + return mb_put_mem(mbp, (caddr_t)&x, sizeof(x), MB_MSYSTEM); +} + +int +mb_put_uint32be(struct mbchain *mbp, u_int32_t x) +{ + x = htobel(x); + return mb_put_mem(mbp, (caddr_t)&x, sizeof(x), MB_MSYSTEM); +} + +int +mb_put_uint32le(struct mbchain *mbp, u_int32_t x) +{ + x = htolel(x); + return mb_put_mem(mbp, (caddr_t)&x, sizeof(x), MB_MSYSTEM); +} + +int +mb_put_int64be(struct mbchain *mbp, int64_t x) +{ + x = htobeq(x); + return mb_put_mem(mbp, (caddr_t)&x, sizeof(x), MB_MSYSTEM); +} + +int +mb_put_int64le(struct mbchain *mbp, int64_t x) +{ + x = htoleq(x); + return mb_put_mem(mbp, (caddr_t)&x, sizeof(x), MB_MSYSTEM); +} + +int +mb_put_mem(struct mbchain *mbp, c_caddr_t source, int size, int type) +{ + struct mbuf *m; + caddr_t dst; + c_caddr_t src; + int cplen, error, mleft, count; + + m = mbp->mb_cur; + mleft = mbp->mb_mleft; + + while (size > 0) { + if (mleft == 0) { + if (m->m_next == NULL) { + m = m_getm(m, size, M_TRYWAIT, MT_DATA); + if (m == NULL) + return ENOBUFS; + } + m = m->m_next; + mleft = M_TRAILINGSPACE(m); + continue; + } + cplen = mleft > size ? size : mleft; + dst = mtod(m, caddr_t) + m->m_len; + switch (type) { + case MB_MCUSTOM: + error = mbp->mb_copy(mbp, source, dst, cplen); + if (error) + return error; + break; + case MB_MINLINE: + for (src = source, count = cplen; count; count--) + *dst++ = *src++; + break; + case MB_MSYSTEM: + bcopy(source, dst, cplen); + break; + case MB_MUSER: + error = copyin(source, dst, cplen); + if (error) + return error; + break; + case MB_MZERO: + bzero(dst, cplen); + break; + } + size -= cplen; + source += cplen; + m->m_len += cplen; + mleft -= cplen; + mbp->mb_count += cplen; + } + mbp->mb_cur = m; + mbp->mb_mleft = mleft; + return 0; +} + +int +mb_put_mbuf(struct mbchain *mbp, struct mbuf *m) +{ + mbp->mb_cur->m_next = m; + while (m) { + mbp->mb_count += m->m_len; + if (m->m_next == NULL) + break; + m = m->m_next; + } + mbp->mb_mleft = M_TRAILINGSPACE(m); + mbp->mb_cur = m; + return 0; +} + +/* + * copies a uio scatter/gather list to an mbuf chain. + * NOTE: can ony handle iovcnt == 1 + */ +int +mb_put_uio(struct mbchain *mbp, struct uio *uiop, int size) +{ + long left; + int mtype, error; + +#ifdef DIAGNOSTIC + if (uiop->uio_iovcnt != 1) + MBPANIC("iovcnt != 1"); +#endif + mtype = (uiop->uio_segflg == UIO_SYSSPACE) ? MB_MSYSTEM : MB_MUSER; + + while (size > 0) { + left = uiop->uio_iov->iov_len; + if (left > size) + left = size; + error = mb_put_mem(mbp, uiop->uio_iov->iov_base, left, mtype); + if (error) + return error; + uiop->uio_offset += left; + uiop->uio_resid -= left; + uiop->uio_iov->iov_base += left; + uiop->uio_iov->iov_len -= left; + size -= left; + } + return 0; +} + +/* + * Routines for fetching data from an mbuf chain + */ +int +md_init(struct mdchain *mdp) +{ + struct mbuf *m; + + m = m_gethdr(M_TRYWAIT, MT_DATA); + if (m == NULL) + return ENOBUFS; + m->m_len = 0; + md_initm(mdp, m); + return 0; +} + +void +md_initm(struct mdchain *mdp, struct mbuf *m) +{ + bzero(mdp, sizeof(*mdp)); + mdp->md_top = mdp->md_cur = m; + mdp->md_pos = mtod(m, u_char*); +} + +void +md_done(struct mdchain *mdp) +{ + if (mdp->md_top) { + m_freem(mdp->md_top); + mdp->md_top = NULL; + } +} + +/* + * Append a separate mbuf chain. It is caller responsibility to prevent + * multiple calls to fetch/record routines. + */ +void +md_append_record(struct mdchain *mdp, struct mbuf *top) +{ + struct mbuf *m; + + if (mdp->md_top == NULL) { + md_initm(mdp, top); + return; + } + m = mdp->md_top; + while (m->m_nextpkt) + m = m->m_nextpkt; + m->m_nextpkt = top; + top->m_nextpkt = NULL; + return; +} + +/* + * Put next record in place of existing + */ +int +md_next_record(struct mdchain *mdp) +{ + struct mbuf *m; + + if (mdp->md_top == NULL) + return ENOENT; + m = mdp->md_top->m_nextpkt; + md_done(mdp); + if (m == NULL) + return ENOENT; + md_initm(mdp, m); + return 0; +} + +int +md_get_uint8(struct mdchain *mdp, u_int8_t *x) +{ + return md_get_mem(mdp, x, 1, MB_MINLINE); +} + +int +md_get_uint16(struct mdchain *mdp, u_int16_t *x) +{ + return md_get_mem(mdp, (caddr_t)x, 2, MB_MINLINE); +} + +int +md_get_uint16le(struct mdchain *mdp, u_int16_t *x) +{ + u_int16_t v; + int error = md_get_uint16(mdp, &v); + + *x = letohs(v); + return error; +} + +int +md_get_uint16be(struct mdchain *mdp, u_int16_t *x) { + u_int16_t v; + int error = md_get_uint16(mdp, &v); + + *x = betohs(v); + return error; +} + +int +md_get_uint32(struct mdchain *mdp, u_int32_t *x) +{ + return md_get_mem(mdp, (caddr_t)x, 4, MB_MINLINE); +} + +int +md_get_uint32be(struct mdchain *mdp, u_int32_t *x) +{ + u_int32_t v; + int error; + + error = md_get_uint32(mdp, &v); + *x = betohl(v); + return error; +} + +int +md_get_uint32le(struct mdchain *mdp, u_int32_t *x) +{ + u_int32_t v; + int error; + + error = md_get_uint32(mdp, &v); + *x = letohl(v); + return error; +} + +int +md_get_int64(struct mdchain *mdp, int64_t *x) +{ + return md_get_mem(mdp, (caddr_t)x, 8, MB_MINLINE); +} + +int +md_get_int64be(struct mdchain *mdp, int64_t *x) +{ + int64_t v; + int error; + + error = md_get_int64(mdp, &v); + *x = betohq(v); + return error; +} + +int +md_get_int64le(struct mdchain *mdp, int64_t *x) +{ + int64_t v; + int error; + + error = md_get_int64(mdp, &v); + *x = letohq(v); + return error; +} + +int +md_get_mem(struct mdchain *mdp, caddr_t target, int size, int type) +{ + struct mbuf *m = mdp->md_cur; + int error; + u_int count; + u_char *s; + + while (size > 0) { + if (m == NULL) { + MBERROR("incomplete copy\n"); + return EBADRPC; + } + s = mdp->md_pos; + count = mtod(m, u_char*) + m->m_len - s; + if (count == 0) { + mdp->md_cur = m = m->m_next; + if (m) + s = mdp->md_pos = mtod(m, caddr_t); + continue; + } + if (count > size) + count = size; + size -= count; + mdp->md_pos += count; + if (target == NULL) + continue; + switch (type) { + case MB_MUSER: + error = copyout(s, target, count); + if (error) + return error; + break; + case MB_MSYSTEM: + bcopy(s, target, count); + break; + case MB_MINLINE: + while (count--) + *target++ = *s++; + continue; + } + target += count; + } + return 0; +} + +int +md_get_mbuf(struct mdchain *mdp, int size, struct mbuf **ret) +{ + struct mbuf *m = mdp->md_cur, *rm; + + rm = m_copym(m, mdp->md_pos - mtod(m, u_char*), size, M_TRYWAIT); + if (rm == NULL) + return EBADRPC; + md_get_mem(mdp, NULL, size, MB_MZERO); + *ret = rm; + return 0; +} + +int +md_get_uio(struct mdchain *mdp, struct uio *uiop, int size) +{ + char *uiocp; + long left; + int mtype, error; + + mtype = (uiop->uio_segflg == UIO_SYSSPACE) ? MB_MSYSTEM : MB_MUSER; + while (size > 0) { + if (uiop->uio_iovcnt <= 0 || uiop->uio_iov == NULL) + return EFBIG; + left = uiop->uio_iov->iov_len; + uiocp = uiop->uio_iov->iov_base; + if (left > size) + left = size; + error = md_get_mem(mdp, uiocp, left, mtype); + if (error) + return error; + uiop->uio_offset += left; + uiop->uio_resid -= left; + if (uiop->uio_iov->iov_len <= size) { + uiop->uio_iovcnt--; + uiop->uio_iov++; + } else { + uiop->uio_iov->iov_base += left; + uiop->uio_iov->iov_len -= left; + } + size -= left; + } + return 0; +} diff --git a/sys/modules/libmchain/Makefile b/sys/modules/libmchain/Makefile new file mode 100644 index 000000000000..39cfeb042767 --- /dev/null +++ b/sys/modules/libmchain/Makefile @@ -0,0 +1,8 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../kern + +KMOD= libmchain +SRCS= subr_mchain.c + +.include <bsd.kmod.mk> diff --git a/sys/netgraph/ng_eiface.h b/sys/netgraph/ng_eiface.h new file mode 100644 index 000000000000..ed639be6f2f3 --- /dev/null +++ b/sys/netgraph/ng_eiface.h @@ -0,0 +1,84 @@ +/* + * ng_eiface.h + * + * Copyright (c) 1999-2001, Vitaly V Belekhov + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice unmodified, this list of conditions, and the following + * disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _NETGRAPH_EIFACE_H_ +#define _NETGRAPH_EIFACE_H_ + +/* Node type name and magic cookie */ +#define NG_EIFACE_NODE_TYPE "eiface" +#define NGM_EIFACE_COOKIE 948105892 + +/* Interface base name */ +#define NG_EIFACE_EIFACE_NAME "nge" +#define NG_EIFACE_EIFACE_NAME_MAX 15 + +/* My hook names */ +#define NG_EIFACE_HOOK_ETHER "ether" + +/* MTU bounds */ +#define NG_EIFACE_MTU_MIN 72 +#define NG_EIFACE_MTU_MAX 2312 +#define NG_EIFACE_MTU_DEFAULT 1500 + +/* Netgraph commands */ +enum { + NGM_EIFACE_GET_IFNAME = 1, /* returns struct ng_eiface_ifname */ + NGM_EIFACE_GET_IFADDRS, /* returns list of addresses */ + NGM_EIFACE_SET, /* set ethernet address */ +}; + +struct ng_eiface_ifname { + char ngif_name[NG_EIFACE_EIFACE_NAME_MAX + 1]; +}; + +struct ng_eiface_par { + u_char oct0; + u_char oct1; + u_char oct2; + u_char oct3; + u_char oct4; + u_char oct5; +}; + +static const struct ng_parse_struct_info ng_eiface_par_fields = { + { + { "oct0", &ng_parse_int8_type }, + { "oct1", &ng_parse_int8_type }, + { "oct2", &ng_parse_int8_type }, + { "oct3", &ng_parse_int8_type }, + { "oct4", &ng_parse_int8_type }, + { "oct5", &ng_parse_int8_type }, + { NULL }, + } +}; + + +#endif /* _NETGRAPH_EIFACE_H_ */ diff --git a/sys/sys/mchain.h b/sys/sys/mchain.h new file mode 100644 index 000000000000..e79fbfb03524 --- /dev/null +++ b/sys/sys/mchain.h @@ -0,0 +1,155 @@ +/* + * Copyright (c) 2000, 2001 Boris Popov + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Boris Popov. + * 4. Neither the name of the author nor the names of any co-contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ +#ifndef _SYS_MCHAIN_H_ +#define _SYS_MCHAIN_H_ + +#include <machine/endian.h> + +/* + * This macros probably belongs to the endian.h + */ +#if (BYTE_ORDER == LITTLE_ENDIAN) + +#define htoles(x) ((u_int16_t)(x)) +#define letohs(x) ((u_int16_t)(x)) +#define htolel(x) ((u_int32_t)(x)) +#define letohl(x) ((u_int32_t)(x)) +#define htoleq(x) ((int64_t)(x)) +#define letohq(x) ((int64_t)(x)) + +#define htobes(x) (htons(x)) +#define betohs(x) (ntohs(x)) +#define htobel(x) (htonl(x)) +#define betohl(x) (ntohl(x)) + +static __inline int64_t +htobeq(int64_t x) +{ + return (int64_t)htonl((u_int32_t)(x >> 32)) | + (int64_t)htonl((u_int32_t)(x & 0xffffffff)) << 32; +} + +static __inline int64_t +betohq(int64_t x) +{ + return (int64_t)ntohl((u_int32_t)(x >> 32)) | + (int64_t)ntohl((u_int32_t)(x & 0xffffffff)) << 32; +} + +#else /* (BYTE_ORDER == LITTLE_ENDIAN) */ + +#error "Macros for Big-Endians are incomplete" + +/* +#define htoles(x) ((u_int16_t)(x)) +#define letohs(x) ((u_int16_t)(x)) +#define htolel(x) ((u_int32_t)(x)) +#define letohl(x) ((u_int32_t)(x)) +*/ +#endif /* (BYTE_ORDER == LITTLE_ENDIAN) */ + + +#ifdef _KERNEL + +/* + * Type of copy for mb_{put|get}_mem() + */ +#define MB_MSYSTEM 0 /* use bcopy() */ +#define MB_MUSER 1 /* use copyin()/copyout() */ +#define MB_MINLINE 2 /* use an inline copy loop */ +#define MB_MZERO 3 /* bzero(), mb_put_mem only */ +#define MB_MCUSTOM 4 /* use an user defined function */ + +struct mbuf; +struct mbchain; + +typedef int mb_copy_t(struct mbchain *mbp, c_caddr_t src, caddr_t dst, int len); + +struct mbchain { + struct mbuf * mb_top; /* head of mbufs chain */ + struct mbuf * mb_cur; /* current mbuf */ + int mb_mleft; /* free space in the current mbuf */ + int mb_count; /* total number of bytes */ + mb_copy_t * mb_copy; /* user defined copy function */ + void * mb_udata; /* user data */ +}; + +struct mdchain { + struct mbuf * md_top; /* head of mbufs chain */ + struct mbuf * md_cur; /* current mbuf */ + u_char * md_pos; /* offset in the current mbuf */ +}; + +int m_fixhdr(struct mbuf *m); + +int mb_init(struct mbchain *mbp); +void mb_initm(struct mbchain *mbp, struct mbuf *m); +void mb_done(struct mbchain *mbp); +struct mbuf *mb_detach(struct mbchain *mbp); +int mb_fixhdr(struct mbchain *mbp); +caddr_t mb_reserve(struct mbchain *mbp, int size); + +int mb_put_uint8(struct mbchain *mbp, u_int8_t x); +int mb_put_uint16be(struct mbchain *mbp, u_int16_t x); +int mb_put_uint16le(struct mbchain *mbp, u_int16_t x); +int mb_put_uint32be(struct mbchain *mbp, u_int32_t x); +int mb_put_uint32le(struct mbchain *mbp, u_int32_t x); +int mb_put_int64be(struct mbchain *mbp, int64_t x); +int mb_put_int64le(struct mbchain *mbp, int64_t x); +int mb_put_mem(struct mbchain *mbp, c_caddr_t source, int size, int type); +int mb_put_mbuf(struct mbchain *mbp, struct mbuf *m); +int mb_put_uio(struct mbchain *mbp, struct uio *uiop, int size); + +int md_init(struct mdchain *mdp); +void md_initm(struct mdchain *mbp, struct mbuf *m); +void md_done(struct mdchain *mdp); +void md_append_record(struct mdchain *mdp, struct mbuf *top); +int md_next_record(struct mdchain *mdp); +int md_get_uint8(struct mdchain *mdp, u_int8_t *x); +int md_get_uint16(struct mdchain *mdp, u_int16_t *x); +int md_get_uint16le(struct mdchain *mdp, u_int16_t *x); +int md_get_uint16be(struct mdchain *mdp, u_int16_t *x); +int md_get_uint32(struct mdchain *mdp, u_int32_t *x); +int md_get_uint32be(struct mdchain *mdp, u_int32_t *x); +int md_get_uint32le(struct mdchain *mdp, u_int32_t *x); +int md_get_int64(struct mdchain *mdp, int64_t *x); +int md_get_int64be(struct mdchain *mdp, int64_t *x); +int md_get_int64le(struct mdchain *mdp, int64_t *x); +int md_get_mem(struct mdchain *mdp, caddr_t target, int size, int type); +int md_get_mbuf(struct mdchain *mdp, int size, struct mbuf **m); +int md_get_uio(struct mdchain *mdp, struct uio *uiop, int size); + +#endif /* ifdef _KERNEL */ + +#endif /* !_SYS_MCHAIN_H_ */ |