diff --git a/appl/ftp/Makefile.in b/appl/ftp/Makefile.in
deleted file mode 100644
index 9f2c24a6596bb8df6ff9b70843f45a5f64994965..0000000000000000000000000000000000000000
--- a/appl/ftp/Makefile.in
+++ /dev/null
@@ -1,41 +0,0 @@
-# $Id$
-
-srcdir = @srcdir@
-top_srcdir = @top_srcdir@
-VPATH = @srcdir@
-
-SHELL = /bin/sh
-
-@SET_MAKE@
-
-CC = @CC@
-RANLIB = @RANLIB@
-DEFS = @DEFS@
-CFLAGS = @CFLAGS@
-
-INSTALL = @INSTALL@
-
-prefix = @prefix@
-
-SUBDIRS=common ftp ftpd
-
-all:
- for i in $(SUBDIRS); \
- do (cd $$i && $(MAKE) $(MFLAGS) all); done
-
-install: all
- for i in $(SUBDIRS); \
- do (cd $$i && $(MAKE) $(MFLAGS) install); done
-
-uninstall:
- for i in $(SUBDIRS); \
- do (cd $$i && $(MAKE) $(MFLAGS) uninstall); done
-
-clean cleandir:
- for i in $(SUBDIRS); \
- do (cd $$i && $(MAKE) $(MFLAGS) clean); done
-
-distclean:
- for i in $(SUBDIRS); \
- do (cd $$i && $(MAKE) $(MFLAGS) distclean); done
- rm -f Makefile *~
diff --git a/appl/ftp/common/Makefile.in b/appl/ftp/common/Makefile.in
deleted file mode 100644
index 1c91e8480666fe6753c214b2627ac6fa1d03f6ea..0000000000000000000000000000000000000000
--- a/appl/ftp/common/Makefile.in
+++ /dev/null
@@ -1,52 +0,0 @@
-# $Id$
-
-SHELL = /bin/sh
-
-srcdir = @srcdir@
-top_srcdir = @top_srcdir@
-VPATH = @srcdir@
-
-CC = @CC@
-AR = ar
-RANLIB = @RANLIB@
-DEFS = @DEFS@
-CFLAGS = @CFLAGS@
-
-INSTALL = @INSTALL@
-
-prefix = @prefix@
-
-SOURCES = glob.c sockbuf.c buffer.c
-OBJECTS = $(libcommon_OBJS)
-
-libcommon_OBJS = glob.o sockbuf.o buffer.o
-
-LIBNAME = $(LIBPREFIX)common
-LIBEXT = a
-LIBPREFIX = @LIBPREFIX@
-LIB = $(LIBNAME).$(LIBEXT)
-
-all: $(LIB)
-
-.c.o:
- $(CC) -c $(CFLAGS) -I$(srcdir) -I../../../include $(DEFS) $<
-
-$(LIB): $(libcommon_OBJS)
- rm -f $@
- ar cr $@ $(libcommon_OBJS)
- -$(RANLIB) $@
-
-install:
-
-uninstall:
-
-TAGS: $(SOURCES)
- etags $(SOURCES)
-
-clean cleandir:
- rm -f *~ *.o libcommon.a core \#*
-
-distclean:
- rm -f Makefile
-
-$(OBJECTS): ../../../include/config.h
diff --git a/appl/ftp/common/buffer.c b/appl/ftp/common/buffer.c
deleted file mode 100644
index ab5535cbc91eb2089afdb4f638acee3571a8f13f..0000000000000000000000000000000000000000
--- a/appl/ftp/common/buffer.c
+++ /dev/null
@@ -1,74 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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 "common.h"
-#include <stdio.h>
-#include <err.h>
-#include "roken.h"
-
-RCSID("$Id$");
-
-/*
- * Allocate a buffer enough to handle st->st_blksize, if
- * there is such a field, otherwise BUFSIZ.
- */
-
-void *
-alloc_buffer (void *oldbuf, size_t *sz, struct stat *st)
-{
- size_t new_sz;
-
- new_sz = BUFSIZ;
-#ifdef HAVE_ST_BLKSIZE
- if (st)
- new_sz = max(BUFSIZ, st->st_blksize);
-#endif
- if(new_sz > *sz) {
- if (oldbuf)
- free (oldbuf);
- oldbuf = malloc (new_sz);
- if (oldbuf == NULL) {
- warn ("malloc");
- *sz = 0;
- return NULL;
- }
- *sz = new_sz;
- }
- return oldbuf;
-}
-
diff --git a/appl/ftp/common/common.h b/appl/ftp/common/common.h
deleted file mode 100644
index ec011e6124b4cd7e3a874a1886610d79daa0fe61..0000000000000000000000000000000000000000
--- a/appl/ftp/common/common.h
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-
-#ifndef __COMMON_H__
-#define __COMMON_H__
-
-#include "base64.h"
-
-void set_buffer_size(int, int);
-
-#include <stdlib.h>
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_STAT_H
-#include <sys/stat.h>
-#endif
-
-void *alloc_buffer (void *oldbuf, size_t *sz, struct stat *st);
-
-#endif /* __COMMON_H__ */
diff --git a/appl/ftp/common/glob.c b/appl/ftp/common/glob.c
deleted file mode 100644
index 8f19d7ca4dab176a0c7dff11708c28a2a4e56b69..0000000000000000000000000000000000000000
--- a/appl/ftp/common/glob.c
+++ /dev/null
@@ -1,835 +0,0 @@
-/*
- * 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(3) -- a superset of the one defined in POSIX 1003.2.
- *
- * The [!...] convention to negate a range is supported (SysV, Posix, ksh).
- *
- * Optional extra services, controlled by flags not defined by POSIX:
- *
- * GLOB_QUOTE:
- * Escaping convention: \ inhibits any special meaning the following
- * character might have (except \ at end of string is retained).
- * GLOB_MAGCHAR:
- * Set in gl_flags if pattern contained a globbing character.
- * GLOB_NOMAGIC:
- * Same as GLOB_NOCHECK, but it will only append pattern if it did
- * not contain any magic characters. [Used in csh style globbing]
- * GLOB_ALTDIRFUNC:
- * Use alternately specified directory access functions.
- * GLOB_TILDE:
- * expand ~user/foo to the /home/dir/of/user/foo
- * GLOB_BRACE:
- * expand {1,2}{a,b} to 1a 1b 2a 2b
- * gl_matchc:
- * Number of matches in the current invocation of glob.
- */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-
-#ifdef HAVE_SYS_PARAM_H
-#include <sys/param.h>
-#endif
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_STAT_H
-#include <sys/stat.h>
-#endif
-
-#include <ctype.h>
-#ifdef HAVE_DIRENT_H
-#include <dirent.h>
-#endif
-#include <errno.h>
-#ifdef HAVE_PWD_H
-#include <pwd.h>
-#endif
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
-
-#include "glob.h"
-#include "roken.h"
-
-#define CHAR_DOLLAR '$'
-#define CHAR_DOT '.'
-#define CHAR_EOS '\0'
-#define CHAR_LBRACKET '['
-#define CHAR_NOT '!'
-#define CHAR_QUESTION '?'
-#define CHAR_QUOTE '\\'
-#define CHAR_RANGE '-'
-#define CHAR_RBRACKET ']'
-#define CHAR_SEP '/'
-#define CHAR_STAR '*'
-#define CHAR_TILDE '~'
-#define CHAR_UNDERSCORE '_'
-#define CHAR_LBRACE '{'
-#define CHAR_RBRACE '}'
-#define CHAR_SLASH '/'
-#define CHAR_COMMA ','
-
-#ifndef DEBUG
-
-#define M_QUOTE 0x8000
-#define M_PROTECT 0x4000
-#define M_MASK 0xffff
-#define M_ASCII 0x00ff
-
-typedef u_short Char;
-
-#else
-
-#define M_QUOTE 0x80
-#define M_PROTECT 0x40
-#define M_MASK 0xff
-#define M_ASCII 0x7f
-
-typedef char Char;
-
-#endif
-
-
-#define CHAR(c) ((Char)((c)&M_ASCII))
-#define META(c) ((Char)((c)|M_QUOTE))
-#define M_ALL META('*')
-#define M_END META(']')
-#define M_NOT META('!')
-#define M_ONE META('?')
-#define M_RNG META('-')
-#define M_SET META('[')
-#define ismeta(c) (((c)&M_QUOTE) != 0)
-
-
-static int compare (const void *, const void *);
-static void g_Ctoc (const Char *, char *);
-static int g_lstat (Char *, struct stat *, glob_t *);
-static DIR *g_opendir (Char *, glob_t *);
-static Char *g_strchr (Char *, int);
-#ifdef notdef
-static Char *g_strcat (Char *, const Char *);
-#endif
-static int g_stat (Char *, struct stat *, glob_t *);
-static int glob0 (const Char *, glob_t *);
-static int glob1 (Char *, glob_t *);
-static int glob2 (Char *, Char *, Char *, glob_t *);
-static int glob3 (Char *, Char *, Char *, Char *, glob_t *);
-static int globextend (const Char *, glob_t *);
-static const Char * globtilde (const Char *, Char *, glob_t *);
-static int globexp1 (const Char *, glob_t *);
-static int globexp2 (const Char *, const Char *, glob_t *, int *);
-static int match (Char *, Char *, Char *);
-#ifdef DEBUG
-static void qprintf (const char *, Char *);
-#endif
-
-int
-glob(const char *pattern,
- int flags,
- int (*errfunc)(const char *, int),
- glob_t *pglob)
-{
- const u_char *patnext;
- int c;
- Char *bufnext, *bufend, patbuf[MaxPathLen+1];
-
- patnext = (u_char *) pattern;
- if (!(flags & GLOB_APPEND)) {
- pglob->gl_pathc = 0;
- pglob->gl_pathv = NULL;
- if (!(flags & GLOB_DOOFFS))
- pglob->gl_offs = 0;
- }
- pglob->gl_flags = flags & ~GLOB_MAGCHAR;
- pglob->gl_errfunc = errfunc;
- pglob->gl_matchc = 0;
-
- bufnext = patbuf;
- bufend = bufnext + MaxPathLen;
- if (flags & GLOB_QUOTE) {
- /* Protect the quoted characters. */
- while (bufnext < bufend && (c = *patnext++) != CHAR_EOS)
- if (c == CHAR_QUOTE) {
- if ((c = *patnext++) == CHAR_EOS) {
- c = CHAR_QUOTE;
- --patnext;
- }
- *bufnext++ = c | M_PROTECT;
- }
- else
- *bufnext++ = c;
- }
- else
- while (bufnext < bufend && (c = *patnext++) != CHAR_EOS)
- *bufnext++ = c;
- *bufnext = CHAR_EOS;
-
- if (flags & GLOB_BRACE)
- return globexp1(patbuf, pglob);
- else
- return glob0(patbuf, pglob);
-}
-
-/*
- * Expand recursively a glob {} pattern. When there is no more expansion
- * invoke the standard globbing routine to glob the rest of the magic
- * characters
- */
-static int globexp1(const Char *pattern, glob_t *pglob)
-{
- const Char* ptr = pattern;
- int rv;
-
- /* Protect a single {}, for find(1), like csh */
- if (pattern[0] == CHAR_LBRACE && pattern[1] == CHAR_RBRACE && pattern[2] == CHAR_EOS)
- return glob0(pattern, pglob);
-
- while ((ptr = (const Char *) g_strchr((Char *) ptr, CHAR_LBRACE)) != NULL)
- if (!globexp2(ptr, pattern, pglob, &rv))
- return rv;
-
- return glob0(pattern, pglob);
-}
-
-
-/*
- * Recursive brace globbing helper. Tries to expand a single brace.
- * If it succeeds then it invokes globexp1 with the new pattern.
- * If it fails then it tries to glob the rest of the pattern and returns.
- */
-static int globexp2(const Char *ptr, const Char *pattern,
- glob_t *pglob, int *rv)
-{
- int i;
- Char *lm, *ls;
- const Char *pe, *pm, *pl;
- Char patbuf[MaxPathLen + 1];
-
- /* copy part up to the brace */
- for (lm = patbuf, pm = pattern; pm != ptr; *lm++ = *pm++)
- continue;
- ls = lm;
-
- /* Find the balanced brace */
- for (i = 0, pe = ++ptr; *pe; pe++)
- if (*pe == CHAR_LBRACKET) {
- /* Ignore everything between [] */
- for (pm = pe++; *pe != CHAR_RBRACKET && *pe != CHAR_EOS; pe++)
- continue;
- if (*pe == CHAR_EOS) {
- /*
- * We could not find a matching CHAR_RBRACKET.
- * Ignore and just look for CHAR_RBRACE
- */
- pe = pm;
- }
- }
- else if (*pe == CHAR_LBRACE)
- i++;
- else if (*pe == CHAR_RBRACE) {
- if (i == 0)
- break;
- i--;
- }
-
- /* Non matching braces; just glob the pattern */
- if (i != 0 || *pe == CHAR_EOS) {
- *rv = glob0(patbuf, pglob);
- return 0;
- }
-
- for (i = 0, pl = pm = ptr; pm <= pe; pm++)
- switch (*pm) {
- case CHAR_LBRACKET:
- /* Ignore everything between [] */
- for (pl = pm++; *pm != CHAR_RBRACKET && *pm != CHAR_EOS; pm++)
- continue;
- if (*pm == CHAR_EOS) {
- /*
- * We could not find a matching CHAR_RBRACKET.
- * Ignore and just look for CHAR_RBRACE
- */
- pm = pl;
- }
- break;
-
- case CHAR_LBRACE:
- i++;
- break;
-
- case CHAR_RBRACE:
- if (i) {
- i--;
- break;
- }
- /* FALLTHROUGH */
- case CHAR_COMMA:
- if (i && *pm == CHAR_COMMA)
- break;
- else {
- /* Append the current string */
- for (lm = ls; (pl < pm); *lm++ = *pl++)
- continue;
- /*
- * Append the rest of the pattern after the
- * closing brace
- */
- for (pl = pe + 1; (*lm++ = *pl++) != CHAR_EOS;)
- continue;
-
- /* Expand the current pattern */
-#ifdef DEBUG
- qprintf("globexp2:", patbuf);
-#endif
- *rv = globexp1(patbuf, pglob);
-
- /* move after the comma, to the next string */
- pl = pm + 1;
- }
- break;
-
- default:
- break;
- }
- *rv = 0;
- return 0;
-}
-
-
-
-/*
- * expand tilde from the passwd file.
- */
-static const Char *
-globtilde(const Char *pattern, Char *patbuf, glob_t *pglob)
-{
- struct passwd *pwd;
- char *h;
- const Char *p;
- Char *b;
-
- if (*pattern != CHAR_TILDE || !(pglob->gl_flags & GLOB_TILDE))
- return pattern;
-
- /* Copy up to the end of the string or / */
- for (p = pattern + 1, h = (char *) patbuf; *p && *p != CHAR_SLASH;
- *h++ = *p++)
- continue;
-
- *h = CHAR_EOS;
-
- if (((char *) patbuf)[0] == CHAR_EOS) {
- /*
- * handle a plain ~ or ~/ by expanding $HOME
- * first and then trying the password file
- */
- if ((h = getenv("HOME")) == NULL) {
- if ((pwd = k_getpwuid(getuid())) == NULL)
- return pattern;
- else
- h = pwd->pw_dir;
- }
- }
- else {
- /*
- * Expand a ~user
- */
- if ((pwd = k_getpwnam((char*) patbuf)) == NULL)
- return pattern;
- else
- h = pwd->pw_dir;
- }
-
- /* Copy the home directory */
- for (b = patbuf; *h; *b++ = *h++)
- continue;
-
- /* Append the rest of the pattern */
- while ((*b++ = *p++) != CHAR_EOS)
- continue;
-
- return patbuf;
-}
-
-
-/*
- * The main glob() routine: compiles the pattern (optionally processing
- * quotes), calls glob1() to do the real pattern matching, and finally
- * sorts the list (unless unsorted operation is requested). Returns 0
- * if things went well, nonzero if errors occurred. It is not an error
- * to find no matches.
- */
-static int
-glob0(const Char *pattern, glob_t *pglob)
-{
- const Char *qpatnext;
- int c, err, oldpathc;
- Char *bufnext, patbuf[MaxPathLen+1];
-
- qpatnext = globtilde(pattern, patbuf, pglob);
- oldpathc = pglob->gl_pathc;
- bufnext = patbuf;
-
- /* We don't need to check for buffer overflow any more. */
- while ((c = *qpatnext++) != CHAR_EOS) {
- switch (c) {
- case CHAR_LBRACKET:
- c = *qpatnext;
- if (c == CHAR_NOT)
- ++qpatnext;
- if (*qpatnext == CHAR_EOS ||
- g_strchr((Char *) qpatnext+1, CHAR_RBRACKET) == NULL) {
- *bufnext++ = CHAR_LBRACKET;
- if (c == CHAR_NOT)
- --qpatnext;
- break;
- }
- *bufnext++ = M_SET;
- if (c == CHAR_NOT)
- *bufnext++ = M_NOT;
- c = *qpatnext++;
- do {
- *bufnext++ = CHAR(c);
- if (*qpatnext == CHAR_RANGE &&
- (c = qpatnext[1]) != CHAR_RBRACKET) {
- *bufnext++ = M_RNG;
- *bufnext++ = CHAR(c);
- qpatnext += 2;
- }
- } while ((c = *qpatnext++) != CHAR_RBRACKET);
- pglob->gl_flags |= GLOB_MAGCHAR;
- *bufnext++ = M_END;
- break;
- case CHAR_QUESTION:
- pglob->gl_flags |= GLOB_MAGCHAR;
- *bufnext++ = M_ONE;
- break;
- case CHAR_STAR:
- pglob->gl_flags |= GLOB_MAGCHAR;
- /* collapse adjacent stars to one,
- * to avoid exponential behavior
- */
- if (bufnext == patbuf || bufnext[-1] != M_ALL)
- *bufnext++ = M_ALL;
- break;
- default:
- *bufnext++ = CHAR(c);
- break;
- }
- }
- *bufnext = CHAR_EOS;
-#ifdef DEBUG
- qprintf("glob0:", patbuf);
-#endif
-
- if ((err = glob1(patbuf, pglob)) != 0)
- return(err);
-
- /*
- * If there was no match we are going to append the pattern
- * if GLOB_NOCHECK was specified or if GLOB_NOMAGIC was specified
- * and the pattern did not contain any magic characters
- * GLOB_NOMAGIC is there just for compatibility with csh.
- */
- if (pglob->gl_pathc == oldpathc &&
- ((pglob->gl_flags & GLOB_NOCHECK) ||
- ((pglob->gl_flags & GLOB_NOMAGIC) &&
- !(pglob->gl_flags & GLOB_MAGCHAR))))
- return(globextend(pattern, pglob));
- else if (!(pglob->gl_flags & GLOB_NOSORT))
- qsort(pglob->gl_pathv + pglob->gl_offs + oldpathc,
- pglob->gl_pathc - oldpathc, sizeof(char *), compare);
- return(0);
-}
-
-static int
-compare(const void *p, const void *q)
-{
- return(strcmp(*(char **)p, *(char **)q));
-}
-
-static int
-glob1(Char *pattern, glob_t *pglob)
-{
- Char pathbuf[MaxPathLen+1];
-
- /* A null pathname is invalid -- POSIX 1003.1 sect. 2.4. */
- if (*pattern == CHAR_EOS)
- return(0);
- return(glob2(pathbuf, pathbuf, pattern, pglob));
-}
-
-/*
- * The functions glob2 and glob3 are mutually recursive; there is one level
- * of recursion for each segment in the pattern that contains one or more
- * meta characters.
- */
-
-#ifndef S_ISLNK
-#if defined(S_IFLNK) && defined(S_IFMT)
-#define S_ISLNK(mode) (((mode) & S_IFMT) == S_IFLNK)
-#else
-#define S_ISLNK(mode) 0
-#endif
-#endif
-
-static int
-glob2(Char *pathbuf, Char *pathend, Char *pattern, glob_t *pglob)
-{
- struct stat sb;
- Char *p, *q;
- int anymeta;
-
- /*
- * Loop over pattern segments until end of pattern or until
- * segment with meta character found.
- */
- for (anymeta = 0;;) {
- if (*pattern == CHAR_EOS) { /* End of pattern? */
- *pathend = CHAR_EOS;
- if (g_lstat(pathbuf, &sb, pglob))
- return(0);
-
- if (((pglob->gl_flags & GLOB_MARK) &&
- pathend[-1] != CHAR_SEP) && (S_ISDIR(sb.st_mode)
- || (S_ISLNK(sb.st_mode) &&
- (g_stat(pathbuf, &sb, pglob) == 0) &&
- S_ISDIR(sb.st_mode)))) {
- *pathend++ = CHAR_SEP;
- *pathend = CHAR_EOS;
- }
- ++pglob->gl_matchc;
- return(globextend(pathbuf, pglob));
- }
-
- /* Find end of next segment, copy tentatively to pathend. */
- q = pathend;
- p = pattern;
- while (*p != CHAR_EOS && *p != CHAR_SEP) {
- if (ismeta(*p))
- anymeta = 1;
- *q++ = *p++;
- }
-
- if (!anymeta) { /* No expansion, do next segment. */
- pathend = q;
- pattern = p;
- while (*pattern == CHAR_SEP)
- *pathend++ = *pattern++;
- } else /* Need expansion, recurse. */
- return(glob3(pathbuf, pathend, pattern, p, pglob));
- }
- /* CHAR_NOTREACHED */
-}
-
-static int
-glob3(Char *pathbuf, Char *pathend, Char *pattern, Char *restpattern,
- glob_t *pglob)
-{
- struct dirent *dp;
- DIR *dirp;
- int err;
- char buf[MaxPathLen];
-
- /*
- * The readdirfunc declaration can't be prototyped, because it is
- * assigned, below, to two functions which are prototyped in glob.h
- * and dirent.h as taking pointers to differently typed opaque
- * structures.
- */
- struct dirent *(*readdirfunc)(void *);
-
- *pathend = CHAR_EOS;
- errno = 0;
-
- if ((dirp = g_opendir(pathbuf, pglob)) == NULL) {
- /* TODO: don't call for ENOENT or ENOTDIR? */
- if (pglob->gl_errfunc) {
- g_Ctoc(pathbuf, buf);
- if (pglob->gl_errfunc(buf, errno) ||
- pglob->gl_flags & GLOB_ERR)
- return (GLOB_ABEND);
- }
- return(0);
- }
-
- err = 0;
-
- /* Search directory for matching names. */
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- readdirfunc = pglob->gl_readdir;
- else
- readdirfunc = (struct dirent *(*)(void *))readdir;
- while ((dp = (*readdirfunc)(dirp))) {
- u_char *sc;
- Char *dc;
-
- /* Initial CHAR_DOT must be matched literally. */
- if (dp->d_name[0] == CHAR_DOT && *pattern != CHAR_DOT)
- continue;
- for (sc = (u_char *) dp->d_name, dc = pathend;
- (*dc++ = *sc++) != CHAR_EOS;)
- continue;
- if (!match(pathend, pattern, restpattern)) {
- *pathend = CHAR_EOS;
- continue;
- }
- err = glob2(pathbuf, --dc, restpattern, pglob);
- if (err)
- break;
- }
-
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- (*pglob->gl_closedir)(dirp);
- else
- closedir(dirp);
- return(err);
-}
-
-
-/*
- * Extend the gl_pathv member of a glob_t structure to accomodate a new item,
- * add the new item, and update gl_pathc.
- *
- * This assumes the BSD realloc, which only copies the block when its size
- * crosses a power-of-two boundary; for v7 realloc, this would cause quadratic
- * behavior.
- *
- * Return 0 if new item added, error code if memory couldn't be allocated.
- *
- * Invariant of the glob_t structure:
- * Either gl_pathc is zero and gl_pathv is NULL; or gl_pathc > 0 and
- * gl_pathv points to (gl_offs + gl_pathc + 1) items.
- */
-static int
-globextend(const Char *path, glob_t *pglob)
-{
- char **pathv;
- int i;
- u_int newsize;
- char *copy;
- const Char *p;
-
- newsize = sizeof(*pathv) * (2 + pglob->gl_pathc + pglob->gl_offs);
- pathv = pglob->gl_pathv ?
- realloc(pglob->gl_pathv, newsize) :
- malloc(newsize);
- if (pathv == NULL)
- return(GLOB_NOSPACE);
-
- if (pglob->gl_pathv == NULL && pglob->gl_offs > 0) {
- /* first time around -- clear initial gl_offs items */
- pathv += pglob->gl_offs;
- for (i = pglob->gl_offs; --i >= 0; )
- *--pathv = NULL;
- }
- pglob->gl_pathv = pathv;
-
- for (p = path; *p++;)
- continue;
- if ((copy = malloc(p - path)) != NULL) {
- g_Ctoc(path, copy);
- pathv[pglob->gl_offs + pglob->gl_pathc++] = copy;
- }
- pathv[pglob->gl_offs + pglob->gl_pathc] = NULL;
- return(copy == NULL ? GLOB_NOSPACE : 0);
-}
-
-
-/*
- * pattern matching function for filenames. Each occurrence of the *
- * pattern causes a recursion level.
- */
-static int
-match(Char *name, Char *pat, Char *patend)
-{
- int ok, negate_range;
- Char c, k;
-
- while (pat < patend) {
- c = *pat++;
- switch (c & M_MASK) {
- case M_ALL:
- if (pat == patend)
- return(1);
- do
- if (match(name, pat, patend))
- return(1);
- while (*name++ != CHAR_EOS);
- return(0);
- case M_ONE:
- if (*name++ == CHAR_EOS)
- return(0);
- break;
- case M_SET:
- ok = 0;
- if ((k = *name++) == CHAR_EOS)
- return(0);
- if ((negate_range = ((*pat & M_MASK) == M_NOT)) != CHAR_EOS)
- ++pat;
- while (((c = *pat++) & M_MASK) != M_END)
- if ((*pat & M_MASK) == M_RNG) {
- if (c <= k && k <= pat[1])
- ok = 1;
- pat += 2;
- } else if (c == k)
- ok = 1;
- if (ok == negate_range)
- return(0);
- break;
- default:
- if (*name++ != c)
- return(0);
- break;
- }
- }
- return(*name == CHAR_EOS);
-}
-
-/* Free allocated data belonging to a glob_t structure. */
-void
-globfree(glob_t *pglob)
-{
- int i;
- char **pp;
-
- if (pglob->gl_pathv != NULL) {
- pp = pglob->gl_pathv + pglob->gl_offs;
- for (i = pglob->gl_pathc; i--; ++pp)
- if (*pp)
- free(*pp);
- free(pglob->gl_pathv);
- }
-}
-
-static DIR *
-g_opendir(Char *str, glob_t *pglob)
-{
- char buf[MaxPathLen];
-
- if (!*str)
- strcpy(buf, ".");
- else
- g_Ctoc(str, buf);
-
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- return((*pglob->gl_opendir)(buf));
-
- return(opendir(buf));
-}
-
-static int
-g_lstat(Char *fn, struct stat *sb, glob_t *pglob)
-{
- char buf[MaxPathLen];
-
- g_Ctoc(fn, buf);
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- return((*pglob->gl_lstat)(buf, sb));
- return(lstat(buf, sb));
-}
-
-static int
-g_stat(Char *fn, struct stat *sb, glob_t *pglob)
-{
- char buf[MaxPathLen];
-
- g_Ctoc(fn, buf);
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- return((*pglob->gl_stat)(buf, sb));
- return(stat(buf, sb));
-}
-
-static Char *
-g_strchr(Char *str, int ch)
-{
- do {
- if (*str == ch)
- return (str);
- } while (*str++);
- return (NULL);
-}
-
-#ifdef notdef
-static Char *
-g_strcat(Char *dst, const Char *src)
-{
- Char *sdst = dst;
-
- while (*dst++)
- continue;
- --dst;
- while((*dst++ = *src++) != CHAR_EOS)
- continue;
-
- return (sdst);
-}
-#endif
-
-static void
-g_Ctoc(const Char *str, char *buf)
-{
- char *dc;
-
- for (dc = buf; (*dc++ = *str++) != CHAR_EOS;)
- continue;
-}
-
-#ifdef DEBUG
-static void
-qprintf(const Char *str, Char *s)
-{
- Char *p;
-
- printf("%s:\n", str);
- for (p = s; *p; p++)
- printf("%c", CHAR(*p));
- printf("\n");
- for (p = s; *p; p++)
- printf("%c", *p & M_PROTECT ? '"' : ' ');
- printf("\n");
- for (p = s; *p; p++)
- printf("%c", ismeta(*p) ? '_' : ' ');
- printf("\n");
-}
-#endif
diff --git a/appl/ftp/common/glob.h b/appl/ftp/common/glob.h
deleted file mode 100644
index bece48a89cd76a787f8824ec319bcd8da22a6773..0000000000000000000000000000000000000000
--- a/appl/ftp/common/glob.h
+++ /dev/null
@@ -1,84 +0,0 @@
-/*
- * 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/appl/ftp/common/sockbuf.c b/appl/ftp/common/sockbuf.c
deleted file mode 100644
index a3d0756b5d0d3d633b7fb68a11cb6fa090ab2581..0000000000000000000000000000000000000000
--- a/appl/ftp/common/sockbuf.c
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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 "common.h"
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_SOCKET_H
-#include <sys/socket.h>
-#endif
-
-RCSID("$Id$");
-
-void
-set_buffer_size(int fd, int read)
-{
-#if defined(SO_RCVBUF) && defined(SO_SNDBUF) && defined(HAVE_SETSOCKOPT)
- size_t size = 4194304;
- while(size >= 131072 &&
- setsockopt(fd, SOL_SOCKET, read ? SO_RCVBUF : SO_SNDBUF,
- (void *)&size, sizeof(size)) < 0)
- size /= 2;
-#endif
-}
-
-
diff --git a/appl/ftp/ftp/Makefile.in b/appl/ftp/ftp/Makefile.in
deleted file mode 100644
index 994f28efbc5ff4e5ed3e2d1adc30f8b969256de6..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/Makefile.in
+++ /dev/null
@@ -1,76 +0,0 @@
-#
-# $Id$
-#
-
-SHELL = /bin/sh
-
-srcdir = @srcdir@
-top_srcdir = @top_srcdir@
-VPATH = @srcdir@
-
-top_builddir = ../../..
-
-CC = @CC@
-RANLIB = @RANLIB@
-DEFS = @DEFS@
-CFLAGS = @CFLAGS@
-CPPFLAGS= @CPPFLAGS@ -I. -I$(srcdir) -I$(top_builddir) -I$(top_srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include -I$(srcdir)/../common @INCLUDE_readline@
-LD_FLAGS = @LD_FLAGS@
-LIB_tgetent = @LIB_tgetent@
-LIBS = @LIBS@ @LIB_readline@
-MKINSTALLDIRS = $(top_srcdir)/mkinstalldirs
-
-INSTALL = @INSTALL@
-INSTALL_PROGRAM = @INSTALL_PROGRAM@
-
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-bindir = @bindir@
-libdir = @libdir@
-transform=@program_transform_name@
-EXECSUFFIX=@EXECSUFFIX@
-
-INCTOP = $(top_builddir)/include
-
-LIBTOP = $(top_builddir)/lib
-
-PROGS = ftp$(EXECSUFFIX)
-
-ftp_OBJS = cmds.o cmdtab.o ftp.o krb4.o main.o ruserpass.o domacro.o \
- globals.o kauth.o
-
-ftp_SOURCES = cmds.c cmdtab.c ftp.c krb4.c main.c ruserpass.c \
- domacro.c globals.c kauth.c
-
-OBJECTS = $(ftp_OBJS)
-SOURCES = $(ftp_SOURCES)
-
-all: $(PROGS)
-
-.c.o:
- $(CC) -c $(CFLAGS) $(CPPFLAGS) $(DEFS) $<
-
-install: all
- $(MKINSTALLDIRS) $(bindir)
- for x in $(PROGS); do \
- $(INSTALL_PROGRAM) $$x $(bindir)/`echo $$x | sed '$(transform)'`; \
- done
-
-uninstall:
- for x in $(PROGS); do \
- rm -f $(bindir)/`echo $$x | sed '$(transform)'`; \
- done
-
-ftp$(EXECSUFFIX): $(ftp_OBJS) # ../common/libcommon.a
- $(CC) $(LD_FLAGS) $(LDFLAGS) -o $@ $(ftp_OBJS) -L../common -lcommon -L$(LIBTOP)/krb -lkrb -L$(LIBTOP)/des -ldes -L$(LIBTOP)/roken -lroken $(LIBS) -L$(LIBTOP)/roken -lroken
-
-TAGS: $(SOURCES)
- etags $(SOURCES)
-
-clean cleandir:
- rm -f *~ *.o core ftp$(EXECSUFFIX) \#*
-
-distclean:
- rm -f Makefile
-
-$(OBJECTS): ../../../include/config.h
diff --git a/appl/ftp/ftp/cmds.c b/appl/ftp/ftp/cmds.c
deleted file mode 100644
index 5aa9b6e52f9e20428991c2bde895ef93859fd835..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/cmds.c
+++ /dev/null
@@ -1,2090 +0,0 @@
-/*
- * Copyright (c) 1985, 1989, 1993, 1994
- * 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.
- */
-
-/*
- * FTP User Program -- Command Routines.
- */
-
-#include "ftp_locl.h"
-RCSID("$Id$");
-
-typedef void (*sighand)(int);
-
-jmp_buf jabort;
-char *mname;
-char *home = "/";
-
-/*
- * `Another' gets another argument, and stores the new argc and argv.
- * It reverts to the top level (via main.c's intr()) on EOF/error.
- *
- * Returns false if no new arguments have been added.
- */
-int
-another(int *pargc, char ***pargv, char *prompt)
-{
- int len = strlen(line), ret;
-
- if (len >= sizeof(line) - 3) {
- printf("sorry, arguments too long\n");
- intr(0);
- }
- printf("(%s) ", prompt);
- line[len++] = ' ';
- if (fgets(&line[len], sizeof(line) - len, stdin) == NULL)
- intr(0);
- len += strlen(&line[len]);
- if (len > 0 && line[len - 1] == '\n')
- line[len - 1] = '\0';
- makeargv();
- ret = margc > *pargc;
- *pargc = margc;
- *pargv = margv;
- return (ret);
-}
-
-/*
- * Connect to peer server and
- * auto-login, if possible.
- */
-void
-setpeer(int argc, char **argv)
-{
- char *host;
- short port;
- struct servent *sp;
-
- if (connected) {
- printf("Already connected to %s, use close first.\n",
- hostname);
- code = -1;
- return;
- }
- if (argc < 2)
- another(&argc, &argv, "to");
- if (argc < 2 || argc > 3) {
- printf("usage: %s host-name [port]\n", argv[0]);
- code = -1;
- return;
- }
- sp = getservbyname("ftp", "tcp");
- if (sp == NULL)
- errx(1, "You bastard. You removed ftp/tcp from services");
- port = sp->s_port;
- if (argc > 2) {
- port = atoi(argv[2]);
- if (port <= 0) {
- printf("%s: bad port number-- %s\n", argv[1], argv[2]);
- printf ("usage: %s host-name [port]\n", argv[0]);
- code = -1;
- return;
- }
- port = htons(port);
- }
- host = hookup(argv[1], port);
- if (host) {
- int overbose;
-
- connected = 1;
- /*
- * Set up defaults for FTP.
- */
- strcpy(typename, "ascii"), type = TYPE_A;
- curtype = TYPE_A;
- strcpy(formname, "non-print"), form = FORM_N;
- strcpy(modename, "stream"), mode = MODE_S;
- strcpy(structname, "file"), stru = STRU_F;
- strcpy(bytename, "8"), bytesize = 8;
- if (autologin)
- login(argv[1]);
-
-#if (defined(unix) || defined(__unix__) || defined(__unix) || defined(_AIX) || defined(_CRAY)) && NBBY == 8
-/*
- * this ifdef is to keep someone form "porting" this to an incompatible
- * system and not checking this out. This way they have to think about it.
- */
- overbose = verbose;
- if (debug == 0)
- verbose = -1;
- if (command("SYST") == COMPLETE && overbose) {
- char *cp, c;
- cp = strchr(reply_string+4, ' ');
- if (cp == NULL)
- cp = strchr(reply_string+4, '\r');
- if (cp) {
- if (cp[-1] == '.')
- cp--;
- c = *cp;
- *cp = '\0';
- }
-
- printf("Remote system type is %s.\n",
- reply_string+4);
- if (cp)
- *cp = c;
- }
- if (!strncmp(reply_string, "215 UNIX Type: L8", 17)) {
- if (proxy)
- unix_proxy = 1;
- else
- unix_server = 1;
- /*
- * Set type to 0 (not specified by user),
- * meaning binary by default, but don't bother
- * telling server. We can use binary
- * for text files unless changed by the user.
- */
- type = 0;
- strcpy(typename, "binary");
- if (overbose)
- printf("Using %s mode to transfer files.\n",
- typename);
- } else {
- if (proxy)
- unix_proxy = 0;
- else
- unix_server = 0;
- if (overbose &&
- !strncmp(reply_string, "215 TOPS20", 10))
- printf(
-"Remember to set tenex mode when transfering binary files from this machine.\n");
- }
- verbose = overbose;
-#endif /* unix */
- }
-}
-
-struct types {
- char *t_name;
- char *t_mode;
- int t_type;
- char *t_arg;
-} types[] = {
- { "ascii", "A", TYPE_A, 0 },
- { "binary", "I", TYPE_I, 0 },
- { "image", "I", TYPE_I, 0 },
- { "ebcdic", "E", TYPE_E, 0 },
- { "tenex", "L", TYPE_L, bytename },
- { NULL }
-};
-
-/*
- * Set transfer type.
- */
-void
-settype(int argc, char **argv)
-{
- struct types *p;
- int comret;
-
- if (argc > 2) {
- char *sep;
-
- printf("usage: %s [", argv[0]);
- sep = " ";
- for (p = types; p->t_name; p++) {
- printf("%s%s", sep, p->t_name);
- sep = " | ";
- }
- printf(" ]\n");
- code = -1;
- return;
- }
- if (argc < 2) {
- printf("Using %s mode to transfer files.\n", typename);
- code = 0;
- return;
- }
- for (p = types; p->t_name; p++)
- if (strcmp(argv[1], p->t_name) == 0)
- break;
- if (p->t_name == 0) {
- printf("%s: unknown mode\n", argv[1]);
- code = -1;
- return;
- }
- if ((p->t_arg != NULL) && (*(p->t_arg) != '\0'))
- comret = command ("TYPE %s %s", p->t_mode, p->t_arg);
- else
- comret = command("TYPE %s", p->t_mode);
- if (comret == COMPLETE) {
- strcpy(typename, p->t_name);
- curtype = type = p->t_type;
- }
-}
-
-/*
- * Internal form of settype; changes current type in use with server
- * without changing our notion of the type for data transfers.
- * Used to change to and from ascii for listings.
- */
-void
-changetype(int newtype, int show)
-{
- struct types *p;
- int comret, oldverbose = verbose;
-
- if (newtype == 0)
- newtype = TYPE_I;
- if (newtype == curtype)
- return;
- if (debug == 0 && show == 0)
- verbose = 0;
- for (p = types; p->t_name; p++)
- if (newtype == p->t_type)
- break;
- if (p->t_name == 0) {
- printf("ftp: internal error: unknown type %d\n", newtype);
- return;
- }
- if (newtype == TYPE_L && bytename[0] != '\0')
- comret = command("TYPE %s %s", p->t_mode, bytename);
- else
- comret = command("TYPE %s", p->t_mode);
- if (comret == COMPLETE)
- curtype = newtype;
- verbose = oldverbose;
-}
-
-char *stype[] = {
- "type",
- "",
- 0
-};
-
-/*
- * Set binary transfer type.
- */
-/*VARARGS*/
-void
-setbinary(int argc, char **argv)
-{
-
- stype[1] = "binary";
- settype(2, stype);
-}
-
-/*
- * Set ascii transfer type.
- */
-/*VARARGS*/
-void
-setascii(int argc, char **argv)
-{
-
- stype[1] = "ascii";
- settype(2, stype);
-}
-
-/*
- * Set tenex transfer type.
- */
-/*VARARGS*/
-void
-settenex(int argc, char **argv)
-{
-
- stype[1] = "tenex";
- settype(2, stype);
-}
-
-/*
- * Set file transfer mode.
- */
-/*ARGSUSED*/
-void
-setftmode(int argc, char **argv)
-{
-
- printf("We only support %s mode, sorry.\n", modename);
- code = -1;
-}
-
-/*
- * Set file transfer format.
- */
-/*ARGSUSED*/
-void
-setform(int argc, char **argv)
-{
-
- printf("We only support %s format, sorry.\n", formname);
- code = -1;
-}
-
-/*
- * Set file transfer structure.
- */
-/*ARGSUSED*/
-void
-setstruct(int argc, char **argv)
-{
-
- printf("We only support %s structure, sorry.\n", structname);
- code = -1;
-}
-
-/*
- * Send a single file.
- */
-void
-put(int argc, char **argv)
-{
- char *cmd;
- int loc = 0;
- char *oldargv1, *oldargv2;
-
- if (argc == 2) {
- argc++;
- argv[2] = argv[1];
- loc++;
- }
- if (argc < 2 && !another(&argc, &argv, "local-file"))
- goto usage;
- if (argc < 3 && !another(&argc, &argv, "remote-file")) {
-usage:
- printf("usage: %s local-file remote-file\n", argv[0]);
- code = -1;
- return;
- }
- oldargv1 = argv[1];
- oldargv2 = argv[2];
- if (!globulize(&argv[1])) {
- code = -1;
- return;
- }
- /*
- * If "globulize" modifies argv[1], and argv[2] is a copy of
- * the old argv[1], make it a copy of the new argv[1].
- */
- if (argv[1] != oldargv1 && argv[2] == oldargv1) {
- argv[2] = argv[1];
- }
- cmd = (argv[0][0] == 'a') ? "APPE" : ((sunique) ? "STOU" : "STOR");
- if (loc && ntflag) {
- argv[2] = dotrans(argv[2]);
- }
- if (loc && mapflag) {
- argv[2] = domap(argv[2]);
- }
- sendrequest(cmd, argv[1], argv[2],
- argv[1] != oldargv1 || argv[2] != oldargv2);
-}
-
-/* ARGSUSED */
-static RETSIGTYPE
-mabort(int signo)
-{
- int ointer;
-
- printf("\n");
- fflush(stdout);
- if (mflag && fromatty) {
- ointer = interactive;
- interactive = 1;
- if (confirm("Continue with", mname)) {
- interactive = ointer;
- longjmp(jabort,0);
- }
- interactive = ointer;
- }
- mflag = 0;
- longjmp(jabort,0);
-}
-
-/*
- * Send multiple files.
- */
-void
-mput(int argc, char **argv)
-{
- int i;
- RETSIGTYPE (*oldintr)();
- int ointer;
- char *tp;
-
- if (argc < 2 && !another(&argc, &argv, "local-files")) {
- printf("usage: %s local-files\n", argv[0]);
- code = -1;
- return;
- }
- mname = argv[0];
- mflag = 1;
- oldintr = signal(SIGINT, mabort);
- setjmp(jabort);
- if (proxy) {
- char *cp, *tp2, tmpbuf[MaxPathLen];
-
- while ((cp = remglob(argv,0)) != NULL) {
- if (*cp == 0) {
- mflag = 0;
- continue;
- }
- if (mflag && confirm(argv[0], cp)) {
- tp = cp;
- if (mcase) {
- while (*tp && !islower(*tp)) {
- tp++;
- }
- if (!*tp) {
- tp = cp;
- tp2 = tmpbuf;
- while ((*tp2 = *tp) != '\0') {
- if (isupper(*tp2)) {
- *tp2 = 'a' + *tp2 - 'A';
- }
- tp++;
- tp2++;
- }
- }
- tp = tmpbuf;
- }
- if (ntflag) {
- tp = dotrans(tp);
- }
- if (mapflag) {
- tp = domap(tp);
- }
- sendrequest((sunique) ? "STOU" : "STOR",
- cp, tp, cp != tp || !interactive);
- if (!mflag && fromatty) {
- ointer = interactive;
- interactive = 1;
- if (confirm("Continue with","mput")) {
- mflag++;
- }
- interactive = ointer;
- }
- }
- }
- signal(SIGINT, oldintr);
- mflag = 0;
- return;
- }
- for (i = 1; i < argc; i++) {
- char **cpp;
- glob_t gl;
- int flags;
-
- if (!doglob) {
- if (mflag && confirm(argv[0], argv[i])) {
- tp = (ntflag) ? dotrans(argv[i]) : argv[i];
- tp = (mapflag) ? domap(tp) : tp;
- sendrequest((sunique) ? "STOU" : "STOR",
- argv[i], tp, tp != argv[i] || !interactive);
- if (!mflag && fromatty) {
- ointer = interactive;
- interactive = 1;
- if (confirm("Continue with","mput")) {
- mflag++;
- }
- interactive = ointer;
- }
- }
- continue;
- }
-
- memset(&gl, 0, sizeof(gl));
- flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE;
- if (glob(argv[i], flags, NULL, &gl) || gl.gl_pathc == 0) {
- warnx("%s: not found", argv[i]);
- globfree(&gl);
- continue;
- }
- for (cpp = gl.gl_pathv; cpp && *cpp != NULL; cpp++) {
- if (mflag && confirm(argv[0], *cpp)) {
- tp = (ntflag) ? dotrans(*cpp) : *cpp;
- tp = (mapflag) ? domap(tp) : tp;
- sendrequest((sunique) ? "STOU" : "STOR",
- *cpp, tp, *cpp != tp || !interactive);
- if (!mflag && fromatty) {
- ointer = interactive;
- interactive = 1;
- if (confirm("Continue with","mput")) {
- mflag++;
- }
- interactive = ointer;
- }
- }
- }
- globfree(&gl);
- }
- signal(SIGINT, oldintr);
- mflag = 0;
-}
-
-void
-reget(int argc, char **argv)
-{
- getit(argc, argv, 1, "r+w");
-}
-
-void
-get(int argc, char **argv)
-{
- getit(argc, argv, 0, restart_point ? "r+w" : "w" );
-}
-
-/*
- * Receive one file.
- */
-int
-getit(int argc, char **argv, int restartit, char *mode)
-{
- int loc = 0;
- int local_given = 1;
- char *oldargv1, *oldargv2;
-
- if (argc == 2) {
- argc++;
- local_given = 0;
- argv[2] = argv[1];
- loc++;
- }
- if ((argc < 2 && !another(&argc, &argv, "remote-file")) ||
- (argc < 3 && !another(&argc, &argv, "local-file"))) {
- printf("usage: %s remote-file [ local-file ]\n", argv[0]);
- code = -1;
- return (0);
- }
- oldargv1 = argv[1];
- oldargv2 = argv[2];
- if (!globulize(&argv[2])) {
- code = -1;
- return (0);
- }
- if (loc && mcase) {
- char *tp = argv[1], *tp2, tmpbuf[MaxPathLen];
-
- while (*tp && !islower(*tp)) {
- tp++;
- }
- if (!*tp) {
- tp = argv[2];
- tp2 = tmpbuf;
- while ((*tp2 = *tp) != '\0') {
- if (isupper(*tp2)) {
- *tp2 = 'a' + *tp2 - 'A';
- }
- tp++;
- tp2++;
- }
- argv[2] = tmpbuf;
- }
- }
- if (loc && ntflag)
- argv[2] = dotrans(argv[2]);
- if (loc && mapflag)
- argv[2] = domap(argv[2]);
- if (restartit) {
- struct stat stbuf;
- int ret;
-
- ret = stat(argv[2], &stbuf);
- if (restartit == 1) {
- if (ret < 0) {
- warn("local: %s", argv[2]);
- return (0);
- }
- restart_point = stbuf.st_size;
- } else {
- if (ret == 0) {
- int overbose;
-
- overbose = verbose;
- if (debug == 0)
- verbose = -1;
- if (command("MDTM %s", argv[1]) == COMPLETE) {
- int yy, mo, day, hour, min, sec;
- struct tm *tm;
- verbose = overbose;
- sscanf(reply_string,
- "%*s %04d%02d%02d%02d%02d%02d",
- &yy, &mo, &day, &hour, &min, &sec);
- tm = gmtime(&stbuf.st_mtime);
- tm->tm_mon++;
- if (tm->tm_year > yy%100)
- return (1);
- if ((tm->tm_year == yy%100 &&
- tm->tm_mon > mo) ||
- (tm->tm_mon == mo &&
- tm->tm_mday > day) ||
- (tm->tm_mday == day &&
- tm->tm_hour > hour) ||
- (tm->tm_hour == hour &&
- tm->tm_min > min) ||
- (tm->tm_min == min &&
- tm->tm_sec > sec))
- return (1);
- } else {
- printf("%s\n", reply_string);
- verbose = overbose;
- return (0);
- }
- }
- }
- }
-
- recvrequest("RETR", argv[2], argv[1], mode,
- argv[1] != oldargv1 || argv[2] != oldargv2, local_given);
- restart_point = 0;
- return (0);
-}
-
-static int
-suspicious_filename(const char *fn)
-{
- return strstr(fn, "../") != NULL || *fn == '/';
-}
-
-/*
- * Get multiple files.
- */
-void
-mget(int argc, char **argv)
-{
- sighand oldintr;
- int ch, ointer;
- char *cp, *tp, *tp2, tmpbuf[MaxPathLen];
-
- if (argc < 2 && !another(&argc, &argv, "remote-files")) {
- printf("usage: %s remote-files\n", argv[0]);
- code = -1;
- return;
- }
- mname = argv[0];
- mflag = 1;
- oldintr = signal(SIGINT, mabort);
- setjmp(jabort);
- while ((cp = remglob(argv,proxy)) != NULL) {
- if (*cp == '\0') {
- mflag = 0;
- continue;
- }
- if (mflag && suspicious_filename(cp))
- printf("*** Suspicious filename: %s\n", cp);
- if (mflag && confirm(argv[0], cp)) {
- tp = cp;
- if (mcase) {
- for (tp2 = tmpbuf; (ch = *tp++);)
- *tp2++ = isupper(ch) ? tolower(ch) : ch;
- *tp2 = '\0';
- tp = tmpbuf;
- }
- if (ntflag) {
- tp = dotrans(tp);
- }
- if (mapflag) {
- tp = domap(tp);
- }
- recvrequest("RETR", tp, cp, "w",
- tp != cp || !interactive, 0);
- if (!mflag && fromatty) {
- ointer = interactive;
- interactive = 1;
- if (confirm("Continue with","mget")) {
- mflag++;
- }
- interactive = ointer;
- }
- }
- }
- signal(SIGINT,oldintr);
- mflag = 0;
-}
-
-char *
-remglob(char **argv, int doswitch)
-{
- char temp[16];
- static char buf[MaxPathLen];
- static FILE *ftemp = NULL;
- static char **args;
- int oldverbose, oldhash;
- char *cp, *mode;
-
- if (!mflag) {
- if (!doglob) {
- args = NULL;
- }
- else {
- if (ftemp) {
- fclose(ftemp);
- ftemp = NULL;
- }
- }
- return (NULL);
- }
- if (!doglob) {
- if (args == NULL)
- args = argv;
- if ((cp = *++args) == NULL)
- args = NULL;
- return (cp);
- }
- if (ftemp == NULL) {
- int fd;
- strcpy(temp, _PATH_TMP_XXX);
- fd = mkstemp(temp);
- if(fd < 0){
- warn("unable to create temporary file %s", temp);
- return NULL;
- }
- close(fd);
- oldverbose = verbose, verbose = 0;
- oldhash = hash, hash = 0;
- if (doswitch) {
- pswitch(!proxy);
- }
- for (mode = "w"; *++argv != NULL; mode = "a")
- recvrequest ("NLST", temp, *argv, mode, 0, 0);
- if (doswitch) {
- pswitch(!proxy);
- }
- verbose = oldverbose; hash = oldhash;
- ftemp = fopen(temp, "r");
- unlink(temp);
- if (ftemp == NULL) {
- printf("can't find list of remote files, oops\n");
- return (NULL);
- }
- }
- while(fgets(buf, sizeof (buf), ftemp)) {
- if ((cp = strchr(buf, '\n')) != NULL)
- *cp = '\0';
- if(!interactive && suspicious_filename(buf)){
- printf("Ignoring remote globbed file `%s'\n", buf);
- continue;
- }
- return buf;
- }
- fclose(ftemp);
- ftemp = NULL;
- return (NULL);
-}
-
-char *
-onoff(int bool)
-{
-
- return (bool ? "on" : "off");
-}
-
-/*
- * Show status.
- */
-/*ARGSUSED*/
-void
-status(int argc, char **argv)
-{
- int i;
-
- if (connected)
- printf("Connected to %s.\n", hostname);
- else
- printf("Not connected.\n");
- if (!proxy) {
- pswitch(1);
- if (connected) {
- printf("Connected for proxy commands to %s.\n", hostname);
- }
- else {
- printf("No proxy connection.\n");
- }
- pswitch(0);
- }
- sec_status();
- printf("Mode: %s; Type: %s; Form: %s; Structure: %s\n",
- modename, typename, formname, structname);
- printf("Verbose: %s; Bell: %s; Prompting: %s; Globbing: %s\n",
- onoff(verbose), onoff(bell), onoff(interactive),
- onoff(doglob));
- printf("Store unique: %s; Receive unique: %s\n", onoff(sunique),
- onoff(runique));
- printf("Case: %s; CR stripping: %s\n",onoff(mcase),onoff(crflag));
- if (ntflag) {
- printf("Ntrans: (in) %s (out) %s\n", ntin,ntout);
- }
- else {
- printf("Ntrans: off\n");
- }
- if (mapflag) {
- printf("Nmap: (in) %s (out) %s\n", mapin, mapout);
- }
- else {
- printf("Nmap: off\n");
- }
- printf("Hash mark printing: %s; Use of PORT cmds: %s\n",
- onoff(hash), onoff(sendport));
- if (macnum > 0) {
- printf("Macros:\n");
- for (i=0; i<macnum; i++) {
- printf("\t%s\n",macros[i].mac_name);
- }
- }
- code = 0;
-}
-
-/*
- * Set beep on cmd completed mode.
- */
-/*VARARGS*/
-void
-setbell(int argc, char **argv)
-{
-
- bell = !bell;
- printf("Bell mode %s.\n", onoff(bell));
- code = bell;
-}
-
-/*
- * Turn on packet tracing.
- */
-/*VARARGS*/
-void
-settrace(int argc, char **argv)
-{
-
- trace = !trace;
- printf("Packet tracing %s.\n", onoff(trace));
- code = trace;
-}
-
-/*
- * Toggle hash mark printing during transfers.
- */
-/*VARARGS*/
-void
-sethash(int argc, char **argv)
-{
-
- hash = !hash;
- printf("Hash mark printing %s", onoff(hash));
- code = hash;
- if (hash)
- printf(" (%d bytes/hash mark)", 1024);
- printf(".\n");
-}
-
-/*
- * Turn on printing of server echo's.
- */
-/*VARARGS*/
-void
-setverbose(int argc, char **argv)
-{
-
- verbose = !verbose;
- printf("Verbose mode %s.\n", onoff(verbose));
- code = verbose;
-}
-
-/*
- * Toggle PORT cmd use before each data connection.
- */
-/*VARARGS*/
-void
-setport(int argc, char **argv)
-{
-
- sendport = !sendport;
- printf("Use of PORT cmds %s.\n", onoff(sendport));
- code = sendport;
-}
-
-/*
- * Turn on interactive prompting
- * during mget, mput, and mdelete.
- */
-/*VARARGS*/
-void
-setprompt(int argc, char **argv)
-{
-
- interactive = !interactive;
- printf("Interactive mode %s.\n", onoff(interactive));
- code = interactive;
-}
-
-/*
- * Toggle metacharacter interpretation
- * on local file names.
- */
-/*VARARGS*/
-void
-setglob(int argc, char **argv)
-{
-
- doglob = !doglob;
- printf("Globbing %s.\n", onoff(doglob));
- code = doglob;
-}
-
-/*
- * Set debugging mode on/off and/or
- * set level of debugging.
- */
-/*VARARGS*/
-void
-setdebug(int argc, char **argv)
-{
- int val;
-
- if (argc > 1) {
- val = atoi(argv[1]);
- if (val < 0) {
- printf("%s: bad debugging value.\n", argv[1]);
- code = -1;
- return;
- }
- } else
- val = !debug;
- debug = val;
- if (debug)
- options |= SO_DEBUG;
- else
- options &= ~SO_DEBUG;
- printf("Debugging %s (debug=%d).\n", onoff(debug), debug);
- code = debug > 0;
-}
-
-/*
- * Set current working directory
- * on remote machine.
- */
-void
-cd(int argc, char **argv)
-{
-
- if (argc < 2 && !another(&argc, &argv, "remote-directory")) {
- printf("usage: %s remote-directory\n", argv[0]);
- code = -1;
- return;
- }
- if (command("CWD %s", argv[1]) == ERROR && code == 500) {
- if (verbose)
- printf("CWD command not recognized, trying XCWD\n");
- command("XCWD %s", argv[1]);
- }
-}
-
-/*
- * Set current working directory
- * on local machine.
- */
-void
-lcd(int argc, char **argv)
-{
- char buf[MaxPathLen];
-
- if (argc < 2)
- argc++, argv[1] = home;
- if (argc != 2) {
- printf("usage: %s local-directory\n", argv[0]);
- code = -1;
- return;
- }
- if (!globulize(&argv[1])) {
- code = -1;
- return;
- }
- if (chdir(argv[1]) < 0) {
- warn("local: %s", argv[1]);
- code = -1;
- return;
- }
- if (getcwd(buf, sizeof(buf)) != NULL)
- printf("Local directory now %s\n", buf);
- else
- warnx("getwd: %s", buf);
- code = 0;
-}
-
-/*
- * Delete a single file.
- */
-void
-delete(int argc, char **argv)
-{
-
- if (argc < 2 && !another(&argc, &argv, "remote-file")) {
- printf("usage: %s remote-file\n", argv[0]);
- code = -1;
- return;
- }
- command("DELE %s", argv[1]);
-}
-
-/*
- * Delete multiple files.
- */
-void
-mdelete(int argc, char **argv)
-{
- sighand oldintr;
- int ointer;
- char *cp;
-
- if (argc < 2 && !another(&argc, &argv, "remote-files")) {
- printf("usage: %s remote-files\n", argv[0]);
- code = -1;
- return;
- }
- mname = argv[0];
- mflag = 1;
- oldintr = signal(SIGINT, mabort);
- setjmp(jabort);
- while ((cp = remglob(argv,0)) != NULL) {
- if (*cp == '\0') {
- mflag = 0;
- continue;
- }
- if (mflag && confirm(argv[0], cp)) {
- command("DELE %s", cp);
- if (!mflag && fromatty) {
- ointer = interactive;
- interactive = 1;
- if (confirm("Continue with", "mdelete")) {
- mflag++;
- }
- interactive = ointer;
- }
- }
- }
- signal(SIGINT, oldintr);
- mflag = 0;
-}
-
-/*
- * Rename a remote file.
- */
-void
-renamefile(int argc, char **argv)
-{
-
- if (argc < 2 && !another(&argc, &argv, "from-name"))
- goto usage;
- if (argc < 3 && !another(&argc, &argv, "to-name")) {
-usage:
- printf("%s from-name to-name\n", argv[0]);
- code = -1;
- return;
- }
- if (command("RNFR %s", argv[1]) == CONTINUE)
- command("RNTO %s", argv[2]);
-}
-
-/*
- * Get a directory listing
- * of remote files.
- */
-void
-ls(int argc, char **argv)
-{
- char *cmd;
-
- if (argc < 2)
- argc++, argv[1] = NULL;
- if (argc < 3)
- argc++, argv[2] = "-";
- if (argc > 3) {
- printf("usage: %s remote-directory local-file\n", argv[0]);
- code = -1;
- return;
- }
- cmd = argv[0][0] == 'n' ? "NLST" : "LIST";
- if (strcmp(argv[2], "-") && !globulize(&argv[2])) {
- code = -1;
- return;
- }
- if (strcmp(argv[2], "-") && *argv[2] != '|')
- if (!globulize(&argv[2]) || !confirm("output to local-file:",
- argv[2])) {
- code = -1;
- return;
- }
- recvrequest(cmd, argv[2], argv[1], "w", 0, 1);
-}
-
-/*
- * Get a directory listing
- * of multiple remote files.
- */
-void
-mls(int argc, char **argv)
-{
- sighand oldintr;
- int ointer, i;
- char *cmd, mode[1], *dest;
-
- if (argc < 2 && !another(&argc, &argv, "remote-files"))
- goto usage;
- if (argc < 3 && !another(&argc, &argv, "local-file")) {
-usage:
- printf("usage: %s remote-files local-file\n", argv[0]);
- code = -1;
- return;
- }
- dest = argv[argc - 1];
- argv[argc - 1] = NULL;
- if (strcmp(dest, "-") && *dest != '|')
- if (!globulize(&dest) ||
- !confirm("output to local-file:", dest)) {
- code = -1;
- return;
- }
- cmd = argv[0][1] == 'l' ? "NLST" : "LIST";
- mname = argv[0];
- mflag = 1;
- oldintr = signal(SIGINT, mabort);
- setjmp(jabort);
- for (i = 1; mflag && i < argc-1; ++i) {
- *mode = (i == 1) ? 'w' : 'a';
- recvrequest(cmd, dest, argv[i], mode, 0, 1);
- if (!mflag && fromatty) {
- ointer = interactive;
- interactive = 1;
- if (confirm("Continue with", argv[0])) {
- mflag ++;
- }
- interactive = ointer;
- }
- }
- signal(SIGINT, oldintr);
- mflag = 0;
-}
-
-/*
- * Do a shell escape
- */
-/*ARGSUSED*/
-void
-shell(int argc, char **argv)
-{
- pid_t pid;
- RETSIGTYPE (*old1)(), (*old2)();
- char shellnam[40], *shell, *namep;
- int status;
-
- old1 = signal (SIGINT, SIG_IGN);
- old2 = signal (SIGQUIT, SIG_IGN);
- if ((pid = fork()) == 0) {
- for (pid = 3; pid < 20; pid++)
- close(pid);
- signal(SIGINT, SIG_DFL);
- signal(SIGQUIT, SIG_DFL);
- shell = getenv("SHELL");
- if (shell == NULL)
- shell = _PATH_BSHELL;
- namep = strrchr(shell,'/');
- if (namep == NULL)
- namep = shell;
- strcpy(shellnam,"-");
- strcat(shellnam, ++namep);
- if (strcmp(namep, "sh") != 0)
- shellnam[0] = '+';
- if (debug) {
- printf ("%s\n", shell);
- fflush (stdout);
- }
- if (argc > 1) {
- execl(shell,shellnam,"-c",altarg,(char *)0);
- }
- else {
- execl(shell,shellnam,(char *)0);
- }
- warn("%s", shell);
- code = -1;
- exit(1);
- }
- if (pid > 0)
- while (waitpid(-1, &status, 0) != pid)
- ;
- signal(SIGINT, old1);
- signal(SIGQUIT, old2);
- if (pid == -1) {
- warn("%s", "Try again later");
- code = -1;
- }
- else {
- code = 0;
- }
-}
-
-/*
- * Send new user information (re-login)
- */
-void
-user(int argc, char **argv)
-{
- char acct[80];
- int n, aflag = 0;
- char tmp[256];
-
- if (argc < 2)
- another(&argc, &argv, "username");
- if (argc < 2 || argc > 4) {
- printf("usage: %s username [password] [account]\n", argv[0]);
- code = -1;
- return;
- }
- n = command("USER %s", argv[1]);
- if (n == CONTINUE) {
- if (argc < 3 ) {
- des_read_pw_string (tmp,
- sizeof(tmp),
- "Password: ", 0);
- argv[2] = tmp;
- argc++;
- }
- n = command("PASS %s", argv[2]);
- }
- if (n == CONTINUE) {
- if (argc < 4) {
- printf("Account: "); fflush(stdout);
- fgets(acct, sizeof(acct) - 1, stdin);
- acct[strlen(acct) - 1] = '\0';
- argv[3] = acct; argc++;
- }
- n = command("ACCT %s", argv[3]);
- aflag++;
- }
- if (n != COMPLETE) {
- fprintf(stdout, "Login failed.\n");
- return;
- }
- if (!aflag && argc == 4) {
- command("ACCT %s", argv[3]);
- }
-}
-
-/*
- * Print working directory.
- */
-/*VARARGS*/
-void
-pwd(int argc, char **argv)
-{
- int oldverbose = verbose;
-
- /*
- * If we aren't verbose, this doesn't do anything!
- */
- verbose = 1;
- if (command("PWD") == ERROR && code == 500) {
- printf("PWD command not recognized, trying XPWD\n");
- command("XPWD");
- }
- verbose = oldverbose;
-}
-
-/*
- * Make a directory.
- */
-void
-makedir(int argc, char **argv)
-{
-
- if (argc < 2 && !another(&argc, &argv, "directory-name")) {
- printf("usage: %s directory-name\n", argv[0]);
- code = -1;
- return;
- }
- if (command("MKD %s", argv[1]) == ERROR && code == 500) {
- if (verbose)
- printf("MKD command not recognized, trying XMKD\n");
- command("XMKD %s", argv[1]);
- }
-}
-
-/*
- * Remove a directory.
- */
-void
-removedir(int argc, char **argv)
-{
-
- if (argc < 2 && !another(&argc, &argv, "directory-name")) {
- printf("usage: %s directory-name\n", argv[0]);
- code = -1;
- return;
- }
- if (command("RMD %s", argv[1]) == ERROR && code == 500) {
- if (verbose)
- printf("RMD command not recognized, trying XRMD\n");
- command("XRMD %s", argv[1]);
- }
-}
-
-/*
- * Send a line, verbatim, to the remote machine.
- */
-void
-quote(int argc, char **argv)
-{
-
- if (argc < 2 && !another(&argc, &argv, "command line to send")) {
- printf("usage: %s line-to-send\n", argv[0]);
- code = -1;
- return;
- }
- quote1("", argc, argv);
-}
-
-/*
- * Send a SITE command to the remote machine. The line
- * is sent verbatim to the remote machine, except that the
- * word "SITE" is added at the front.
- */
-void
-site(int argc, char **argv)
-{
-
- if (argc < 2 && !another(&argc, &argv, "arguments to SITE command")) {
- printf("usage: %s line-to-send\n", argv[0]);
- code = -1;
- return;
- }
- quote1("SITE ", argc, argv);
-}
-
-/*
- * Turn argv[1..argc) into a space-separated string, then prepend initial text.
- * Send the result as a one-line command and get response.
- */
-void
-quote1(char *initial, int argc, char **argv)
-{
- int i, len;
- char buf[BUFSIZ]; /* must be >= sizeof(line) */
-
- strcpy(buf, initial);
- if (argc > 1) {
- len = strlen(buf);
- len += strlen(strcpy(&buf[len], argv[1]));
- for (i = 2; i < argc; i++) {
- buf[len++] = ' ';
- len += strlen(strcpy(&buf[len], argv[i]));
- }
- }
- if (command(buf) == PRELIM) {
- while (getreply(0) == PRELIM)
- continue;
- }
-}
-
-void
-do_chmod(int argc, char **argv)
-{
-
- if (argc < 2 && !another(&argc, &argv, "mode"))
- goto usage;
- if (argc < 3 && !another(&argc, &argv, "file-name")) {
-usage:
- printf("usage: %s mode file-name\n", argv[0]);
- code = -1;
- return;
- }
- command("SITE CHMOD %s %s", argv[1], argv[2]);
-}
-
-void
-do_umask(int argc, char **argv)
-{
- int oldverbose = verbose;
-
- verbose = 1;
- command(argc == 1 ? "SITE UMASK" : "SITE UMASK %s", argv[1]);
- verbose = oldverbose;
-}
-
-void
-ftp_idle(int argc, char **argv)
-{
- int oldverbose = verbose;
-
- verbose = 1;
- command(argc == 1 ? "SITE IDLE" : "SITE IDLE %s", argv[1]);
- verbose = oldverbose;
-}
-
-/*
- * Ask the other side for help.
- */
-void
-rmthelp(int argc, char **argv)
-{
- int oldverbose = verbose;
-
- verbose = 1;
- command(argc == 1 ? "HELP" : "HELP %s", argv[1]);
- verbose = oldverbose;
-}
-
-/*
- * Terminate session and exit.
- */
-/*VARARGS*/
-void
-quit(int argc, char **argv)
-{
-
- if (connected)
- disconnect(0, 0);
- pswitch(1);
- if (connected) {
- disconnect(0, 0);
- }
- exit(0);
-}
-
-/*
- * Terminate session, but don't exit.
- */
-void
-disconnect(int argc, char **argv)
-{
-
- if (!connected)
- return;
- command("QUIT");
- if (cout) {
- fclose(cout);
- }
- cout = NULL;
- connected = 0;
- krb4_quit();
- data = -1;
- if (!proxy) {
- macnum = 0;
- }
-}
-
-int
-confirm(char *cmd, char *file)
-{
- char line[BUFSIZ];
-
- if (!interactive)
- return (1);
- printf("%s %s? ", cmd, file);
- fflush(stdout);
- if (fgets(line, sizeof line, stdin) == NULL)
- return (0);
- return (*line == 'y' || *line == 'Y');
-}
-
-void
-fatal(char *msg)
-{
-
- errx(1, "%s", msg);
-}
-
-/*
- * Glob a local file name specification with
- * the expectation of a single return value.
- * Can't control multiple values being expanded
- * from the expression, we return only the first.
- */
-int
-globulize(char **cpp)
-{
- glob_t gl;
- int flags;
-
- if (!doglob)
- return (1);
-
- flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE;
- memset(&gl, 0, sizeof(gl));
- if (glob(*cpp, flags, NULL, &gl) ||
- gl.gl_pathc == 0) {
- warnx("%s: not found", *cpp);
- globfree(&gl);
- return (0);
- }
- *cpp = strdup(gl.gl_pathv[0]); /* XXX - wasted memory */
- globfree(&gl);
- return (1);
-}
-
-void
-account(int argc, char **argv)
-{
- char acct[50];
-
- if (argc > 1) {
- ++argv;
- --argc;
- strncpy(acct,*argv,49);
- acct[49] = '\0';
- while (argc > 1) {
- --argc;
- ++argv;
- strncat(acct,*argv, 49-strlen(acct));
- }
- }
- else {
- des_read_pw_string(acct, sizeof(acct), "Account:", 0);
- }
- command("ACCT %s", acct);
-}
-
-jmp_buf abortprox;
-
-static RETSIGTYPE
-proxabort(int sig)
-{
-
- if (!proxy) {
- pswitch(1);
- }
- if (connected) {
- proxflag = 1;
- }
- else {
- proxflag = 0;
- }
- pswitch(0);
- longjmp(abortprox,1);
-}
-
-void
-doproxy(int argc, char **argv)
-{
- struct cmd *c;
- RETSIGTYPE (*oldintr)();
-
- if (argc < 2 && !another(&argc, &argv, "command")) {
- printf("usage: %s command\n", argv[0]);
- code = -1;
- return;
- }
- c = getcmd(argv[1]);
- if (c == (struct cmd *) -1) {
- printf("?Ambiguous command\n");
- fflush(stdout);
- code = -1;
- return;
- }
- if (c == 0) {
- printf("?Invalid command\n");
- fflush(stdout);
- code = -1;
- return;
- }
- if (!c->c_proxy) {
- printf("?Invalid proxy command\n");
- fflush(stdout);
- code = -1;
- return;
- }
- if (setjmp(abortprox)) {
- code = -1;
- return;
- }
- oldintr = signal(SIGINT, proxabort);
- pswitch(1);
- if (c->c_conn && !connected) {
- printf("Not connected\n");
- fflush(stdout);
- pswitch(0);
- signal(SIGINT, oldintr);
- code = -1;
- return;
- }
- (*c->c_handler)(argc-1, argv+1);
- if (connected) {
- proxflag = 1;
- }
- else {
- proxflag = 0;
- }
- pswitch(0);
- signal(SIGINT, oldintr);
-}
-
-void
-setcase(int argc, char **argv)
-{
-
- mcase = !mcase;
- printf("Case mapping %s.\n", onoff(mcase));
- code = mcase;
-}
-
-void
-setcr(int argc, char **argv)
-{
-
- crflag = !crflag;
- printf("Carriage Return stripping %s.\n", onoff(crflag));
- code = crflag;
-}
-
-void
-setntrans(int argc, char **argv)
-{
- if (argc == 1) {
- ntflag = 0;
- printf("Ntrans off.\n");
- code = ntflag;
- return;
- }
- ntflag++;
- code = ntflag;
- strncpy(ntin, argv[1], 16);
- ntin[16] = '\0';
- if (argc == 2) {
- ntout[0] = '\0';
- return;
- }
- strncpy(ntout, argv[2], 16);
- ntout[16] = '\0';
-}
-
-char *
-dotrans(char *name)
-{
- static char new[MaxPathLen];
- char *cp1, *cp2 = new;
- int i, ostop, found;
-
- for (ostop = 0; *(ntout + ostop) && ostop < 16; ostop++)
- continue;
- for (cp1 = name; *cp1; cp1++) {
- found = 0;
- for (i = 0; *(ntin + i) && i < 16; i++) {
- if (*cp1 == *(ntin + i)) {
- found++;
- if (i < ostop) {
- *cp2++ = *(ntout + i);
- }
- break;
- }
- }
- if (!found) {
- *cp2++ = *cp1;
- }
- }
- *cp2 = '\0';
- return (new);
-}
-
-void
-setnmap(int argc, char **argv)
-{
- char *cp;
-
- if (argc == 1) {
- mapflag = 0;
- printf("Nmap off.\n");
- code = mapflag;
- return;
- }
- if (argc < 3 && !another(&argc, &argv, "mapout")) {
- printf("Usage: %s [mapin mapout]\n",argv[0]);
- code = -1;
- return;
- }
- mapflag = 1;
- code = 1;
- cp = strchr(altarg, ' ');
- if (proxy) {
- while(*++cp == ' ')
- continue;
- altarg = cp;
- cp = strchr(altarg, ' ');
- }
- *cp = '\0';
- strncpy(mapin, altarg, MaxPathLen - 1);
- while (*++cp == ' ')
- continue;
- strncpy(mapout, cp, MaxPathLen - 1);
-}
-
-char *
-domap(char *name)
-{
- static char new[MaxPathLen];
- char *cp1 = name, *cp2 = mapin;
- char *tp[9], *te[9];
- int i, toks[9], toknum = 0, match = 1;
-
- for (i=0; i < 9; ++i) {
- toks[i] = 0;
- }
- while (match && *cp1 && *cp2) {
- switch (*cp2) {
- case '\\':
- if (*++cp2 != *cp1) {
- match = 0;
- }
- break;
- case '$':
- if (*(cp2+1) >= '1' && (*cp2+1) <= '9') {
- if (*cp1 != *(++cp2+1)) {
- toks[toknum = *cp2 - '1']++;
- tp[toknum] = cp1;
- while (*++cp1 && *(cp2+1)
- != *cp1);
- te[toknum] = cp1;
- }
- cp2++;
- break;
- }
- /* FALLTHROUGH */
- default:
- if (*cp2 != *cp1) {
- match = 0;
- }
- break;
- }
- if (match && *cp1) {
- cp1++;
- }
- if (match && *cp2) {
- cp2++;
- }
- }
- if (!match && *cp1) /* last token mismatch */
- {
- toks[toknum] = 0;
- }
- cp1 = new;
- *cp1 = '\0';
- cp2 = mapout;
- while (*cp2) {
- match = 0;
- switch (*cp2) {
- case '\\':
- if (*(cp2 + 1)) {
- *cp1++ = *++cp2;
- }
- break;
- case '[':
-LOOP:
- if (*++cp2 == '$' && isdigit(*(cp2+1))) {
- if (*++cp2 == '0') {
- char *cp3 = name;
-
- while (*cp3) {
- *cp1++ = *cp3++;
- }
- match = 1;
- }
- else if (toks[toknum = *cp2 - '1']) {
- char *cp3 = tp[toknum];
-
- while (cp3 != te[toknum]) {
- *cp1++ = *cp3++;
- }
- match = 1;
- }
- }
- else {
- while (*cp2 && *cp2 != ',' &&
- *cp2 != ']') {
- if (*cp2 == '\\') {
- cp2++;
- }
- else if (*cp2 == '$' &&
- isdigit(*(cp2+1))) {
- if (*++cp2 == '0') {
- char *cp3 = name;
-
- while (*cp3) {
- *cp1++ = *cp3++;
- }
- }
- else if (toks[toknum =
- *cp2 - '1']) {
- char *cp3=tp[toknum];
-
- while (cp3 !=
- te[toknum]) {
- *cp1++ = *cp3++;
- }
- }
- }
- else if (*cp2) {
- *cp1++ = *cp2++;
- }
- }
- if (!*cp2) {
- printf("nmap: unbalanced brackets\n");
- return (name);
- }
- match = 1;
- cp2--;
- }
- if (match) {
- while (*++cp2 && *cp2 != ']') {
- if (*cp2 == '\\' && *(cp2 + 1)) {
- cp2++;
- }
- }
- if (!*cp2) {
- printf("nmap: unbalanced brackets\n");
- return (name);
- }
- break;
- }
- switch (*++cp2) {
- case ',':
- goto LOOP;
- case ']':
- break;
- default:
- cp2--;
- goto LOOP;
- }
- break;
- case '$':
- if (isdigit(*(cp2 + 1))) {
- if (*++cp2 == '0') {
- char *cp3 = name;
-
- while (*cp3) {
- *cp1++ = *cp3++;
- }
- }
- else if (toks[toknum = *cp2 - '1']) {
- char *cp3 = tp[toknum];
-
- while (cp3 != te[toknum]) {
- *cp1++ = *cp3++;
- }
- }
- break;
- }
- /* intentional drop through */
- default:
- *cp1++ = *cp2;
- break;
- }
- cp2++;
- }
- *cp1 = '\0';
- if (!*new) {
- return (name);
- }
- return (new);
-}
-
-void
-setpassive(int argc, char **argv)
-{
-
- passivemode = !passivemode;
- printf("Passive mode %s.\n", onoff(passivemode));
- code = passivemode;
-}
-
-void
-setsunique(int argc, char **argv)
-{
-
- sunique = !sunique;
- printf("Store unique %s.\n", onoff(sunique));
- code = sunique;
-}
-
-void
-setrunique(int argc, char **argv)
-{
-
- runique = !runique;
- printf("Receive unique %s.\n", onoff(runique));
- code = runique;
-}
-
-/* change directory to perent directory */
-void
-cdup(int argc, char **argv)
-{
-
- if (command("CDUP") == ERROR && code == 500) {
- if (verbose)
- printf("CDUP command not recognized, trying XCUP\n");
- command("XCUP");
- }
-}
-
-/* restart transfer at specific point */
-void
-restart(int argc, char **argv)
-{
-
- if (argc != 2)
- printf("restart: offset not specified\n");
- else {
- restart_point = atol(argv[1]);
- printf("restarting at %ld. %s\n", (long)restart_point,
- "execute get, put or append to initiate transfer");
- }
-}
-
-/* show remote system type */
-void
-syst(int argc, char **argv)
-{
-
- command("SYST");
-}
-
-void
-macdef(int argc, char **argv)
-{
- char *tmp;
- int c;
-
- if (macnum == 16) {
- printf("Limit of 16 macros have already been defined\n");
- code = -1;
- return;
- }
- if (argc < 2 && !another(&argc, &argv, "macro name")) {
- printf("Usage: %s macro_name\n",argv[0]);
- code = -1;
- return;
- }
- if (interactive) {
- printf("Enter macro line by line, terminating it with a null line\n");
- }
- strncpy(macros[macnum].mac_name, argv[1], 8);
- if (macnum == 0) {
- macros[macnum].mac_start = macbuf;
- }
- else {
- macros[macnum].mac_start = macros[macnum - 1].mac_end + 1;
- }
- tmp = macros[macnum].mac_start;
- while (tmp != macbuf+4096) {
- if ((c = getchar()) == EOF) {
- printf("macdef:end of file encountered\n");
- code = -1;
- return;
- }
- if ((*tmp = c) == '\n') {
- if (tmp == macros[macnum].mac_start) {
- macros[macnum++].mac_end = tmp;
- code = 0;
- return;
- }
- if (*(tmp-1) == '\0') {
- macros[macnum++].mac_end = tmp - 1;
- code = 0;
- return;
- }
- *tmp = '\0';
- }
- tmp++;
- }
- while (1) {
- while ((c = getchar()) != '\n' && c != EOF)
- /* LOOP */;
- if (c == EOF || getchar() == '\n') {
- printf("Macro not defined - 4k buffer exceeded\n");
- code = -1;
- return;
- }
- }
-}
-
-/*
- * get size of file on remote machine
- */
-void
-sizecmd(int argc, char **argv)
-{
-
- if (argc < 2 && !another(&argc, &argv, "filename")) {
- printf("usage: %s filename\n", argv[0]);
- code = -1;
- return;
- }
- command("SIZE %s", argv[1]);
-}
-
-/*
- * get last modification time of file on remote machine
- */
-void
-modtime(int argc, char **argv)
-{
- int overbose;
-
- if (argc < 2 && !another(&argc, &argv, "filename")) {
- printf("usage: %s filename\n", argv[0]);
- code = -1;
- return;
- }
- overbose = verbose;
- if (debug == 0)
- verbose = -1;
- if (command("MDTM %s", argv[1]) == COMPLETE) {
- int yy, mo, day, hour, min, sec;
- sscanf(reply_string, "%*s %04d%02d%02d%02d%02d%02d", &yy, &mo,
- &day, &hour, &min, &sec);
- /* might want to print this in local time */
- printf("%s\t%02d/%02d/%04d %02d:%02d:%02d GMT\n", argv[1],
- mo, day, yy, hour, min, sec);
- } else
- printf("%s\n", reply_string);
- verbose = overbose;
-}
-
-/*
- * show status on reomte machine
- */
-void
-rmtstatus(int argc, char **argv)
-{
-
- command(argc > 1 ? "STAT %s" : "STAT" , argv[1]);
-}
-
-/*
- * get file if modtime is more recent than current file
- */
-void
-newer(int argc, char **argv)
-{
-
- if (getit(argc, argv, -1, "w"))
- printf("Local file \"%s\" is newer than remote file \"%s\"\n",
- argv[2], argv[1]);
-}
diff --git a/appl/ftp/ftp/cmdtab.c b/appl/ftp/ftp/cmdtab.c
deleted file mode 100644
index 803240d9b58a4ae41097f987faa5f3a112ff183a..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/cmdtab.c
+++ /dev/null
@@ -1,198 +0,0 @@
-/*
- * Copyright (c) 1985, 1989, 1993, 1994
- * 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 "ftp_locl.h"
-
-/*
- * User FTP -- Command Tables.
- */
-
-char accounthelp[] = "send account command to remote server";
-char appendhelp[] = "append to a file";
-char asciihelp[] = "set ascii transfer type";
-char beephelp[] = "beep when command completed";
-char binaryhelp[] = "set binary transfer type";
-char casehelp[] = "toggle mget upper/lower case id mapping";
-char cdhelp[] = "change remote working directory";
-char cduphelp[] = "change remote working directory to parent directory";
-char chmodhelp[] = "change file permissions of remote file";
-char connecthelp[] = "connect to remote tftp";
-char crhelp[] = "toggle carriage return stripping on ascii gets";
-char deletehelp[] = "delete remote file";
-char debughelp[] = "toggle/set debugging mode";
-char dirhelp[] = "list contents of remote directory";
-char disconhelp[] = "terminate ftp session";
-char domachelp[] = "execute macro";
-char formhelp[] = "set file transfer format";
-char globhelp[] = "toggle metacharacter expansion of local file names";
-char hashhelp[] = "toggle printing `#' for each buffer transferred";
-char helphelp[] = "print local help information";
-char idlehelp[] = "get (set) idle timer on remote side";
-char lcdhelp[] = "change local working directory";
-char lshelp[] = "list contents of remote directory";
-char macdefhelp[] = "define a macro";
-char mdeletehelp[] = "delete multiple files";
-char mdirhelp[] = "list contents of multiple remote directories";
-char mgethelp[] = "get multiple files";
-char mkdirhelp[] = "make directory on the remote machine";
-char mlshelp[] = "list contents of multiple remote directories";
-char modtimehelp[] = "show last modification time of remote file";
-char modehelp[] = "set file transfer mode";
-char mputhelp[] = "send multiple files";
-char newerhelp[] = "get file if remote file is newer than local file ";
-char nlisthelp[] = "nlist contents of remote directory";
-char nmaphelp[] = "set templates for default file name mapping";
-char ntranshelp[] = "set translation table for default file name mapping";
-char porthelp[] = "toggle use of PORT cmd for each data connection";
-char prompthelp[] = "force interactive prompting on multiple commands";
-char proxyhelp[] = "issue command on alternate connection";
-char pwdhelp[] = "print working directory on remote machine";
-char quithelp[] = "terminate ftp session and exit";
-char quotehelp[] = "send arbitrary ftp command";
-char receivehelp[] = "receive file";
-char regethelp[] = "get file restarting at end of local file";
-char remotehelp[] = "get help from remote server";
-char renamehelp[] = "rename file";
-char restarthelp[]= "restart file transfer at bytecount";
-char rmdirhelp[] = "remove directory on the remote machine";
-char rmtstatushelp[]="show status of remote machine";
-char runiquehelp[] = "toggle store unique for local files";
-char resethelp[] = "clear queued command replies";
-char sendhelp[] = "send one file";
-char passivehelp[] = "enter passive transfer mode";
-char sitehelp[] = "send site specific command to remote server\n\t\tTry \"rhelp site\" or \"site help\" for more information";
-char shellhelp[] = "escape to the shell";
-char sizecmdhelp[] = "show size of remote file";
-char statushelp[] = "show current status";
-char structhelp[] = "set file transfer structure";
-char suniquehelp[] = "toggle store unique on remote machine";
-char systemhelp[] = "show remote system type";
-char tenexhelp[] = "set tenex file transfer type";
-char tracehelp[] = "toggle packet tracing";
-char typehelp[] = "set file transfer type";
-char umaskhelp[] = "get (set) umask on remote side";
-char userhelp[] = "send new user information";
-char verbosehelp[] = "toggle verbose mode";
-
-char prothelp[] = "set protection level";
-char kauthhelp[] = "get remote tokens";
-char klisthelp[] = "show remote tickets";
-char kdestroyhelp[] = "destroy remote tickets";
-char krbtkfilehelp[] = "set filename of remote tickets";
-char afsloghelp[] = "obtain remote AFS tokens";
-
-struct cmd cmdtab[] = {
- { "!", shellhelp, 0, 0, 0, shell },
- { "$", domachelp, 1, 0, 0, domacro },
- { "account", accounthelp, 0, 1, 1, account},
- { "append", appendhelp, 1, 1, 1, put },
- { "ascii", asciihelp, 0, 1, 1, setascii },
- { "bell", beephelp, 0, 0, 0, setbell },
- { "binary", binaryhelp, 0, 1, 1, setbinary },
- { "bye", quithelp, 0, 0, 0, quit },
- { "case", casehelp, 0, 0, 1, setcase },
- { "cd", cdhelp, 0, 1, 1, cd },
- { "cdup", cduphelp, 0, 1, 1, cdup },
- { "chmod", chmodhelp, 0, 1, 1, do_chmod },
- { "close", disconhelp, 0, 1, 1, disconnect },
- { "cr", crhelp, 0, 0, 0, setcr },
- { "delete", deletehelp, 0, 1, 1, delete },
- { "debug", debughelp, 0, 0, 0, setdebug },
- { "dir", dirhelp, 1, 1, 1, ls },
- { "disconnect", disconhelp, 0, 1, 1, disconnect },
- { "form", formhelp, 0, 1, 1, setform },
- { "get", receivehelp, 1, 1, 1, get },
- { "glob", globhelp, 0, 0, 0, setglob },
- { "hash", hashhelp, 0, 0, 0, sethash },
- { "help", helphelp, 0, 0, 1, help },
- { "idle", idlehelp, 0, 1, 1, ftp_idle },
- { "image", binaryhelp, 0, 1, 1, setbinary },
- { "lcd", lcdhelp, 0, 0, 0, lcd },
- { "ls", lshelp, 1, 1, 1, ls },
- { "macdef", macdefhelp, 0, 0, 0, macdef },
- { "mdelete", mdeletehelp, 1, 1, 1, mdelete },
- { "mdir", mdirhelp, 1, 1, 1, mls },
- { "mget", mgethelp, 1, 1, 1, mget },
- { "mkdir", mkdirhelp, 0, 1, 1, makedir },
- { "mls", mlshelp, 1, 1, 1, mls },
- { "mode", modehelp, 0, 1, 1, setftmode },
- { "modtime", modtimehelp, 0, 1, 1, modtime },
- { "mput", mputhelp, 1, 1, 1, mput },
- { "newer", newerhelp, 1, 1, 1, newer },
- { "nmap", nmaphelp, 0, 0, 1, setnmap },
- { "nlist", nlisthelp, 1, 1, 1, ls },
- { "ntrans", ntranshelp, 0, 0, 1, setntrans },
- { "open", connecthelp, 0, 0, 1, setpeer },
- { "passive", passivehelp, 0, 0, 0, setpassive },
- { "prompt", prompthelp, 0, 0, 0, setprompt },
- { "proxy", proxyhelp, 0, 0, 1, doproxy },
- { "sendport", porthelp, 0, 0, 0, setport },
- { "put", sendhelp, 1, 1, 1, put },
- { "pwd", pwdhelp, 0, 1, 1, pwd },
- { "quit", quithelp, 0, 0, 0, quit },
- { "quote", quotehelp, 1, 1, 1, quote },
- { "recv", receivehelp, 1, 1, 1, get },
- { "reget", regethelp, 1, 1, 1, reget },
- { "rstatus", rmtstatushelp, 0, 1, 1, rmtstatus },
- { "rhelp", remotehelp, 0, 1, 1, rmthelp },
- { "rename", renamehelp, 0, 1, 1, renamefile },
- { "reset", resethelp, 0, 1, 1, reset },
- { "restart", restarthelp, 1, 1, 1, restart },
- { "rmdir", rmdirhelp, 0, 1, 1, removedir },
- { "runique", runiquehelp, 0, 0, 1, setrunique },
- { "send", sendhelp, 1, 1, 1, put },
- { "site", sitehelp, 0, 1, 1, site },
- { "size", sizecmdhelp, 1, 1, 1, sizecmd },
- { "status", statushelp, 0, 0, 1, status },
- { "struct", structhelp, 0, 1, 1, setstruct },
- { "system", systemhelp, 0, 1, 1, syst },
- { "sunique", suniquehelp, 0, 0, 1, setsunique },
- { "tenex", tenexhelp, 0, 1, 1, settenex },
- { "trace", tracehelp, 0, 0, 0, settrace },
- { "type", typehelp, 0, 1, 1, settype },
- { "user", userhelp, 0, 1, 1, user },
- { "umask", umaskhelp, 0, 1, 1, do_umask },
- { "verbose", verbosehelp, 0, 0, 0, setverbose },
- { "?", helphelp, 0, 0, 1, help },
-
- { "prot", prothelp, 0, 1, 0, sec_prot },
- { "kauth", kauthhelp, 0, 1, 0, kauth },
- { "klist", klisthelp, 0, 1, 0, klist },
- { "kdestroy", kdestroyhelp, 0, 1, 0, kdestroy },
- { "krbtkfile", krbtkfilehelp, 0, 1, 0, krbtkfile },
- { "afslog", afsloghelp, 0, 1, 0, afslog },
-
- { 0 },
-};
-
-int NCMDS = (sizeof (cmdtab) / sizeof (cmdtab[0])) - 1;
diff --git a/appl/ftp/ftp/domacro.c b/appl/ftp/ftp/domacro.c
deleted file mode 100644
index 3d26d5d31fdf536847e79d6ef367bb081ac6f07c..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/domacro.c
+++ /dev/null
@@ -1,138 +0,0 @@
-/*
- * Copyright (c) 1985, 1993, 1994
- * 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 "ftp_locl.h"
-RCSID("$Id$");
-
-void
-domacro(int argc, char **argv)
-{
- int i, j, count = 2, loopflg = 0;
- char *cp1, *cp2, line2[200];
- struct cmd *c;
-
- if (argc < 2 && !another(&argc, &argv, "macro name")) {
- printf("Usage: %s macro_name.\n", argv[0]);
- code = -1;
- return;
- }
- for (i = 0; i < macnum; ++i) {
- if (!strncmp(argv[1], macros[i].mac_name, 9)) {
- break;
- }
- }
- if (i == macnum) {
- printf("'%s' macro not found.\n", argv[1]);
- code = -1;
- return;
- }
- strcpy(line2, line);
-TOP:
- cp1 = macros[i].mac_start;
- while (cp1 != macros[i].mac_end) {
- while (isspace(*cp1)) {
- cp1++;
- }
- cp2 = line;
- while (*cp1 != '\0') {
- switch(*cp1) {
- case '\\':
- *cp2++ = *++cp1;
- break;
- case '$':
- if (isdigit(*(cp1+1))) {
- j = 0;
- while (isdigit(*++cp1)) {
- j = 10*j + *cp1 - '0';
- }
- cp1--;
- if (argc - 2 >= j) {
- strcpy(cp2, argv[j+1]);
- cp2 += strlen(argv[j+1]);
- }
- break;
- }
- if (*(cp1+1) == 'i') {
- loopflg = 1;
- cp1++;
- if (count < argc) {
- strcpy(cp2, argv[count]);
- cp2 += strlen(argv[count]);
- }
- break;
- }
- /* intentional drop through */
- default:
- *cp2++ = *cp1;
- break;
- }
- if (*cp1 != '\0') {
- cp1++;
- }
- }
- *cp2 = '\0';
- makeargv();
- c = getcmd(margv[0]);
- if (c == (struct cmd *)-1) {
- printf("?Ambiguous command\n");
- code = -1;
- }
- else if (c == 0) {
- printf("?Invalid command\n");
- code = -1;
- }
- else if (c->c_conn && !connected) {
- printf("Not connected.\n");
- code = -1;
- }
- else {
- if (verbose) {
- printf("%s\n",line);
- }
- (*c->c_handler)(margc, margv);
- if (bell && c->c_bell) {
- putchar('\007');
- }
- strcpy(line, line2);
- makeargv();
- argc = margc;
- argv = margv;
- }
- if (cp1 != macros[i].mac_end) {
- cp1++;
- }
- }
- if (loopflg && ++count < argc) {
- goto TOP;
- }
-}
diff --git a/appl/ftp/ftp/extern.h b/appl/ftp/ftp/extern.h
deleted file mode 100644
index 3e7452c278c17dea06db9d7041099b7153d039c7..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/extern.h
+++ /dev/null
@@ -1,167 +0,0 @@
-/*-
- * Copyright (c) 1994 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.3 (Berkeley) 10/9/94
- */
-
-/* $Id$ */
-
-#include <setjmp.h>
-#include <stdlib.h>
-#ifdef TIME_WITH_SYS_TIME
-#include <sys/time.h>
-#include <time.h>
-#elif defined(HAVE_SYS_TIME_H)
-#include <sys/time.h>
-#else
-#include <time.h>
-#endif
-#ifdef HAVE_SYS_SELECT_H
-#include <sys/select.h>
-#endif
-
-void abort_remote (FILE *);
-void abortpt (int);
-void abortrecv (int);
-void account (int, char **);
-int another (int *, char ***, char *);
-void blkfree (char **);
-void cd (int, char **);
-void cdup (int, char **);
-void changetype (int, int);
-void cmdabort (int);
-void cmdscanner (int);
-int command (char *fmt, ...);
-int confirm (char *, char *);
-FILE *dataconn (char *);
-void delete (int, char **);
-void disconnect (int, char **);
-void do_chmod (int, char **);
-void do_umask (int, char **);
-void domacro (int, char **);
-char *domap (char *);
-void doproxy (int, char **);
-char *dotrans (char *);
-int empty (fd_set *, int);
-void fatal (char *);
-void get (int, char **);
-struct cmd *getcmd (char *);
-int getit (int, char **, int, char *);
-int getreply (int);
-int globulize (char **);
-char *gunique (char *);
-void help (int, char **);
-char *hookup (char *, int);
-void ftp_idle (int, char **);
-int initconn (void);
-void intr (int);
-void lcd (int, char **);
-int login (char *);
-RETSIGTYPE lostpeer (int);
-void ls (int, char **);
-void macdef (int, char **);
-void makeargv (void);
-void makedir (int, char **);
-void mdelete (int, char **);
-void mget (int, char **);
-void mls (int, char **);
-void modtime (int, char **);
-void mput (int, char **);
-char *onoff (int);
-void newer (int, char **);
-void proxtrans (char *, char *, char *);
-void psabort (int);
-void pswitch (int);
-void ptransfer (char *, long, struct timeval *, struct timeval *);
-void put (int, char **);
-void pwd (int, char **);
-void quit (int, char **);
-void quote (int, char **);
-void quote1 (char *, int, char **);
-void recvrequest (char *, char *, char *, char *, int, int);
-void reget (int, char **);
-char *remglob (char **, int);
-void removedir (int, char **);
-void renamefile (int, char **);
-void reset (int, char **);
-void restart (int, char **);
-void rmthelp (int, char **);
-void rmtstatus (int, char **);
-int ruserpass (char *, char **, char **, char **);
-void sendrequest (char *, char *, char *, int);
-void setascii (int, char **);
-void setbell (int, char **);
-void setbinary (int, char **);
-void setcase (int, char **);
-void setcr (int, char **);
-void setdebug (int, char **);
-void setform (int, char **);
-void setftmode (int, char **);
-void setglob (int, char **);
-void sethash (int, char **);
-void setnmap (int, char **);
-void setntrans (int, char **);
-void setpassive (int, char **);
-void setpeer (int, char **);
-void setport (int, char **);
-void setprompt (int, char **);
-void setrunique (int, char **);
-void setstruct (int, char **);
-void setsunique (int, char **);
-void settenex (int, char **);
-void settrace (int, char **);
-void settype (int, char **);
-void setverbose (int, char **);
-void shell (int, char **);
-void site (int, char **);
-void sizecmd (int, char **);
-char *slurpstring (void);
-void status (int, char **);
-void syst (int, char **);
-void tvsub (struct timeval *, struct timeval *, struct timeval *);
-void user (int, char **);
-
-extern jmp_buf abortprox;
-extern int abrtflag;
-extern struct cmd cmdtab[];
-extern FILE *cout;
-extern int data;
-extern char *home;
-extern jmp_buf jabort;
-extern int proxy;
-extern char reply_string[];
-extern off_t restart_point;
-extern int NCMDS;
-
-extern char username[32];
-extern char myhostname[];
-extern char *mydomain;
diff --git a/appl/ftp/ftp/ftp.1 b/appl/ftp/ftp/ftp.1
deleted file mode 100644
index e01b46f24fee9fa4db3ccfcbe2942912d555187e..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/ftp.1
+++ /dev/null
@@ -1,1190 +0,0 @@
-.\" $NetBSD: ftp.1,v 1.11 1995/09/08 01:06:24 tls Exp $
-.\"
-.\" Copyright (c) 1985, 1989, 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.
-.\"
-.\" @(#)ftp.1 8.3 (Berkeley) 10/9/94
-.\"
-.Dd April 27, 1996
-.Dt FTP 1
-.Os BSD 4.2
-.Sh NAME
-.Nm ftp
-.Nd
-.Tn ARPANET
-file transfer program
-.Sh SYNOPSIS
-.Nm ftp
-.Op Fl t
-.Op Fl v
-.Op Fl d
-.Op Fl i
-.Op Fl n
-.Op Fl g
-.Op Ar host
-.Sh DESCRIPTION
-.Nm Ftp
-is the user interface to the
-.Tn ARPANET
-standard File Transfer Protocol.
-The program allows a user to transfer files to and from a
-remote network site.
-.Pp
-Modifications has been made so that it almost follows the ftpsec
-Internet draft.
-.Pp
-Options may be specified at the command line, or to the
-command interpreter.
-.Bl -tag -width flag
-.It Fl t
-Enables packet tracing.
-.It Fl v
-Verbose option forces
-.Nm ftp
-to show all responses from the remote server, as well
-as report on data transfer statistics.
-.It Fl n
-Restrains
-.Nm ftp
-from attempting \*(Lqauto-login\*(Rq upon initial connection.
-If auto-login is enabled,
-.Nm ftp
-will check the
-.Pa .netrc
-(see below) file in the user's home directory for an entry describing
-an account on the remote machine.
-If no entry exists,
-.Nm ftp
-will prompt for the remote machine login name (default is the user
-identity on the local machine), and, if necessary, prompt for a password
-and an account with which to login.
-.It Fl i
-Turns off interactive prompting during
-multiple file transfers.
-.It Fl d
-Enables debugging.
-.It Fl g
-Disables file name globbing.
-.El
-.Pp
-The client host with which
-.Nm ftp
-is to communicate may be specified on the command line.
-If this is done,
-.Nm ftp
-will immediately attempt to establish a connection to an
-.Tn FTP
-server on that host; otherwise,
-.Nm ftp
-will enter its command interpreter and await instructions
-from the user.
-When
-.Nm ftp
-is awaiting commands from the user the prompt
-.Ql ftp>
-is provided to the user.
-The following commands are recognized
-by
-.Nm ftp :
-.Bl -tag -width Fl
-.It Ic \&! Op Ar command Op Ar args
-Invoke an interactive shell on the local machine.
-If there are arguments, the first is taken to be a command to execute
-directly, with the rest of the arguments as its arguments.
-.It Ic \&$ Ar macro-name Op Ar args
-Execute the macro
-.Ar macro-name
-that was defined with the
-.Ic macdef
-command.
-Arguments are passed to the macro unglobbed.
-.It Ic account Op Ar passwd
-Supply a supplemental password required by a remote system for access
-to resources once a login has been successfully completed.
-If no argument is included, the user will be prompted for an account
-password in a non-echoing input mode.
-.It Ic append Ar local-file Op Ar remote-file
-Append a local file to a file on the remote machine.
-If
-.Ar remote-file
-is left unspecified, the local file name is used in naming the
-remote file after being altered by any
-.Ic ntrans
-or
-.Ic nmap
-setting.
-File transfer uses the current settings for
-.Ic type ,
-.Ic format ,
-.Ic mode ,
-and
-.Ic structure .
-.It Ic ascii
-Set the file transfer
-.Ic type
-to network
-.Tn ASCII .
-This is the default type.
-.It Ic bell
-Arrange that a bell be sounded after each file transfer
-command is completed.
-.It Ic binary
-Set the file transfer
-.Ic type
-to support binary image transfer.
-.It Ic bye
-Terminate the
-.Tn FTP
-session with the remote server
-and exit
-.Nm ftp .
-An end of file will also terminate the session and exit.
-.It Ic case
-Toggle remote computer file name case mapping during
-.Ic mget
-commands.
-When
-.Ic case
-is on (default is off), remote computer file names with all letters in
-upper case are written in the local directory with the letters mapped
-to lower case.
-.It Ic \&cd Ar remote-directory
-Change the working directory on the remote machine
-to
-.Ar remote-directory .
-.It Ic cdup
-Change the remote machine working directory to the parent of the
-current remote machine working directory.
-.It Ic chmod Ar mode file-name
-Change the permission modes of the file
-.Ar file-name
-on the remote
-sytem to
-.Ar mode .
-.It Ic close
-Terminate the
-.Tn FTP
-session with the remote server, and
-return to the command interpreter.
-Any defined macros are erased.
-.It Ic \&cr
-Toggle carriage return stripping during
-ascii type file retrieval.
-Records are denoted by a carriage return/linefeed sequence
-during ascii type file transfer.
-When
-.Ic \&cr
-is on (the default), carriage returns are stripped from this
-sequence to conform with the
-.Ux
-single linefeed record
-delimiter.
-Records on
-.Pf non\- Ns Ux
-remote systems may contain single linefeeds;
-when an ascii type transfer is made, these linefeeds may be
-distinguished from a record delimiter only when
-.Ic \&cr
-is off.
-.It Ic delete Ar remote-file
-Delete the file
-.Ar remote-file
-on the remote machine.
-.It Ic debug Op Ar debug-value
-Toggle debugging mode.
-If an optional
-.Ar debug-value
-is specified it is used to set the debugging level.
-When debugging is on,
-.Nm ftp
-prints each command sent to the remote machine, preceded
-by the string
-.Ql \-\->
-.It Xo
-.Ic dir
-.Op Ar remote-directory
-.Op Ar local-file
-.Xc
-Print a listing of the directory contents in the
-directory,
-.Ar remote-directory ,
-and, optionally, placing the output in
-.Ar local-file .
-If interactive prompting is on,
-.Nm ftp
-will prompt the user to verify that the last argument is indeed the
-target local file for receiving
-.Ic dir
-output.
-If no directory is specified, the current working
-directory on the remote machine is used.
-If no local
-file is specified, or
-.Ar local-file
-is
-.Fl ,
-output comes to the terminal.
-.It Ic disconnect
-A synonym for
-.Ar close .
-.It Ic form Ar format
-Set the file transfer
-.Ic form
-to
-.Ar format .
-The default format is \*(Lqfile\*(Rq.
-.It Ic get Ar remote-file Op Ar local-file
-Retrieve the
-.Ar remote-file
-and store it on the local machine.
-If the local
-file name is not specified, it is given the same
-name it has on the remote machine, subject to
-alteration by the current
-.Ic case ,
-.Ic ntrans ,
-and
-.Ic nmap
-settings.
-The current settings for
-.Ic type ,
-.Ic form ,
-.Ic mode ,
-and
-.Ic structure
-are used while transferring the file.
-.It Ic glob
-Toggle filename expansion for
-.Ic mdelete ,
-.Ic mget
-and
-.Ic mput .
-If globbing is turned off with
-.Ic glob ,
-the file name arguments
-are taken literally and not expanded.
-Globbing for
-.Ic mput
-is done as in
-.Xr csh 1 .
-For
-.Ic mdelete
-and
-.Ic mget ,
-each remote file name is expanded
-separately on the remote machine and the lists are not merged.
-Expansion of a directory name is likely to be
-different from expansion of the name of an ordinary file:
-the exact result depends on the foreign operating system and ftp server,
-and can be previewed by doing
-.Ql mls remote-files \- .
-As a security measure, remotely globbed files that starts with
-.Sq /
-or contains
-.Sq ../ ,
-will not be automatically received. If you have interactive prompting
-turned off, these filenames will be ignored. Note:
-.Ic mget
-and
-.Ic mput
-are not meant to transfer
-entire directory subtrees of files.
-That can be done by
-transferring a
-.Xr tar 1
-archive of the subtree (in binary mode).
-.It Ic hash
-Toggle hash-sign (``#'') printing for each data block
-transferred.
-The size of a data block is 1024 bytes.
-.It Ic help Op Ar command
-Print an informative message about the meaning of
-.Ar command .
-If no argument is given,
-.Nm ftp
-prints a list of the known commands.
-.It Ic idle Op Ar seconds
-Set the inactivity timer on the remote server to
-.Ar seconds
-seconds.
-If
-.Ar seconds
-is omitted, the current inactivity timer is printed.
-.It Ic lcd Op Ar directory
-Change the working directory on the local machine.
-If
-no
-.Ar directory
-is specified, the user's home directory is used.
-.It Xo
-.Ic \&ls
-.Op Ar remote-directory
-.Op Ar local-file
-.Xc
-Print a listing of the contents of a
-directory on the remote machine.
-The listing includes any system-dependent information that the server
-chooses to include; for example, most
-.Ux
-systems will produce
-output from the command
-.Ql ls \-l .
-(See also
-.Ic nlist . )
-If
-.Ar remote-directory
-is left unspecified, the current working directory is used.
-If interactive prompting is on,
-.Nm ftp
-will prompt the user to verify that the last argument is indeed the
-target local file for receiving
-.Ic \&ls
-output.
-If no local file is specified, or if
-.Ar local-file
-is
-.Sq Fl ,
-the output is sent to the terminal.
-.It Ic macdef Ar macro-name
-Define a macro.
-Subsequent lines are stored as the macro
-.Ar macro-name ;
-a null line (consecutive newline characters
-in a file or
-carriage returns from the terminal) terminates macro input mode.
-There is a limit of 16 macros and 4096 total characters in all
-defined macros.
-Macros remain defined until a
-.Ic close
-command is executed.
-The macro processor interprets `$' and `\e' as special characters.
-A `$' followed by a number (or numbers) is replaced by the
-corresponding argument on the macro invocation command line.
-A `$' followed by an `i' signals that macro processor that the
-executing macro is to be looped.
-On the first pass `$i' is
-replaced by the first argument on the macro invocation command line,
-on the second pass it is replaced by the second argument, and so on.
-A `\e' followed by any character is replaced by that character.
-Use the `\e' to prevent special treatment of the `$'.
-.It Ic mdelete Op Ar remote-files
-Delete the
-.Ar remote-files
-on the remote machine.
-.It Ic mdir Ar remote-files local-file
-Like
-.Ic dir ,
-except multiple remote files may be specified.
-If interactive prompting is on,
-.Nm ftp
-will prompt the user to verify that the last argument is indeed the
-target local file for receiving
-.Ic mdir
-output.
-.It Ic mget Ar remote-files
-Expand the
-.Ar remote-files
-on the remote machine
-and do a
-.Ic get
-for each file name thus produced.
-See
-.Ic glob
-for details on the filename expansion.
-Resulting file names will then be processed according to
-.Ic case ,
-.Ic ntrans ,
-and
-.Ic nmap
-settings.
-Files are transferred into the local working directory,
-which can be changed with
-.Ql lcd directory ;
-new local directories can be created with
-.Ql "\&! mkdir directory" .
-.It Ic mkdir Ar directory-name
-Make a directory on the remote machine.
-.It Ic mls Ar remote-files local-file
-Like
-.Ic nlist ,
-except multiple remote files may be specified,
-and the
-.Ar local-file
-must be specified.
-If interactive prompting is on,
-.Nm ftp
-will prompt the user to verify that the last argument is indeed the
-target local file for receiving
-.Ic mls
-output.
-.It Ic mode Op Ar mode-name
-Set the file transfer
-.Ic mode
-to
-.Ar mode-name .
-The default mode is \*(Lqstream\*(Rq mode.
-.It Ic modtime Ar file-name
-Show the last modification time of the file on the remote machine.
-.It Ic mput Ar local-files
-Expand wild cards in the list of local files given as arguments
-and do a
-.Ic put
-for each file in the resulting list.
-See
-.Ic glob
-for details of filename expansion.
-Resulting file names will then be processed according to
-.Ic ntrans
-and
-.Ic nmap
-settings.
-.It Ic newer Ar file-name
-Get the file only if the modification time of the remote file is more
-recent that the file on the current system.
-If the file does not
-exist on the current system, the remote file is considered
-.Ic newer .
-Otherwise, this command is identical to
-.Ar get .
-.It Xo
-.Ic nlist
-.Op Ar remote-directory
-.Op Ar local-file
-.Xc
-Print a list of the files in a
-directory on the remote machine.
-If
-.Ar remote-directory
-is left unspecified, the current working directory is used.
-If interactive prompting is on,
-.Nm ftp
-will prompt the user to verify that the last argument is indeed the
-target local file for receiving
-.Ic nlist
-output.
-If no local file is specified, or if
-.Ar local-file
-is
-.Fl ,
-the output is sent to the terminal.
-.It Ic nmap Op Ar inpattern outpattern
-Set or unset the filename mapping mechanism.
-If no arguments are specified, the filename mapping mechanism is unset.
-If arguments are specified, remote filenames are mapped during
-.Ic mput
-commands and
-.Ic put
-commands issued without a specified remote target filename.
-If arguments are specified, local filenames are mapped during
-.Ic mget
-commands and
-.Ic get
-commands issued without a specified local target filename.
-This command is useful when connecting to a
-.No non\- Ns Ux
-remote computer
-with different file naming conventions or practices.
-The mapping follows the pattern set by
-.Ar inpattern
-and
-.Ar outpattern .
-.Op Ar Inpattern
-is a template for incoming filenames (which may have already been
-processed according to the
-.Ic ntrans
-and
-.Ic case
-settings).
-Variable templating is accomplished by including the
-sequences `$1', `$2', ..., `$9' in
-.Ar inpattern .
-Use `\\' to prevent this special treatment of the `$' character.
-All other characters are treated literally, and are used to determine the
-.Ic nmap
-.Op Ar inpattern
-variable values.
-For example, given
-.Ar inpattern
-$1.$2 and the remote file name "mydata.data", $1 would have the value
-"mydata", and $2 would have the value "data".
-The
-.Ar outpattern
-determines the resulting mapped filename.
-The sequences `$1', `$2', ...., `$9' are replaced by any value resulting
-from the
-.Ar inpattern
-template.
-The sequence `$0' is replace by the original filename.
-Additionally, the sequence
-.Ql Op Ar seq1 , Ar seq2
-is replaced by
-.Op Ar seq1
-if
-.Ar seq1
-is not a null string; otherwise it is replaced by
-.Ar seq2 .
-For example, the command
-.Pp
-.Bd -literal -offset indent -compact
-nmap $1.$2.$3 [$1,$2].[$2,file]
-.Ed
-.Pp
-would yield
-the output filename "myfile.data" for input filenames "myfile.data" and
-"myfile.data.old", "myfile.file" for the input filename "myfile", and
-"myfile.myfile" for the input filename ".myfile".
-Spaces may be included in
-.Ar outpattern ,
-as in the example: `nmap $1 sed "s/ *$//" > $1' .
-Use the `\e' character to prevent special treatment
-of the `$','[','[', and `,' characters.
-.It Ic ntrans Op Ar inchars Op Ar outchars
-Set or unset the filename character translation mechanism.
-If no arguments are specified, the filename character
-translation mechanism is unset.
-If arguments are specified, characters in
-remote filenames are translated during
-.Ic mput
-commands and
-.Ic put
-commands issued without a specified remote target filename.
-If arguments are specified, characters in
-local filenames are translated during
-.Ic mget
-commands and
-.Ic get
-commands issued without a specified local target filename.
-This command is useful when connecting to a
-.No non\- Ns Ux
-remote computer
-with different file naming conventions or practices.
-Characters in a filename matching a character in
-.Ar inchars
-are replaced with the corresponding character in
-.Ar outchars .
-If the character's position in
-.Ar inchars
-is longer than the length of
-.Ar outchars ,
-the character is deleted from the file name.
-.It Ic open Ar host Op Ar port
-Establish a connection to the specified
-.Ar host
-.Tn FTP
-server.
-An optional port number may be supplied,
-in which case,
-.Nm ftp
-will attempt to contact an
-.Tn FTP
-server at that port.
-If the
-.Ic auto-login
-option is on (default),
-.Nm ftp
-will also attempt to automatically log the user in to
-the
-.Tn FTP
-server (see below).
-.It Ic passive
-Toggle passive mode. If passive mode is turned on
-(default is off), the ftp client will
-send a
-.Dv PASV
-command for all data connections instead of the usual
-.Dv PORT
-command. The
-.Dv PASV
-command requests that the remote server open a port for the data connection
-and return the address of that port. The remote server listens on that
-port and the client connects to it. When using the more traditional
-.Dv PORT
-command, the client listens on a port and sends that address to the remote
-server, who connects back to it. Passive mode is useful when using
-.Nm ftp
-through a gateway router or host that controls the directionality of
-traffic.
-(Note that though ftp servers are required to support the
-.Dv PASV
-command by RFC 1123, some do not.)
-.It Ic prompt
-Toggle interactive prompting.
-Interactive prompting
-occurs during multiple file transfers to allow the
-user to selectively retrieve or store files.
-If prompting is turned off (default is on), any
-.Ic mget
-or
-.Ic mput
-will transfer all files, and any
-.Ic mdelete
-will delete all files.
-.It Ic proxy Ar ftp-command
-Execute an ftp command on a secondary control connection.
-This command allows simultaneous connection to two remote ftp
-servers for transferring files between the two servers.
-The first
-.Ic proxy
-command should be an
-.Ic open ,
-to establish the secondary control connection.
-Enter the command "proxy ?" to see other ftp commands executable on the
-secondary connection.
-The following commands behave differently when prefaced by
-.Ic proxy :
-.Ic open
-will not define new macros during the auto-login process,
-.Ic close
-will not erase existing macro definitions,
-.Ic get
-and
-.Ic mget
-transfer files from the host on the primary control connection
-to the host on the secondary control connection, and
-.Ic put ,
-.Ic mput ,
-and
-.Ic append
-transfer files from the host on the secondary control connection
-to the host on the primary control connection.
-Third party file transfers depend upon support of the ftp protocol
-.Dv PASV
-command by the server on the secondary control connection.
-.It Ic put Ar local-file Op Ar remote-file
-Store a local file on the remote machine.
-If
-.Ar remote-file
-is left unspecified, the local file name is used
-after processing according to any
-.Ic ntrans
-or
-.Ic nmap
-settings
-in naming the remote file.
-File transfer uses the
-current settings for
-.Ic type ,
-.Ic format ,
-.Ic mode ,
-and
-.Ic structure .
-.It Ic pwd
-Print the name of the current working directory on the remote
-machine.
-.It Ic quit
-A synonym for
-.Ic bye .
-.It Ic quote Ar arg1 arg2 ...
-The arguments specified are sent, verbatim, to the remote
-.Tn FTP
-server.
-.It Ic recv Ar remote-file Op Ar local-file
-A synonym for get.
-.It Ic reget Ar remote-file Op Ar local-file
-Reget acts like get, except that if
-.Ar local-file
-exists and is
-smaller than
-.Ar remote-file ,
-.Ar local-file
-is presumed to be
-a partially transferred copy of
-.Ar remote-file
-and the transfer
-is continued from the apparent point of failure.
-This command
-is useful when transferring very large files over networks that
-are prone to dropping connections.
-.It Ic remotehelp Op Ar command-name
-Request help from the remote
-.Tn FTP
-server.
-If a
-.Ar command-name
-is specified it is supplied to the server as well.
-.It Ic remotestatus Op Ar file-name
-With no arguments, show status of remote machine.
-If
-.Ar file-name
-is specified, show status of
-.Ar file-name
-on remote machine.
-.It Xo
-.Ic rename
-.Op Ar from
-.Op Ar to
-.Xc
-Rename the file
-.Ar from
-on the remote machine, to the file
-.Ar to .
-.It Ic reset
-Clear reply queue.
-This command re-synchronizes command/reply sequencing with the remote
-ftp server.
-Resynchronization may be necessary following a violation of the ftp protocol
-by the remote server.
-.It Ic restart Ar marker
-Restart the immediately following
-.Ic get
-or
-.Ic put
-at the
-indicated
-.Ar marker .
-On
-.Ux
-systems, marker is usually a byte
-offset into the file.
-.It Ic rmdir Ar directory-name
-Delete a directory on the remote machine.
-.It Ic runique
-Toggle storing of files on the local system with unique filenames.
-If a file already exists with a name equal to the target
-local filename for a
-.Ic get
-or
-.Ic mget
-command, a ".1" is appended to the name.
-If the resulting name matches another existing file,
-a ".2" is appended to the original name.
-If this process continues up to ".99", an error
-message is printed, and the transfer does not take place.
-The generated unique filename will be reported.
-Note that
-.Ic runique
-will not affect local files generated from a shell command
-(see below).
-The default value is off.
-.It Ic send Ar local-file Op Ar remote-file
-A synonym for put.
-.It Ic sendport
-Toggle the use of
-.Dv PORT
-commands.
-By default,
-.Nm ftp
-will attempt to use a
-.Dv PORT
-command when establishing
-a connection for each data transfer.
-The use of
-.Dv PORT
-commands can prevent delays
-when performing multiple file transfers.
-If the
-.Dv PORT
-command fails,
-.Nm ftp
-will use the default data port.
-When the use of
-.Dv PORT
-commands is disabled, no attempt will be made to use
-.Dv PORT
-commands for each data transfer.
-This is useful
-for certain
-.Tn FTP
-implementations which do ignore
-.Dv PORT
-commands but, incorrectly, indicate they've been accepted.
-.It Ic site Ar arg1 arg2 ...
-The arguments specified are sent, verbatim, to the remote
-.Tn FTP
-server as a
-.Dv SITE
-command.
-.It Ic size Ar file-name
-Return size of
-.Ar file-name
-on remote machine.
-.It Ic status
-Show the current status of
-.Nm ftp .
-.It Ic struct Op Ar struct-name
-Set the file transfer
-.Ar structure
-to
-.Ar struct-name .
-By default \*(Lqstream\*(Rq structure is used.
-.It Ic sunique
-Toggle storing of files on remote machine under unique file names.
-Remote ftp server must support ftp protocol
-.Dv STOU
-command for
-successful completion.
-The remote server will report unique name.
-Default value is off.
-.It Ic system
-Show the type of operating system running on the remote machine.
-.It Ic tenex
-Set the file transfer type to that needed to
-talk to
-.Tn TENEX
-machines.
-.It Ic trace
-Toggle packet tracing.
-.It Ic type Op Ar type-name
-Set the file transfer
-.Ic type
-to
-.Ar type-name .
-If no type is specified, the current type
-is printed.
-The default type is network
-.Tn ASCII .
-.It Ic umask Op Ar newmask
-Set the default umask on the remote server to
-.Ar newmask .
-If
-.Ar newmask
-is omitted, the current umask is printed.
-.It Xo
-.Ic user Ar user-name
-.Op Ar password
-.Op Ar account
-.Xc
-Identify yourself to the remote
-.Tn FTP
-server.
-If the
-.Ar password
-is not specified and the server requires it,
-.Nm ftp
-will prompt the user for it (after disabling local echo).
-If an
-.Ar account
-field is not specified, and the
-.Tn FTP
-server
-requires it, the user will be prompted for it.
-If an
-.Ar account
-field is specified, an account command will
-be relayed to the remote server after the login sequence
-is completed if the remote server did not require it
-for logging in.
-Unless
-.Nm ftp
-is invoked with \*(Lqauto-login\*(Rq disabled, this
-process is done automatically on initial connection to
-the
-.Tn FTP
-server.
-.It Ic verbose
-Toggle verbose mode.
-In verbose mode, all responses from
-the
-.Tn FTP
-server are displayed to the user.
-In addition,
-if verbose is on, when a file transfer completes, statistics
-regarding the efficiency of the transfer are reported.
-By default,
-verbose is on.
-.It Ic ? Op Ar command
-A synonym for help.
-.El
-.Pp
-The following command can be used with ftpsec-aware servers.
-.Bl -tag -width Fl
-.It Xo
-.Ic prot
-.Ar clear |
-.Ar safe |
-.Ar confidential |
-.Ar private
-.Xc
-Set the data protection level to the requested level.
-.El
-.Pp
-The following command can be used with ftp servers that has
-implemented the KAUTH site command.
-.Bl -tag -width Fl
-.It Ic kauth Op Ar principal
-Obtain remote tickets.
-.El
-.Pp
-Command arguments which have embedded spaces may be quoted with
-quote `"' marks.
-.Sh ABORTING A FILE TRANSFER
-To abort a file transfer, use the terminal interrupt key
-(usually Ctrl-C).
-Sending transfers will be immediately halted.
-Receiving transfers will be halted by sending a ftp protocol
-.Dv ABOR
-command to the remote server, and discarding any further data received.
-The speed at which this is accomplished depends upon the remote
-server's support for
-.Dv ABOR
-processing.
-If the remote server does not support the
-.Dv ABOR
-command, an
-.Ql ftp>
-prompt will not appear until the remote server has completed
-sending the requested file.
-.Pp
-The terminal interrupt key sequence will be ignored when
-.Nm ftp
-has completed any local processing and is awaiting a reply
-from the remote server.
-A long delay in this mode may result from the ABOR processing described
-above, or from unexpected behavior by the remote server, including
-violations of the ftp protocol.
-If the delay results from unexpected remote server behavior, the local
-.Nm ftp
-program must be killed by hand.
-.Sh FILE NAMING CONVENTIONS
-Files specified as arguments to
-.Nm ftp
-commands are processed according to the following rules.
-.Bl -enum
-.It
-If the file name
-.Sq Fl
-is specified, the
-.Ar stdin
-(for reading) or
-.Ar stdout
-(for writing) is used.
-.It
-If the first character of the file name is
-.Sq \&| ,
-the
-remainder of the argument is interpreted as a shell command.
-.Nm Ftp
-then forks a shell, using
-.Xr popen 3
-with the argument supplied, and reads (writes) from the stdout
-(stdin).
-If the shell command includes spaces, the argument
-must be quoted; e.g.
-\*(Lq" ls -lt"\*(Rq.
-A particularly
-useful example of this mechanism is: \*(Lqdir more\*(Rq.
-.It
-Failing the above checks, if ``globbing'' is enabled,
-local file names are expanded
-according to the rules used in the
-.Xr csh 1 ;
-c.f. the
-.Ic glob
-command.
-If the
-.Nm ftp
-command expects a single local file (.e.g.
-.Ic put ) ,
-only the first filename generated by the "globbing" operation is used.
-.It
-For
-.Ic mget
-commands and
-.Ic get
-commands with unspecified local file names, the local filename is
-the remote filename, which may be altered by a
-.Ic case ,
-.Ic ntrans ,
-or
-.Ic nmap
-setting.
-The resulting filename may then be altered if
-.Ic runique
-is on.
-.It
-For
-.Ic mput
-commands and
-.Ic put
-commands with unspecified remote file names, the remote filename is
-the local filename, which may be altered by a
-.Ic ntrans
-or
-.Ic nmap
-setting.
-The resulting filename may then be altered by the remote server if
-.Ic sunique
-is on.
-.El
-.Sh FILE TRANSFER PARAMETERS
-The FTP specification specifies many parameters which may
-affect a file transfer.
-The
-.Ic type
-may be one of \*(Lqascii\*(Rq, \*(Lqimage\*(Rq (binary),
-\*(Lqebcdic\*(Rq, and \*(Lqlocal byte size\*(Rq (for
-.Tn PDP Ns -10's
-and
-.Tn PDP Ns -20's
-mostly).
-.Nm Ftp
-supports the ascii and image types of file transfer,
-plus local byte size 8 for
-.Ic tenex
-mode transfers.
-.Pp
-.Nm Ftp
-supports only the default values for the remaining
-file transfer parameters:
-.Ic mode ,
-.Ic form ,
-and
-.Ic struct .
-.Sh THE .netrc FILE
-The
-.Pa .netrc
-file contains login and initialization information
-used by the auto-login process.
-It resides in the user's home directory.
-The following tokens are recognized; they may be separated by spaces,
-tabs, or new-lines:
-.Bl -tag -width password
-.It Ic machine Ar name
-Identify a remote machine
-.Ar name .
-The auto-login process searches the
-.Pa .netrc
-file for a
-.Ic machine
-token that matches the remote machine specified on the
-.Nm ftp
-command line or as an
-.Ic open
-command argument.
-Once a match is made, the subsequent
-.Pa .netrc
-tokens are processed,
-stopping when the end of file is reached or another
-.Ic machine
-or a
-.Ic default
-token is encountered.
-.It Ic default
-This is the same as
-.Ic machine
-.Ar name
-except that
-.Ic default
-matches any name.
-There can be only one
-.Ic default
-token, and it must be after all
-.Ic machine
-tokens.
-This is normally used as:
-.Pp
-.Dl default login anonymous password user@site
-.Pp
-thereby giving the user
-.Ar automatic
-anonymous ftp login to
-machines not specified in
-.Pa .netrc .
-This can be overridden
-by using the
-.Fl n
-flag to disable auto-login.
-.It Ic login Ar name
-Identify a user on the remote machine.
-If this token is present, the auto-login process will initiate
-a login using the specified
-.Ar name .
-.It Ic password Ar string
-Supply a password.
-If this token is present, the auto-login process will supply the
-specified string if the remote server requires a password as part
-of the login process.
-Note that if this token is present in the
-.Pa .netrc
-file for any user other
-than
-.Ar anonymous ,
-.Nm ftp
-will abort the auto-login process if the
-.Pa .netrc
-is readable by
-anyone besides the user.
-.It Ic account Ar string
-Supply an additional account password.
-If this token is present, the auto-login process will supply the
-specified string if the remote server requires an additional
-account password, or the auto-login process will initiate an
-.Dv ACCT
-command if it does not.
-.It Ic macdef Ar name
-Define a macro.
-This token functions like the
-.Nm ftp
-.Ic macdef
-command functions.
-A macro is defined with the specified name; its contents begin with the
-next
-.Pa .netrc
-line and continue until a null line (consecutive new-line
-characters) is encountered.
-If a macro named
-.Ic init
-is defined, it is automatically executed as the last step in the
-auto-login process.
-.El
-.Sh ENVIRONMENT
-.Nm Ftp
-utilizes the following environment variables.
-.Bl -tag -width Fl
-.It Ev HOME
-For default location of a
-.Pa .netrc
-file, if one exists.
-.It Ev SHELL
-For default shell.
-.El
-.Sh SEE ALSO
-.Xr ftpd 8 ,
-.%T RFC2228
-.Sh HISTORY
-The
-.Nm ftp
-command appeared in
-.Bx 4.2 .
-.Sh BUGS
-Correct execution of many commands depends upon proper behavior
-by the remote server.
-.Pp
-An error in the treatment of carriage returns
-in the
-.Bx 4.2
-ascii-mode transfer code
-has been corrected.
-This correction may result in incorrect transfers of binary files
-to and from
-.Bx 4.2
-servers using the ascii type.
-Avoid this problem by using the binary image type.
diff --git a/appl/ftp/ftp/ftp.c b/appl/ftp/ftp/ftp.c
deleted file mode 100644
index a55a2c01c39d71c19d7a53dc75dd1faf135898cd..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/ftp.c
+++ /dev/null
@@ -1,1659 +0,0 @@
-/*
- * Copyright (c) 1985, 1989, 1993, 1994
- * 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 "ftp_locl.h"
-RCSID("$Id$");
-
-struct sockaddr_in hisctladdr;
-struct sockaddr_in data_addr;
-int data = -1;
-int abrtflag = 0;
-jmp_buf ptabort;
-int ptabflg;
-int ptflag = 0;
-struct sockaddr_in myctladdr;
-off_t restart_point = 0;
-
-
-FILE *cin, *cout;
-
-typedef void (*sighand)(int);
-
-char *
-hookup(char *host, int port)
-{
- struct hostent *hp = 0;
- int s, len, tos;
- static char hostnamebuf[80];
-
- memset(&hisctladdr, 0, sizeof (hisctladdr));
- if(inet_aton(host, &hisctladdr.sin_addr)){
- hisctladdr.sin_family = AF_INET;
- strncpy(hostnamebuf, host, sizeof(hostnamebuf));
- } else {
- hp = gethostbyname(host);
- if (hp == NULL) {
-#ifdef HAVE_H_ERRNO
- warnx("%s: %s", host, hstrerror(h_errno));
-#else
- warnx("%s: %s", host, "unknown error");
-#endif
- code = -1;
- return NULL;
- }
- hisctladdr.sin_family = hp->h_addrtype;
- memmove(&hisctladdr.sin_addr,
- hp->h_addr_list[0],
- sizeof(hisctladdr.sin_addr));
- strncpy(hostnamebuf, hp->h_name, sizeof(hostnamebuf));
- hostnamebuf[sizeof(hostnamebuf) - 1] = '\0';
- }
- hostname = hostnamebuf;
- s = socket(hisctladdr.sin_family, SOCK_STREAM, 0);
- if (s < 0) {
- warn("socket");
- code = -1;
- return (0);
- }
- hisctladdr.sin_port = port;
- while (connect(s, (struct sockaddr *)&hisctladdr, sizeof (hisctladdr)) < 0) {
- if (hp && hp->h_addr_list[1]) {
- int oerrno = errno;
- char *ia;
-
- ia = inet_ntoa(hisctladdr.sin_addr);
- errno = oerrno;
- warn("connect to address %s", ia);
- hp->h_addr_list++;
- memmove(&hisctladdr.sin_addr,
- hp->h_addr_list[0],
- sizeof(hisctladdr.sin_addr));
- fprintf(stdout, "Trying %s...\n",
- inet_ntoa(hisctladdr.sin_addr));
- close(s);
- s = socket(hisctladdr.sin_family, SOCK_STREAM, 0);
- if (s < 0) {
- warn("socket");
- code = -1;
- return (0);
- }
- continue;
- }
- warn("connect");
- code = -1;
- goto bad;
- }
- len = sizeof (myctladdr);
- if (getsockname(s, (struct sockaddr *)&myctladdr, &len) < 0) {
- warn("getsockname");
- code = -1;
- goto bad;
- }
-#if defined(IP_TOS) && defined(HAVE_SETSOCKOPT)
- tos = IPTOS_LOWDELAY;
- if (setsockopt(s, IPPROTO_IP, IP_TOS, (char *)&tos, sizeof(int)) < 0)
- warn("setsockopt TOS (ignored)");
-#endif
- cin = fdopen(s, "r");
- cout = fdopen(s, "w");
- if (cin == NULL || cout == NULL) {
- warnx("fdopen failed.");
- if (cin)
- fclose(cin);
- if (cout)
- fclose(cout);
- code = -1;
- goto bad;
- }
- if (verbose)
- printf("Connected to %s.\n", hostname);
- if (getreply(0) > 2) { /* read startup message from server */
- if (cin)
- fclose(cin);
- if (cout)
- fclose(cout);
- code = -1;
- goto bad;
- }
-#if defined(SO_OOBINLINE) && defined(HAVE_SETSOCKOPT)
- {
- int on = 1;
-
- if (setsockopt(s, SOL_SOCKET, SO_OOBINLINE, (char *)&on, sizeof(on))
- < 0 && debug) {
- warn("setsockopt");
- }
- }
-#endif /* SO_OOBINLINE */
-
- return (hostname);
-bad:
- close(s);
- return NULL;
-}
-
-int
-login(char *host)
-{
- char tmp[80];
- char defaultpass[128];
- char *user, *pass, *acct;
- int n, aflag = 0;
-
- char *myname = NULL;
- struct passwd *pw = k_getpwuid(getuid());
- if (pw != NULL)
- myname = pw->pw_name;
-
- user = pass = acct = 0;
-
- if(do_klogin(host))
- printf("\n*** Using plaintext user and password ***\n\n");
- else{
- printf("Kerberos authentication successful.\n\n");
- }
-
- if (ruserpass(host, &user, &pass, &acct) < 0) {
- code = -1;
- return (0);
- }
- while (user == NULL) {
- if (myname)
- printf("Name (%s:%s): ", host, myname);
- else
- printf("Name (%s): ", host);
- fgets(tmp, sizeof(tmp) - 1, stdin);
- tmp[strlen(tmp) - 1] = '\0';
- if (*tmp == '\0')
- user = myname;
- else
- user = tmp;
- }
- strcpy(username, user);
- n = command("USER %s", user);
- if (n == CONTINUE) {
- if(auth_complete)
- pass = myname;
- else if (pass == NULL) {
- char prompt[128];
- if(myname &&
- (!strcmp(user, "ftp") || !strcmp(user, "anonymous"))){
- snprintf(defaultpass, sizeof(defaultpass), "%s@%s", myname, mydomain);
- snprintf(prompt, sizeof(prompt), "Password (%s): ", defaultpass);
- }else{
- strcpy(defaultpass, "");
- snprintf(prompt, sizeof(prompt), "Password: ");
- }
- pass = defaultpass;
- des_read_pw_string (tmp, sizeof(tmp), prompt, 0);
- if(tmp[0])
- pass = tmp;
- }
- n = command("PASS %s", pass);
- }
- if (n == CONTINUE) {
- aflag++;
- acct = tmp;
- des_read_pw_string(acct, 128, "Account:", 0);
- n = command("ACCT %s", acct);
- }
- if (n != COMPLETE) {
- warnx("Login failed.");
- return (0);
- }
- if (!aflag && acct != NULL)
- command("ACCT %s", acct);
- if (proxy)
- return (1);
- for (n = 0; n < macnum; ++n) {
- if (!strcmp("init", macros[n].mac_name)) {
- strcpy(line, "$init");
- makeargv();
- domacro(margc, margv);
- break;
- }
- }
- sec_set_protection_level();
- return (1);
-}
-
-void
-cmdabort(int sig)
-{
-
- printf("\n");
- fflush(stdout);
- abrtflag++;
- if (ptflag)
- longjmp(ptabort,1);
-}
-
-int
-command(char *fmt, ...)
-{
- va_list ap;
- int r;
- sighand oldintr;
-
- abrtflag = 0;
- if (cout == NULL) {
- warn("No control connection for command");
- code = -1;
- return (0);
- }
- oldintr = signal(SIGINT, cmdabort);
- va_start(ap, fmt);
- if(debug){
- printf("---> ");
- if (strncmp("PASS ", fmt, 5) == 0)
- printf("PASS XXXX");
- else
- vfprintf(stdout, fmt, ap);
- va_start(ap, fmt);
- }
- if(auth_complete)
- krb4_write_enc(cout, fmt, ap);
- else
- vfprintf(cout, fmt, ap);
- va_end(ap);
- if(debug){
- printf("\n");
- fflush(stdout);
- }
- fprintf(cout, "\r\n");
- fflush(cout);
- cpend = 1;
- r = getreply(!strcmp(fmt, "QUIT"));
- if (abrtflag && oldintr != SIG_IGN)
- (*oldintr)(SIGINT);
- signal(SIGINT, oldintr);
- return (r);
-}
-
-char reply_string[BUFSIZ]; /* last line of previous reply */
-
-int
-getreply(int expecteof)
-{
- char *p;
- char *lead_string;
- int c;
- struct sigaction sa, osa;
- char buf[1024];
-
- sigemptyset(&sa.sa_mask);
- sa.sa_flags = 0;
- sa.sa_handler = cmdabort;
- sigaction(SIGINT, &sa, &osa);
-
- p = buf;
-
- while(1){
- c = getc(cin);
- switch(c){
- case EOF:
- if (expecteof) {
- sigaction(SIGINT,&osa, NULL);
- code = 221;
- return 0;
- }
- lostpeer(0);
- if (verbose) {
- printf("421 Service not available, "
- "remote server has closed connection\n");
- fflush(stdout);
- }
- code = 421;
- return (4);
- break;
- case IAC:
- c = getc(cin);
- if(c == WILL || c == WONT)
- fprintf(cout, "%c%c%c", IAC, DONT, getc(cin));
- if(c == DO || c == DONT)
- fprintf(cout, "%c%c%c", IAC, WONT, getc(cin));
- continue;
- case '\n':
- *p++ = 0;
- if(isdigit(buf[0])){
- sscanf(buf, "%d", &code);
- if(code == 631){
- krb4_read_mic(buf);
- sscanf(buf, "%d", &code);
- lead_string = "S:";
- } else if(code == 632){
- krb4_read_enc(buf);
- sscanf(buf, "%d", &code);
- lead_string = "P:";
- }else if(code == 633){
- printf("Received confidential reply!\n");
- }else if(auth_complete)
- lead_string = "!!";
- else
- lead_string = "";
- if(verbose > 0 || (verbose > -1 && code > 499))
- fprintf(stdout, "%s%s\n", lead_string, buf);
- if(buf[3] == ' '){
- strcpy(reply_string, buf);
- if (code >= 200)
- cpend = 0;
- sigaction(SIGINT, &osa, NULL);
- if (code == 421)
- lostpeer(0);
-#if 1
- if (abrtflag &&
- osa.sa_handler != cmdabort &&
- osa.sa_handler != SIG_IGN)
- osa.sa_handler(SIGINT);
-#endif
- if(code == 227){
- char *p, *q;
- pasv[0] = 0;
- p = strchr(reply_string, '(');
- if(p){
- p++;
- q = strchr(p, ')');
- if(q){
- strncpy(pasv, p, q - p);
- pasv[q - p] = 0;
- }
- }
- }
- return code / 100;
- }
- }else{
- if(verbose > 0 || (verbose > -1 && code > 499)){
- if(auth_complete)
- fprintf(stdout, "!!");
- fprintf(stdout, "%s\n", buf);
- }
- }
- p = buf;
- continue;
- default:
- *p++ = c;
- }
- }
-
-}
-
-
-#if 0
-int
-getreply(int expecteof)
-{
- int c, n;
- int dig;
- int originalcode = 0, continuation = 0;
- sighand oldintr;
- int pflag = 0;
- char *cp, *pt = pasv;
-
- oldintr = signal(SIGINT, cmdabort);
- for (;;) {
- dig = n = code = 0;
- cp = reply_string;
- while ((c = getc(cin)) != '\n') {
- if (c == IAC) { /* handle telnet commands */
- switch (c = getc(cin)) {
- case WILL:
- case WONT:
- c = getc(cin);
- fprintf(cout, "%c%c%c", IAC, DONT, c);
- fflush(cout);
- break;
- case DO:
- case DONT:
- c = getc(cin);
- fprintf(cout, "%c%c%c", IAC, WONT, c);
- fflush(cout);
- break;
- default:
- break;
- }
- continue;
- }
- dig++;
- if (c == EOF) {
- if (expecteof) {
- signal(SIGINT,oldintr);
- code = 221;
- return (0);
- }
- lostpeer(0);
- if (verbose) {
- printf("421 Service not available, remote server has closed connection\n");
- fflush(stdout);
- }
- code = 421;
- return (4);
- }
- if (c != '\r' && (verbose > 0 ||
- (verbose > -1 && n == '5' && dig > 4))) {
- if (proxflag &&
- (dig == 1 || dig == 5 && verbose == 0))
- printf("%s:",hostname);
- putchar(c);
- }
- if (dig < 4 && isdigit(c))
- code = code * 10 + (c - '0');
- if (!pflag && code == 227)
- pflag = 1;
- if (dig > 4 && pflag == 1 && isdigit(c))
- pflag = 2;
- if (pflag == 2) {
- if (c != '\r' && c != ')')
- *pt++ = c;
- else {
- *pt = '\0';
- pflag = 3;
- }
- }
- if (dig == 4 && c == '-') {
- if (continuation)
- code = 0;
- continuation++;
- }
- if (n == 0)
- n = c;
- if (cp < &reply_string[sizeof(reply_string) - 1])
- *cp++ = c;
- }
- if (verbose > 0 || verbose > -1 && n == '5') {
- putchar(c);
- fflush (stdout);
- }
- if (continuation && code != originalcode) {
- if (originalcode == 0)
- originalcode = code;
- continue;
- }
- *cp = '\0';
- if(auth_complete){
- if(code == 631)
- krb4_read_mic(reply_string);
- else
- krb4_read_enc(reply_string);
- n = code / 100 + '0';
- }
-
- if (n != '1')
- cpend = 0;
- signal(SIGINT,oldintr);
- if (code == 421 || originalcode == 421)
- lostpeer(0);
- if (abrtflag && oldintr != cmdabort && oldintr != SIG_IGN)
- (*oldintr)(SIGINT);
- return (n - '0');
- }
-}
-#endif
-
-int
-empty(fd_set *mask, int sec)
-{
- struct timeval t;
-
- t.tv_sec = (long) sec;
- t.tv_usec = 0;
- return (select(32, mask, NULL, NULL, &t));
-}
-
-jmp_buf sendabort;
-
-static RETSIGTYPE
-abortsend(int sig)
-{
-
- mflag = 0;
- abrtflag = 0;
- printf("\nsend aborted\nwaiting for remote to finish abort\n");
- fflush(stdout);
- longjmp(sendabort, 1);
-}
-
-#define HASHBYTES 1024
-
-static int
-copy_stream(FILE *from, FILE *to)
-{
- static size_t bufsize;
- static char *buf;
- int n;
- int bytes = 0;
- int werr;
- int hashbytes = HASHBYTES;
- struct stat st;
-
-#if defined(HAVE_MMAP) && !defined(NO_MMAP)
- void *chunk;
-
-#ifndef MAP_FAILED
-#define MAP_FAILED (-1)
-#endif
-
- if(fstat(fileno(from), &st) == 0 && S_ISREG(st.st_mode)){
- chunk = mmap(0, st.st_size, PROT_READ, MAP_SHARED, fileno(from), 0);
- if (chunk != (void *)MAP_FAILED) {
- int res;
-
- res = sec_write(fileno(to), chunk, st.st_size);
- if (munmap(chunk, st.st_size) < 0)
- warn ("munmap");
- sec_fflush(to);
- return res;
- }
- }
-#endif
-
- buf = alloc_buffer (buf, &bufsize,
- fstat(fileno(from), &st) >= 0 ? &st : NULL);
- if (buf == NULL)
- return -1;
-
- while((n = read(fileno(from), buf, bufsize)) > 0){
- werr = sec_write(fileno(to), buf, n);
- if(werr < 0)
- break;
- bytes += werr;
- while(hash && bytes > hashbytes){
- putchar('#');
- hashbytes += HASHBYTES;
- }
- }
- sec_fflush(to);
- if(n < 0)
- warn("local");
-
- if(werr < 0){
- if(errno != EPIPE)
- warn("netout");
- bytes = -1;
- }
- return bytes;
-}
-
-void
-sendrequest(char *cmd, char *local, char *remote, int printnames)
-{
- struct stat st;
- struct timeval start, stop;
- int c, d;
- FILE *fin, *dout = 0;
- int (*closefunc) (FILE *);
- RETSIGTYPE (*oldintr)(), (*oldintp)();
- long bytes = 0, hashbytes = HASHBYTES;
- char *lmode;
-
- if (verbose && printnames) {
- if (local && strcmp(local, "-") != 0)
- printf("local: %s ", local);
- if (remote)
- printf("remote: %s\n", remote);
- }
- if (proxy) {
- proxtrans(cmd, local, remote);
- return;
- }
- if (curtype != type)
- changetype(type, 0);
- closefunc = NULL;
- oldintr = NULL;
- oldintp = NULL;
- lmode = "w";
- if (setjmp(sendabort)) {
- while (cpend) {
- getreply(0);
- }
- if (data >= 0) {
- close(data);
- data = -1;
- }
- if (oldintr)
- signal(SIGINT,oldintr);
- if (oldintp)
- signal(SIGPIPE,oldintp);
- code = -1;
- return;
- }
- oldintr = signal(SIGINT, abortsend);
- if (strcmp(local, "-") == 0)
- fin = stdin;
- else if (*local == '|') {
- oldintp = signal(SIGPIPE,SIG_IGN);
- fin = popen(local + 1, "r");
- if (fin == NULL) {
- warn("%s", local + 1);
- signal(SIGINT, oldintr);
- signal(SIGPIPE, oldintp);
- code = -1;
- return;
- }
- closefunc = pclose;
- } else {
- fin = fopen(local, "r");
- if (fin == NULL) {
- warn("local: %s", local);
- signal(SIGINT, oldintr);
- code = -1;
- return;
- }
- closefunc = fclose;
- if (fstat(fileno(fin), &st) < 0 ||
- (st.st_mode&S_IFMT) != S_IFREG) {
- fprintf(stdout, "%s: not a plain file.\n", local);
- signal(SIGINT, oldintr);
- fclose(fin);
- code = -1;
- return;
- }
- }
- if (initconn()) {
- signal(SIGINT, oldintr);
- if (oldintp)
- signal(SIGPIPE, oldintp);
- code = -1;
- if (closefunc != NULL)
- (*closefunc)(fin);
- return;
- }
- if (setjmp(sendabort))
- goto abort;
-
- if (restart_point &&
- (strcmp(cmd, "STOR") == 0 || strcmp(cmd, "APPE") == 0)) {
- int rc;
-
- switch (curtype) {
- case TYPE_A:
- rc = fseek(fin, (long) restart_point, SEEK_SET);
- break;
- case TYPE_I:
- case TYPE_L:
- rc = lseek(fileno(fin), restart_point, SEEK_SET);
- break;
- }
- if (rc < 0) {
- warn("local: %s", local);
- restart_point = 0;
- if (closefunc != NULL)
- (*closefunc)(fin);
- return;
- }
- if (command("REST %ld", (long) restart_point)
- != CONTINUE) {
- restart_point = 0;
- if (closefunc != NULL)
- (*closefunc)(fin);
- return;
- }
- restart_point = 0;
- lmode = "r+w";
- }
- if (remote) {
- if (command("%s %s", cmd, remote) != PRELIM) {
- signal(SIGINT, oldintr);
- if (oldintp)
- signal(SIGPIPE, oldintp);
- if (closefunc != NULL)
- (*closefunc)(fin);
- return;
- }
- } else
- if (command("%s", cmd) != PRELIM) {
- signal(SIGINT, oldintr);
- if (oldintp)
- signal(SIGPIPE, oldintp);
- if (closefunc != NULL)
- (*closefunc)(fin);
- return;
- }
- dout = dataconn(lmode);
- if (dout == NULL)
- goto abort;
- set_buffer_size(fileno(dout), 0);
- gettimeofday(&start, (struct timezone *)0);
- oldintp = signal(SIGPIPE, SIG_IGN);
- switch (curtype) {
-
- case TYPE_I:
- case TYPE_L:
- errno = d = c = 0;
- bytes = copy_stream(fin, dout);
- break;
-
- case TYPE_A:
- while ((c = getc(fin)) != EOF) {
- if (c == '\n') {
- while (hash && (bytes >= hashbytes)) {
- putchar('#');
- fflush(stdout);
- hashbytes += HASHBYTES;
- }
- if (ferror(dout))
- break;
- sec_putc('\r', dout);
- bytes++;
- }
- sec_putc(c, dout);
- bytes++;
- }
- sec_fflush(dout);
- if (hash) {
- if (bytes < hashbytes)
- putchar('#');
- putchar('\n');
- fflush(stdout);
- }
- if (ferror(fin))
- warn("local: %s", local);
- if (ferror(dout)) {
- if (errno != EPIPE)
- warn("netout");
- bytes = -1;
- }
- break;
- }
- if (closefunc != NULL)
- (*closefunc)(fin);
- fclose(dout);
- gettimeofday(&stop, (struct timezone *)0);
- getreply(0);
- signal(SIGINT, oldintr);
- if (oldintp)
- signal(SIGPIPE, oldintp);
- if (bytes > 0)
- ptransfer("sent", bytes, &start, &stop);
- return;
-abort:
- signal(SIGINT, oldintr);
- if (oldintp)
- signal(SIGPIPE, oldintp);
- if (!cpend) {
- code = -1;
- return;
- }
- if (data >= 0) {
- close(data);
- data = -1;
- }
- if (dout)
- fclose(dout);
- getreply(0);
- code = -1;
- if (closefunc != NULL && fin != NULL)
- (*closefunc)(fin);
- gettimeofday(&stop, (struct timezone *)0);
- if (bytes > 0)
- ptransfer("sent", bytes, &start, &stop);
-}
-
-jmp_buf recvabort;
-
-void
-abortrecv(int sig)
-{
-
- mflag = 0;
- abrtflag = 0;
- printf("\nreceive aborted\nwaiting for remote to finish abort\n");
- fflush(stdout);
- longjmp(recvabort, 1);
-}
-
-void
-recvrequest(char *cmd, char *local, char *remote,
- char *lmode, int printnames, int local_given)
-{
- FILE *fout, *din = 0;
- int (*closefunc) (FILE *);
- sighand oldintr, oldintp;
- int c, d, is_retr, tcrflag, bare_lfs = 0;
- static size_t bufsize;
- static char *buf;
- long bytes = 0, hashbytes = HASHBYTES;
- struct timeval start, stop;
- struct stat st;
-
- is_retr = strcmp(cmd, "RETR") == 0;
- if (is_retr && verbose && printnames) {
- if (local && strcmp(local, "-") != 0)
- printf("local: %s ", local);
- if (remote)
- printf("remote: %s\n", remote);
- }
- if (proxy && is_retr) {
- proxtrans(cmd, local, remote);
- return;
- }
- closefunc = NULL;
- oldintr = NULL;
- oldintp = NULL;
- tcrflag = !crflag && is_retr;
- if (setjmp(recvabort)) {
- while (cpend) {
- getreply(0);
- }
- if (data >= 0) {
- close(data);
- data = -1;
- }
- if (oldintr)
- signal(SIGINT, oldintr);
- code = -1;
- return;
- }
- oldintr = signal(SIGINT, abortrecv);
- if (!local_given || (strcmp(local, "-") && *local != '|')) {
- if (access(local, 2) < 0) {
- char *dir = strrchr(local, '/');
-
- if (errno != ENOENT && errno != EACCES) {
- warn("local: %s", local);
- signal(SIGINT, oldintr);
- code = -1;
- return;
- }
- if (dir != NULL)
- *dir = 0;
- d = access(dir ? local : ".", 2);
- if (dir != NULL)
- *dir = '/';
- if (d < 0) {
- warn("local: %s", local);
- signal(SIGINT, oldintr);
- code = -1;
- return;
- }
- if (!runique && errno == EACCES &&
- chmod(local, 0600) < 0) {
- warn("local: %s", local);
- signal(SIGINT, oldintr);
- signal(SIGINT, oldintr);
- code = -1;
- return;
- }
- if (runique && errno == EACCES &&
- (local = gunique(local)) == NULL) {
- signal(SIGINT, oldintr);
- code = -1;
- return;
- }
- }
- else if (runique && (local = gunique(local)) == NULL) {
- signal(SIGINT, oldintr);
- code = -1;
- return;
- }
- }
- if (!is_retr) {
- if (curtype != TYPE_A)
- changetype(TYPE_A, 0);
- } else if (curtype != type)
- changetype(type, 0);
- if (initconn()) {
- signal(SIGINT, oldintr);
- code = -1;
- return;
- }
- if (setjmp(recvabort))
- goto abort;
- if (is_retr && restart_point &&
- command("REST %ld", (long) restart_point) != CONTINUE)
- return;
- if (remote) {
- if (command("%s %s", cmd, remote) != PRELIM) {
- signal(SIGINT, oldintr);
- return;
- }
- } else {
- if (command("%s", cmd) != PRELIM) {
- signal(SIGINT, oldintr);
- return;
- }
- }
- din = dataconn("r");
- if (din == NULL)
- goto abort;
- set_buffer_size(fileno(din), 1);
- if (local_given && strcmp(local, "-") == 0)
- fout = stdout;
- else if (local_given && *local == '|') {
- oldintp = signal(SIGPIPE, SIG_IGN);
- fout = popen(local + 1, "w");
- if (fout == NULL) {
- warn("%s", local+1);
- goto abort;
- }
- closefunc = pclose;
- } else {
- fout = fopen(local, lmode);
- if (fout == NULL) {
- warn("local: %s", local);
- goto abort;
- }
- closefunc = fclose;
- }
- buf = alloc_buffer (buf, &bufsize,
- fstat(fileno(fout), &st) >= 0 ? &st : NULL);
- if (buf == NULL)
- goto abort;
-
- gettimeofday(&start, (struct timezone *)0);
- switch (curtype) {
-
- case TYPE_I:
- case TYPE_L:
- if (restart_point &&
- lseek(fileno(fout), restart_point, SEEK_SET) < 0) {
- warn("local: %s", local);
- if (closefunc != NULL)
- (*closefunc)(fout);
- return;
- }
- errno = d = 0;
- while ((c = sec_read(fileno(din), buf, bufsize)) > 0) {
- if ((d = write(fileno(fout), buf, c)) != c)
- break;
- bytes += c;
- if (hash) {
- while (bytes >= hashbytes) {
- putchar('#');
- hashbytes += HASHBYTES;
- }
- fflush(stdout);
- }
- }
- if (hash && bytes > 0) {
- if (bytes < HASHBYTES)
- putchar('#');
- putchar('\n');
- fflush(stdout);
- }
- if (c < 0) {
- if (errno != EPIPE)
- warn("netin");
- bytes = -1;
- }
- if (d < c) {
- if (d < 0)
- warn("local: %s", local);
- else
- warnx("%s: short write", local);
- }
- break;
-
- case TYPE_A:
- if (restart_point) {
- int i, n, ch;
-
- if (fseek(fout, 0L, SEEK_SET) < 0)
- goto done;
- n = restart_point;
- for (i = 0; i++ < n;) {
- if ((ch = sec_getc(fout)) == EOF)
- goto done;
- if (ch == '\n')
- i++;
- }
- if (fseek(fout, 0L, SEEK_CUR) < 0) {
- done:
- warn("local: %s", local);
- if (closefunc != NULL)
- (*closefunc)(fout);
- return;
- }
- }
-
- while ((c = sec_getc(din)) != EOF) {
- if (c == '\n')
- bare_lfs++;
- while (c == '\r') {
- while (hash && (bytes >= hashbytes)) {
- putchar('#');
- fflush(stdout);
- hashbytes += HASHBYTES;
- }
- bytes++;
- if ((c = sec_getc(din)) != '\n' || tcrflag) {
- if (ferror(fout))
- goto break2;
- putc('\r', fout);
- if (c == '\0') {
- bytes++;
- goto contin2;
- }
- if (c == EOF)
- goto contin2;
- }
- }
- putc(c, fout);
- bytes++;
- contin2: ;
- }
- break2:
- if (bare_lfs) {
- printf("WARNING! %d bare linefeeds received in ASCII mode\n",
- bare_lfs);
- printf("File may not have transferred correctly.\n");
- }
- if (hash) {
- if (bytes < hashbytes)
- putchar('#');
- putchar('\n');
- fflush(stdout);
- }
- if (ferror(din)) {
- if (errno != EPIPE)
- warn("netin");
- bytes = -1;
- }
- if (ferror(fout))
- warn("local: %s", local);
- break;
- }
- if (closefunc != NULL)
- (*closefunc)(fout);
- signal(SIGINT, oldintr);
- if (oldintp)
- signal(SIGPIPE, oldintp);
- fclose(din);
- gettimeofday(&stop, (struct timezone *)0);
- getreply(0);
- if (bytes > 0 && is_retr)
- ptransfer("received", bytes, &start, &stop);
- return;
-abort:
-
- /* abort using RFC959 recommended IP,SYNC sequence */
-
- if (oldintp)
- signal(SIGPIPE, oldintr);
- signal(SIGINT, SIG_IGN);
- if (!cpend) {
- code = -1;
- signal(SIGINT, oldintr);
- return;
- }
-
- abort_remote(din);
- code = -1;
- if (data >= 0) {
- close(data);
- data = -1;
- }
- if (closefunc != NULL && fout != NULL)
- (*closefunc)(fout);
- if (din)
- fclose(din);
- gettimeofday(&stop, (struct timezone *)0);
- if (bytes > 0)
- ptransfer("received", bytes, &start, &stop);
- signal(SIGINT, oldintr);
-}
-
-/*
- * Need to start a listen on the data channel before we send the command,
- * otherwise the server's connect may fail.
- */
-int
-initconn(void)
-{
- int result, len, tmpno = 0;
- int on = 1;
- int a0, a1, a2, a3, p0, p1;
-
- if (passivemode) {
- data = socket(AF_INET, SOCK_STREAM, 0);
- if (data < 0) {
- perror("ftp: socket");
- return(1);
- }
-#if defined(SO_DEBUG) && defined(HAVE_SETSOCKOPT)
- if ((options & SO_DEBUG) &&
- setsockopt(data, SOL_SOCKET, SO_DEBUG, (char *)&on,
- sizeof (on)) < 0)
- perror("ftp: setsockopt (ignored)");
-#endif
- if (command("PASV") != COMPLETE) {
- printf("Passive mode refused.\n");
- goto bad;
- }
-
- /*
- * What we've got at this point is a string of comma
- * separated one-byte unsigned integer values.
- * The first four are the an IP address. The fifth is
- * the MSB of the port number, the sixth is the LSB.
- * From that we'll prepare a sockaddr_in.
- */
-
- if (sscanf(pasv,"%d,%d,%d,%d,%d,%d",
- &a0, &a1, &a2, &a3, &p0, &p1) != 6) {
- printf("Passive mode address scan failure. "
- "Shouldn't happen!\n");
- goto bad;
- }
- if(a0 < 0 || a0 > 255 ||
- a1 < 0 || a1 > 255 ||
- a2 < 0 || a2 > 255 ||
- a3 < 0 || a3 > 255 ||
- p0 < 0 || p0 > 255 ||
- p1 < 0 || p1 > 255){
- printf("Can't parse passive mode string.\n");
- goto bad;
- }
-
- memset(&data_addr, 0, sizeof(data_addr));
- data_addr.sin_family = AF_INET;
- data_addr.sin_addr.s_addr = htonl((a0 << 24) | (a1 << 16) |
- (a2 << 8) | a3);
- data_addr.sin_port = htons((p0 << 8) | p1);
-
- if (connect(data, (struct sockaddr *)&data_addr,
- sizeof(data_addr)) < 0) {
- perror("ftp: connect");
- goto bad;
- }
-#if defined(IP_TOS) && defined(HAVE_SETSOCKOPT)
- on = IPTOS_THROUGHPUT;
- if (setsockopt(data, IPPROTO_IP, IP_TOS, (char *)&on,
- sizeof(int)) < 0)
- perror("ftp: setsockopt TOS (ignored)");
-#endif
- return(0);
- }
-
-noport:
- data_addr = myctladdr;
- if (sendport)
- data_addr.sin_port = 0; /* let system pick one */
- if (data != -1)
- close(data);
- data = socket(AF_INET, SOCK_STREAM, 0);
- if (data < 0) {
- warn("socket");
- if (tmpno)
- sendport = 1;
- return (1);
- }
-#if defined(SO_REUSEADDR) && defined(HAVE_SETSOCKOPT)
- if (!sendport)
- if (setsockopt(data, SOL_SOCKET, SO_REUSEADDR, (char *)&on, sizeof (on)) < 0) {
- warn("setsockopt (reuse address)");
- goto bad;
- }
-#endif
- if (bind(data, (struct sockaddr *)&data_addr, sizeof (data_addr)) < 0) {
- warn("bind");
- goto bad;
- }
-#if defined(SO_DEBUG) && defined(HAVE_SETSOCKOPT)
- if (options & SO_DEBUG &&
- setsockopt(data, SOL_SOCKET, SO_DEBUG, (char *)&on, sizeof (on)) < 0)
- warn("setsockopt (ignored)");
-#endif
- len = sizeof (data_addr);
- if (getsockname(data, (struct sockaddr *)&data_addr, &len) < 0) {
- warn("getsockname");
- goto bad;
- }
- if (listen(data, 1) < 0)
- warn("listen");
- if (sendport) {
- unsigned int a = ntohl(data_addr.sin_addr.s_addr);
- unsigned int p = ntohs(data_addr.sin_port);
- result = command("PORT %d,%d,%d,%d,%d,%d",
- (a >> 24) & 0xff,
- (a >> 16) & 0xff,
- (a >> 8) & 0xff,
- a & 0xff,
- (p >> 8) & 0xff,
- p & 0xff);
- if (result == ERROR && sendport == -1) {
- sendport = 0;
- tmpno = 1;
- goto noport;
- }
- return (result != COMPLETE);
- }
- if (tmpno)
- sendport = 1;
-#if defined(IP_TOS) && defined(HAVE_SETSOCKOPT)
- on = IPTOS_THROUGHPUT;
- if (setsockopt(data, IPPROTO_IP, IP_TOS, (char *)&on, sizeof(int)) < 0)
- warn("setsockopt TOS (ignored)");
-#endif
- return (0);
-bad:
- close(data), data = -1;
- if (tmpno)
- sendport = 1;
- return (1);
-}
-
-FILE *
-dataconn(char *lmode)
-{
- struct sockaddr_in from;
- int s, fromlen = sizeof (from), tos;
-
- if (passivemode)
- return (fdopen(data, lmode));
-
- s = accept(data, (struct sockaddr *) &from, &fromlen);
- if (s < 0) {
- warn("accept");
- close(data), data = -1;
- return (NULL);
- }
- close(data);
- data = s;
-#if defined(IP_TOS) && defined(HAVE_SETSOCKOPT)
- tos = IPTOS_THROUGHPUT;
- if (setsockopt(s, IPPROTO_IP, IP_TOS, (char *)&tos, sizeof(int)) < 0)
- warn("setsockopt TOS (ignored)");
-#endif
- return (fdopen(data, lmode));
-}
-
-void
-ptransfer(char *direction, long int bytes,
- struct timeval *t0, struct timeval *t1)
-{
- struct timeval td;
- float s;
- float bs;
- int prec;
- char *unit;
-
- if (verbose) {
- td.tv_sec = t1->tv_sec - t0->tv_sec;
- td.tv_usec = t1->tv_usec - t0->tv_usec;
- if(td.tv_usec < 0){
- td.tv_sec--;
- td.tv_usec += 1000000;
- }
- s = td.tv_sec + (td.tv_usec / 1000000.);
- bs = bytes / (s?s:1);
- if(bs >= 1048576){
- bs /= 1048576;
- unit = "M";
- prec = 2;
- }else if(bs >= 1024){
- bs /= 1024;
- unit = "k";
- prec = 1;
- }else{
- unit = "";
- prec = 0;
- }
-
- printf("%ld bytes %s in %.3g seconds (%.*f %sbyte/s)\n",
- bytes, direction, s, prec, bs, unit);
- }
-}
-
-void
-psabort(int sig)
-{
-
- abrtflag++;
-}
-
-void
-pswitch(int flag)
-{
- sighand oldintr;
- static struct comvars {
- int connect;
- char name[MaxHostNameLen];
- struct sockaddr_in mctl;
- struct sockaddr_in hctl;
- FILE *in;
- FILE *out;
- int tpe;
- int curtpe;
- int cpnd;
- int sunqe;
- int runqe;
- int mcse;
- int ntflg;
- char nti[17];
- char nto[17];
- int mapflg;
- char mi[MaxPathLen];
- char mo[MaxPathLen];
- } proxstruct, tmpstruct;
- struct comvars *ip, *op;
-
- abrtflag = 0;
- oldintr = signal(SIGINT, psabort);
- if (flag) {
- if (proxy)
- return;
- ip = &tmpstruct;
- op = &proxstruct;
- proxy++;
- } else {
- if (!proxy)
- return;
- ip = &proxstruct;
- op = &tmpstruct;
- proxy = 0;
- }
- ip->connect = connected;
- connected = op->connect;
- if (hostname) {
- strncpy(ip->name, hostname, sizeof(ip->name) - 1);
- ip->name[strlen(ip->name)] = '\0';
- } else
- ip->name[0] = 0;
- hostname = op->name;
- ip->hctl = hisctladdr;
- hisctladdr = op->hctl;
- ip->mctl = myctladdr;
- myctladdr = op->mctl;
- ip->in = cin;
- cin = op->in;
- ip->out = cout;
- cout = op->out;
- ip->tpe = type;
- type = op->tpe;
- ip->curtpe = curtype;
- curtype = op->curtpe;
- ip->cpnd = cpend;
- cpend = op->cpnd;
- ip->sunqe = sunique;
- sunique = op->sunqe;
- ip->runqe = runique;
- runique = op->runqe;
- ip->mcse = mcase;
- mcase = op->mcse;
- ip->ntflg = ntflag;
- ntflag = op->ntflg;
- strncpy(ip->nti, ntin, 16);
- (ip->nti)[strlen(ip->nti)] = '\0';
- strcpy(ntin, op->nti);
- strncpy(ip->nto, ntout, 16);
- (ip->nto)[strlen(ip->nto)] = '\0';
- strcpy(ntout, op->nto);
- ip->mapflg = mapflag;
- mapflag = op->mapflg;
- strncpy(ip->mi, mapin, MaxPathLen - 1);
- (ip->mi)[strlen(ip->mi)] = '\0';
- strcpy(mapin, op->mi);
- strncpy(ip->mo, mapout, MaxPathLen - 1);
- (ip->mo)[strlen(ip->mo)] = '\0';
- strcpy(mapout, op->mo);
- signal(SIGINT, oldintr);
- if (abrtflag) {
- abrtflag = 0;
- (*oldintr)(SIGINT);
- }
-}
-
-void
-abortpt(int sig)
-{
-
- printf("\n");
- fflush(stdout);
- ptabflg++;
- mflag = 0;
- abrtflag = 0;
- longjmp(ptabort, 1);
-}
-
-void
-proxtrans(char *cmd, char *local, char *remote)
-{
- sighand oldintr;
- int secndflag = 0, prox_type, nfnd;
- char *cmd2;
- fd_set mask;
-
- if (strcmp(cmd, "RETR"))
- cmd2 = "RETR";
- else
- cmd2 = runique ? "STOU" : "STOR";
- if ((prox_type = type) == 0) {
- if (unix_server && unix_proxy)
- prox_type = TYPE_I;
- else
- prox_type = TYPE_A;
- }
- if (curtype != prox_type)
- changetype(prox_type, 1);
- if (command("PASV") != COMPLETE) {
- printf("proxy server does not support third party transfers.\n");
- return;
- }
- pswitch(0);
- if (!connected) {
- printf("No primary connection\n");
- pswitch(1);
- code = -1;
- return;
- }
- if (curtype != prox_type)
- changetype(prox_type, 1);
- if (command("PORT %s", pasv) != COMPLETE) {
- pswitch(1);
- return;
- }
- if (setjmp(ptabort))
- goto abort;
- oldintr = signal(SIGINT, abortpt);
- if (command("%s %s", cmd, remote) != PRELIM) {
- signal(SIGINT, oldintr);
- pswitch(1);
- return;
- }
- sleep(2);
- pswitch(1);
- secndflag++;
- if (command("%s %s", cmd2, local) != PRELIM)
- goto abort;
- ptflag++;
- getreply(0);
- pswitch(0);
- getreply(0);
- signal(SIGINT, oldintr);
- pswitch(1);
- ptflag = 0;
- printf("local: %s remote: %s\n", local, remote);
- return;
-abort:
- signal(SIGINT, SIG_IGN);
- ptflag = 0;
- if (strcmp(cmd, "RETR") && !proxy)
- pswitch(1);
- else if (!strcmp(cmd, "RETR") && proxy)
- pswitch(0);
- if (!cpend && !secndflag) { /* only here if cmd = "STOR" (proxy=1) */
- if (command("%s %s", cmd2, local) != PRELIM) {
- pswitch(0);
- if (cpend)
- abort_remote((FILE *) NULL);
- }
- pswitch(1);
- if (ptabflg)
- code = -1;
- signal(SIGINT, oldintr);
- return;
- }
- if (cpend)
- abort_remote((FILE *) NULL);
- pswitch(!proxy);
- if (!cpend && !secndflag) { /* only if cmd = "RETR" (proxy=1) */
- if (command("%s %s", cmd2, local) != PRELIM) {
- pswitch(0);
- if (cpend)
- abort_remote((FILE *) NULL);
- pswitch(1);
- if (ptabflg)
- code = -1;
- signal(SIGINT, oldintr);
- return;
- }
- }
- if (cpend)
- abort_remote((FILE *) NULL);
- pswitch(!proxy);
- if (cpend) {
- FD_ZERO(&mask);
- FD_SET(fileno(cin), &mask);
- if ((nfnd = empty(&mask, 10)) <= 0) {
- if (nfnd < 0) {
- warn("abort");
- }
- if (ptabflg)
- code = -1;
- lostpeer(0);
- }
- getreply(0);
- getreply(0);
- }
- if (proxy)
- pswitch(0);
- pswitch(1);
- if (ptabflg)
- code = -1;
- signal(SIGINT, oldintr);
-}
-
-void
-reset(int argc, char **argv)
-{
- fd_set mask;
- int nfnd = 1;
-
- FD_ZERO(&mask);
- while (nfnd > 0) {
- FD_SET(fileno(cin), &mask);
- if ((nfnd = empty(&mask,0)) < 0) {
- warn("reset");
- code = -1;
- lostpeer(0);
- }
- else if (nfnd) {
- getreply(0);
- }
- }
-}
-
-char *
-gunique(char *local)
-{
- static char new[MaxPathLen];
- char *cp = strrchr(local, '/');
- int d, count=0;
- char ext = '1';
-
- if (cp)
- *cp = '\0';
- d = access(cp ? local : ".", 2);
- if (cp)
- *cp = '/';
- if (d < 0) {
- warn("local: %s", local);
- return NULL;
- }
- strcpy(new, local);
- cp = new + strlen(new);
- *cp++ = '.';
- while (!d) {
- if (++count == 100) {
- printf("runique: can't find unique file name.\n");
- return NULL;
- }
- *cp++ = ext;
- *cp = '\0';
- if (ext == '9')
- ext = '0';
- else
- ext++;
- if ((d = access(new, 0)) < 0)
- break;
- if (ext != '0')
- cp--;
- else if (*(cp - 2) == '.')
- *(cp - 1) = '1';
- else {
- *(cp - 2) = *(cp - 2) + 1;
- cp--;
- }
- }
- return (new);
-}
-
-void
-abort_remote(FILE *din)
-{
- char buf[BUFSIZ];
- int nfnd;
- fd_set mask;
-
- /*
- * send IAC in urgent mode instead of DM because 4.3BSD places oob mark
- * after urgent byte rather than before as is protocol now
- */
- snprintf(buf, sizeof(buf), "%c%c%c", IAC, IP, IAC);
- if (send(fileno(cout), buf, 3, MSG_OOB) != 3)
- warn("abort");
- fprintf(cout,"%cABOR\r\n", DM);
- fflush(cout);
- FD_ZERO(&mask);
- FD_SET(fileno(cin), &mask);
- if (din) {
- FD_SET(fileno(din), &mask);
- }
- if ((nfnd = empty(&mask, 10)) <= 0) {
- if (nfnd < 0) {
- warn("abort");
- }
- if (ptabflg)
- code = -1;
- lostpeer(0);
- }
- if (din && FD_ISSET(fileno(din), &mask)) {
- while (read(fileno(din), buf, BUFSIZ) > 0)
- /* LOOP */;
- }
- if (getreply(0) == ERROR && code == 552) {
- /* 552 needed for nic style abort */
- getreply(0);
- }
- getreply(0);
-}
diff --git a/appl/ftp/ftp/ftp_locl.h b/appl/ftp/ftp/ftp_locl.h
deleted file mode 100644
index ce9c35d3756bc8701d2c9a7666cfa5172bd1054c..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/ftp_locl.h
+++ /dev/null
@@ -1,143 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifndef __FTP_LOCL_H__
-#define __FTP_LOCL_H__
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-
-#ifdef HAVE_PWD_H
-#include <pwd.h>
-#endif
-#include <signal.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <stdarg.h>
-#include <string.h>
-#ifdef TIME_WITH_SYS_TIME
-#include <sys/time.h>
-#include <time.h>
-#elif defined(HAVE_SYS_TIME_H)
-#include <sys/time.h>
-#else
-#include <time.h>
-#endif
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
-
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_PARAM_H
-#include <sys/param.h>
-#endif
-#ifdef HAVE_SYS_RESOURCE_H
-#include <sys/resource.h>
-#endif
-#ifdef HAVE_SYS_WAIT_H
-#include <sys/wait.h>
-#endif
-#ifdef HAVE_SYS_STAT_H
-#include <sys/stat.h>
-#endif
-#ifdef HAVE_SYS_SOCKET_H
-#include <sys/socket.h>
-#endif
-
-#ifdef HAVE_NETINET_IN_H
-#include <netinet/in.h>
-#endif
-#ifdef HAVE_NETINET_IN_SYSTM_H
-#include <netinet/in_systm.h>
-#endif
-#ifdef HAVE_NETINET_IP_H
-#include <netinet/ip.h>
-#endif
-
-#ifdef HAVE_ARPA_FTP_H
-#include <arpa/ftp.h>
-#endif
-#ifdef HAVE_ARPA_INET_H
-#include <arpa/inet.h>
-#endif
-#ifdef HAVE_ARPA_TELNET_H
-#include <arpa/telnet.h>
-#endif
-
-#include <errno.h>
-#include <ctype.h>
-#include <glob.h>
-#ifdef HAVE_NETDB_H
-#include <netdb.h>
-#endif
-
-#ifdef HAVE_SYS_MMAN_H
-#include <sys/mman.h>
-#endif
-
-#include <err.h>
-
-#ifdef SOCKS
-#include <socks.h>
-extern int LIBPREFIX(fclose) __P((FILE *));
-#endif
-
-#include "ftp_var.h"
-#include "extern.h"
-#include "common.h"
-#include "pathnames.h"
-
-#include <des.h>
-
-#include <krb.h>
-
-#include "krb4.h"
-
-#include "roken.h"
-
-#if defined(__sun__) && !defined(__svr4)
-int fclose(FILE*);
-int pclose(FILE*);
-#endif
-
-#endif /* __FTP_LOCL_H__ */
diff --git a/appl/ftp/ftp/ftp_var.h b/appl/ftp/ftp/ftp_var.h
deleted file mode 100644
index ffac59a50fa9aaf96b39a11bf88135c3a21566c2..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/ftp_var.h
+++ /dev/null
@@ -1,127 +0,0 @@
-/*
- * Copyright (c) 1985, 1989, 1993, 1994
- * 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.
- *
- * @(#)ftp_var.h 8.4 (Berkeley) 10/9/94
- */
-
-/*
- * FTP global variables.
- */
-
-#ifdef HAVE_SYS_PARAM_H
-#include <sys/param.h>
-#endif
-#include <setjmp.h>
-
-/*
- * Options and other state info.
- */
-extern int trace; /* trace packets exchanged */
-extern int hash; /* print # for each buffer transferred */
-extern int sendport; /* use PORT cmd for each data connection */
-extern int verbose; /* print messages coming back from server */
-extern int connected; /* connected to server */
-extern int fromatty; /* input is from a terminal */
-extern int interactive; /* interactively prompt on m* cmds */
-extern int debug; /* debugging level */
-extern int bell; /* ring bell on cmd completion */
-extern int doglob; /* glob local file names */
-extern int autologin; /* establish user account on connection */
-extern int proxy; /* proxy server connection active */
-extern int proxflag; /* proxy connection exists */
-extern int sunique; /* store files on server with unique name */
-extern int runique; /* store local files with unique name */
-extern int mcase; /* map upper to lower case for mget names */
-extern int ntflag; /* use ntin ntout tables for name translation */
-extern int mapflag; /* use mapin mapout templates on file names */
-extern int code; /* return/reply code for ftp command */
-extern int crflag; /* if 1, strip car. rets. on ascii gets */
-extern char pasv[64]; /* passive port for proxy data connection */
-extern int passivemode; /* passive mode enabled */
-extern char *altarg; /* argv[1] with no shell-like preprocessing */
-extern char ntin[17]; /* input translation table */
-extern char ntout[17]; /* output translation table */
-extern char mapin[MaxPathLen]; /* input map template */
-extern char mapout[MaxPathLen]; /* output map template */
-extern char typename[32]; /* name of file transfer type */
-extern int type; /* requested file transfer type */
-extern int curtype; /* current file transfer type */
-extern char structname[32]; /* name of file transfer structure */
-extern int stru; /* file transfer structure */
-extern char formname[32]; /* name of file transfer format */
-extern int form; /* file transfer format */
-extern char modename[32]; /* name of file transfer mode */
-extern int mode; /* file transfer mode */
-extern char bytename[32]; /* local byte size in ascii */
-extern int bytesize; /* local byte size in binary */
-
-extern char *hostname; /* name of host connected to */
-extern int unix_server; /* server is unix, can use binary for ascii */
-extern int unix_proxy; /* proxy is unix, can use binary for ascii */
-
-extern jmp_buf toplevel; /* non-local goto stuff for cmd scanner */
-
-extern char line[200]; /* input line buffer */
-extern char *stringbase; /* current scan point in line buffer */
-extern char argbuf[200]; /* argument storage buffer */
-extern char *argbase; /* current storage point in arg buffer */
-extern int margc; /* count of arguments on input line */
-extern char **margv; /* args parsed from input line */
-extern int margvlen; /* how large margv is currently */
-extern int cpend; /* flag: if != 0, then pending server reply */
-extern int mflag; /* flag: if != 0, then active multi command */
-
-extern int options; /* used during socket creation */
-
-/*
- * Format of command table.
- */
-struct cmd {
- char *c_name; /* name of command */
- char *c_help; /* help string */
- char c_bell; /* give bell when command completes */
- char c_conn; /* must be connected to use command */
- char c_proxy; /* proxy server may execute */
- void (*c_handler) (int, char **); /* function to call */
-};
-
-struct macel {
- char mac_name[9]; /* macro name */
- char *mac_start; /* start of macro in macbuf */
- char *mac_end; /* end of macro in macbuf */
-};
-
-extern int macnum; /* number of defined macros */
-extern struct macel macros[16];
-extern char macbuf[4096];
-
-
diff --git a/appl/ftp/ftp/globals.c b/appl/ftp/ftp/globals.c
deleted file mode 100644
index d51ffeef82e7cc1248f4ca1c8b9a9fc11b97537e..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/globals.c
+++ /dev/null
@@ -1,76 +0,0 @@
-#include "ftp_locl.h"
-RCSID("$Id$");
-
-/*
- * Options and other state info.
- */
-int trace; /* trace packets exchanged */
-int hash; /* print # for each buffer transferred */
-int sendport; /* use PORT cmd for each data connection */
-int verbose; /* print messages coming back from server */
-int connected; /* connected to server */
-int fromatty; /* input is from a terminal */
-int interactive; /* interactively prompt on m* cmds */
-int debug; /* debugging level */
-int bell; /* ring bell on cmd completion */
-int doglob; /* glob local file names */
-int autologin; /* establish user account on connection */
-int proxy; /* proxy server connection active */
-int proxflag; /* proxy connection exists */
-int sunique; /* store files on server with unique name */
-int runique; /* store local files with unique name */
-int mcase; /* map upper to lower case for mget names */
-int ntflag; /* use ntin ntout tables for name translation */
-int mapflag; /* use mapin mapout templates on file names */
-int code; /* return/reply code for ftp command */
-int crflag; /* if 1, strip car. rets. on ascii gets */
-char pasv[64]; /* passive port for proxy data connection */
-int passivemode; /* passive mode enabled */
-char *altarg; /* argv[1] with no shell-like preprocessing */
-char ntin[17]; /* input translation table */
-char ntout[17]; /* output translation table */
-char mapin[MaxPathLen]; /* input map template */
-char mapout[MaxPathLen]; /* output map template */
-char typename[32]; /* name of file transfer type */
-int type; /* requested file transfer type */
-int curtype; /* current file transfer type */
-char structname[32]; /* name of file transfer structure */
-int stru; /* file transfer structure */
-char formname[32]; /* name of file transfer format */
-int form; /* file transfer format */
-char modename[32]; /* name of file transfer mode */
-int mode; /* file transfer mode */
-char bytename[32]; /* local byte size in ascii */
-int bytesize; /* local byte size in binary */
-
-char *hostname; /* name of host connected to */
-int unix_server; /* server is unix, can use binary for ascii */
-int unix_proxy; /* proxy is unix, can use binary for ascii */
-
-jmp_buf toplevel; /* non-local goto stuff for cmd scanner */
-
-char line[200]; /* input line buffer */
-char *stringbase; /* current scan point in line buffer */
-char argbuf[200]; /* argument storage buffer */
-char *argbase; /* current storage point in arg buffer */
-int margc; /* count of arguments on input line */
-char **margv; /* args parsed from input line */
-int margvlen; /* how large margv is currently */
-int cpend; /* flag: if != 0, then pending server reply */
-int mflag; /* flag: if != 0, then active multi command */
-
-int options; /* used during socket creation */
-
-/*
- * Format of command table.
- */
-
-int macnum; /* number of defined macros */
-struct macel macros[16];
-char macbuf[4096];
-
-char username[32];
-
-/* these are set in ruserpass */
-char myhostname[MaxHostNameLen];
-char *mydomain;
diff --git a/appl/ftp/ftp/kauth.c b/appl/ftp/ftp/kauth.c
deleted file mode 100644
index 1295d8cd1617e375d2104a1b9124ea8eedaf75ca..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/kauth.c
+++ /dev/null
@@ -1,193 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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 "ftp_locl.h"
-RCSID("$Id$");
-
-void
-kauth(int argc, char **argv)
-{
- int ret;
- char buf[1024];
- des_cblock key;
- des_key_schedule schedule;
- KTEXT_ST tkt, tktcopy;
- char *name;
- char *p;
- int overbose;
- char passwd[100];
- int tmp;
-
- if(argc > 2){
- printf("usage: %s [principal]\n", argv[0]);
- code = -1;
- return;
- }
- if(argc == 2)
- name = argv[1];
- else
- name = username;
-
- overbose = verbose;
- verbose = 0;
-
- ret = command("SITE KAUTH %s", name);
- if(ret != CONTINUE){
- verbose = overbose;
- code = -1;
- return;
- }
- verbose = overbose;
- p = strstr(reply_string, "T=");
- if(!p){
- printf("Bad reply from server.\n");
- code = -1;
- return;
- }
- p += 2;
- tmp = base64_decode(p, &tkt.dat);
- if(tmp < 0){
- printf("Failed to decode base64 in reply.\n");
- code = -1;
- return;
- }
- tkt.length = tmp;
- tktcopy.length = tkt.length;
-
- p = strstr(reply_string, "P=");
- if(!p){
- printf("Bad reply from server.\n");
- verbose = overbose;
- code = -1;
- return;
- }
- name = p + 2;
- for(; *p && *p != ' ' && *p != '\r' && *p != '\n'; p++);
- *p = 0;
-
- snprintf(buf, sizeof(buf), "Password for %s:", name);
- if (des_read_pw_string (passwd, sizeof(passwd)-1, buf, 0))
- *passwd = '\0';
- des_string_to_key (passwd, &key);
-
- des_key_sched(&key, schedule);
-
- des_pcbc_encrypt((des_cblock*)tkt.dat, (des_cblock*)tktcopy.dat,
- tkt.length,
- schedule, &key, DES_DECRYPT);
- if (strcmp ((char*)tktcopy.dat + 8,
- KRB_TICKET_GRANTING_TICKET) != 0) {
- afs_string_to_key (passwd, krb_realmofhost(hostname), &key);
- des_key_sched (&key, schedule);
- des_pcbc_encrypt((des_cblock*)tkt.dat, (des_cblock*)tktcopy.dat,
- tkt.length,
- schedule, &key, DES_DECRYPT);
- }
- memset(key, 0, sizeof(key));
- memset(schedule, 0, sizeof(schedule));
- memset(passwd, 0, sizeof(passwd));
- if(base64_encode(tktcopy.dat, tktcopy.length, &p) < 0) {
- printf("Out of memory base64-encoding.\n");
- code = -1;
- return;
- }
- memset (tktcopy.dat, 0, tktcopy.length);
- ret = command("SITE KAUTH %s %s", name, p);
- free(p);
- if(ret != COMPLETE){
- code = -1;
- return;
- }
- code = 0;
-}
-
-void
-klist(int argc, char **argv)
-{
- int ret;
- if(argc != 1){
- printf("usage: %s\n", argv[0]);
- code = -1;
- return;
- }
-
- ret = command("SITE KLIST");
- code = (ret == COMPLETE);
-}
-
-void
-kdestroy(int argc, char **argv)
-{
- int ret;
- if (argc != 1) {
- printf("usage: %s\n", argv[0]);
- code = -1;
- return;
- }
- ret = command("SITE KDESTROY");
- code = (ret == COMPLETE);
-}
-
-void
-krbtkfile(int argc, char **argv)
-{
- int ret;
- if(argc != 2) {
- printf("usage: %s tktfile\n", argv[0]);
- code = -1;
- return;
- }
- ret = command("SITE KRBTKFILE %s", argv[1]);
- code = (ret == COMPLETE);
-}
-
-void
-afslog(int argc, char **argv)
-{
- int ret;
- if(argc > 2) {
- printf("usage: %s [cell]\n", argv[0]);
- code = -1;
- return;
- }
- if(argc == 2)
- ret = command("SITE AFSLOG %s", argv[1]);
- else
- ret = command("SITE AFSLOG");
- code = (ret == COMPLETE);
-}
diff --git a/appl/ftp/ftp/krb4.c b/appl/ftp/ftp/krb4.c
deleted file mode 100644
index 7727458e1835776a47b59d836171faf2f1dedfaa..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/krb4.c
+++ /dev/null
@@ -1,575 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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 "ftp_locl.h"
-
-RCSID("$Id$");
-
-static KTEXT_ST krb4_adat;
-
-static des_cblock key;
-static des_key_schedule schedule;
-
-static char *data_buffer;
-
-extern struct sockaddr_in hisctladdr, myctladdr;
-
-int auth_complete;
-
-static int command_prot;
-
-static int auth_pbsz;
-static int data_prot;
-
-static int request_data_prot;
-
-
-static struct {
- int level;
- char *name;
-} level_names[] = {
- { prot_clear, "clear" },
- { prot_safe, "safe" },
- { prot_confidential, "confidential" },
- { prot_private, "private" }
-};
-
-static char *level_to_name(int level)
-{
- int i;
- for(i = 0; i < sizeof(level_names) / sizeof(level_names[0]); i++)
- if(level_names[i].level == level)
- return level_names[i].name;
- return "unknown";
-}
-
-static int name_to_level(char *name)
-{
- int i;
- for(i = 0; i < sizeof(level_names) / sizeof(level_names[0]); i++)
- if(!strncasecmp(level_names[i].name, name, strlen(name)))
- return level_names[i].level;
- return -1;
-}
-
-void sec_status(void)
-{
- if(auth_complete){
- printf("Using KERBEROS_V4 for authentication.\n");
-
- command_prot = prot_private; /* this variable is not used */
-
- printf("Using %s command channel.\n",
- level_to_name(command_prot));
-
- printf("Using %s data channel.\n",
- level_to_name(data_prot));
- if(auth_pbsz > 0)
- printf("Protection buffer size: %d.\n", auth_pbsz);
- }else{
- printf("Not using any security mechanism.\n");
- }
-}
-
-static int
-sec_prot_internal(int level)
-{
- int ret;
- char *p;
- int s = 1048576;
-
- int old_verbose = verbose;
- verbose = 0;
-
- if(!auth_complete){
- printf("No security data exchange has taken place.\n");
- return -1;
- }
-
- if(level){
- ret = command("PBSZ %d", s);
- if(ret != COMPLETE){
- printf("Failed to set protection buffer size.\n");
- return -1;
- }
- auth_pbsz = s;
- p = strstr(reply_string, "PBSZ=");
- if(p)
- sscanf(p, "PBSZ=%d", &s);
- if(s < auth_pbsz)
- auth_pbsz = s;
- if(data_buffer)
- free(data_buffer);
- data_buffer = malloc(auth_pbsz);
- }
- verbose = old_verbose;
- ret = command("PROT %c", level["CSEP"]); /* XXX :-) */
- if(ret != COMPLETE){
- printf("Failed to set protection level.\n");
- return -1;
- }
-
- data_prot = level;
- return 0;
-}
-
-
-void
-sec_prot(int argc, char **argv)
-{
- int level = -1;
-
- if(argc != 2){
- printf("usage: %s (clear | safe | confidential | private)\n",
- argv[0]);
- code = -1;
- return;
- }
- if(!auth_complete){
- printf("No security data exchange has taken place.\n");
- code = -1;
- return;
- }
- level = name_to_level(argv[1]);
-
- if(level == -1){
- printf("usage: %s (clear | safe | confidential | private)\n",
- argv[0]);
- code = -1;
- return;
- }
-
- if(level == prot_confidential){
- printf("Confidential protection is not defined with Kerberos.\n");
- code = -1;
- return;
- }
-
- if(sec_prot_internal(level) < 0){
- code = -1;
- return;
- }
- code = 0;
-}
-
-void
-sec_set_protection_level(void)
-{
- if(auth_complete && data_prot != request_data_prot)
- sec_prot_internal(request_data_prot);
-}
-
-
-int
-sec_request_prot(char *level)
-{
- int l = name_to_level(level);
- if(l == -1)
- return -1;
- request_data_prot = l;
- return 0;
-}
-
-
-int sec_getc(FILE *F)
-{
- if(auth_complete && data_prot)
- return krb4_getc(F);
- else
- return getc(F);
-}
-
-int sec_read(int fd, void *data, int length)
-{
- if(auth_complete && data_prot)
- return krb4_read(fd, data, length);
- else
- return read(fd, data, length);
-}
-
-static int
-krb4_recv(int fd)
-{
- int len;
- MSG_DAT m;
- int kerror;
-
- krb_net_read(fd, &len, sizeof(len));
- len = ntohl(len);
- krb_net_read(fd, data_buffer, len);
- if(data_prot == prot_safe)
- kerror = krb_rd_safe(data_buffer, len, &key,
- &hisctladdr, &myctladdr, &m);
- else
- kerror = krb_rd_priv(data_buffer, len, schedule, &key,
- &hisctladdr, &myctladdr, &m);
- if(kerror){
- return -1;
- }
- memmove(data_buffer, m.app_data, m.app_length);
- return m.app_length;
-}
-
-
-int krb4_getc(FILE *F)
-{
- static int bytes;
- static int index;
- if(bytes == 0){
- bytes = krb4_recv(fileno(F));
- index = 0;
- }
- if(bytes){
- bytes--;
- return (unsigned char)data_buffer[index++];
- }
- return EOF;
-}
-
-int krb4_read(int fd, char *data, int length)
-{
- static int left;
- static int index;
- static int eof;
- int len = left;
- int rx = 0;
-
- if(eof){
- eof = 0;
- return 0;
- }
-
- if(left){
- if(length < len)
- len = length;
- memmove(data, data_buffer + index, len);
- length -= len;
- index += len;
- rx += len;
- left -= len;
- }
-
- while(length){
- len = krb4_recv(fd);
- if(len == 0){
- if(rx)
- eof = 1;
- return rx;
- }
- if(len > length){
- left = len - length;
- len = index = length;
- }
- memmove(data, data_buffer, len);
- length -= len;
- data += len;
- rx += len;
- }
- return rx;
-}
-
-
-static int
-krb4_encode(char *from, char *to, int length)
-{
- if(data_prot == prot_safe)
- return krb_mk_safe(from, to, length, &key,
- &myctladdr, &hisctladdr);
- else
- return krb_mk_priv(from, to, length, schedule, &key,
- &myctladdr, &hisctladdr);
-}
-
-static int
-krb4_overhead(int len)
-{
- if(data_prot == prot_safe)
- return 31;
- else
- return 26;
-}
-
-static char p_buf[1024];
-static int p_index;
-
-int
-sec_putc(int c, FILE *F)
-{
- if(data_prot){
- if((c == '\n' && p_index) || p_index == sizeof(p_buf)){
- sec_write(fileno(F), p_buf, p_index);
- p_index = 0;
- }
- p_buf[p_index++] = c;
- return c;
- }
- return putc(c, F);
-}
-
-static int
-sec_send(int fd, char *from, int length)
-{
- int bytes;
- bytes = krb4_encode(from, data_buffer, length);
- bytes = htonl(bytes);
- krb_net_write(fd, &bytes, sizeof(bytes));
- krb_net_write(fd, data_buffer, ntohl(bytes));
- return length;
-}
-
-int
-sec_fflush(FILE *F)
-{
- if(data_prot){
- if(p_index){
- sec_write(fileno(F), p_buf, p_index);
- p_index = 0;
- }
- sec_send(fileno(F), NULL, 0);
- }
- fflush(F);
- return 0;
-}
-
-int
-sec_write(int fd, char *data, int length)
-{
- int len = auth_pbsz;
- int tx = 0;
-
- if(data_prot == prot_clear)
- return write(fd, data, length);
-
- len -= krb4_overhead(len);
- while(length){
- if(length < len)
- len = length;
- sec_send(fd, data, len);
- length -= len;
- data += len;
- tx += len;
- }
- return tx;
-}
-
-static int
-do_auth(char *service, char *host, int checksum)
-{
- int ret;
- CREDENTIALS cred;
- char sname[SNAME_SZ], inst[INST_SZ], realm[REALM_SZ];
- strcpy(sname, service);
- strcpy(inst, krb_get_phost(host));
- strcpy(realm, krb_realmofhost(host));
- ret = krb_mk_req(&krb4_adat, sname, inst, realm, checksum);
- if(ret)
- return ret;
- strcpy(sname, service);
- strcpy(inst, krb_get_phost(host));
- strcpy(realm, krb_realmofhost(host));
- ret = krb_get_cred(sname, inst, realm, &cred);
- memmove(&key, &cred.session, sizeof(des_cblock));
- des_key_sched(&key, schedule);
- memset(&cred, 0, sizeof(cred));
- return ret;
-}
-
-
-int
-do_klogin(char *host)
-{
- int ret;
- char *p;
- int len;
- char adat[1024];
- MSG_DAT msg_data;
- int checksum;
-
- int old_verbose = verbose;
-
- verbose = 0;
- printf("Trying KERBEROS_V4...\n");
- ret = command("AUTH KERBEROS_V4");
- if(ret != CONTINUE){
- if(code == 504){
- printf("Kerberos 4 is not supported by the server.\n");
- }else if(code == 534){
- printf("KERBEROS_V4 rejected as security mechanism.\n");
- }else if(ret == ERROR)
- printf("The server doesn't understand the FTP "
- "security extensions.\n");
- verbose = old_verbose;
- return -1;
- }
-
- checksum = getpid();
- ret = do_auth("ftp", host, checksum);
- if(ret == KDC_PR_UNKNOWN)
- ret = do_auth("rcmd", host, checksum);
- if(ret){
- printf("%s\n", krb_get_err_text(ret));
- verbose = old_verbose;
- return ret;
- }
-
- if(base64_encode(krb4_adat.dat, krb4_adat.length, &p) < 0) {
- printf("Out of memory base64-encoding.\n");
- verbose = old_verbose;
- return -1;
- }
- ret = command("ADAT %s", p);
- free(p);
-
- if(ret != COMPLETE){
- printf("Server didn't accept auth data.\n");
- verbose = old_verbose;
- return -1;
- }
-
- p = strstr(reply_string, "ADAT=");
- if(!p){
- printf("Remote host didn't send adat reply.\n");
- verbose = old_verbose;
- return -1;
- }
- p+=5;
- len = base64_decode(p, adat);
- if(len < 0){
- printf("Failed to decode base64 from server.\n");
- verbose = old_verbose;
- return -1;
- }
- ret = krb_rd_safe(adat, len, &key,
- &hisctladdr, &myctladdr, &msg_data);
- if(ret){
- printf("Error reading reply from server: %s.\n",
- krb_get_err_text(ret));
- verbose = old_verbose;
- return -1;
- }
- {
- /* the draft doesn't tell what size the return has */
- int i;
- u_int32_t cs = 0;
- for(i = 0; i < msg_data.app_length; i++)
- cs = (cs<<8) + msg_data.app_data[i];
- if(cs - checksum != 1){
- printf("Bad checksum returned from server.\n");
- verbose = old_verbose;
- return -1;
- }
- }
- auth_complete = 1;
- verbose = old_verbose;
- return 0;
-}
-
-void
-krb4_quit(void)
-{
- auth_complete = 0;
- data_prot = 0;
-}
-
-int
-krb4_write_enc(FILE *F, char *fmt, va_list ap)
-{
- int len;
- char *p;
- char buf[1024];
- char enc[1024];
-
- vsnprintf(buf, sizeof(buf), fmt, ap);
- len = krb_mk_priv(buf, enc, strlen(buf), schedule, &key,
- &myctladdr, &hisctladdr);
- if(base64_encode(enc, len, &p) < 0) {
- return -1;
- }
-
- fprintf(F, "ENC %s", p);
- free (p);
- return 0;
-}
-
-
-int krb4_read_msg(char *s, int priv)
-{
- int len;
- int ret;
- char buf[1024];
- MSG_DAT m;
- int code;
-
- len = base64_decode(s + 4, buf);
- if(priv)
- ret = krb_rd_priv(buf, len, schedule, &key,
- &hisctladdr, &myctladdr, &m);
- else
- ret = krb_rd_safe(buf, len, &key, &hisctladdr, &myctladdr, &m);
- if(ret){
- printf("%s\n", krb_get_err_text(ret));
- return -1;
- }
-
- m.app_data[m.app_length] = 0;
- if(m.app_data[3] == '-')
- code = 0;
- else
- sscanf((char*)m.app_data, "%d", &code);
- strncpy(s, (char*)m.app_data, strlen((char*)m.app_data));
-
- s[m.app_length] = 0;
- len = strlen(s);
- if(s[len-1] == '\n')
- s[len-1] = 0;
-
- return code;
-}
-
-int
-krb4_read_mic(char *s)
-{
- return krb4_read_msg(s, 0);
-}
-
-int
-krb4_read_enc(char *s)
-{
- return krb4_read_msg(s, 1);
-}
-
diff --git a/appl/ftp/ftp/krb4.h b/appl/ftp/ftp/krb4.h
deleted file mode 100644
index 3ef2c67efbd41c1f735bb768c16993594090861c..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/krb4.h
+++ /dev/null
@@ -1,84 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifndef __KRB4_H__
-#define __KRB4_H__
-
-#include <stdio.h>
-#include <stdarg.h>
-
-extern int auth_complete;
-
-void sec_status(void);
-
-enum { prot_clear, prot_safe, prot_confidential, prot_private };
-
-void sec_prot(int, char**);
-
-int sec_getc(FILE *F);
-int sec_putc(int c, FILE *F);
-int sec_fflush(FILE *F);
-int sec_read(int fd, void *data, int length);
-int sec_write(int fd, char *data, int length);
-
-int krb4_getc(FILE *F);
-int krb4_read(int fd, char *data, int length);
-
-
-
-void sec_set_protection_level(void);
-int sec_request_prot(char *level);
-
-void kauth(int, char **);
-void klist(int, char **);
-void kdestroy(int, char **);
-void krbtkfile(int, char **);
-void afslog(int, char **);
-
-void krb4_quit(void);
-
-int krb4_write_enc(FILE *F, char *fmt, va_list ap);
-int krb4_read_msg(char *s, int priv);
-int krb4_read_mic(char *s);
-int krb4_read_enc(char *s);
-
-int do_klogin(char *host);
-
-#endif /* __KRB4_H__ */
diff --git a/appl/ftp/ftp/main.c b/appl/ftp/ftp/main.c
deleted file mode 100644
index d1dfcaf0b1758dd6c6cb6d081250ac281d72ebf5..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/main.c
+++ /dev/null
@@ -1,543 +0,0 @@
-/*
- * Copyright (c) 1985, 1989, 1993, 1994
- * 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.
- */
-
-/*
- * FTP User Program -- Command Interface.
- */
-
-#include "ftp_locl.h"
-RCSID("$Id$");
-
-int
-main(int argc, char **argv)
-{
- int ch, top;
- struct passwd *pw = NULL;
- char homedir[MaxPathLen];
- struct servent *sp;
-
- set_progname(argv[0]);
-
- sp = getservbyname("ftp", "tcp");
- if (sp == 0)
- errx(1, "ftp/tcp: unknown service");
- doglob = 1;
- interactive = 1;
- autologin = 1;
-
- while ((ch = getopt(argc, argv, "dgintv")) != EOF) {
- switch (ch) {
- case 'd':
- options |= SO_DEBUG;
- debug++;
- break;
-
- case 'g':
- doglob = 0;
- break;
-
- case 'i':
- interactive = 0;
- break;
-
- case 'n':
- autologin = 0;
- break;
-
- case 't':
- trace++;
- break;
-
- case 'v':
- verbose++;
- break;
-
- default:
- fprintf(stderr,
- "usage: ftp [-dgintv] [host [port]]\n");
- exit(1);
- }
- }
- argc -= optind;
- argv += optind;
-
- fromatty = isatty(fileno(stdin));
- if (fromatty)
- verbose++;
- cpend = 0; /* no pending replies */
- proxy = 0; /* proxy not active */
- passivemode = 0; /* passive mode not active */
- crflag = 1; /* strip c.r. on ascii gets */
- sendport = -1; /* not using ports */
- /*
- * Set up the home directory in case we're globbing.
- */
- pw = k_getpwuid(getuid());
- if (pw != NULL) {
- home = homedir;
- strcpy(home, pw->pw_dir);
- }
- if (argc > 0) {
- char *xargv[5];
-
- if (setjmp(toplevel))
- exit(0);
- signal(SIGINT, intr);
- signal(SIGPIPE, lostpeer);
- xargv[0] = (char*)__progname;
- xargv[1] = argv[0];
- xargv[2] = argv[1];
- xargv[3] = argv[2];
- xargv[4] = NULL;
- setpeer(argc+1, xargv);
- }
- if(setjmp(toplevel) == 0)
- top = 1;
- else
- top = 0;
- if (top) {
- signal(SIGINT, intr);
- signal(SIGPIPE, lostpeer);
- }
- for (;;) {
- cmdscanner(top);
- top = 1;
- }
-}
-
-void
-intr(int sig)
-{
-
- longjmp(toplevel, 1);
-}
-
-#ifndef SHUT_RDWR
-#define SHUT_RDWR 2
-#endif
-
-RETSIGTYPE
-lostpeer(int sig)
-{
-
- if (connected) {
- if (cout != NULL) {
- shutdown(fileno(cout), SHUT_RDWR);
- fclose(cout);
- cout = NULL;
- }
- if (data >= 0) {
- shutdown(data, SHUT_RDWR);
- close(data);
- data = -1;
- }
- connected = 0;
- }
- pswitch(1);
- if (connected) {
- if (cout != NULL) {
- shutdown(fileno(cout), SHUT_RDWR);
- fclose(cout);
- cout = NULL;
- }
- connected = 0;
- }
- proxflag = 0;
- pswitch(0);
- krb4_quit();
- SIGRETURN(0);
-}
-
-/*
-char *
-tail(filename)
- char *filename;
-{
- char *s;
-
- while (*filename) {
- s = strrchr(filename, '/');
- if (s == NULL)
- break;
- if (s[1])
- return (s + 1);
- *s = '\0';
- }
- return (filename);
-}
-*/
-
-#ifndef HAVE_READLINE
-
-static char *
-readline(char *prompt)
-{
- char buf[BUFSIZ];
- printf ("%s", prompt);
- fflush (stdout);
- if(fgets(buf, sizeof(buf), stdin) == NULL)
- return NULL;
- if (buf[strlen(buf) - 1] == '\n')
- buf[strlen(buf) - 1] = '\0';
- return strdup(buf);
-}
-
-static void
-add_history(char *p)
-{
-}
-
-#else
-
-/* These should not really be here */
-
-char *readline(char *);
-void add_history(char *);
-
-#endif
-
-/*
- * Command parser.
- */
-void
-cmdscanner(int top)
-{
- struct cmd *c;
- int l;
-
- if (!top)
- putchar('\n');
- for (;;) {
- if (fromatty) {
- char *p;
- p = readline("ftp> ");
- if(p == NULL)
- quit(0, 0);
- strncpy(line, p, sizeof(line));
- line[sizeof(line) - 1] = 0;
- add_history(p);
- free(p);
- } else{
- if (fgets(line, sizeof line, stdin) == NULL)
- quit(0, 0);
- }
- /* XXX will break on long lines */
- l = strlen(line);
- if (l == 0)
- break;
- if (line[--l] == '\n') {
- if (l == 0)
- break;
- line[l] = '\0';
- } else if (l == sizeof(line) - 2) {
- printf("sorry, input line too long\n");
- while ((l = getchar()) != '\n' && l != EOF)
- /* void */;
- break;
- } /* else it was a line without a newline */
- makeargv();
- if (margc == 0) {
- continue;
- }
- c = getcmd(margv[0]);
- if (c == (struct cmd *)-1) {
- printf("?Ambiguous command\n");
- continue;
- }
- if (c == 0) {
- printf("?Invalid command\n");
- continue;
- }
- if (c->c_conn && !connected) {
- printf("Not connected.\n");
- continue;
- }
- (*c->c_handler)(margc, margv);
- if (bell && c->c_bell)
- putchar('\007');
- if (c->c_handler != help)
- break;
- }
- signal(SIGINT, intr);
- signal(SIGPIPE, lostpeer);
-}
-
-struct cmd *
-getcmd(char *name)
-{
- char *p, *q;
- struct cmd *c, *found;
- int nmatches, longest;
-
- longest = 0;
- nmatches = 0;
- found = 0;
- for (c = cmdtab; (p = c->c_name); c++) {
- for (q = name; *q == *p++; q++)
- if (*q == 0) /* exact match? */
- return (c);
- if (!*q) { /* the name was a prefix */
- if (q - name > longest) {
- longest = q - name;
- nmatches = 1;
- found = c;
- } else if (q - name == longest)
- nmatches++;
- }
- }
- if (nmatches > 1)
- return ((struct cmd *)-1);
- return (found);
-}
-
-/*
- * Slice a string up into argc/argv.
- */
-
-int slrflag;
-
-void
-makeargv(void)
-{
- char **argp;
-
- argp = margv;
- stringbase = line; /* scan from first of buffer */
- argbase = argbuf; /* store from first of buffer */
- slrflag = 0;
- for (margc = 0; ; margc++) {
- /* Expand array if necessary */
- if (margc == margvlen) {
- margv = (margvlen == 0)
- ? (char **)malloc(20 * sizeof(char *))
- : (char **)realloc(margv,
- (margvlen + 20)*sizeof(char *));
- if (margv == NULL)
- errx(1, "cannot realloc argv array");
- margvlen += 20;
- argp = margv + margc;
- }
-
- if ((*argp++ = slurpstring()) == NULL)
- break;
- }
-
-}
-
-/*
- * Parse string into argbuf;
- * implemented with FSM to
- * handle quoting and strings
- */
-char *
-slurpstring(void)
-{
- int got_one = 0;
- char *sb = stringbase;
- char *ap = argbase;
- char *tmp = argbase; /* will return this if token found */
-
- if (*sb == '!' || *sb == '$') { /* recognize ! as a token for shell */
- switch (slrflag) { /* and $ as token for macro invoke */
- case 0:
- slrflag++;
- stringbase++;
- return ((*sb == '!') ? "!" : "$");
- /* NOTREACHED */
- case 1:
- slrflag++;
- altarg = stringbase;
- break;
- default:
- break;
- }
- }
-
-S0:
- switch (*sb) {
-
- case '\0':
- goto OUT;
-
- case ' ':
- case '\t':
- sb++; goto S0;
-
- default:
- switch (slrflag) {
- case 0:
- slrflag++;
- break;
- case 1:
- slrflag++;
- altarg = sb;
- break;
- default:
- break;
- }
- goto S1;
- }
-
-S1:
- switch (*sb) {
-
- case ' ':
- case '\t':
- case '\0':
- goto OUT; /* end of token */
-
- case '\\':
- sb++; goto S2; /* slurp next character */
-
- case '"':
- sb++; goto S3; /* slurp quoted string */
-
- default:
- *ap++ = *sb++; /* add character to token */
- got_one = 1;
- goto S1;
- }
-
-S2:
- switch (*sb) {
-
- case '\0':
- goto OUT;
-
- default:
- *ap++ = *sb++;
- got_one = 1;
- goto S1;
- }
-
-S3:
- switch (*sb) {
-
- case '\0':
- goto OUT;
-
- case '"':
- sb++; goto S1;
-
- default:
- *ap++ = *sb++;
- got_one = 1;
- goto S3;
- }
-
-OUT:
- if (got_one)
- *ap++ = '\0';
- argbase = ap; /* update storage pointer */
- stringbase = sb; /* update scan pointer */
- if (got_one) {
- return (tmp);
- }
- switch (slrflag) {
- case 0:
- slrflag++;
- break;
- case 1:
- slrflag++;
- altarg = (char *) 0;
- break;
- default:
- break;
- }
- return NULL;
-}
-
-#define HELPINDENT ((int) sizeof ("directory"))
-
-/*
- * Help command.
- * Call each command handler with argc == 0 and argv[0] == name.
- */
-void
-help(int argc, char **argv)
-{
- struct cmd *c;
-
- if (argc == 1) {
- int i, j, w, k;
- int columns, width = 0, lines;
-
- printf("Commands may be abbreviated. Commands are:\n\n");
- for (c = cmdtab; c < &cmdtab[NCMDS]; c++) {
- int len = strlen(c->c_name);
-
- if (len > width)
- width = len;
- }
- width = (width + 8) &~ 7;
- columns = 80 / width;
- if (columns == 0)
- columns = 1;
- lines = (NCMDS + columns - 1) / columns;
- for (i = 0; i < lines; i++) {
- for (j = 0; j < columns; j++) {
- c = cmdtab + j * lines + i;
- if (c->c_name && (!proxy || c->c_proxy)) {
- printf("%s", c->c_name);
- }
- else if (c->c_name) {
- for (k=0; k < strlen(c->c_name); k++) {
- putchar(' ');
- }
- }
- if (c + lines >= &cmdtab[NCMDS]) {
- printf("\n");
- break;
- }
- w = strlen(c->c_name);
- while (w < width) {
- w = (w + 8) &~ 7;
- putchar('\t');
- }
- }
- }
- return;
- }
- while (--argc > 0) {
- char *arg;
- arg = *++argv;
- c = getcmd(arg);
- if (c == (struct cmd *)-1)
- printf("?Ambiguous help command %s\n", arg);
- else if (c == (struct cmd *)0)
- printf("?Invalid help command %s\n", arg);
- else
- printf("%-*s\t%s\n", HELPINDENT,
- c->c_name, c->c_help);
- }
-}
diff --git a/appl/ftp/ftp/pathnames.h b/appl/ftp/ftp/pathnames.h
deleted file mode 100644
index f7c1fb391d6957cdc470f429c7d8daf5c86b16ee..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/pathnames.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * 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.
- *
- * @(#)pathnames.h 8.1 (Berkeley) 6/6/93
- */
-
-#ifdef HAVE_PATHS_H
-#include <paths.h>
-#endif
-
-#define _PATH_TMP_XXX "/tmp/ftpXXXXXX"
-
-#ifndef _PATH_BSHELL
-#define _PATH_BSHELL "/bin/sh"
-#endif
diff --git a/appl/ftp/ftp/ruserpass.c b/appl/ftp/ftp/ruserpass.c
deleted file mode 100644
index 22cee4b99d0d568a5e30725b0617944cfda2c141..0000000000000000000000000000000000000000
--- a/appl/ftp/ftp/ruserpass.c
+++ /dev/null
@@ -1,274 +0,0 @@
-/*
- * Copyright (c) 1985, 1993, 1994
- * 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 "ftp_locl.h"
-RCSID("$Id$");
-
-static int token (void);
-static FILE *cfile;
-
-#define DEFAULT 1
-#define LOGIN 2
-#define PASSWD 3
-#define ACCOUNT 4
-#define MACDEF 5
-#define PROT 6
-#define ID 10
-#define MACH 11
-
-static char tokval[100];
-
-static struct toktab {
- char *tokstr;
- int tval;
-} toktab[]= {
- { "default", DEFAULT },
- { "login", LOGIN },
- { "password", PASSWD },
- { "passwd", PASSWD },
- { "account", ACCOUNT },
- { "machine", MACH },
- { "macdef", MACDEF },
- { "prot", PROT },
- { NULL, 0 }
-};
-
-int
-ruserpass(char *host, char **aname, char **apass, char **aacct)
-{
- char *hdir, buf[BUFSIZ], *tmp;
- int t, i, c, usedefault = 0;
- struct stat stb;
-
- if(gethostname(myhostname, MaxHostNameLen) < 0)
- strcpy(myhostname, "");
- if((mydomain = strchr(myhostname, '.')) == NULL)
- mydomain = myhostname;
- else
- mydomain++;
- hdir = getenv("HOME");
- if (hdir == NULL)
- hdir = ".";
- snprintf(buf, sizeof(buf), "%s/.netrc", hdir);
- cfile = fopen(buf, "r");
- if (cfile == NULL) {
- if (errno != ENOENT)
- warn("%s", buf);
- return (0);
- }
-
-next:
- while ((t = token())) switch(t) {
-
- case DEFAULT:
- usedefault = 1;
- /* FALL THROUGH */
-
- case MACH:
- if (!usedefault) {
- if (token() != ID)
- continue;
- /*
- * Allow match either for user's input host name
- * or official hostname. Also allow match of
- * incompletely-specified host in local domain.
- */
- if (strcasecmp(host, tokval) == 0)
- goto match;
- if (strcasecmp(hostname, tokval) == 0)
- goto match;
- if ((tmp = strchr(hostname, '.')) != NULL &&
- tmp++ &&
- strcasecmp(tmp, mydomain) == 0 &&
- strncasecmp(hostname, tokval, tmp-hostname) == 0 &&
- tokval[tmp - hostname] == '\0')
- goto match;
- if ((tmp = strchr(host, '.')) != NULL &&
- tmp++ &&
- strcasecmp(tmp, mydomain) == 0 &&
- strncasecmp(host, tokval, tmp - host) == 0 &&
- tokval[tmp - host] == '\0')
- goto match;
- continue;
- }
- match:
- while ((t = token()) && t != MACH && t != DEFAULT) switch(t) {
-
- case LOGIN:
- if (token())
- if (*aname == 0) {
- *aname = strdup(tokval);
- } else {
- if (strcmp(*aname, tokval))
- goto next;
- }
- break;
- case PASSWD:
- if ((*aname == NULL || strcmp(*aname, "anonymous")) &&
- fstat(fileno(cfile), &stb) >= 0 &&
- (stb.st_mode & 077) != 0) {
- warnx("Error: .netrc file is readable by others.");
- warnx("Remove password or make file unreadable by others.");
- goto bad;
- }
- if (token() && *apass == 0) {
- *apass = strdup(tokval);
- }
- break;
- case ACCOUNT:
- if (fstat(fileno(cfile), &stb) >= 0
- && (stb.st_mode & 077) != 0) {
- warnx("Error: .netrc file is readable by others.");
- warnx("Remove account or make file unreadable by others.");
- goto bad;
- }
- if (token() && *aacct == 0) {
- *aacct = strdup(tokval);
- }
- break;
- case MACDEF:
- if (proxy) {
- fclose(cfile);
- return (0);
- }
- while ((c=getc(cfile)) != EOF && c == ' ' || c == '\t');
- if (c == EOF || c == '\n') {
- printf("Missing macdef name argument.\n");
- goto bad;
- }
- if (macnum == 16) {
- printf("Limit of 16 macros have already been defined\n");
- goto bad;
- }
- tmp = macros[macnum].mac_name;
- *tmp++ = c;
- for (i=0; i < 8 && (c=getc(cfile)) != EOF &&
- !isspace(c); ++i) {
- *tmp++ = c;
- }
- if (c == EOF) {
- printf("Macro definition missing null line terminator.\n");
- goto bad;
- }
- *tmp = '\0';
- if (c != '\n') {
- while ((c=getc(cfile)) != EOF && c != '\n');
- }
- if (c == EOF) {
- printf("Macro definition missing null line terminator.\n");
- goto bad;
- }
- if (macnum == 0) {
- macros[macnum].mac_start = macbuf;
- }
- else {
- macros[macnum].mac_start = macros[macnum-1].mac_end + 1;
- }
- tmp = macros[macnum].mac_start;
- while (tmp != macbuf + 4096) {
- if ((c=getc(cfile)) == EOF) {
- printf("Macro definition missing null line terminator.\n");
- goto bad;
- }
- *tmp = c;
- if (*tmp == '\n') {
- if (*(tmp-1) == '\0') {
- macros[macnum++].mac_end = tmp - 1;
- break;
- }
- *tmp = '\0';
- }
- tmp++;
- }
- if (tmp == macbuf + 4096) {
- printf("4K macro buffer exceeded\n");
- goto bad;
- }
- break;
- case PROT:
- token();
- if(sec_request_prot(tokval) < 0)
- warnx("Unknown protection level \"%s\"", tokval);
- break;
- default:
- warnx("Unknown .netrc keyword %s", tokval);
- break;
- }
- goto done;
- }
-done:
- fclose(cfile);
- return (0);
-bad:
- fclose(cfile);
- return (-1);
-}
-
-static int
-token(void)
-{
- char *cp;
- int c;
- struct toktab *t;
-
- if (feof(cfile) || ferror(cfile))
- return (0);
- while ((c = getc(cfile)) != EOF &&
- (c == '\n' || c == '\t' || c == ' ' || c == ','))
- continue;
- if (c == EOF)
- return (0);
- cp = tokval;
- if (c == '"') {
- while ((c = getc(cfile)) != EOF && c != '"') {
- if (c == '\\')
- c = getc(cfile);
- *cp++ = c;
- }
- } else {
- *cp++ = c;
- while ((c = getc(cfile)) != EOF
- && c != '\n' && c != '\t' && c != ' ' && c != ',') {
- if (c == '\\')
- c = getc(cfile);
- *cp++ = c;
- }
- }
- *cp = 0;
- if (tokval[0] == 0)
- return (0);
- for (t = toktab; t->tokstr; t++)
- if (!strcmp(t->tokstr, tokval))
- return (t->tval);
- return (ID);
-}
diff --git a/appl/ftp/ftpd/Makefile.in b/appl/ftp/ftpd/Makefile.in
deleted file mode 100644
index ce6cf86ba43724170affc9c52bc374721b13dfe4..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/Makefile.in
+++ /dev/null
@@ -1,84 +0,0 @@
-#
-# $Id$
-#
-
-srcdir = @srcdir@
-top_srcdir = @top_srcdir@
-VPATH = @srcdir@
-
-top_builddir = ../../..
-
-SHELL = /bin/sh
-
-CC = @CC@
-YACC = @YACC@
-RANLIB = @RANLIB@
-DEFS = @DEFS@
-CFLAGS = @CFLAGS@
-LD_FLAGS = @LD_FLAGS@
-LIBS = @LIBS@
-LIB_DBM = @LIB_DBM@
-MKINSTALLDIRS = $(top_srcdir)/mkinstalldirs
-
-INSTALL = @INSTALL@
-INSTALL_PROGRAM = @INSTALL_PROGRAM@
-
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-libdir = @libdir@
-libexecdir = @libexecdir@
-transform=@program_transform_name@
-EXECSUFFIX=@EXECSUFFIX@
-
-ATHENA = ../../..
-
-INCTOP = $(ATHENA)/include
-
-LIBTOP = $(ATHENA)/lib
-
-LIBKAFS = @KRB_KAFS_LIB@
-LIBKRB = -L$(LIBTOP)/krb -lkrb
-LIBDES = -L$(LIBTOP)/des -ldes
-LIBOTP = @LIB_otp@
-LIBROKEN= -L$(LIBTOP)/roken -lroken
-
-PROGS = ftpd$(EXECSUFFIX)
-
-ftpd_SOURCES = ftpd.c ftpcmd.c logwtmp.c popen.c auth.c krb4.c kauth.c
-ftpd_OBJS = ftpd.o ftpcmd.o logwtmp.o popen.o auth.o krb4.o kauth.o
-
-SOURCES = $(ftpd_SOURCES)
-OBJECTS = $(ftpd_OBJS)
-
-all: $(PROGS)
-
-.c.o:
- $(CC) -c $(CFLAGS) -I$(srcdir) -I$(srcdir)/../common -I$(INCTOP) $(DEFS) $<
-
-install: all
- $(MKINSTALLDIRS) $(libexecdir)
- for x in $(PROGS); do \
- $(INSTALL_PROGRAM) $$x $(libexecdir)/`echo $$x | sed '$(transform)'`; \
- done
-
-uninstall:
- for x in $(PROGS); do \
- rm -f $(libexecdir)/`echo $$x | sed '$(transform)'`; \
- done
-
-ftpd$(EXECSUFFIX): $(ftpd_OBJS)
- $(CC) $(LD_FLAGS) $(LDFLAGS) -o $@ $(ftpd_OBJS) -L../common -lcommon $(LIBKAFS) $(LIBKRB) $(LIBOTP) $(LIBDES) $(LIBROKEN) $(LIB_DBM) $(LIBS) $(LIBROKEN)
-
-ftpcmd.c: ftpcmd.y
- $(YACC) $(YFLAGS) $<
- chmod a-w y.tab.c
- mv -f y.tab.c ftpcmd.c
-
-TAGS: $(SOURCES)
- etags $(SOURCES)
-
-clean cleandir:
- rm -f *~ *.o core ftpd$(EXECSUFFIX) ftpcmd.c \#*
-
-distclean:
- rm -f Makefile
diff --git a/appl/ftp/ftpd/auth.c b/appl/ftp/ftpd/auth.c
deleted file mode 100644
index efce62375a0bc15efa3c1446c09f7c7817b2ae5b..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/auth.c
+++ /dev/null
@@ -1,249 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-#endif
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_SOCKET_H
-#include <sys/socket.h>
-#endif
-#if defined(HAVE_SYS_IOCTL_H) && SunOS != 4
-#include <sys/ioctl.h>
-#endif
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
-
-#include "extern.h"
-#include "krb4.h"
-#include "auth.h"
-
-static struct at auth_types [] = {
- { "KERBEROS_V4", krb4_auth, krb4_adat, krb4_pbsz, krb4_prot, krb4_ccc,
- krb4_mic, krb4_conf, krb4_enc, krb4_read, krb4_write, krb4_userok,
- krb4_vprintf },
- { 0, 0, 0, 0, 0, 0, 0, 0, 0 }
-};
-
-struct at *ct;
-
-int data_protection;
-int buffer_size;
-unsigned char *data_buffer;
-int auth_complete;
-
-
-char *protection_names[] = {
- "clear", "safe",
- "confidential", "private"
-};
-
-
-void auth_init(void)
-{
-}
-
-char *ftp_command;
-int prot_level;
-
-void new_ftp_command(char *command)
-{
- ftp_command = command;
-}
-
-void delete_ftp_command(void)
-{
- if(ftp_command){
- free(ftp_command);
- ftp_command = NULL;
- }
-}
-
-int auth_ok(void)
-{
- return ct && auth_complete;
-}
-
-void auth(char *auth)
-{
- for(ct=auth_types; ct->name; ct++){
- if(!strcasecmp(auth, ct->name)){
- ct->auth(auth);
- return;
- }
- }
- reply(504, "%s is not a known security mechanism", auth);
-}
-
-void adat(char *auth)
-{
- if(ct && !auth_complete)
- ct->adat(auth);
- else
- reply(503, "You must (re)issue an AUTH first.");
-}
-
-void pbsz(int size)
-{
- int old = buffer_size;
- if(auth_ok())
- ct->pbsz(size);
- else
- reply(503, "Incomplete security data exchange.");
- if(buffer_size != old){
- if(data_buffer)
- free(data_buffer);
- data_buffer = malloc(buffer_size + 4);
- }
-}
-
-void prot(char *pl)
-{
- int p = -1;
-
- if(buffer_size == 0){
- reply(503, "No protection buffer size negotiated.");
- return;
- }
-
- if(!strcasecmp(pl, "C"))
- p = prot_clear;
-
- if(!strcasecmp(pl, "S"))
- p = prot_safe;
-
- if(!strcasecmp(pl, "E"))
- p = prot_confidential;
-
- if(!strcasecmp(pl, "P"))
- p = prot_private;
-
- if(p == -1){
- reply(504, "Unrecognized protection level.");
- return;
- }
-
- if(auth_ok()){
- if(ct->prot(p)){
- reply(536, "%s does not support %s protection.",
- ct->name, protection_names[p]);
- }else{
- data_protection = p;
- reply(200, "Data protection is %s.",
- protection_names[data_protection]);
- }
- }else{
- reply(503, "Incomplete security data exchange.");
- }
-}
-
-void ccc(void)
-{
- if(auth_ok()){
- if(!ct->ccc())
- prot_level = prot_clear;
- }else
- reply(503, "Incomplete security data exchange.");
-}
-
-void mic(char *msg)
-{
- if(auth_ok()){
- if(!ct->mic(msg))
- prot_level = prot_safe;
- }else
- reply(503, "Incomplete security data exchange.");
-}
-
-void conf(char *msg)
-{
- if(auth_ok()){
- if(!ct->conf(msg))
- prot_level = prot_confidential;
- }else
- reply(503, "Incomplete security data exchange.");
-}
-
-void enc(char *msg)
-{
- if(auth_ok()){
- if(!ct->enc(msg))
- prot_level = prot_private;
- }else
- reply(503, "Incomplete security data exchange.");
-}
-
-int auth_read(int fd, void *data, int length)
-{
- if(auth_ok() && data_protection)
- return ct->read(fd, data, length);
- else
- return read(fd, data, length);
-}
-
-int auth_write(int fd, void *data, int length)
-{
- if(auth_ok() && data_protection)
- return ct->write(fd, data, length);
- else
- return write(fd, data, length);
-}
-
-void auth_vprintf(const char *fmt, va_list ap)
-{
- if(auth_ok() && prot_level){
- ct->vprintf(fmt, ap);
- }else
- vprintf(fmt, ap);
-}
-
-void auth_printf(const char *fmt, ...)
-{
- va_list ap;
- va_start(ap, fmt);
- auth_vprintf(fmt, ap);
- va_end(ap);
-}
diff --git a/appl/ftp/ftpd/auth.h b/appl/ftp/ftpd/auth.h
deleted file mode 100644
index 317a7e06f704d4c1ff86d71b3a8916717f248f97..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/auth.h
+++ /dev/null
@@ -1,109 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifndef __AUTH_H__
-#define __AUTH_H__
-
-#include <stdarg.h>
-
-struct at {
- char *name;
- int (*auth)(char*);
- int (*adat)(char*);
- int (*pbsz)(int);
- int (*prot)(int);
- int (*ccc)(void);
- int (*mic)(char*);
- int (*conf)(char*);
- int (*enc)(char*);
- int (*read)(int, void*, int);
- int (*write)(int, void*, int);
- int (*userok)(char*);
- int (*vprintf)(const char*, va_list);
-};
-
-extern struct at *ct;
-
-enum protection_levels {
- prot_clear, prot_safe, prot_confidential, prot_private
-};
-
-extern char *protection_names[];
-
-extern char *ftp_command;
-extern int prot_level;
-
-void delete_ftp_command(void);
-
-extern int data_protection;
-extern int buffer_size;
-extern unsigned char *data_buffer;
-extern int auth_complete;
-
-void auth_init(void);
-
-int auth_ok(void);
-
-void auth(char*);
-void adat(char*);
-void pbsz(int);
-void prot(char*);
-void ccc(void);
-void mic(char*);
-void conf(char*);
-void enc(char*);
-
-int auth_read(int, void*, int);
-int auth_write(int, void*, int);
-
-void auth_vprintf(const char *fmt, va_list ap)
-#ifdef __GNUC__
-__attribute__ ((format (printf, 1, 0)))
-#endif
-;
-void auth_printf(const char *fmt, ...)
-#ifdef __GNUC__
-__attribute__ ((format (printf, 1, 2)))
-#endif
-;
-
-void new_ftp_command(char *command);
-
-#endif /* __AUTH_H__ */
diff --git a/appl/ftp/ftpd/extern.h b/appl/ftp/ftpd/extern.h
deleted file mode 100644
index 3b27965ad68102f93de34f76141ffa7bca9db2ab..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/extern.h
+++ /dev/null
@@ -1,154 +0,0 @@
-/*-
- * 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.2 (Berkeley) 4/4/94
- */
-
-#ifndef _EXTERN_H_
-#define _EXTERN_H_
-
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_NETINET_IN_H
-#include <netinet/in.h>
-#endif
-#ifdef HAVE_NETDB_H
-#include <netdb.h>
-#endif
-
-#include <stdio.h>
-#include <stdarg.h>
-#include <setjmp.h>
-#ifdef HAVE_PWD_H
-#include <pwd.h>
-#endif
-
-#ifdef HAVE_LIMITS_H
-#include <limits.h>
-#endif
-
-#ifndef NBBY
-#define NBBY CHAR_BIT
-#endif
-
-void abor(void);
-void blkfree(char **);
-char **copyblk(char **);
-void cwd(char *);
-void do_delete(char *);
-void dologout(int);
-void fatal(char *);
-int filename_check(char *);
-int ftpd_pclose(FILE *);
-FILE *ftpd_popen(char *, char *, int, int);
-char *getline(char *, int);
-void logwtmp(char *, char *, char *);
-void lreply(int, const char *, ...)
-#ifdef __GNUC__
-__attribute__ ((format (printf, 2, 3)))
-#endif
-;
-void makedir(char *);
-void nack(char *);
-void nreply(const char *, ...)
-#ifdef __GNUC__
-__attribute__ ((format (printf, 1, 2)))
-#endif
-;
-void pass(char *);
-void passive(void);
-void perror_reply(int, char *);
-void pwd(void);
-void removedir(char *);
-void renamecmd(char *, char *);
-char *renamefrom(char *);
-void reply(int, const char *, ...)
-#ifdef __GNUC__
-__attribute__ ((format (printf, 2, 3)))
-#endif
-;
-void retrieve(char *, char *);
-void send_file_list(char *);
-void setproctitle(const char *, ...)
-#ifdef __GNUC__
-__attribute__ ((format (printf, 1, 2)))
-#endif
-;
-void statcmd(void);
-void statfilecmd(char *);
-void do_store(char *, char *, int);
-void upper(char *);
-void user(char *);
-void yyerror(char *);
-
-void kauth(char *, char*);
-void klist(void);
-void cond_kdestroy(void);
-void kdestroy(void);
-void krbtkfile(const char *tkfile);
-void afslog(const char *cell);
-void afsunlog(void);
-
-int find(char *);
-
-int do_login(int code, char *passwd);
-int klogin(char *name, char *password);
-
-const char *ftp_rooted(const char *path);
-
-extern struct sockaddr_in ctrl_addr, his_addr;
-extern char hostname[];
-
-extern struct sockaddr_in data_dest;
-extern int logged_in;
-extern struct passwd *pw;
-extern int guest;
-extern int logging;
-extern int type;
-extern int oobflag;
-extern off_t file_size;
-extern off_t byte_count;
-extern jmp_buf urgcatch;
-
-extern int form;
-extern int debug;
-extern int ftpd_timeout;
-extern int maxtimeout;
-extern int pdata;
-extern char hostname[], remotehost[];
-extern char proctitle[];
-extern int usedefault;
-extern int transflag;
-extern char tmpline[];
-
-#endif /* _EXTERN_H_ */
diff --git a/appl/ftp/ftpd/ftpcmd.y b/appl/ftp/ftpd/ftpcmd.y
deleted file mode 100644
index 73728ea9688a87182a8a29d06c3b50a1fb899370..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/ftpcmd.y
+++ /dev/null
@@ -1,1443 +0,0 @@
-/* $NetBSD: ftpcmd.y,v 1.6 1995/06/03 22:46:45 mycroft Exp $ */
-
-/*
- * Copyright (c) 1985, 1988, 1993, 1994
- * 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.
- *
- * @(#)ftpcmd.y 8.3 (Berkeley) 4/6/94
- */
-
-/*
- * Grammar for FTP commands.
- * See RFC 959.
- */
-
-%{
-
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-
-RCSID("$Id$");
-
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-
-#ifdef HAVE_SYS_PARAM_H
-#include <sys/param.h>
-#endif
-#ifdef HAVE_SYS_SOCKET_H
-#include <sys/socket.h>
-#endif
-#ifdef HAVE_SYS_STAT_H
-#include <sys/stat.h>
-#endif
-
-#ifdef HAVE_NETINET_IN_H
-#include <netinet/in.h>
-#endif
-#ifdef HAVE_ARPA_FTP_H
-#include <arpa/ftp.h>
-#endif
-
-#include <ctype.h>
-#include <errno.h>
-#include <glob.h>
-#ifdef HAVE_PWD_H
-#include <pwd.h>
-#endif
-#include <setjmp.h>
-#include <signal.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#ifdef HAVE_SYSLOG_H
-#include <syslog.h>
-#endif
-#include <time.h>
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
-
-#ifdef HAVE_BSD_BSD_H
-#include <bsd/bsd.h>
-#endif
-
-#include <roken.h>
-
-#ifdef SOCKS
-#include <socks.h>
-extern int LIBPREFIX(fclose) __P((FILE *));
-#endif
-
-#include "extern.h"
-#include "auth.h"
-
-off_t restart_point;
-
-static int cmd_type;
-static int cmd_form;
-static int cmd_bytesz;
-char cbuf[512];
-char *fromname;
-
-struct tab {
- char *name;
- short token;
- short state;
- short implemented; /* 1 if command is implemented */
- char *help;
-};
-
-extern struct tab cmdtab[];
-extern struct tab sitetab[];
-
-static char *copy (char *);
-static void help (struct tab *, char *);
-static struct tab *
- lookup (struct tab *, char *);
-static void sizecmd (char *);
-static void toolong (int);
-static int yylex (void);
-
-/* This is for bison */
-
-#if !defined(alloca) && !defined(HAVE_ALLOCA)
-#define alloca(x) malloc(x)
-#endif
-
-%}
-
-%union {
- int i;
- char *s;
-}
-
-%token
- A B C E F I
- L N P R S T
-
- SP CRLF COMMA
-
- USER PASS ACCT REIN QUIT PORT
- PASV TYPE STRU MODE RETR STOR
- APPE MLFL MAIL MSND MSOM MSAM
- MRSQ MRCP ALLO REST RNFR RNTO
- ABOR DELE CWD LIST NLST SITE
- STAT HELP NOOP MKD RMD PWD
- CDUP STOU SMNT SYST SIZE MDTM
-
- UMASK IDLE CHMOD
-
- AUTH ADAT PROT PBSZ CCC MIC
- CONF ENC
-
- KAUTH KLIST KDESTROY KRBTKFILE AFSLOG
- FIND URL
-
- LEXERR
-
-%token <s> STRING
-%token <i> NUMBER
-
-%type <i> check_login check_login_no_guest octal_number byte_size
-%type <i> struct_code mode_code type_code form_code
-%type <s> pathstring pathname password username
-
-%start cmd_list
-
-%%
-
-cmd_list
- : /* empty */
- | cmd_list cmd
- {
- fromname = (char *) 0;
- restart_point = (off_t) 0;
- }
- | cmd_list rcmd
- ;
-
-cmd
- : USER SP username CRLF
- {
- user($3);
- free($3);
- }
- | AUTH SP STRING CRLF
- {
- auth($3);
- free($3);
- }
- | ADAT SP STRING CRLF
- {
- adat($3);
- free($3);
- }
- | PBSZ SP NUMBER CRLF
- {
- pbsz($3);
- }
- | PROT SP STRING CRLF
- {
- prot($3);
- }
- | CCC CRLF
- {
- ccc();
- }
- | MIC SP STRING CRLF
- {
- mic($3);
- free($3);
- }
- | CONF SP STRING CRLF
- {
- conf($3);
- free($3);
- }
- | PASS SP password CRLF
- {
- pass($3);
- memset ($3, 0, strlen($3));
- free($3);
- }
- | PORT SP host_port CRLF
- {
- usedefault = 0;
- if (pdata >= 0) {
- close(pdata);
- pdata = -1;
- }
- reply(200, "PORT command successful.");
- }
- | PASV CRLF
- {
- passive();
- }
- | TYPE SP type_code CRLF
- {
- switch (cmd_type) {
-
- case TYPE_A:
- if (cmd_form == FORM_N) {
- reply(200, "Type set to A.");
- type = cmd_type;
- form = cmd_form;
- } else
- reply(504, "Form must be N.");
- break;
-
- case TYPE_E:
- reply(504, "Type E not implemented.");
- break;
-
- case TYPE_I:
- reply(200, "Type set to I.");
- type = cmd_type;
- break;
-
- case TYPE_L:
-#if NBBY == 8
- if (cmd_bytesz == 8) {
- reply(200,
- "Type set to L (byte size 8).");
- type = cmd_type;
- } else
- reply(504, "Byte size must be 8.");
-#else /* NBBY == 8 */
- UNIMPLEMENTED for NBBY != 8
-#endif /* NBBY == 8 */
- }
- }
- | STRU SP struct_code CRLF
- {
- switch ($3) {
-
- case STRU_F:
- reply(200, "STRU F ok.");
- break;
-
- default:
- reply(504, "Unimplemented STRU type.");
- }
- }
- | MODE SP mode_code CRLF
- {
- switch ($3) {
-
- case MODE_S:
- reply(200, "MODE S ok.");
- break;
-
- default:
- reply(502, "Unimplemented MODE type.");
- }
- }
- | ALLO SP NUMBER CRLF
- {
- reply(202, "ALLO command ignored.");
- }
- | ALLO SP NUMBER SP R SP NUMBER CRLF
- {
- reply(202, "ALLO command ignored.");
- }
- | RETR check_login SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- retrieve((char *) 0, $4);
- if ($4 != NULL)
- free($4);
- }
- | STOR check_login SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- do_store($4, "w", 0);
- if ($4 != NULL)
- free($4);
- }
- | APPE check_login SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- do_store($4, "a", 0);
- if ($4 != NULL)
- free($4);
- }
- | NLST check_login CRLF
- {
- if ($2)
- send_file_list(".");
- }
- | NLST check_login SP STRING CRLF
- {
- if ($2 && $4 != NULL)
- send_file_list($4);
- if ($4 != NULL)
- free($4);
- }
- | LIST check_login CRLF
- {
-#ifdef HAVE_LS_A
- char *cmd = "/bin/ls -lA";
-#else
- char *cmd = "/bin/ls -la";
-#endif
- if ($2)
- retrieve(cmd, "");
-
- }
- | LIST check_login SP pathname CRLF
- {
-#ifdef HAVE_LS_A
- char *cmd = "/bin/ls -lA %s";
-#else
- char *cmd = "/bin/ls -la %s";
-#endif
- if ($2 && $4 != NULL)
- retrieve(cmd, $4);
- if ($4 != NULL)
- free($4);
- }
- | STAT check_login SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- statfilecmd($4);
- if ($4 != NULL)
- free($4);
- }
- | STAT CRLF
- {
- if(oobflag){
- if (file_size != (off_t) -1)
- reply(213, "Status: %ld of %ld bytes transferred",
- byte_count, file_size);
- else
- reply(213, "Status: %ld bytes transferred", byte_count);
- }else
- statcmd();
- }
- | DELE check_login_no_guest SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- do_delete($4);
- if ($4 != NULL)
- free($4);
- }
- | RNTO check_login_no_guest SP pathname CRLF
- {
- if($2){
- if (fromname) {
- renamecmd(fromname, $4);
- free(fromname);
- fromname = (char *) 0;
- } else {
- reply(503, "Bad sequence of commands.");
- }
- }
- if ($4 != NULL)
- free($4);
- }
- | ABOR CRLF
- {
- if(oobflag){
- reply(426, "Transfer aborted. Data connection closed.");
- reply(226, "Abort successful");
- oobflag = 0;
- longjmp(urgcatch, 1);
- }else
- reply(225, "ABOR command successful.");
- }
- | CWD check_login CRLF
- {
- if ($2)
- cwd(pw->pw_dir);
- }
- | CWD check_login SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- cwd($4);
- if ($4 != NULL)
- free($4);
- }
- | HELP CRLF
- {
- help(cmdtab, (char *) 0);
- }
- | HELP SP STRING CRLF
- {
- char *cp = $3;
-
- if (strncasecmp(cp, "SITE", 4) == 0) {
- cp = $3 + 4;
- if (*cp == ' ')
- cp++;
- if (*cp)
- help(sitetab, cp);
- else
- help(sitetab, (char *) 0);
- } else
- help(cmdtab, $3);
- }
- | NOOP CRLF
- {
- reply(200, "NOOP command successful.");
- }
- | MKD check_login SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- makedir($4);
- if ($4 != NULL)
- free($4);
- }
- | RMD check_login_no_guest SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- removedir($4);
- if ($4 != NULL)
- free($4);
- }
- | PWD check_login CRLF
- {
- if ($2)
- pwd();
- }
- | CDUP check_login CRLF
- {
- if ($2)
- cwd("..");
- }
- | SITE SP HELP CRLF
- {
- help(sitetab, (char *) 0);
- }
- | SITE SP HELP SP STRING CRLF
- {
- help(sitetab, $5);
- }
- | SITE SP UMASK check_login CRLF
- {
- int oldmask;
-
- if ($4) {
- oldmask = umask(0);
- umask(oldmask);
- reply(200, "Current UMASK is %03o", oldmask);
- }
- }
- | SITE SP UMASK check_login_no_guest SP octal_number CRLF
- {
- int oldmask;
-
- if ($4) {
- if (($6 == -1) || ($6 > 0777)) {
- reply(501, "Bad UMASK value");
- } else {
- oldmask = umask($6);
- reply(200,
- "UMASK set to %03o (was %03o)",
- $6, oldmask);
- }
- }
- }
- | SITE SP CHMOD check_login_no_guest SP octal_number SP pathname CRLF
- {
- if ($4 && $8 != NULL) {
- if ($6 > 0777)
- reply(501,
- "CHMOD: Mode value must be between 0 and 0777");
- else if (chmod($8, $6) < 0)
- perror_reply(550, $8);
- else
- reply(200, "CHMOD command successful.");
- }
- if ($8 != NULL)
- free($8);
- }
- | SITE SP IDLE CRLF
- {
- reply(200,
- "Current IDLE time limit is %d seconds; max %d",
- ftpd_timeout, maxtimeout);
- }
- | SITE SP IDLE SP NUMBER CRLF
- {
- if ($5 < 30 || $5 > maxtimeout) {
- reply(501,
- "Maximum IDLE time must be between 30 and %d seconds",
- maxtimeout);
- } else {
- ftpd_timeout = $5;
- alarm((unsigned) ftpd_timeout);
- reply(200,
- "Maximum IDLE time set to %d seconds",
- ftpd_timeout);
- }
- }
-
- | SITE SP KAUTH check_login SP STRING CRLF
- {
- char *p;
-
- if(guest)
- reply(500, "Can't be done as guest.");
- else{
- if($4 && $6 != NULL){
- p = strpbrk($6, " \t");
- if(p){
- *p++ = 0;
- kauth($6, p + strspn(p, " \t"));
- }else
- kauth($6, NULL);
- }
- }
- if($6 != NULL)
- free($6);
- }
- | SITE SP KLIST check_login CRLF
- {
- if($4)
- klist();
- }
- | SITE SP KDESTROY check_login CRLF
- {
- if($4)
- kdestroy();
- }
- | SITE SP KRBTKFILE check_login SP STRING CRLF
- {
- if(guest)
- reply(500, "Can't be done as guest.");
- else if($4 && $6)
- krbtkfile($6);
- if($6)
- free($6);
- }
- | SITE SP AFSLOG check_login CRLF
- {
- if(guest)
- reply(500, "Can't be done as guest.");
- else if($4)
- afslog(NULL);
- }
- | SITE SP AFSLOG check_login SP STRING CRLF
- {
- if(guest)
- reply(500, "Can't be done as guest.");
- else if($4){
- afslog($6);
- }
- if($6)
- free($6);
- }
- | SITE SP FIND check_login SP STRING CRLF
- {
- if($4 && $6 != NULL)
- find($6);
- if($6 != NULL)
- free($6);
- }
- | SITE SP URL CRLF
- {
- reply(200, "http://www.pdc.kth.se/kth-krb/");
- }
- | STOU check_login SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- do_store($4, "w", 1);
- if ($4 != NULL)
- free($4);
- }
- | SYST CRLF
- {
-#if defined(unix) || defined(__unix__) || defined(__unix) || defined(_AIX) || defined(_CRAY)
- reply(215, "UNIX Type: L%d", NBBY);
-#else
- reply(215, "UNKNOWN Type: L%d", NBBY);
-#endif
- }
-
- /*
- * SIZE is not in RFC959, but Postel has blessed it and
- * it will be in the updated RFC.
- *
- * Return size of file in a format suitable for
- * using with RESTART (we just count bytes).
- */
- | SIZE check_login SP pathname CRLF
- {
- if ($2 && $4 != NULL)
- sizecmd($4);
- if ($4 != NULL)
- free($4);
- }
-
- /*
- * MDTM is not in RFC959, but Postel has blessed it and
- * it will be in the updated RFC.
- *
- * Return modification time of file as an ISO 3307
- * style time. E.g. YYYYMMDDHHMMSS or YYYYMMDDHHMMSS.xxx
- * where xxx is the fractional second (of any precision,
- * not necessarily 3 digits)
- */
- | MDTM check_login SP pathname CRLF
- {
- if ($2 && $4 != NULL) {
- struct stat stbuf;
- if (stat($4, &stbuf) < 0)
- reply(550, "%s: %s",
- $4, strerror(errno));
- else if (!S_ISREG(stbuf.st_mode)) {
- reply(550, "%s: not a plain file.", $4);
- } else {
- struct tm *t;
- t = gmtime(&stbuf.st_mtime);
- reply(213,
- "%04d%02d%02d%02d%02d%02d",
- t->tm_year + 1900,
- t->tm_mon + 1,
- t->tm_mday,
- t->tm_hour,
- t->tm_min,
- t->tm_sec);
- }
- }
- if ($4 != NULL)
- free($4);
- }
- | QUIT CRLF
- {
- reply(221, "Goodbye.");
- dologout(0);
- }
- | error CRLF
- {
- yyerrok;
- }
- ;
-rcmd
- : RNFR check_login_no_guest SP pathname CRLF
- {
- restart_point = (off_t) 0;
- if ($2 && $4) {
- fromname = renamefrom($4);
- if (fromname == (char *) 0 && $4) {
- free($4);
- }
- }
- }
- | REST SP byte_size CRLF
- {
- fromname = (char *) 0;
- restart_point = $3; /* XXX $3 is only "int" */
- reply(350, "Restarting at %ld. %s",
- (long)restart_point,
- "Send STORE or RETRIEVE to initiate transfer.");
- }
- | ENC SP STRING CRLF
- {
- enc($3);
- free($3);
- }
- ;
-
-username
- : STRING
- ;
-
-password
- : /* empty */
- {
- $$ = (char *)calloc(1, sizeof(char));
- }
- | STRING
- ;
-
-byte_size
- : NUMBER
- ;
-
-host_port
- : NUMBER COMMA NUMBER COMMA NUMBER COMMA NUMBER COMMA
- NUMBER COMMA NUMBER
- {
- data_dest.sin_family = AF_INET;
- data_dest.sin_port = htons($9 * 256 + $11);
- data_dest.sin_addr.s_addr =
- htonl(($1 << 24) | ($3 << 16) | ($5 << 8) | $7);
- }
- ;
-
-form_code
- : N
- {
- $$ = FORM_N;
- }
- | T
- {
- $$ = FORM_T;
- }
- | C
- {
- $$ = FORM_C;
- }
- ;
-
-type_code
- : A
- {
- cmd_type = TYPE_A;
- cmd_form = FORM_N;
- }
- | A SP form_code
- {
- cmd_type = TYPE_A;
- cmd_form = $3;
- }
- | E
- {
- cmd_type = TYPE_E;
- cmd_form = FORM_N;
- }
- | E SP form_code
- {
- cmd_type = TYPE_E;
- cmd_form = $3;
- }
- | I
- {
- cmd_type = TYPE_I;
- }
- | L
- {
- cmd_type = TYPE_L;
- cmd_bytesz = NBBY;
- }
- | L SP byte_size
- {
- cmd_type = TYPE_L;
- cmd_bytesz = $3;
- }
- /* this is for a bug in the BBN ftp */
- | L byte_size
- {
- cmd_type = TYPE_L;
- cmd_bytesz = $2;
- }
- ;
-
-struct_code
- : F
- {
- $$ = STRU_F;
- }
- | R
- {
- $$ = STRU_R;
- }
- | P
- {
- $$ = STRU_P;
- }
- ;
-
-mode_code
- : S
- {
- $$ = MODE_S;
- }
- | B
- {
- $$ = MODE_B;
- }
- | C
- {
- $$ = MODE_C;
- }
- ;
-
-pathname
- : pathstring
- {
- /*
- * Problem: this production is used for all pathname
- * processing, but only gives a 550 error reply.
- * This is a valid reply in some cases but not in others.
- */
- if (logged_in && $1 && *$1 == '~') {
- glob_t gl;
- int flags =
- GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE;
-
- memset(&gl, 0, sizeof(gl));
- if (glob($1, flags, NULL, &gl) ||
- gl.gl_pathc == 0) {
- reply(550, "not found");
- $$ = NULL;
- } else {
- $$ = strdup(gl.gl_pathv[0]);
- }
- globfree(&gl);
- free($1);
- } else
- $$ = $1;
- }
- ;
-
-pathstring
- : STRING
- ;
-
-octal_number
- : NUMBER
- {
- int ret, dec, multby, digit;
-
- /*
- * Convert a number that was read as decimal number
- * to what it would be if it had been read as octal.
- */
- dec = $1;
- multby = 1;
- ret = 0;
- while (dec) {
- digit = dec%10;
- if (digit > 7) {
- ret = -1;
- break;
- }
- ret += digit * multby;
- multby *= 8;
- dec /= 10;
- }
- $$ = ret;
- }
- ;
-
-
-check_login_no_guest : check_login
- {
- $$ = $1 && !guest;
- if($1 && !$$)
- reply(550, "Permission denied");
- }
- ;
-
-check_login
- : /* empty */
- {
- if(auth_complete && prot_level == prot_clear){
- reply(533, "Command protection level denied for paranoid reasons.");
- $$ = 0;
- }else
- if (logged_in)
- $$ = 1;
- else {
- reply(530, "Please login with USER and PASS.");
- $$ = 0;
- }
- }
- ;
-
-%%
-
-extern jmp_buf errcatch;
-
-#define CMD 0 /* beginning of command */
-#define ARGS 1 /* expect miscellaneous arguments */
-#define STR1 2 /* expect SP followed by STRING */
-#define STR2 3 /* expect STRING */
-#define OSTR 4 /* optional SP then STRING */
-#define ZSTR1 5 /* SP then optional STRING */
-#define ZSTR2 6 /* optional STRING after SP */
-#define SITECMD 7 /* SITE command */
-#define NSTR 8 /* Number followed by a string */
-
-struct tab cmdtab[] = { /* In order defined in RFC 765 */
- { "USER", USER, STR1, 1, "<sp> username" },
- { "PASS", PASS, ZSTR1, 1, "<sp> password" },
- { "ACCT", ACCT, STR1, 0, "(specify account)" },
- { "SMNT", SMNT, ARGS, 0, "(structure mount)" },
- { "REIN", REIN, ARGS, 0, "(reinitialize server state)" },
- { "QUIT", QUIT, ARGS, 1, "(terminate service)", },
- { "PORT", PORT, ARGS, 1, "<sp> b0, b1, b2, b3, b4" },
- { "PASV", PASV, ARGS, 1, "(set server in passive mode)" },
- { "TYPE", TYPE, ARGS, 1, "<sp> [ A | E | I | L ]" },
- { "STRU", STRU, ARGS, 1, "(specify file structure)" },
- { "MODE", MODE, ARGS, 1, "(specify transfer mode)" },
- { "RETR", RETR, STR1, 1, "<sp> file-name" },
- { "STOR", STOR, STR1, 1, "<sp> file-name" },
- { "APPE", APPE, STR1, 1, "<sp> file-name" },
- { "MLFL", MLFL, OSTR, 0, "(mail file)" },
- { "MAIL", MAIL, OSTR, 0, "(mail to user)" },
- { "MSND", MSND, OSTR, 0, "(mail send to terminal)" },
- { "MSOM", MSOM, OSTR, 0, "(mail send to terminal or mailbox)" },
- { "MSAM", MSAM, OSTR, 0, "(mail send to terminal and mailbox)" },
- { "MRSQ", MRSQ, OSTR, 0, "(mail recipient scheme question)" },
- { "MRCP", MRCP, STR1, 0, "(mail recipient)" },
- { "ALLO", ALLO, ARGS, 1, "allocate storage (vacuously)" },
- { "REST", REST, ARGS, 1, "<sp> offset (restart command)" },
- { "RNFR", RNFR, STR1, 1, "<sp> file-name" },
- { "RNTO", RNTO, STR1, 1, "<sp> file-name" },
- { "ABOR", ABOR, ARGS, 1, "(abort operation)" },
- { "DELE", DELE, STR1, 1, "<sp> file-name" },
- { "CWD", CWD, OSTR, 1, "[ <sp> directory-name ]" },
- { "XCWD", CWD, OSTR, 1, "[ <sp> directory-name ]" },
- { "LIST", LIST, OSTR, 1, "[ <sp> path-name ]" },
- { "NLST", NLST, OSTR, 1, "[ <sp> path-name ]" },
- { "SITE", SITE, SITECMD, 1, "site-cmd [ <sp> arguments ]" },
- { "SYST", SYST, ARGS, 1, "(get type of operating system)" },
- { "STAT", STAT, OSTR, 1, "[ <sp> path-name ]" },
- { "HELP", HELP, OSTR, 1, "[ <sp> <string> ]" },
- { "NOOP", NOOP, ARGS, 1, "" },
- { "MKD", MKD, STR1, 1, "<sp> path-name" },
- { "XMKD", MKD, STR1, 1, "<sp> path-name" },
- { "RMD", RMD, STR1, 1, "<sp> path-name" },
- { "XRMD", RMD, STR1, 1, "<sp> path-name" },
- { "PWD", PWD, ARGS, 1, "(return current directory)" },
- { "XPWD", PWD, ARGS, 1, "(return current directory)" },
- { "CDUP", CDUP, ARGS, 1, "(change to parent directory)" },
- { "XCUP", CDUP, ARGS, 1, "(change to parent directory)" },
- { "STOU", STOU, STR1, 1, "<sp> file-name" },
- { "SIZE", SIZE, OSTR, 1, "<sp> path-name" },
- { "MDTM", MDTM, OSTR, 1, "<sp> path-name" },
-
- /* extensions from RFC2228 */
- { "AUTH", AUTH, STR1, 1, "<sp> auth-type" },
- { "ADAT", ADAT, STR1, 1, "<sp> auth-data" },
- { "PBSZ", PBSZ, ARGS, 1, "<sp> buffer-size" },
- { "PROT", PROT, STR1, 1, "<sp> prot-level" },
- { "CCC", CCC, ARGS, 1, "" },
- { "MIC", MIC, STR1, 1, "<sp> integrity command" },
- { "CONF", CONF, STR1, 1, "<sp> confidentiality command" },
- { "ENC", ENC, STR1, 1, "<sp> privacy command" },
-
- { NULL, 0, 0, 0, 0 }
-};
-
-struct tab sitetab[] = {
- { "UMASK", UMASK, ARGS, 1, "[ <sp> umask ]" },
- { "IDLE", IDLE, ARGS, 1, "[ <sp> maximum-idle-time ]" },
- { "CHMOD", CHMOD, NSTR, 1, "<sp> mode <sp> file-name" },
- { "HELP", HELP, OSTR, 1, "[ <sp> <string> ]" },
-
- { "KAUTH", KAUTH, STR1, 1, "<sp> principal [ <sp> ticket ]" },
- { "KLIST", KLIST, ARGS, 1, "(show ticket file)" },
- { "KDESTROY", KDESTROY, ARGS, 1, "(destroy tickets)" },
- { "KRBTKFILE", KRBTKFILE, STR1, 1, "<sp> ticket-file" },
- { "AFSLOG", AFSLOG, OSTR, 1, "[<sp> cell]" },
-
- { "FIND", FIND, STR1, 1, "<sp> globexpr" },
-
- { "URL", URL, ARGS, 1, "?" },
-
- { NULL, 0, 0, 0, 0 }
-};
-
-static struct tab *
-lookup(struct tab *p, char *cmd)
-{
-
- for (; p->name != NULL; p++)
- if (strcmp(cmd, p->name) == 0)
- return (p);
- return (0);
-}
-
-#include <arpa/telnet.h>
-
-/*
- * getline - a hacked up version of fgets to ignore TELNET escape codes.
- */
-char *
-getline(char *s, int n)
-{
- int c;
- char *cs;
-
- cs = s;
-/* tmpline may contain saved command from urgent mode interruption */
- if(ftp_command){
- strncpy(s, ftp_command, n);
- if (debug)
- syslog(LOG_DEBUG, "command: %s", s);
-#ifdef XXX
- fprintf(stderr, "%s\n", s);
-#endif
- return s;
- }
- prot_level = prot_clear;
- while ((c = getc(stdin)) != EOF) {
- c &= 0377;
- if (c == IAC) {
- if ((c = getc(stdin)) != EOF) {
- c &= 0377;
- switch (c) {
- case WILL:
- case WONT:
- c = getc(stdin);
- printf("%c%c%c", IAC, DONT, 0377&c);
- fflush(stdout);
- continue;
- case DO:
- case DONT:
- c = getc(stdin);
- printf("%c%c%c", IAC, WONT, 0377&c);
- fflush(stdout);
- continue;
- case IAC:
- break;
- default:
- continue; /* ignore command */
- }
- }
- }
- *cs++ = c;
- if (--n <= 0 || c == '\n')
- break;
- }
- if (c == EOF && cs == s)
- return (NULL);
- *cs++ = '\0';
- if (debug) {
- if (!guest && strncasecmp("pass ", s, 5) == 0) {
- /* Don't syslog passwords */
- syslog(LOG_DEBUG, "command: %.5s ???", s);
- } else {
- char *cp;
- int len;
-
- /* Don't syslog trailing CR-LF */
- len = strlen(s);
- cp = s + len - 1;
- while (cp >= s && (*cp == '\n' || *cp == '\r')) {
- --cp;
- --len;
- }
- syslog(LOG_DEBUG, "command: %.*s", len, s);
- }
- }
-#ifdef XXX
- fprintf(stderr, "%s\n", s);
-#endif
- return (s);
-}
-
-static RETSIGTYPE
-toolong(int signo)
-{
-
- reply(421,
- "Timeout (%d seconds): closing control connection.",
- ftpd_timeout);
- if (logging)
- syslog(LOG_INFO, "User %s timed out after %d seconds",
- (pw ? pw -> pw_name : "unknown"), ftpd_timeout);
- dologout(1);
- SIGRETURN(0);
-}
-
-static int
-yylex(void)
-{
- static int cpos, state;
- char *cp, *cp2;
- struct tab *p;
- int n;
- char c;
-
- for (;;) {
- switch (state) {
-
- case CMD:
- signal(SIGALRM, toolong);
- alarm((unsigned) ftpd_timeout);
- if (getline(cbuf, sizeof(cbuf)-1) == NULL) {
- reply(221, "You could at least say goodbye.");
- dologout(0);
- }
- alarm(0);
-#ifdef HASSETPROCTITLE
- if (strncasecmp(cbuf, "PASS", 4) != NULL)
- setproctitle("%s: %s", proctitle, cbuf);
-#endif /* HASSETPROCTITLE */
- if ((cp = strchr(cbuf, '\r'))) {
- *cp++ = '\n';
- *cp = '\0';
- }
- if ((cp = strpbrk(cbuf, " \n")))
- cpos = cp - cbuf;
- if (cpos == 0)
- cpos = 4;
- c = cbuf[cpos];
- cbuf[cpos] = '\0';
- strupr(cbuf);
- p = lookup(cmdtab, cbuf);
- cbuf[cpos] = c;
- if (p != 0) {
- if (p->implemented == 0) {
- nack(p->name);
- longjmp(errcatch,0);
- /* NOTREACHED */
- }
- state = p->state;
- yylval.s = p->name;
- return (p->token);
- }
- break;
-
- case SITECMD:
- if (cbuf[cpos] == ' ') {
- cpos++;
- return (SP);
- }
- cp = &cbuf[cpos];
- if ((cp2 = strpbrk(cp, " \n")))
- cpos = cp2 - cbuf;
- c = cbuf[cpos];
- cbuf[cpos] = '\0';
- strupr(cp);
- p = lookup(sitetab, cp);
- cbuf[cpos] = c;
- if (p != 0) {
- if (p->implemented == 0) {
- state = CMD;
- nack(p->name);
- longjmp(errcatch,0);
- /* NOTREACHED */
- }
- state = p->state;
- yylval.s = p->name;
- return (p->token);
- }
- state = CMD;
- break;
-
- case OSTR:
- if (cbuf[cpos] == '\n') {
- state = CMD;
- return (CRLF);
- }
- /* FALLTHROUGH */
-
- case STR1:
- case ZSTR1:
- dostr1:
- if (cbuf[cpos] == ' ') {
- cpos++;
- state = state == OSTR ? STR2 : ++state;
- return (SP);
- }
- break;
-
- case ZSTR2:
- if (cbuf[cpos] == '\n') {
- state = CMD;
- return (CRLF);
- }
- /* FALLTHROUGH */
-
- case STR2:
- cp = &cbuf[cpos];
- n = strlen(cp);
- cpos += n - 1;
- /*
- * Make sure the string is nonempty and \n terminated.
- */
- if (n > 1 && cbuf[cpos] == '\n') {
- cbuf[cpos] = '\0';
- yylval.s = copy(cp);
- cbuf[cpos] = '\n';
- state = ARGS;
- return (STRING);
- }
- break;
-
- case NSTR:
- if (cbuf[cpos] == ' ') {
- cpos++;
- return (SP);
- }
- if (isdigit(cbuf[cpos])) {
- cp = &cbuf[cpos];
- while (isdigit(cbuf[++cpos]))
- ;
- c = cbuf[cpos];
- cbuf[cpos] = '\0';
- yylval.i = atoi(cp);
- cbuf[cpos] = c;
- state = STR1;
- return (NUMBER);
- }
- state = STR1;
- goto dostr1;
-
- case ARGS:
- if (isdigit(cbuf[cpos])) {
- cp = &cbuf[cpos];
- while (isdigit(cbuf[++cpos]))
- ;
- c = cbuf[cpos];
- cbuf[cpos] = '\0';
- yylval.i = atoi(cp);
- cbuf[cpos] = c;
- return (NUMBER);
- }
- switch (cbuf[cpos++]) {
-
- case '\n':
- state = CMD;
- return (CRLF);
-
- case ' ':
- return (SP);
-
- case ',':
- return (COMMA);
-
- case 'A':
- case 'a':
- return (A);
-
- case 'B':
- case 'b':
- return (B);
-
- case 'C':
- case 'c':
- return (C);
-
- case 'E':
- case 'e':
- return (E);
-
- case 'F':
- case 'f':
- return (F);
-
- case 'I':
- case 'i':
- return (I);
-
- case 'L':
- case 'l':
- return (L);
-
- case 'N':
- case 'n':
- return (N);
-
- case 'P':
- case 'p':
- return (P);
-
- case 'R':
- case 'r':
- return (R);
-
- case 'S':
- case 's':
- return (S);
-
- case 'T':
- case 't':
- return (T);
-
- }
- break;
-
- default:
- fatal("Unknown state in scanner.");
- }
- yyerror((char *) 0);
- state = CMD;
- longjmp(errcatch,0);
- }
-}
-
-static char *
-copy(char *s)
-{
- char *p;
-
- p = strdup(s);
- if (p == NULL)
- fatal("Ran out of memory.");
- return p;
-}
-
-static void
-help(struct tab *ctab, char *s)
-{
- struct tab *c;
- int width, NCMDS;
- char *type;
- char buf[1024];
-
- if (ctab == sitetab)
- type = "SITE ";
- else
- type = "";
- width = 0, NCMDS = 0;
- for (c = ctab; c->name != NULL; c++) {
- int len = strlen(c->name);
-
- if (len > width)
- width = len;
- NCMDS++;
- }
- width = (width + 8) &~ 7;
- if (s == 0) {
- int i, j, w;
- int columns, lines;
-
- lreply(214, "The following %scommands are recognized %s.",
- type, "(* =>'s unimplemented)");
- columns = 76 / width;
- if (columns == 0)
- columns = 1;
- lines = (NCMDS + columns - 1) / columns;
- for (i = 0; i < lines; i++) {
- strcpy (buf, " ");
- for (j = 0; j < columns; j++) {
- c = ctab + j * lines + i;
- snprintf (buf + strlen(buf), sizeof(buf) - strlen(buf),
- "%s%c", c->name, c->implemented ? ' ' : '*');
- if (c + lines >= &ctab[NCMDS])
- break;
- w = strlen(c->name) + 1;
- while (w < width) {
- strcat(buf, " ");
- w++;
- }
- }
- lreply(214, buf);
- }
- reply(214, "Direct comments to kth-krb-bugs@pdc.kth.se");
- return;
- }
- strupr(s);
- c = lookup(ctab, s);
- if (c == (struct tab *)0) {
- reply(502, "Unknown command %s.", s);
- return;
- }
- if (c->implemented)
- reply(214, "Syntax: %s%s %s", type, c->name, c->help);
- else
- reply(214, "%s%-*s\t%s; unimplemented.", type, width,
- c->name, c->help);
-}
-
-static void
-sizecmd(char *filename)
-{
- switch (type) {
- case TYPE_L:
- case TYPE_I: {
- struct stat stbuf;
- if (stat(filename, &stbuf) < 0 || !S_ISREG(stbuf.st_mode))
- reply(550, "%s: not a plain file.", filename);
- else
- reply(213, "%lu", (unsigned long)stbuf.st_size);
- break; }
- case TYPE_A: {
- FILE *fin;
- int c;
- off_t count;
- struct stat stbuf;
- fin = fopen(filename, "r");
- if (fin == NULL) {
- perror_reply(550, filename);
- return;
- }
- if (fstat(fileno(fin), &stbuf) < 0 || !S_ISREG(stbuf.st_mode)) {
- reply(550, "%s: not a plain file.", filename);
- fclose(fin);
- return;
- }
-
- count = 0;
- while((c=getc(fin)) != EOF) {
- if (c == '\n') /* will get expanded to \r\n */
- count++;
- count++;
- }
- fclose(fin);
-
- reply(213, "%ld", count);
- break; }
- default:
- reply(504, "SIZE not implemented for Type %c.", "?AEIL"[type]);
- }
-}
diff --git a/appl/ftp/ftpd/ftpd.8 b/appl/ftp/ftpd/ftpd.8
deleted file mode 100644
index ed6475f69f878508f5222ada884c4060677c879d..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/ftpd.8
+++ /dev/null
@@ -1,469 +0,0 @@
-.\" $NetBSD: ftpd.8,v 1.7 1995/04/11 02:44:53 cgd Exp $
-.\"
-.\" Copyright (c) 1985, 1988, 1991, 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.
-.\"
-.\" @(#)ftpd.8 8.2 (Berkeley) 4/19/94
-.\"
-.Dd April 19, 1997
-.Dt FTPD 8
-.Os BSD 4.2
-.Sh NAME
-.Nm ftpd
-.Nd
-Internet File Transfer Protocol server
-.Sh SYNOPSIS
-.Nm ftpd
-.Op Fl a Ar authmode
-.Op Fl dilv
-.Op Fl g Ar umask
-.Op Fl p Ar port
-.Op Fl T Ar maxtimeout
-.Op Fl t Ar timeout
-.Op Fl u Ar default umask
-.Sh DESCRIPTION
-.Nm Ftpd
-is the
-Internet File Transfer Protocol
-server process. The server uses the
-.Tn TCP
-protocol
-and listens at the port specified in the
-.Dq ftp
-service specification; see
-.Xr services 5 .
-.Pp
-Available options:
-.Bl -tag -width Ds
-.It Fl a
-Select the level of authentication required. Kerberised login can not
-be turned off. The default is to only allow kerberised login. Other
-possibilities can be turned on by giving a string of comma separated
-flags as argument to
-.Fl a .
-Recognised flags are:
-.Bl -tag -width plain
-.It Ar plain
-Allow logging in with plaintext password. The password can be a(n) OTP
-or an ordinary password.
-.It Ar otp
-Same as
-.Ar plain ,
-but only OTP is allowed.
-.It Ar ftp
-Allow anonymous login.
-.El
-
-The following combination modes exists for backwards compatibility:
-.Bl -tag -width plain
-.It Ar none
-Same as
-.Ar plain,ftp .
-.It Ar safe
-Same as
-.Ar ftp .
-.It Ar user
-Ignored.
-.El
-.It Fl d
-Debugging information is written to the syslog using LOG_FTP.
-.It Fl g
-Anonymous users will get a umask of
-.Ar umask .
-.It Fl i
-Open a socket and wait for a connection. This is mainly used for
-debugging when ftpd isn't started by inetd.
-.It Fl l
-Each successful and failed
-.Xr ftp 1
-session is logged using syslog with a facility of LOG_FTP.
-If this option is specified twice, the retrieve (get), store (put), append,
-delete, make directory, remove directory and rename operations and
-their filename arguments are also logged.
-.It Fl p
-Use
-.Ar port
-(a service name or number) instead of the default
-.Ar ftp/tcp .
-.It Fl T
-A client may also request a different timeout period;
-the maximum period allowed may be set to
-.Ar timeout
-seconds with the
-.Fl T
-option.
-The default limit is 2 hours.
-.It Fl t
-The inactivity timeout period is set to
-.Ar timeout
-seconds (the default is 15 minutes).
-.It Fl u
-Set the initial umask to something else than the default 027.
-.It Fl v
-Verbose mode.
-.El
-.Pp
-The file
-.Pa /etc/nologin
-can be used to disable ftp access.
-If the file exists,
-.Nm
-displays it and exits.
-If the file
-.Pa /etc/ftpwelcome
-exists,
-.Nm
-prints it before issuing the
-.Dq ready
-message.
-If the file
-.Pa /etc/motd
-exists,
-.Nm
-prints it after a successful login.
-.Pp
-The ftp server currently supports the following ftp requests.
-The case of the requests is ignored.
-.Bl -column "Request" -offset indent
-.It Request Ta "Description"
-.It ABOR Ta "abort previous command"
-.It ACCT Ta "specify account (ignored)"
-.It ALLO Ta "allocate storage (vacuously)"
-.It APPE Ta "append to a file"
-.It CDUP Ta "change to parent of current working directory"
-.It CWD Ta "change working directory"
-.It DELE Ta "delete a file"
-.It HELP Ta "give help information"
-.It LIST Ta "give list files in a directory" Pq Dq Li "ls -lgA"
-.It MKD Ta "make a directory"
-.It MDTM Ta "show last modification time of file"
-.It MODE Ta "specify data transfer" Em mode
-.It NLST Ta "give name list of files in directory"
-.It NOOP Ta "do nothing"
-.It PASS Ta "specify password"
-.It PASV Ta "prepare for server-to-server transfer"
-.It PORT Ta "specify data connection port"
-.It PWD Ta "print the current working directory"
-.It QUIT Ta "terminate session"
-.It REST Ta "restart incomplete transfer"
-.It RETR Ta "retrieve a file"
-.It RMD Ta "remove a directory"
-.It RNFR Ta "specify rename-from file name"
-.It RNTO Ta "specify rename-to file name"
-.It SITE Ta "non-standard commands (see next section)"
-.It SIZE Ta "return size of file"
-.It STAT Ta "return status of server"
-.It STOR Ta "store a file"
-.It STOU Ta "store a file with a unique name"
-.It STRU Ta "specify data transfer" Em structure
-.It SYST Ta "show operating system type of server system"
-.It TYPE Ta "specify data transfer" Em type
-.It USER Ta "specify user name"
-.It XCUP Ta "change to parent of current working directory (deprecated)"
-.It XCWD Ta "change working directory (deprecated)"
-.It XMKD Ta "make a directory (deprecated)"
-.It XPWD Ta "print the current working directory (deprecated)"
-.It XRMD Ta "remove a directory (deprecated)"
-.El
-.Pp
-The following commands are specified by RFC2228.
-.Bl -column Request -offset indent
-.It AUTH Ta "authentication/security mechanism"
-.It ADAT Ta "authentication/security data"
-.It PROT Ta "data channel protection level"
-.It PBSZ Ta "protection buffer size"
-.It MIC Ta "integrity protected command"
-.It CONF Ta "confidentiality protected command"
-.It ENC Ta "privacy protected command"
-.It CCC Ta "clear command channel"
-.El
-.Pp
-The following non-standard or
-.Tn UNIX
-specific commands are supported
-by the
-SITE request.
-.Pp
-.Bl -column Request -offset indent
-.It UMASK Ta change umask, (e.g.
-.Ic "SITE UMASK 002" )
-.It IDLE Ta set idle-timer, (e.g.
-.Ic "SITE IDLE 60" )
-.It CHMOD Ta change mode of a file (e.g.
-.Ic "SITE CHMOD 755 filename" )
-.It FIND Ta quickly find a specific file with GNU
-.Xr locate 1 .
-.It HELP Ta give help information.
-.El
-.Pp
-The following Kerberos related site commands are understood.
-.Bl -column Request -offset indent
-.It KAUTH Ta obtain remote tickets.
-.It KLIST Ta show remote tickets
-.El
-.Pp
-The remaining ftp requests specified in Internet RFC 959
-are
-recognized, but not implemented.
-MDTM and SIZE are not specified in RFC 959, but will appear in the
-next updated FTP RFC.
-.Pp
-The ftp server will abort an active file transfer only when the
-ABOR
-command is preceded by a Telnet "Interrupt Process" (IP)
-signal and a Telnet "Synch" signal in the command Telnet stream,
-as described in Internet RFC 959.
-If a
-STAT
-command is received during a data transfer, preceded by a Telnet IP
-and Synch, transfer status will be returned.
-.Pp
-.Nm Ftpd
-interprets file names according to the
-.Dq globbing
-conventions used by
-.Xr csh 1 .
-This allows users to utilize the metacharacters
-.Dq Li \&*?[]{}~ .
-.Pp
-.Nm Ftpd
-authenticates users according to these rules.
-.Pp
-.Bl -enum -offset indent
-.It
-If Kerberos authentication is used, the user must pass valid tickets
-and the principal must be allowed to login as the remote user.
-.It
-The login name must be in the password data base, and not have a null
-password (if kerberos is used the password field is not checked). In
-this case a password must be provided by the client before any file
-operations may be performed. If the user has an OTP key, the response
-from a successful USER command will include an OTP challenge. The
-client may choose to respond with a PASS command giving either a
-standard password or an OTP one-time password. The server will
-automatically determine which type of password it has been given and
-attempt to authenticate accordingly. See
-.Xr otp 1
-for more information on OTP authentication.
-.It
-The login name must not appear in the file
-.Pa /etc/ftpusers .
-.It
-The user must have a standard shell returned by
-.Xr getusershell 3 .
-.It
-If the user name appears in the file
-.Pa /etc/ftpchroot
-the session's root will be changed to the user's login directory by
-.Xr chroot 2
-as for an
-.Dq anonymous
-or
-.Dq ftp
-account (see next item). However, the user must still supply a password.
-This feature is intended as a compromise between a fully anonymous account
-and a fully privileged account. The account should also be set up as for an
-anonymous account.
-.It
-If the user name is
-.Dq anonymous
-or
-.Dq ftp ,
-an
-anonymous ftp account must be present in the password
-file (user
-.Dq ftp ) .
-In this case the user is allowed
-to log in by specifying any password (by convention an email address for
-the user should be used as the password).
-.El
-.Pp
-In the last case,
-.Nm ftpd
-takes special measures to restrict the client's access privileges.
-The server performs a
-.Xr chroot 2
-to the home directory of the
-.Dq ftp
-user.
-In order that system security is not breached, it is recommended
-that the
-.Dq ftp
-subtree be constructed with care, consider following these guidelines
-for anonymous ftp.
-
-In general all files should be owned by
-.Dq root ,
-and have non-write permissions (644 or 755 depending on the kind of
-file). No files should be owned or writable by
-.Dq ftp
-(possibly with exception for the
-.Pa ~ftp/incoming ,
-as specified below).
-.Bl -tag -width "~ftp/pub" -offset indent
-.It Pa ~ftp
-The
-.Dq ftp
-homedirectory should be owned by root.
-.It Pa ~ftp/bin
-The directory for external programs (such as
-.Xr ls 1 ) .
-These programs must either be statically linked, or you must setup an
-environment for dynamic linking when running chrooted.
-These programs will be used if present:
-.Bl -tag -width "locate" -offset indent
-.It ls
-Used when listing files.
-.It compress
-When retrieving a filename that ends in
-.Pa .Z ,
-and that file isn't present,
-.Nm
-will try to find the filename without
-.Pa .Z
-and compress it on the fly.
-.It gzip
-Same as compress, just with files ending in
-.Pa .gz .
-.It gtar
-Enables retrieval of whole directories as files ending in
-.Pa .tar .
-Can also be combined with compression. You must use GNU Tar (or some
-other that supports the
-.Fl z
-and
-.Fl Z
-flags).
-.It locate
-Will enable ``fast find'' with the
-.Ic SITE FIND
-command. You must also create a
-.Pa locatedb
-file in
-.Pa ~ftp/etc .
-.El
-.It Pa ~ftp/etc
-If you put copies of the
-.Xr passwd 5
-and
-.Xr group 5
-files here, ls will be able to produce owner names rather than
-numbers. Remember to remove any passwords from these files.
-
-The file
-.Pa motd ,
-if present, will be printed after a successful login.
-.It Pa ~ftp/pub
-Traditional place to put whatever you want to make public.
-.El
-
-If you want guests to be able to upload files, create a
-.Pa ~ftp/incoming
-directory owned by
-.Dq root ,
-and group
-.Dq ftp
-with mode 730 (make sure
-.Dq ftp
-is member of group
-.Dq ftp ) .
-The following restrictions apply to anonymous users:
-.Bl -bullet
-.It
-Directories created will have mode 700.
-.It
-Uploaded files will be created with an umask of 777, if not changed
-with the
-.Fl g
-option.
-.It
-These command are not accessible:
-.Ic DELE , RMD , RNTO , RNFR ,
-.Ic SITE UMASK ,
-and
-.Ic SITE CHMOD .
-.It
-Filenames must start with an alpha-numeric character, and consist of
-alpha-numeric characters or any of the following:
-.Li \&+
-(plus),
-.Li \&-
-(minus),
-.Li \&=
-(equal),
-.Li \&_
-(underscore),
-.Li \&.
-(period), and
-.Li \&,
-(comma).
-.El
-.Sh FILES
-.Bl -tag -width /etc/ftpwelcome -compact
-.It Pa /etc/ftpusers
-Access list for users.
-.It Pa /etc/ftpchroot
-List of normal users who should be chroot'd.
-.It Pa /etc/ftpwelcome
-Welcome notice.
-.It Pa /etc/motd
-Welcome notice after login.
-.It Pa /etc/nologin
-Displayed and access refused.
-.It Pa ~/.klogin
-Login access for Kerberos.
-.El
-.Sh SEE ALSO
-.Xr ftp 1 ,
-.Xr otp 1 ,
-.Xr getusershell 3 ,
-.Xr ftpusers 5 ,
-.Xr syslogd 8 ,
-.Sh STANDARDS
-.Bl -tag -compact -width "RFC 1938"
-.It Cm RFC 959
-FTP PROTOCOL SPECIFICATION
-.It Cm RFC 1938
-OTP Specification
-.It Cm RFC 2228
-FTP Security Extensions.
-.Sh BUGS
-The server must run as the super-user
-to create sockets with privileged port numbers. It maintains
-an effective user id of the logged in user, reverting to
-the super-user only when binding addresses to sockets. The
-possible security holes have been extensively
-scrutinized, but are possibly incomplete.
-.Sh HISTORY
-The
-.Nm
-command appeared in
-.Bx 4.2 .
diff --git a/appl/ftp/ftpd/ftpd.c b/appl/ftp/ftpd/ftpd.c
deleted file mode 100644
index 0414113b83c85ce379529a7cb5bc4fea84344658..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/ftpd.c
+++ /dev/null
@@ -1,2093 +0,0 @@
-/*
- * Copyright (c) 1985, 1988, 1990, 1992, 1993, 1994
- * 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.
- */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-RCSID("$Id$");
-#endif
-
-/*
- * FTP server.
- */
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_PARAM_H
-#include <sys/param.h>
-#endif
-#ifdef HAVE_SYS_STAT_H
-#include <sys/stat.h>
-#endif
-#ifdef HAVE_SYS_SOCKET_H
-#include <sys/socket.h>
-#endif
-#if defined(HAVE_SYS_IOCTL_H) && SunOS != 4
-#include <sys/ioctl.h>
-#endif
-#ifdef TIME_WITH_SYS_TIME
-#include <sys/time.h>
-#include <time.h>
-#elif defined(HAVE_SYS_TIME_H)
-#include <sys/time.h>
-#else
-#include <time.h>
-#endif
-#ifdef HAVE_SYS_RESOURCE_H
-#include <sys/resource.h>
-#endif
-#ifdef HAVE_SYS_WAIT_H
-#include <sys/wait.h>
-#endif
-
-#ifdef HAVE_NETINET_IN_H
-#include <netinet/in.h>
-#endif
-#ifdef HAVE_NETINET_IN_SYSTM_H
-#include <netinet/in_systm.h>
-#endif
-#ifdef HAVE_NETINET_IP_H
-#include <netinet/ip.h>
-#endif
-
-#ifdef HAVE_SYS_MMAN_H
-#include <sys/mman.h>
-#endif
-
-#define FTP_NAMES
-#include <arpa/ftp.h>
-#ifdef HAVE_ARPA_INET_H
-#include <arpa/inet.h>
-#endif
-#ifdef HAVE_ARPA_TELNET_H
-#include <arpa/telnet.h>
-#endif
-
-#include <ctype.h>
-#ifdef HAVE_DIRENT_H
-#include <dirent.h>
-#endif
-#include <errno.h>
-#ifdef HAVE_FCNTL_H
-#include <fcntl.h>
-#endif
-#include <glob.h>
-#include <limits.h>
-#ifdef HAVE_PWD_H
-#include <pwd.h>
-#endif
-#include <setjmp.h>
-#include <signal.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <stdarg.h>
-#include <string.h>
-#ifdef HAVE_SYSLOG_H
-#include <syslog.h>
-#endif
-#include <time.h>
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
-#ifdef HAVE_GRP_H
-#include <grp.h>
-#endif
-
-#include <err.h>
-
-#include "pathnames.h"
-#include "extern.h"
-#include "common.h"
-
-#include "auth.h"
-
-#include <krb.h>
-
-#include <kafs.h>
-#include "roken.h"
-
-#ifdef OTP
-#include <otp.h>
-#endif
-
-#ifdef SOCKS
-#include <socks.h>
-extern int LIBPREFIX(fclose) __P((FILE *));
-#endif
-
-void yyparse();
-
-#ifndef LOG_FTP
-#define LOG_FTP LOG_DAEMON
-#endif
-
-static char version[] = "Version 6.00";
-
-extern off_t restart_point;
-extern char cbuf[];
-
-struct sockaddr_in ctrl_addr;
-struct sockaddr_in data_source;
-struct sockaddr_in data_dest;
-struct sockaddr_in his_addr;
-struct sockaddr_in pasv_addr;
-
-int data;
-jmp_buf errcatch, urgcatch;
-int oobflag;
-int logged_in;
-struct passwd *pw;
-int debug = 0;
-int ftpd_timeout = 900; /* timeout after 15 minutes of inactivity */
-int maxtimeout = 7200;/* don't allow idle time to be set beyond 2 hours */
-int logging;
-int guest;
-int dochroot;
-int type;
-int form;
-int stru; /* avoid C keyword */
-int mode;
-int usedefault = 1; /* for data transfers */
-int pdata = -1; /* for passive mode */
-int transflag;
-off_t file_size;
-off_t byte_count;
-#if !defined(CMASK) || CMASK == 0
-#undef CMASK
-#define CMASK 027
-#endif
-int defumask = CMASK; /* default umask value */
-int guest_umask = 0777; /* Paranoia for anonymous users */
-char tmpline[10240];
-char hostname[MaxHostNameLen];
-char remotehost[MaxHostNameLen];
-static char ttyline[20];
-
-#define AUTH_PLAIN (1 << 0) /* allow sending passwords */
-#define AUTH_OTP (1 << 1) /* passwords are one-time */
-#define AUTH_FTP (1 << 2) /* allow anonymous login */
-
-static int auth_level = 0; /* Only allow kerberos login by default */
-
-/*
- * Timeout intervals for retrying connections
- * to hosts that don't accept PORT cmds. This
- * is a kludge, but given the problems with TCP...
- */
-#define SWAITMAX 90 /* wait at most 90 seconds */
-#define SWAITINT 5 /* interval between retries */
-
-int swaitmax = SWAITMAX;
-int swaitint = SWAITINT;
-
-#ifdef HAVE_SETPROCTITLE
-char proctitle[BUFSIZ]; /* initial part of title */
-#endif /* HAVE_SETPROCTITLE */
-
-#define LOGCMD(cmd, file) \
- if (logging > 1) \
- syslog(LOG_INFO,"%s %s%s", cmd, \
- *(file) == '/' ? "" : curdir(), file);
-#define LOGCMD2(cmd, file1, file2) \
- if (logging > 1) \
- syslog(LOG_INFO,"%s %s%s %s%s", cmd, \
- *(file1) == '/' ? "" : curdir(), file1, \
- *(file2) == '/' ? "" : curdir(), file2);
-#define LOGBYTES(cmd, file, cnt) \
- if (logging > 1) { \
- if (cnt == (off_t)-1) \
- syslog(LOG_INFO,"%s %s%s", cmd, \
- *(file) == '/' ? "" : curdir(), file); \
- else \
- syslog(LOG_INFO, "%s %s%s = %ld bytes", \
- cmd, (*(file) == '/') ? "" : curdir(), file, (long)cnt); \
- }
-
-static void ack (char *);
-static void myoob (int);
-static int checkuser (char *, char *);
-static int checkaccess (char *);
-static FILE *dataconn (char *, off_t, char *);
-static void dolog (struct sockaddr_in *);
-static void end_login (void);
-static FILE *getdatasock (char *);
-static char *gunique (char *);
-static RETSIGTYPE lostconn (int);
-static int receive_data (FILE *, FILE *);
-static void send_data (FILE *, FILE *);
-static struct passwd * sgetpwnam (char *);
-static void usage(void);
-
-static char *
-curdir(void)
-{
- static char path[MaxPathLen+1+1]; /* path + '/' + '\0' */
-
- if (getcwd(path, sizeof(path)-2) == NULL)
- return ("");
- if (path[1] != '\0') /* special case for root dir. */
- strcat(path, "/");
- /* For guest account, skip / since it's chrooted */
- return (guest ? path+1 : path);
-}
-
-#ifndef LINE_MAX
-#define LINE_MAX 1024
-#endif
-
-static int
-parse_auth_level(char *str)
-{
- char *p;
- int ret = 0;
- char *foo = NULL;
-
- for(p = strtok_r(str, ",", &foo);
- p;
- p = strtok_r(NULL, ",", &foo)) {
- if(strcmp(p, "user") == 0)
- ;
-#ifdef OTP
- else if(strcmp(p, "otp") == 0)
- ret |= AUTH_PLAIN|AUTH_OTP;
-#endif
- else if(strcmp(p, "ftp") == 0 ||
- strcmp(p, "safe") == 0)
- ret |= AUTH_FTP;
- else if(strcmp(p, "plain") == 0)
- ret |= AUTH_PLAIN;
- else if(strcmp(p, "none") == 0)
- ret |= AUTH_PLAIN|AUTH_FTP;
- else
- warnx("bad value for -a: `%s'", p);
- }
- return ret;
-}
-
-/*
- * Print usage and die.
- */
-
-static void
-usage (void)
-{
- fprintf (stderr,
- "Usage: %s [-d] [-i] [-g guest_umask] [-l] [-p port]"
- " [-t timeout] [-T max_timeout] [-u umask] [-v]"
- " [-a auth_level] \n",
- __progname);
- exit (1);
-}
-
-int
-main(int argc, char **argv)
-{
- int addrlen, ch, on = 1, tos;
- char *cp, line[LINE_MAX];
- FILE *fd;
- int not_inetd = 0;
- int port;
- struct servent *sp;
- char tkfile[1024];
-
- set_progname (argv[0]);
-
- /* detach from any tickets and tokens */
-
- snprintf(tkfile, sizeof(tkfile),
- "/tmp/ftp_%u", (unsigned)getpid());
- krb_set_tkt_string(tkfile);
- if(k_hasafs())
- k_setpag();
-
- sp = getservbyname("ftp", "tcp");
- if(sp)
- port = sp->s_port;
- else
- port = htons(21);
-
- while ((ch = getopt(argc, argv, "a:dg:ilp:t:T:u:v")) != EOF) {
- switch (ch) {
- case 'a':
- auth_level = parse_auth_level(optarg);
- break;
- case 'd':
- debug = 1;
- break;
-
- case 'i':
- not_inetd = 1;
- break;
- case 'g':
- {
- long val = 0;
-
- val = strtol(optarg, &optarg, 8);
- if (*optarg != '\0' || val < 0)
- warnx("bad value for -g");
- else
- guest_umask = val;
- break;
- }
- case 'l':
- logging++; /* > 1 == extra logging */
- break;
-
- case 'p':
- sp = getservbyname(optarg, "tcp");
- if(sp)
- port = sp->s_port;
- else
- if(isdigit(optarg[0]))
- port = htons(atoi(optarg));
- else
- warnx("bad value for -p");
- break;
-
- case 't':
- ftpd_timeout = atoi(optarg);
- if (maxtimeout < ftpd_timeout)
- maxtimeout = ftpd_timeout;
- break;
-
- case 'T':
- maxtimeout = atoi(optarg);
- if (ftpd_timeout > maxtimeout)
- ftpd_timeout = maxtimeout;
- break;
-
- case 'u':
- {
- long val = 0;
-
- val = strtol(optarg, &optarg, 8);
- if (*optarg != '\0' || val < 0)
- warnx("bad value for -u");
- else
- defumask = val;
- break;
- }
-
- case 'v':
- debug = 1;
- break;
-
- default:
- usage ();
- }
- }
-
- if(not_inetd)
- mini_inetd (port);
-
- /*
- * LOG_NDELAY sets up the logging connection immediately,
- * necessary for anonymous ftp's that chroot and can't do it later.
- */
- openlog("ftpd", LOG_PID | LOG_NDELAY, LOG_FTP);
- addrlen = sizeof(his_addr);
- if (getpeername(0, (struct sockaddr *)&his_addr, &addrlen) < 0) {
- syslog(LOG_ERR, "getpeername (%s): %m",argv[0]);
- exit(1);
- }
- addrlen = sizeof(ctrl_addr);
- if (getsockname(0, (struct sockaddr *)&ctrl_addr, &addrlen) < 0) {
- syslog(LOG_ERR, "getsockname (%s): %m",argv[0]);
- exit(1);
- }
-#if defined(IP_TOS) && defined(HAVE_SETSOCKOPT)
- tos = IPTOS_LOWDELAY;
- if (setsockopt(0, IPPROTO_IP, IP_TOS, (void *)&tos, sizeof(int)) < 0)
- syslog(LOG_WARNING, "setsockopt (IP_TOS): %m");
-#endif
- data_source.sin_port = htons(ntohs(ctrl_addr.sin_port) - 1);
-
- /* set this here so it can be put in wtmp */
- snprintf(ttyline, sizeof(ttyline), "ftp%u", (unsigned)getpid());
-
-
- /* freopen(_PATH_DEVNULL, "w", stderr); */
- signal(SIGPIPE, lostconn);
- signal(SIGCHLD, SIG_IGN);
-#ifdef SIGURG
- if (signal(SIGURG, myoob) == SIG_ERR)
- syslog(LOG_ERR, "signal: %m");
-#endif
-
- auth_init();
-
- /* Try to handle urgent data inline */
-#if defined(SO_OOBINLINE) && defined(HAVE_SETSOCKOPT)
- if (setsockopt(0, SOL_SOCKET, SO_OOBINLINE, (void *)&on,
- sizeof(on)) < 0)
- syslog(LOG_ERR, "setsockopt: %m");
-#endif
-
-#ifdef F_SETOWN
- if (fcntl(fileno(stdin), F_SETOWN, getpid()) == -1)
- syslog(LOG_ERR, "fcntl F_SETOWN: %m");
-#endif
- dolog(&his_addr);
- /*
- * Set up default state
- */
- data = -1;
- type = TYPE_A;
- form = FORM_N;
- stru = STRU_F;
- mode = MODE_S;
- tmpline[0] = '\0';
-
- /* If logins are disabled, print out the message. */
- if ((fd = fopen(_PATH_NOLOGIN,"r")) != NULL) {
- while (fgets(line, sizeof(line), fd) != NULL) {
- if ((cp = strchr(line, '\n')) != NULL)
- *cp = '\0';
- lreply(530, "%s", line);
- }
- fflush(stdout);
- fclose(fd);
- reply(530, "System not available.");
- exit(0);
- }
- if ((fd = fopen(_PATH_FTPWELCOME, "r")) != NULL) {
- while (fgets(line, sizeof(line), fd) != NULL) {
- if ((cp = strchr(line, '\n')) != NULL)
- *cp = '\0';
- lreply(220, "%s", line);
- }
- fflush(stdout);
- fclose(fd);
- /* reply(220,) must follow */
- }
- gethostname(hostname, sizeof(hostname));
- reply(220, "%s FTP server (%s+%s) ready.", hostname,
- version, krb4_version);
- setjmp(errcatch);
- for (;;)
- yyparse();
- /* NOTREACHED */
-}
-
-static RETSIGTYPE
-lostconn(int signo)
-{
-
- if (debug)
- syslog(LOG_DEBUG, "lost connection");
- dologout(-1);
-}
-
-/*
- * Helper function for sgetpwnam().
- */
-static char *
-sgetsave(char *s)
-{
- char *new = strdup(s);
-
- if (new == NULL) {
- perror_reply(421, "Local resource failure: malloc");
- dologout(1);
- /* NOTREACHED */
- }
- return new;
-}
-
-/*
- * Save the result of a getpwnam. Used for USER command, since
- * the data returned must not be clobbered by any other command
- * (e.g., globbing).
- */
-static struct passwd *
-sgetpwnam(char *name)
-{
- static struct passwd save;
- struct passwd *p;
-
- if ((p = k_getpwnam(name)) == NULL)
- return (p);
- if (save.pw_name) {
- free(save.pw_name);
- free(save.pw_passwd);
- free(save.pw_gecos);
- free(save.pw_dir);
- free(save.pw_shell);
- }
- save = *p;
- save.pw_name = sgetsave(p->pw_name);
- save.pw_passwd = sgetsave(p->pw_passwd);
- save.pw_gecos = sgetsave(p->pw_gecos);
- save.pw_dir = sgetsave(p->pw_dir);
- save.pw_shell = sgetsave(p->pw_shell);
- return (&save);
-}
-
-static int login_attempts; /* number of failed login attempts */
-static int askpasswd; /* had user command, ask for passwd */
-static char curname[10]; /* current USER name */
-#ifdef OTP
-OtpContext otp_ctx;
-#endif
-
-/*
- * USER command.
- * Sets global passwd pointer pw if named account exists and is acceptable;
- * sets askpasswd if a PASS command is expected. If logged in previously,
- * need to reset state. If name is "ftp" or "anonymous", the name is not in
- * _PATH_FTPUSERS, and ftp account exists, set guest and pw, then just return.
- * If account doesn't exist, ask for passwd anyway. Otherwise, check user
- * requesting login privileges. Disallow anyone who does not have a standard
- * shell as returned by getusershell(). Disallow anyone mentioned in the file
- * _PATH_FTPUSERS to allow people such as root and uucp to be avoided.
- */
-void
-user(char *name)
-{
- char *cp, *shell;
-
- if(auth_level == 0 && !auth_complete){
- reply(530, "No login allowed without authorization.");
- return;
- }
-
- if (logged_in) {
- if (guest) {
- reply(530, "Can't change user from guest login.");
- return;
- } else if (dochroot) {
- reply(530, "Can't change user from chroot user.");
- return;
- }
- end_login();
- }
-
- guest = 0;
- if (strcmp(name, "ftp") == 0 || strcmp(name, "anonymous") == 0) {
- if ((auth_level & AUTH_FTP) == 0 ||
- checkaccess("ftp") ||
- checkaccess("anonymous"))
- reply(530, "User %s access denied.", name);
- else if ((pw = sgetpwnam("ftp")) != NULL) {
- guest = 1;
- defumask = guest_umask; /* paranoia for incoming */
- askpasswd = 1;
- reply(331, "Guest login ok, type your name as password.");
- } else
- reply(530, "User %s unknown.", name);
- if (!askpasswd && logging)
- syslog(LOG_NOTICE,
- "ANONYMOUS FTP LOGIN REFUSED FROM %s(%s)",
- remotehost, inet_ntoa(his_addr.sin_addr));
- return;
- }
- if((auth_level & AUTH_PLAIN) == 0 && !auth_complete){
- reply(530, "Only authorized and anonymous login allowed.");
- return;
- }
- if ((pw = sgetpwnam(name))) {
- if ((shell = pw->pw_shell) == NULL || *shell == 0)
- shell = _PATH_BSHELL;
- while ((cp = getusershell()) != NULL)
- if (strcmp(cp, shell) == 0)
- break;
- endusershell();
-
- if (cp == NULL || checkaccess(name)) {
- reply(530, "User %s access denied.", name);
- if (logging)
- syslog(LOG_NOTICE,
- "FTP LOGIN REFUSED FROM %s(%s), %s",
- remotehost,
- inet_ntoa(his_addr.sin_addr),
- name);
- pw = (struct passwd *) NULL;
- return;
- }
- }
- if (logging)
- strncpy(curname, name, sizeof(curname)-1);
- if(auth_ok())
- ct->userok(name);
- else {
- char ss[256];
-
-#ifdef OTP
- if (otp_challenge(&otp_ctx, name, ss, sizeof(ss)) == 0) {
- reply(331, "Password %s for %s required.",
- ss, name);
- askpasswd = 1;
- } else
-#endif
- if ((auth_level & AUTH_OTP) == 0) {
- reply(331, "Password required for %s.", name);
- askpasswd = 1;
- } else {
- char *s;
-
-#ifdef OTP
- if (s = otp_error (&otp_ctx))
- lreply(530, "OTP: %s", s);
-#endif
- reply(530,
- "Only authorized, anonymous"
-#ifdef OTP
- " and OTP "
-#endif
- "login allowed.");
- }
-
- }
- /*
- * Delay before reading passwd after first failed
- * attempt to slow down passwd-guessing programs.
- */
- if (login_attempts)
- sleep(login_attempts);
-}
-
-/*
- * Check if a user is in the file "fname"
- */
-static int
-checkuser(char *fname, char *name)
-{
- FILE *fd;
- int found = 0;
- char *p, line[BUFSIZ];
-
- if ((fd = fopen(fname, "r")) != NULL) {
- while (fgets(line, sizeof(line), fd) != NULL)
- if ((p = strchr(line, '\n')) != NULL) {
- *p = '\0';
- if (line[0] == '#')
- continue;
- if (strcmp(line, name) == 0) {
- found = 1;
- break;
- }
- }
- fclose(fd);
- }
- return (found);
-}
-
-
-/*
- * Determine whether a user has access, based on information in
- * _PATH_FTPUSERS. The users are listed one per line, with `allow'
- * or `deny' after the username. If anything other than `allow', or
- * just nothing, is given after the username, `deny' is assumed.
- *
- * If the user is not found in the file, but the pseudo-user `*' is,
- * the permission is taken from that line.
- *
- * This preserves the old semantics where if a user was listed in the
- * file he was denied, otherwise he was allowed.
- *
- * Return 1 if the user is denied, or 0 if he is allowed. */
-
-static int
-match(const char *pattern, const char *string)
-{
-#ifdef HAVE_FNMATCH
- return fnmatch(pattern, string, FNM_NOESCAPE);
-#else
- return strcmp(pattern, "*") != 0 && strcmp(pattern, string) != 0;
-#endif
-}
-
-static int
-checkaccess(char *name)
-{
-#define ALLOWED 0
-#define NOT_ALLOWED 1
- FILE *fd;
- int allowed = ALLOWED;
- char *user, *perm, line[BUFSIZ];
- char *foo;
-
- fd = fopen(_PATH_FTPUSERS, "r");
-
- if(fd == NULL)
- return allowed;
-
- while (fgets(line, sizeof(line), fd) != NULL) {
- foo = NULL;
- user = strtok_r(line, " \t\n", &foo);
- if (user == NULL || user[0] == '#')
- continue;
- perm = strtok_r(NULL, " \t\n", &foo);
- if (match(user, name) == 0){
- if(perm && strcmp(perm, "allow") == 0)
- allowed = ALLOWED;
- else
- allowed = NOT_ALLOWED;
- break;
- }
- }
- fclose(fd);
- return allowed;
-}
-#undef ALLOWED
-#undef NOT_ALLOWED
-
-int do_login(int code, char *passwd)
-{
- FILE *fd;
- login_attempts = 0; /* this time successful */
- if (setegid((gid_t)pw->pw_gid) < 0) {
- reply(550, "Can't set gid.");
- return -1;
- }
- initgroups(pw->pw_name, pw->pw_gid);
-
- /* open wtmp before chroot */
- logwtmp(ttyline, pw->pw_name, remotehost);
- logged_in = 1;
-
- dochroot = checkuser(_PATH_FTPCHROOT, pw->pw_name);
- if (guest) {
- /*
- * We MUST do a chdir() after the chroot. Otherwise
- * the old current directory will be accessible as "."
- * outside the new root!
- */
- if (chroot(pw->pw_dir) < 0 || chdir("/") < 0) {
- reply(550, "Can't set guest privileges.");
- return -1;
- }
- } else if (dochroot) {
- if (chroot(pw->pw_dir) < 0 || chdir("/") < 0) {
- reply(550, "Can't change root.");
- return -1;
- }
- } else if (chdir(pw->pw_dir) < 0) {
- if (chdir("/") < 0) {
- reply(530, "User %s: can't change directory to %s.",
- pw->pw_name, pw->pw_dir);
- return -1;
- } else
- lreply(code, "No directory! Logging in with home=/");
- }
- if (seteuid((uid_t)pw->pw_uid) < 0) {
- reply(550, "Can't set uid.");
- return -1;
- }
- /*
- * Display a login message, if it exists.
- * N.B. reply(code,) must follow the message.
- */
- if ((fd = fopen(_PATH_FTPLOGINMESG, "r")) != NULL) {
- char *cp, line[LINE_MAX];
-
- while (fgets(line, sizeof(line), fd) != NULL) {
- if ((cp = strchr(line, '\n')) != NULL)
- *cp = '\0';
- lreply(code, "%s", line);
- }
- }
- if (guest) {
- reply(code, "Guest login ok, access restrictions apply.");
-#ifdef HAVE_SETPROCTITLE
- snprintf (proctitle, sizeof(proctitle),
- "%s: anonymous/%s",
- remotehost,
- passwd);
-#endif /* HAVE_SETPROCTITLE */
- if (logging)
- syslog(LOG_INFO, "ANONYMOUS FTP LOGIN FROM %s(%s), %s",
- remotehost,
- inet_ntoa(his_addr.sin_addr),
- passwd);
- } else {
- reply(code, "User %s logged in.", pw->pw_name);
-#ifdef HAVE_SETPROCTITLE
- snprintf(proctitle, sizeof(proctitle), "%s: %s", remotehost, pw->pw_name);
- setproctitle(proctitle);
-#endif /* HAVE_SETPROCTITLE */
- if (logging)
- syslog(LOG_INFO, "FTP LOGIN FROM %s(%s) as %s",
- remotehost,
- inet_ntoa(his_addr.sin_addr),
- pw->pw_name);
- }
- umask(defumask);
- return 0;
-}
-
-/*
- * Terminate login as previous user, if any, resetting state;
- * used when USER command is given or login fails.
- */
-static void
-end_login(void)
-{
-
- seteuid((uid_t)0);
- if (logged_in)
- logwtmp(ttyline, "", "");
- pw = NULL;
- logged_in = 0;
- guest = 0;
- dochroot = 0;
-}
-
-void
-pass(char *passwd)
-{
- int rval;
-
- /* some clients insists on sending a password */
- if (logged_in && askpasswd == 0){
- reply(230, "Dumpucko!");
- return;
- }
-
- if (logged_in || askpasswd == 0) {
- reply(503, "Login with USER first.");
- return;
- }
- askpasswd = 0;
- rval = 1;
- if (!guest) { /* "ftp" is only account allowed no password */
- if (pw == NULL)
- rval = 1; /* failure below */
-#ifdef OTP
- else if (otp_verify_user (&otp_ctx, passwd) == 0) {
- rval = 0;
- }
-#endif
- else if((auth_level & AUTH_OTP) == 0) {
- char realm[REALM_SZ];
- if((rval = krb_get_lrealm(realm, 1)) == KSUCCESS)
- rval = krb_verify_user(pw->pw_name, "", realm,
- passwd, 1, NULL, "");
- if (rval == KSUCCESS ) {
- chown (tkt_string(), pw->pw_uid, pw->pw_gid);
- if(k_hasafs())
- krb_afslog(0, 0);
- } else
- rval = unix_verify_user(pw->pw_name, passwd);
- } else {
- char *s;
-
-#ifdef OTP
- if (s = otp_error(&otp_ctx))
- lreply(530, "OTP: %s", s);
-#endif
- }
- memset (passwd, 0, strlen(passwd));
-
- /*
- * If rval == 1, the user failed the authentication
- * check above. If rval == 0, either Kerberos or
- * local authentication succeeded.
- */
- if (rval) {
- reply(530, "Login incorrect.");
- if (logging)
- syslog(LOG_NOTICE,
- "FTP LOGIN FAILED FROM %s(%s), %s",
- remotehost,
- inet_ntoa(his_addr.sin_addr),
- curname);
- pw = NULL;
- if (login_attempts++ >= 5) {
- syslog(LOG_NOTICE,
- "repeated login failures from %s(%s)",
- remotehost,
- inet_ntoa(his_addr.sin_addr));
- exit(0);
- }
- return;
- }
- }
- if(!do_login(230, passwd))
- return;
-
- /* Forget all about it... */
- end_login();
-}
-
-void
-retrieve(char *cmd, char *name)
-{
- FILE *fin = NULL, *dout;
- struct stat st;
- int (*closefunc) (FILE *);
- char line[BUFSIZ];
-
-
- if (cmd == 0) {
- fin = fopen(name, "r");
- closefunc = fclose;
- st.st_size = 0;
- if(fin == NULL){
- struct cmds {
- char *ext;
- char *cmd;
- } cmds[] = {
- {".tar", "/bin/gtar cPf - %s"},
- {".tar.gz", "/bin/gtar zcPf - %s"},
- {".tar.Z", "/bin/gtar ZcPf - %s"},
- {".gz", "/bin/gzip -c %s"},
- {".Z", "/bin/compress -c %s"},
- {NULL, NULL}
- };
- struct cmds *p;
- for(p = cmds; p->ext; p++){
- char *tail = name + strlen(name) - strlen(p->ext);
- char c = *tail;
-
- if(strcmp(tail, p->ext) == 0 &&
- (*tail = 0) == 0 &&
- access(name, R_OK) == 0){
- snprintf (line, sizeof(line), p->cmd, name);
- *tail = c;
- break;
- }
- *tail = c;
- }
- if(p->ext){
- fin = ftpd_popen(line, "r", 0, 0);
- closefunc = ftpd_pclose;
- st.st_size = -1;
- cmd = line;
- }
- }
- } else {
- snprintf(line, sizeof(line), cmd, name);
- name = line;
- fin = ftpd_popen(line, "r", 1, 0);
- closefunc = ftpd_pclose;
- st.st_size = -1;
- }
- if (fin == NULL) {
- if (errno != 0) {
- perror_reply(550, name);
- if (cmd == 0) {
- LOGCMD("get", name);
- }
- }
- return;
- }
- byte_count = -1;
- if (cmd == 0){
- if(fstat(fileno(fin), &st) < 0 || !S_ISREG(st.st_mode)) {
- reply(550, "%s: not a plain file.", name);
- goto done;
- }
- }
- if (restart_point) {
- if (type == TYPE_A) {
- off_t i, n;
- int c;
-
- n = restart_point;
- i = 0;
- while (i++ < n) {
- if ((c=getc(fin)) == EOF) {
- perror_reply(550, name);
- goto done;
- }
- if (c == '\n')
- i++;
- }
- } else if (lseek(fileno(fin), restart_point, SEEK_SET) < 0) {
- perror_reply(550, name);
- goto done;
- }
- }
- dout = dataconn(name, st.st_size, "w");
- if (dout == NULL)
- goto done;
- set_buffer_size(fileno(dout), 0);
- send_data(fin, dout);
- fclose(dout);
- data = -1;
- pdata = -1;
-done:
- if (cmd == 0)
- LOGBYTES("get", name, byte_count);
- (*closefunc)(fin);
-}
-
-/* filename sanity check */
-
-int
-filename_check(char *filename)
-{
- static const char good_chars[] = "+-=_,.";
- char *p;
-
- p = strrchr(filename, '/');
- if(p)
- filename = p + 1;
-
- p = filename;
-
- if(isalnum(*p)){
- p++;
- while(*p && (isalnum(*p) || strchr(good_chars, *p)))
- p++;
- if(*p == '\0')
- return 0;
- }
- lreply(553, "\"%s\" is an illegal filename.", filename);
- lreply(553, "The filename must start with an alphanumeric "
- "character and must only");
- reply(553, "consist of alphanumeric characters or any of the following: %s",
- good_chars);
- return 1;
-}
-
-void
-do_store(char *name, char *mode, int unique)
-{
- FILE *fout, *din;
- struct stat st;
- int (*closefunc) (FILE *);
-
- if(guest && filename_check(name))
- return;
- if (unique && stat(name, &st) == 0 &&
- (name = gunique(name)) == NULL) {
- LOGCMD(*mode == 'w' ? "put" : "append", name);
- return;
- }
-
- if (restart_point)
- mode = "r+";
- fout = fopen(name, mode);
- closefunc = fclose;
- if (fout == NULL) {
- perror_reply(553, name);
- LOGCMD(*mode == 'w' ? "put" : "append", name);
- return;
- }
- byte_count = -1;
- if (restart_point) {
- if (type == TYPE_A) {
- off_t i, n;
- int c;
-
- n = restart_point;
- i = 0;
- while (i++ < n) {
- if ((c=getc(fout)) == EOF) {
- perror_reply(550, name);
- goto done;
- }
- if (c == '\n')
- i++;
- }
- /*
- * We must do this seek to "current" position
- * because we are changing from reading to
- * writing.
- */
- if (fseek(fout, 0L, SEEK_CUR) < 0) {
- perror_reply(550, name);
- goto done;
- }
- } else if (lseek(fileno(fout), restart_point, SEEK_SET) < 0) {
- perror_reply(550, name);
- goto done;
- }
- }
- din = dataconn(name, (off_t)-1, "r");
- if (din == NULL)
- goto done;
- set_buffer_size(fileno(din), 1);
- if (receive_data(din, fout) == 0) {
- if (unique)
- reply(226, "Transfer complete (unique file name:%s).",
- name);
- else
- reply(226, "Transfer complete.");
- }
- fclose(din);
- data = -1;
- pdata = -1;
-done:
- LOGBYTES(*mode == 'w' ? "put" : "append", name, byte_count);
- (*closefunc)(fout);
-}
-
-static FILE *
-getdatasock(char *mode)
-{
- int on = 1, s, t, tries;
-
- if (data >= 0)
- return (fdopen(data, mode));
- seteuid((uid_t)0);
- s = socket(AF_INET, SOCK_STREAM, 0);
- if (s < 0)
- goto bad;
-#if defined(SO_REUSEADDR) && defined(HAVE_SETSOCKOPT)
- if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR,
- (void *) &on, sizeof(on)) < 0)
- goto bad;
-#endif
- /* anchor socket to avoid multi-homing problems */
- data_source.sin_family = AF_INET;
- data_source.sin_addr = ctrl_addr.sin_addr;
- for (tries = 1; ; tries++) {
- if (bind(s, (struct sockaddr *)&data_source,
- sizeof(data_source)) >= 0)
- break;
- if (errno != EADDRINUSE || tries > 10)
- goto bad;
- sleep(tries);
- }
- seteuid((uid_t)pw->pw_uid);
-#if defined(IP_TOS) && defined(HAVE_SETSOCKOPT)
- on = IPTOS_THROUGHPUT;
- if (setsockopt(s, IPPROTO_IP, IP_TOS, (void *)&on, sizeof(int)) < 0)
- syslog(LOG_WARNING, "setsockopt (IP_TOS): %m");
-#endif
- return (fdopen(s, mode));
-bad:
- /* Return the real value of errno (close may change it) */
- t = errno;
- seteuid((uid_t)pw->pw_uid);
- close(s);
- errno = t;
- return (NULL);
-}
-
-static FILE *
-dataconn(char *name, off_t size, char *mode)
-{
- char sizebuf[32];
- FILE *file;
- int retry = 0, tos;
-
- file_size = size;
- byte_count = 0;
- if (size != (off_t) -1)
- snprintf(sizebuf, sizeof(sizebuf), " (%ld bytes)", size);
- else
- strcpy(sizebuf, "");
- if (pdata >= 0) {
- struct sockaddr_in from;
- int s, fromlen = sizeof(from);
-
- s = accept(pdata, (struct sockaddr *)&from, &fromlen);
- if (s < 0) {
- reply(425, "Can't open data connection.");
- close(pdata);
- pdata = -1;
- return (NULL);
- }
- close(pdata);
- pdata = s;
-#if defined(IP_TOS) && defined(HAVE_SETSOCKOPT)
- tos = IPTOS_THROUGHPUT;
- setsockopt(s, IPPROTO_IP, IP_TOS, (void *)&tos,
- sizeof(int));
-#endif
- reply(150, "Opening %s mode data connection for '%s'%s.",
- type == TYPE_A ? "ASCII" : "BINARY", name, sizebuf);
- return (fdopen(pdata, mode));
- }
- if (data >= 0) {
- reply(125, "Using existing data connection for '%s'%s.",
- name, sizebuf);
- usedefault = 1;
- return (fdopen(data, mode));
- }
- if (usedefault)
- data_dest = his_addr;
- usedefault = 1;
- file = getdatasock(mode);
- if (file == NULL) {
- reply(425, "Can't create data socket (%s,%d): %s.",
- inet_ntoa(data_source.sin_addr),
- ntohs(data_source.sin_port), strerror(errno));
- return (NULL);
- }
- data = fileno(file);
- while (connect(data, (struct sockaddr *)&data_dest,
- sizeof(data_dest)) < 0) {
- if (errno == EADDRINUSE && retry < swaitmax) {
- sleep((unsigned) swaitint);
- retry += swaitint;
- continue;
- }
- perror_reply(425, "Can't build data connection");
- fclose(file);
- data = -1;
- return (NULL);
- }
- reply(150, "Opening %s mode data connection for '%s'%s.",
- type == TYPE_A ? "ASCII" : "BINARY", name, sizebuf);
- return (file);
-}
-
-/*
- * Tranfer the contents of "instr" to "outstr" peer using the appropriate
- * encapsulation of the data subject * to Mode, Structure, and Type.
- *
- * NB: Form isn't handled.
- */
-static void
-send_data(FILE *instr, FILE *outstr)
-{
- int c, cnt, filefd, netfd;
- static char *buf;
- static size_t bufsize;
- int i = 0;
- char s[1024];
-
- transflag++;
- if (setjmp(urgcatch)) {
- transflag = 0;
- return;
- }
- switch (type) {
-
- case TYPE_A:
- while ((c = getc(instr)) != EOF) {
- byte_count++;
- if(i > 1022){
- auth_write(fileno(outstr), s, i);
- i = 0;
- }
- if(c == '\n')
- s[i++] = '\r';
- s[i++] = c;
- }
- if(i)
- auth_write(fileno(outstr), s, i);
- auth_write(fileno(outstr), s, 0);
- fflush(outstr);
- transflag = 0;
- if (ferror(instr))
- goto file_err;
- if (ferror(outstr))
- goto data_err;
- reply(226, "Transfer complete.");
- return;
-
- case TYPE_I:
- case TYPE_L:
-#if defined(HAVE_MMAP) && !defined(NO_MMAP)
-#ifndef MAP_FAILED
-#define MAP_FAILED (-1)
-#endif
- {
- struct stat st;
- char *chunk;
- int in = fileno(instr);
- if(fstat(in, &st) == 0 && S_ISREG(st.st_mode)) {
- chunk = mmap(0, st.st_size, PROT_READ, MAP_SHARED, in, 0);
- if(chunk != (void *)MAP_FAILED) {
- cnt = st.st_size - restart_point;
- auth_write(fileno(outstr),
- chunk + restart_point,
- cnt);
- munmap(chunk, st.st_size);
- auth_write(fileno(outstr), NULL, 0);
- byte_count = cnt;
- transflag = 0;
- }
- }
- }
-
-#endif
- if(transflag){
- struct stat st;
-
- netfd = fileno(outstr);
- filefd = fileno(instr);
- buf = alloc_buffer (buf, &bufsize,
- fstat(filefd, &st) >= 0 ? &st : NULL);
- if (buf == NULL) {
- transflag = 0;
- perror_reply(451, "Local resource failure: malloc");
- return;
- }
- while ((cnt = read(filefd, buf, bufsize)) > 0 &&
- auth_write(netfd, buf, cnt) == cnt)
- byte_count += cnt;
- auth_write(netfd, buf, 0); /* to end an encrypted stream */
- transflag = 0;
- if (cnt != 0) {
- if (cnt < 0)
- goto file_err;
- goto data_err;
- }
- }
- reply(226, "Transfer complete.");
- return;
- default:
- transflag = 0;
- reply(550, "Unimplemented TYPE %d in send_data", type);
- return;
- }
-
-data_err:
- transflag = 0;
- perror_reply(426, "Data connection");
- return;
-
-file_err:
- transflag = 0;
- perror_reply(551, "Error on input file");
-}
-
-/*
- * Transfer data from peer to "outstr" using the appropriate encapulation of
- * the data subject to Mode, Structure, and Type.
- *
- * N.B.: Form isn't handled.
- */
-static int
-receive_data(FILE *instr, FILE *outstr)
-{
- int cnt, bare_lfs = 0;
- static char *buf;
- static size_t bufsize;
- struct stat st;
-
- transflag++;
- if (setjmp(urgcatch)) {
- transflag = 0;
- return (-1);
- }
-
- buf = alloc_buffer (buf, &bufsize,
- fstat(fileno(outstr), &st) >= 0 ? &st : NULL);
- if (buf == NULL) {
- transflag = 0;
- perror_reply(451, "Local resource failure: malloc");
- return -1;
- }
-
- switch (type) {
-
- case TYPE_I:
- case TYPE_L:
- while ((cnt = auth_read(fileno(instr), buf, bufsize)) > 0) {
- if (write(fileno(outstr), buf, cnt) != cnt)
- goto file_err;
- byte_count += cnt;
- }
- if (cnt < 0)
- goto data_err;
- transflag = 0;
- return (0);
-
- case TYPE_E:
- reply(553, "TYPE E not implemented.");
- transflag = 0;
- return (-1);
-
- case TYPE_A:
- {
- char *p, *q;
- int cr_flag = 0;
- while ((cnt = auth_read(fileno(instr),
- buf + cr_flag,
- bufsize - cr_flag)) > 0){
- byte_count += cnt;
- cnt += cr_flag;
- cr_flag = 0;
- for(p = buf, q = buf; p < buf + cnt;) {
- if(*p == '\n')
- bare_lfs++;
- if(*p == '\r')
- if(p == buf + cnt - 1){
- cr_flag = 1;
- p++;
- continue;
- }else if(p[1] == '\n'){
- *q++ = '\n';
- p += 2;
- continue;
- }
- *q++ = *p++;
- }
- fwrite(buf, q - buf, 1, outstr);
- if(cr_flag)
- buf[0] = '\r';
- }
- if(cr_flag)
- putc('\r', outstr);
- fflush(outstr);
- if (ferror(instr))
- goto data_err;
- if (ferror(outstr))
- goto file_err;
- transflag = 0;
- if (bare_lfs) {
- lreply(226, "WARNING! %d bare linefeeds received in ASCII mode\r\n"
- " File may not have transferred correctly.\r\n",
- bare_lfs);
- }
- return (0);
- }
- default:
- reply(550, "Unimplemented TYPE %d in receive_data", type);
- transflag = 0;
- return (-1);
- }
-
-data_err:
- transflag = 0;
- perror_reply(426, "Data Connection");
- return (-1);
-
-file_err:
- transflag = 0;
- perror_reply(452, "Error writing file");
- return (-1);
-}
-
-void
-statfilecmd(char *filename)
-{
- FILE *fin;
- int c;
- char line[LINE_MAX];
-
- snprintf(line, sizeof(line), "/bin/ls -la %s", filename);
- fin = ftpd_popen(line, "r", 1, 0);
- lreply(211, "status of %s:", filename);
- while ((c = getc(fin)) != EOF) {
- if (c == '\n') {
- if (ferror(stdout)){
- perror_reply(421, "control connection");
- ftpd_pclose(fin);
- dologout(1);
- /* NOTREACHED */
- }
- if (ferror(fin)) {
- perror_reply(551, filename);
- ftpd_pclose(fin);
- return;
- }
- putc('\r', stdout);
- }
- putc(c, stdout);
- }
- ftpd_pclose(fin);
- reply(211, "End of Status");
-}
-
-void
-statcmd(void)
-{
-#if 0
- struct sockaddr_in *sin;
- u_char *a, *p;
-
- lreply(211, "%s FTP server status:", hostname, version);
- printf(" %s\r\n", version);
- printf(" Connected to %s", remotehost);
- if (!isdigit(remotehost[0]))
- printf(" (%s)", inet_ntoa(his_addr.sin_addr));
- printf("\r\n");
- if (logged_in) {
- if (guest)
- printf(" Logged in anonymously\r\n");
- else
- printf(" Logged in as %s\r\n", pw->pw_name);
- } else if (askpasswd)
- printf(" Waiting for password\r\n");
- else
- printf(" Waiting for user name\r\n");
- printf(" TYPE: %s", typenames[type]);
- if (type == TYPE_A || type == TYPE_E)
- printf(", FORM: %s", formnames[form]);
- if (type == TYPE_L)
-#if NBBY == 8
- printf(" %d", NBBY);
-#else
- printf(" %d", bytesize); /* need definition! */
-#endif
- printf("; STRUcture: %s; transfer MODE: %s\r\n",
- strunames[stru], modenames[mode]);
- if (data != -1)
- printf(" Data connection open\r\n");
- else if (pdata != -1) {
- printf(" in Passive mode");
- sin = &pasv_addr;
- goto printaddr;
- } else if (usedefault == 0) {
- printf(" PORT");
- sin = &data_dest;
-printaddr:
- a = (u_char *) &sin->sin_addr;
- p = (u_char *) &sin->sin_port;
-#define UC(b) (((int) b) & 0xff)
- printf(" (%d,%d,%d,%d,%d,%d)\r\n", UC(a[0]),
- UC(a[1]), UC(a[2]), UC(a[3]), UC(p[0]), UC(p[1]));
-#undef UC
- } else
- printf(" No data connection\r\n");
-#endif
- reply(211, "End of status");
-}
-
-void
-fatal(char *s)
-{
-
- reply(451, "Error in server: %s\n", s);
- reply(221, "Closing connection due to server error.");
- dologout(0);
- /* NOTREACHED */
-}
-
-static void
-int_reply(int, char *, const char *, va_list)
-#ifdef __GNUC__
-__attribute__ ((format (printf, 3, 0)))
-#endif
-;
-
-static void
-int_reply(int n, char *c, const char *fmt, va_list ap)
-{
- char buf[10240];
- char *p;
- p=buf;
- if(n){
- snprintf(p, sizeof(buf), "%d%s", n, c);
- p+=strlen(p);
- }
- vsnprintf(p, sizeof(buf) - strlen(p), fmt, ap);
- p+=strlen(p);
- snprintf(p, sizeof(buf) - strlen(p), "\r\n");
- p+=strlen(p);
- auth_printf("%s", buf);
- fflush(stdout);
- if (debug)
- syslog(LOG_DEBUG, "<--- %s- ", buf);
-}
-
-void
-reply(int n, const char *fmt, ...)
-{
- va_list ap;
- va_start(ap, fmt);
- int_reply(n, " ", fmt, ap);
- delete_ftp_command();
- va_end(ap);
-}
-
-void
-lreply(int n, const char *fmt, ...)
-{
- va_list ap;
- va_start(ap, fmt);
- int_reply(n, "-", fmt, ap);
- va_end(ap);
-}
-
-void
-nreply(const char *fmt, ...)
-{
- va_list ap;
- va_start(ap, fmt);
- int_reply(0, NULL, fmt, ap);
- va_end(ap);
-}
-
-static void
-ack(char *s)
-{
-
- reply(250, "%s command successful.", s);
-}
-
-void
-nack(char *s)
-{
-
- reply(502, "%s command not implemented.", s);
-}
-
-/* ARGSUSED */
-void
-yyerror(char *s)
-{
- char *cp;
-
- if ((cp = strchr(cbuf,'\n')))
- *cp = '\0';
- reply(500, "'%s': command not understood.", cbuf);
-}
-
-void
-do_delete(char *name)
-{
- struct stat st;
-
- LOGCMD("delete", name);
- if (stat(name, &st) < 0) {
- perror_reply(550, name);
- return;
- }
- if ((st.st_mode&S_IFMT) == S_IFDIR) {
- if (rmdir(name) < 0) {
- perror_reply(550, name);
- return;
- }
- goto done;
- }
- if (unlink(name) < 0) {
- perror_reply(550, name);
- return;
- }
-done:
- ack("DELE");
-}
-
-void
-cwd(char *path)
-{
-
- if (chdir(path) < 0)
- perror_reply(550, path);
- else
- ack("CWD");
-}
-
-void
-makedir(char *name)
-{
-
- LOGCMD("mkdir", name);
- if(guest && filename_check(name))
- return;
- if (mkdir(name, 0777) < 0)
- perror_reply(550, name);
- else{
- if(guest)
- chmod(name, 0700); /* guest has umask 777 */
- reply(257, "MKD command successful.");
- }
-}
-
-void
-removedir(char *name)
-{
-
- LOGCMD("rmdir", name);
- if (rmdir(name) < 0)
- perror_reply(550, name);
- else
- ack("RMD");
-}
-
-void
-pwd(void)
-{
- char path[MaxPathLen + 1];
- char *ret;
-
- /* SunOS has a broken getcwd that does popen(pwd) (!!!), this
- * failes miserably when running chroot
- */
- ret = getcwd(path, sizeof(path));
- if (ret == NULL)
- reply(550, "%s.", strerror(errno));
- else
- reply(257, "\"%s\" is current directory.", path);
-}
-
-char *
-renamefrom(char *name)
-{
- struct stat st;
-
- if (stat(name, &st) < 0) {
- perror_reply(550, name);
- return NULL;
- }
- reply(350, "File exists, ready for destination name");
- return (name);
-}
-
-void
-renamecmd(char *from, char *to)
-{
-
- LOGCMD2("rename", from, to);
- if(guest && filename_check(to))
- return;
- if (rename(from, to) < 0)
- perror_reply(550, "rename");
- else
- ack("RNTO");
-}
-
-static void
-dolog(struct sockaddr_in *sin)
-{
- inaddr2str (sin->sin_addr, remotehost, sizeof(remotehost));
-#ifdef HAVE_SETPROCTITLE
- snprintf(proctitle, sizeof(proctitle), "%s: connected", remotehost);
- setproctitle(proctitle);
-#endif /* HAVE_SETPROCTITLE */
-
- if (logging)
- syslog(LOG_INFO, "connection from %s(%s)",
- remotehost,
- inet_ntoa(his_addr.sin_addr));
-}
-
-/*
- * Record logout in wtmp file
- * and exit with supplied status.
- */
-void
-dologout(int status)
-{
- transflag = 0;
- if (logged_in) {
- seteuid((uid_t)0);
- logwtmp(ttyline, "", "");
- cond_kdestroy();
- }
- /* beware of flushing buffers after a SIGPIPE */
-#ifdef XXX
- exit(status);
-#else
- _exit(status);
-#endif
-}
-
-void abor(void)
-{
-}
-
-static void
-myoob(int signo)
-{
-#if 0
- char *cp;
-#endif
-
- /* only process if transfer occurring */
- if (!transflag)
- return;
-
- /* This is all XXX */
- oobflag = 1;
- /* if the command resulted in a new command,
- parse that as well */
- do{
- yyparse();
- } while(ftp_command);
- oobflag = 0;
-
-#if 0
- cp = tmpline;
- if (getline(cp, 7) == NULL) {
- reply(221, "You could at least say goodbye.");
- dologout(0);
- }
- upper(cp);
- if (strcmp(cp, "ABOR\r\n") == 0) {
- tmpline[0] = '\0';
- reply(426, "Transfer aborted. Data connection closed.");
- reply(226, "Abort successful");
- longjmp(urgcatch, 1);
- }
- if (strcmp(cp, "STAT\r\n") == 0) {
- if (file_size != (off_t) -1)
- reply(213, "Status: %ld of %ld bytes transferred",
- (long)byte_count,
- (long)file_size);
- else
- reply(213, "Status: %ld bytes transferred"
- (long)byte_count);
- }
-#endif
-}
-
-/*
- * Note: a response of 425 is not mentioned as a possible response to
- * the PASV command in RFC959. However, it has been blessed as
- * a legitimate response by Jon Postel in a telephone conversation
- * with Rick Adams on 25 Jan 89.
- */
-void
-passive(void)
-{
- int len;
- char *p, *a;
-
- pdata = socket(AF_INET, SOCK_STREAM, 0);
- if (pdata < 0) {
- perror_reply(425, "Can't open passive connection");
- return;
- }
- pasv_addr = ctrl_addr;
- pasv_addr.sin_port = 0;
- seteuid((uid_t)0);
- if (bind(pdata, (struct sockaddr *)&pasv_addr, sizeof(pasv_addr)) < 0) {
- seteuid((uid_t)pw->pw_uid);
- goto pasv_error;
- }
- seteuid((uid_t)pw->pw_uid);
- len = sizeof(pasv_addr);
- if (getsockname(pdata, (struct sockaddr *) &pasv_addr, &len) < 0)
- goto pasv_error;
- if (listen(pdata, 1) < 0)
- goto pasv_error;
- a = (char *) &pasv_addr.sin_addr;
- p = (char *) &pasv_addr.sin_port;
-
-#define UC(b) (((int) b) & 0xff)
-
- reply(227, "Entering Passive Mode (%d,%d,%d,%d,%d,%d)", UC(a[0]),
- UC(a[1]), UC(a[2]), UC(a[3]), UC(p[0]), UC(p[1]));
- return;
-
-pasv_error:
- close(pdata);
- pdata = -1;
- perror_reply(425, "Can't open passive connection");
- return;
-}
-
-/*
- * Generate unique name for file with basename "local".
- * The file named "local" is already known to exist.
- * Generates failure reply on error.
- */
-static char *
-gunique(char *local)
-{
- static char new[MaxPathLen];
- struct stat st;
- int count;
- char *cp;
-
- cp = strrchr(local, '/');
- if (cp)
- *cp = '\0';
- if (stat(cp ? local : ".", &st) < 0) {
- perror_reply(553, cp ? local : ".");
- return NULL;
- }
- if (cp)
- *cp = '/';
- for (count = 1; count < 100; count++) {
- snprintf (new, sizeof(new), "%s.%d", local, count);
- if (stat(new, &st) < 0)
- return (new);
- }
- reply(452, "Unique file name cannot be created.");
- return (NULL);
-}
-
-/*
- * Format and send reply containing system error number.
- */
-void
-perror_reply(int code, char *string)
-{
- reply(code, "%s: %s.", string, strerror(errno));
-}
-
-static char *onefile[] = {
- "",
- 0
-};
-
-void
-send_file_list(char *whichf)
-{
- struct stat st;
- DIR *dirp = NULL;
- struct dirent *dir;
- FILE *dout = NULL;
- char **dirlist, *dirname;
- int simple = 0;
- int freeglob = 0;
- glob_t gl;
- char buf[MaxPathLen];
-
- if (strpbrk(whichf, "~{[*?") != NULL) {
- int flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE;
-
- memset(&gl, 0, sizeof(gl));
- freeglob = 1;
- if (glob(whichf, flags, 0, &gl)) {
- reply(550, "not found");
- goto out;
- } else if (gl.gl_pathc == 0) {
- errno = ENOENT;
- perror_reply(550, whichf);
- goto out;
- }
- dirlist = gl.gl_pathv;
- } else {
- onefile[0] = whichf;
- dirlist = onefile;
- simple = 1;
- }
-
- if (setjmp(urgcatch)) {
- transflag = 0;
- goto out;
- }
- while ((dirname = *dirlist++)) {
- if (stat(dirname, &st) < 0) {
- /*
- * If user typed "ls -l", etc, and the client
- * used NLST, do what the user meant.
- */
- if (dirname[0] == '-' && *dirlist == NULL &&
- transflag == 0) {
- retrieve("/bin/ls %s", dirname);
- goto out;
- }
- perror_reply(550, whichf);
- if (dout != NULL) {
- fclose(dout);
- transflag = 0;
- data = -1;
- pdata = -1;
- }
- goto out;
- }
-
- if (S_ISREG(st.st_mode)) {
- if (dout == NULL) {
- dout = dataconn("file list", (off_t)-1, "w");
- if (dout == NULL)
- goto out;
- transflag++;
- }
- snprintf(buf, sizeof(buf), "%s%s\n", dirname,
- type == TYPE_A ? "\r" : "");
- auth_write(fileno(dout), buf, strlen(buf));
- byte_count += strlen(dirname) + 1;
- continue;
- } else if (!S_ISDIR(st.st_mode))
- continue;
-
- if ((dirp = opendir(dirname)) == NULL)
- continue;
-
- while ((dir = readdir(dirp)) != NULL) {
- char nbuf[MaxPathLen];
-
- if (!strcmp(dir->d_name, "."))
- continue;
- if (!strcmp(dir->d_name, ".."))
- continue;
-
- snprintf(nbuf, sizeof(nbuf), "%s/%s", dirname, dir->d_name);
-
- /*
- * We have to do a stat to insure it's
- * not a directory or special file.
- */
- if (simple || (stat(nbuf, &st) == 0 &&
- S_ISREG(st.st_mode))) {
- if (dout == NULL) {
- dout = dataconn("file list", (off_t)-1, "w");
- if (dout == NULL)
- goto out;
- transflag++;
- }
- if(strncmp(nbuf, "./", 2) == 0)
- snprintf(buf, sizeof(buf), "%s%s\n", nbuf +2,
- type == TYPE_A ? "\r" : "");
- else
- snprintf(buf, sizeof(buf), "%s%s\n", nbuf,
- type == TYPE_A ? "\r" : "");
- auth_write(fileno(dout), buf, strlen(buf));
- byte_count += strlen(nbuf) + 1;
- }
- }
- closedir(dirp);
- }
- if (dout == NULL)
- reply(550, "No files found.");
- else if (ferror(dout) != 0)
- perror_reply(550, "Data connection");
- else
- reply(226, "Transfer complete.");
-
- transflag = 0;
- if (dout != NULL){
- auth_write(fileno(dout), buf, 0); /* XXX flush */
-
- fclose(dout);
- }
- data = -1;
- pdata = -1;
-out:
- if (freeglob) {
- freeglob = 0;
- globfree(&gl);
- }
-}
-
-
-int
-find(char *pattern)
-{
- char line[1024];
- FILE *f;
-
- snprintf(line, sizeof(line),
- "/bin/locate -d %s %s",
- ftp_rooted("/etc/locatedb"),
- pattern);
- f = ftpd_popen(line, "r", 1, 1);
- if(f == NULL){
- perror_reply(550, "/bin/locate");
- return 1;
- }
- lreply(200, "Output from find.");
- while(fgets(line, sizeof(line), f)){
- if(line[strlen(line)-1] == '\n')
- line[strlen(line)-1] = 0;
- nreply("%s", line);
- }
- reply(200, "Done");
- ftpd_pclose(f);
- return 0;
-}
-
diff --git a/appl/ftp/ftpd/ftpusers.5 b/appl/ftp/ftpd/ftpusers.5
deleted file mode 100644
index 549ff5b80c228c4f1a0d44b13f727c9e324eb1e2..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/ftpusers.5
+++ /dev/null
@@ -1,38 +0,0 @@
-.\" $Id$
-.\"
-.Dd May 7, 1997
-.Dt FTPUSERS 5
-.Os KTH-KRB
-.Sh NAME
-.Pa /etc/ftpusers
-.Nd
-FTP access list file.
-.Sh DESCRIPTION
-.Pa /etc/ftpusers
-contains a list of users that should be allowed or denied FTP
-access. Each line contains a user, optionally followed by
-.Dq allow
-(anything but
-.Dq allow
-is ignored). The semi-user
-.Dq *
-matches any user. Users that has an explicit
-.Dq allow ,
-or that does not match any line, are allowed access. Anyone else is
-denied access.
-
-Note that this is compatible with the old format, where this file
-contained a list of users that should be denied access.
-.Sh EXAMPLES
-This will deny anyone but
-.Dq foo
-and
-.Dq bar
-to use FTP:
-.Bd -literal
-foo allow
-bar allow
-*
-.Ed
-.Sh SEE ALSO
-.Xr ftpd 8
diff --git a/appl/ftp/ftpd/kauth.c b/appl/ftp/ftpd/kauth.c
deleted file mode 100644
index 6cf302de939d3dd1aaffb4c9a21070fbf94e86f9..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/kauth.c
+++ /dev/null
@@ -1,384 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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>
-#endif
-
-RCSID("$Id$");
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <time.h>
-#ifdef HAVE_SYS_TIME_H
-#include <sys/time.h>
-#endif
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-
-#include <roken.h>
-
-#include <des.h>
-#include <krb.h>
-#include <kafs.h>
-
-#include "extern.h"
-#include "krb4.h"
-#include "auth.h"
-#include "base64.h"
-
-static KTEXT_ST cip;
-static unsigned int lifetime;
-static time_t local_time;
-
-static krb_principal pr;
-
-static int do_destroy_tickets = 1;
-
-static int
-save_tkt(char *user, char *instance, char *realm, void *arg,
- int (*key_proc)(char*, char*, char*, void*, des_cblock*), KTEXT *cipp)
-{
- local_time = time(0);
- memmove(&cip, *cipp, sizeof(cip));
- return -1;
-}
-
-static int
-store_ticket(KTEXT cip)
-{
- char *ptr;
- des_cblock session;
- krb_principal sp;
- unsigned char kvno;
- KTEXT_ST tkt;
- int left = cip->length;
-
- int kerror;
-
- ptr = (char *) cip->dat;
-
- /* extract session key */
- memmove(session, ptr, 8);
- ptr += 8;
- left -= 8;
-
- if (strnlen(ptr, left) == left)
- return(INTK_BADPW);
-
- /* extract server's name */
- strcpy(sp.name, ptr);
- ptr += strlen(sp.name) + 1;
- left -= strlen(sp.name) + 1;
-
- if (strnlen(ptr, left) == left)
- return(INTK_BADPW);
-
- /* extract server's instance */
- strcpy(sp.instance, ptr);
- ptr += strlen(sp.instance) + 1;
- left -= strlen(sp.instance) + 1;
-
- if (strnlen(ptr, left) == left)
- return(INTK_BADPW);
-
- /* extract server's realm */
- strcpy(sp.realm,ptr);
- ptr += strlen(sp.realm) + 1;
- left -= strlen(sp.realm) + 1;
-
- if(left < 3)
- return INTK_BADPW;
- /* extract ticket lifetime, server key version, ticket length */
- /* be sure to avoid sign extension on lifetime! */
- lifetime = (unsigned char) ptr[0];
- kvno = (unsigned char) ptr[1];
- tkt.length = (unsigned char) ptr[2];
- ptr += 3;
- left -= 3;
-
- if (tkt.length > left)
- return(INTK_BADPW);
-
- /* extract ticket itself */
- memmove(tkt.dat, ptr, tkt.length);
- ptr += tkt.length;
- left -= tkt.length;
-
- /* Here is where the time should be verified against the KDC.
- * Unfortunately everything is sent in host byte order (receiver
- * makes wrong) , and at this stage there is no way for us to know
- * which byteorder the KDC has. So we simply ignore the time,
- * there are no security risks with this, the only thing that can
- * happen is that we might receive a replayed ticket, which could
- * at most be useless.
- */
-
-#if 0
- /* check KDC time stamp */
- {
- time_t kdc_time;
-
- memmove(&kdc_time, ptr, sizeof(kdc_time));
- if (swap_bytes) swap_u_long(kdc_time);
-
- ptr += 4;
-
- if (abs((int)(local_time - kdc_time)) > CLOCK_SKEW) {
- return(RD_AP_TIME); /* XXX should probably be better
- code */
- }
- }
-#endif
-
- /* initialize ticket cache */
-
- if (tf_create(TKT_FILE) != KSUCCESS)
- return(INTK_ERR);
-
- if (tf_put_pname(pr.name) != KSUCCESS ||
- tf_put_pinst(pr.instance) != KSUCCESS) {
- tf_close();
- return(INTK_ERR);
- }
-
-
- kerror = tf_save_cred(sp.name, sp.instance, sp.realm, session,
- lifetime, kvno, &tkt, local_time);
- tf_close();
-
- return(kerror);
-}
-
-void
-kauth(char *principal, char *ticket)
-{
- char *p;
- int ret;
-
- ret = krb_parse_name(principal, &pr);
- if(ret){
- reply(500, "Bad principal: %s.", krb_get_err_text(ret));
- return;
- }
- if(pr.realm[0] == 0)
- krb_get_lrealm(pr.realm, 1);
-
- if(ticket){
- cip.length = base64_decode(ticket, &cip.dat);
- if(cip.length == -1){
- reply(500, "Failed to decode data.");
- return;
- }
- ret = store_ticket(&cip);
- if(ret){
- reply(500, "Kerberos error: %s.", krb_get_err_text(ret));
- memset(&cip, 0, sizeof(cip));
- return;
- }
- do_destroy_tickets = 1;
-
- if(k_hasafs())
- krb_afslog(0, 0);
- reply(200, "Tickets will be destroyed on exit.");
- return;
- }
-
- ret = krb_get_in_tkt (pr.name,
- pr.instance,
- pr.realm,
- KRB_TICKET_GRANTING_TICKET,
- pr.realm,
- DEFAULT_TKT_LIFE,
- NULL, save_tkt, NULL);
- if(ret != INTK_BADPW){
- reply(500, "Kerberos error: %s.", krb_get_err_text(ret));
- return;
- }
- if(base64_encode(cip.dat, cip.length, &p) < 0) {
- reply(500, "Out of memory while base64-encoding.");
- return;
- }
- reply(300, "P=%s T=%s", krb_unparse_name(&pr), p);
- free(p);
- memset(&cip, 0, sizeof(cip));
-}
-
-
-static char *
-short_date(int32_t dp)
-{
- char *cp;
- time_t t = (time_t)dp;
-
- if (t == (time_t)(-1L)) return "*** Never *** ";
- cp = ctime(&t) + 4;
- cp[15] = '\0';
- return (cp);
-}
-
-void
-klist(void)
-{
- int err;
-
- char *file = tkt_string();
-
- krb_principal pr;
-
- char buf1[128], buf2[128];
- int header = 1;
- CREDENTIALS c;
-
-
-
- err = tf_init(file, R_TKT_FIL);
- if(err != KSUCCESS){
- reply(500, "%s", krb_get_err_text(err));
- return;
- }
- tf_close();
-
- /*
- * We must find the realm of the ticket file here before calling
- * tf_init because since the realm of the ticket file is not
- * really stored in the principal section of the file, the
- * routine we use must itself call tf_init and tf_close.
- */
- err = krb_get_tf_realm(file, pr.realm);
- if(err != KSUCCESS){
- reply(500, "%s", krb_get_err_text(err));
- return;
- }
-
- err = tf_init(file, R_TKT_FIL);
- if(err != KSUCCESS){
- reply(500, "%s", krb_get_err_text(err));
- return;
- }
-
- err = tf_get_pname(pr.name);
- if(err != KSUCCESS){
- reply(500, "%s", krb_get_err_text(err));
- return;
- }
- err = tf_get_pinst(pr.instance);
- if(err != KSUCCESS){
- reply(500, "%s", krb_get_err_text(err));
- return;
- }
-
- /*
- * You may think that this is the obvious place to get the
- * realm of the ticket file, but it can't be done here as the
- * routine to do this must open the ticket file. This is why
- * it was done before tf_init.
- */
-
- lreply(200, "Ticket file: %s", tkt_string());
-
- lreply(200, "Principal: %s", krb_unparse_name(&pr));
- while ((err = tf_get_cred(&c)) == KSUCCESS) {
- if (header) {
- lreply(200, "%-15s %-15s %s",
- " Issued", " Expires", " Principal (kvno)");
- header = 0;
- }
- strcpy(buf1, short_date(c.issue_date));
- c.issue_date = krb_life_to_time(c.issue_date, c.lifetime);
- if (time(0) < (unsigned long) c.issue_date)
- strcpy(buf2, short_date(c.issue_date));
- else
- strcpy(buf2, ">>> Expired <<< ");
- lreply(200, "%s %s %s (%d)", buf1, buf2,
- krb_unparse_name_long(c.service, c.instance, c.realm), c.kvno);
- }
- if (header && err == EOF) {
- lreply(200, "No tickets in file.");
- }
- reply(200, "");
-}
-
-/*
- * Only destroy if we created the tickets
- */
-
-void
-cond_kdestroy(void)
-{
- if (do_destroy_tickets)
- dest_tkt();
- afsunlog();
-}
-
-void
-kdestroy(void)
-{
- dest_tkt();
- afsunlog();
- reply(200, "Tickets destroyed");
-}
-
-void
-krbtkfile(const char *tkfile)
-{
- do_destroy_tickets = 0;
- krb_set_tkt_string(tkfile);
- reply(200, "Using ticket file %s", tkfile);
-}
-
-void
-afslog(const char *cell)
-{
- if(k_hasafs()) {
- krb_afslog(cell, 0);
- reply(200, "afslog done");
- } else {
- reply(200, "no AFS present");
- }
-}
-
-void
-afsunlog(void)
-{
- if(k_hasafs())
- k_unlog();
-}
diff --git a/appl/ftp/ftpd/krb4.c b/appl/ftp/ftpd/krb4.c
deleted file mode 100644
index aa4ba99f0a798c77298d63986c35770eb6f9650c..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/krb4.c
+++ /dev/null
@@ -1,392 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-#endif
-
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_PARAM_H
-#include <sys/param.h>
-#endif
-#ifdef HAVE_NETINET_IN_h
-#include <netinet/in.h>
-#endif
-
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <krb.h>
-
-#include "base64.h"
-#include "extern.h"
-#include "auth.h"
-#include "krb4.h"
-
-#include <roken.h>
-
-static AUTH_DAT auth_dat;
-static des_key_schedule schedule;
-
-int krb4_auth(char *auth)
-{
- auth_complete = 0;
- reply(334, "Using authentication type %s; ADAT must follow", auth);
- return 0;
-}
-
-int krb4_adat(char *auth)
-{
- KTEXT_ST tkt;
- char *p;
- int kerror;
- u_int32_t cs;
- char msg[35]; /* size of encrypted block */
- int len;
-
- char inst[INST_SZ];
-
- memset(&tkt, 0, sizeof(tkt));
- len = base64_decode(auth, tkt.dat);
-
- if(len < 0){
- reply(501, "Failed to decode base64 data.");
- return -1;
- }
- tkt.length = len;
-
- k_getsockinst(0, inst, sizeof(inst));
- kerror = krb_rd_req(&tkt, "ftp", inst, 0, &auth_dat, "");
- if(kerror == RD_AP_UNDEC){
- k_getsockinst(0, inst, sizeof(inst));
- kerror = krb_rd_req(&tkt, "rcmd", inst, 0, &auth_dat, "");
- }
-
- if(kerror){
- reply(535, "Error reading request: %s.", krb_get_err_text(kerror));
- return -1;
- }
-
- des_set_key(&auth_dat.session, schedule);
-
- cs = auth_dat.checksum + 1;
- {
- unsigned char tmp[4];
- tmp[0] = (cs >> 24) & 0xff;
- tmp[1] = (cs >> 16) & 0xff;
- tmp[2] = (cs >> 8) & 0xff;
- tmp[3] = cs & 0xff;
- len = krb_mk_safe(tmp, msg, 4, &auth_dat.session,
- &ctrl_addr, &his_addr);
- }
- if(len < 0){
- reply(535, "Error creating reply: %s.", strerror(errno));
- return -1;
- }
- if(base64_encode(msg, len, &p) < 0) {
- reply(535, "Out of memory base64-encoding.");
- return -1;
- }
- reply(235, "ADAT=%s", p);
- auth_complete = 1;
- free(p);
- return 0;
-}
-
-int krb4_pbsz(int size)
-{
- if(size > 1048576) /* XXX arbitrary number */
- size = 1048576;
- buffer_size = size;
- reply(200, "OK PBSZ=%d", buffer_size);
- return 0;
-}
-
-int krb4_prot(int level)
-{
- if(level == prot_confidential)
- return -1;
- return 0;
-}
-
-int krb4_ccc(void)
-{
- reply(534, "Don't event think about it.");
- return -1;
-}
-
-int krb4_mic(char *msg)
-{
- int len;
- int kerror;
- MSG_DAT m_data;
- char *tmp, *cmd;
-
- cmd = malloc(strlen(msg) + 1);
-
- if (cmd == NULL) {
- reply(451, "Failed to allocate memory.");
- return -1;
- }
-
- len = base64_decode(msg, cmd);
- if(len < 0){
- reply(501, "Failed to decode base 64 data.");
- free(cmd);
- return -1;
- }
- kerror = krb_rd_safe(cmd, len, &auth_dat.session,
- &his_addr, &ctrl_addr, &m_data);
-
- free(cmd);
- if(kerror){
- reply(535, "Error reading request: %s.", krb_get_err_text(kerror));
- return -1;
- }
-
- tmp = malloc(strlen(msg) + 1);
- if (tmp == NULL) {
- reply(451, "Failed to allocate memory.");
- return -1;
- }
- snprintf(tmp, strlen(msg) + 1, "%.*s",
- (int)m_data.app_length, m_data.app_data);
- if(!strstr(tmp, "\r\n"))
- strcat(tmp, "\r\n");
- new_ftp_command(tmp);
- return 0;
-}
-
-int krb4_conf(char *msg)
-{
- prot_level = prot_safe;
-
- reply(537, "Protection level not supported.");
- return -1;
-}
-
-int krb4_enc(char *msg)
-{
- int len;
- int kerror;
- MSG_DAT m_data;
- char *tmp, *cmd;
-
- cmd = malloc(strlen(msg) + 1);
-
- len = base64_decode(msg, cmd);
- if(len < 0){
- reply(501, "Failed to decode base 64 data.");
- free(cmd);
- return -1;
- }
- kerror = krb_rd_priv(cmd, len, schedule, &auth_dat.session,
- &his_addr, &ctrl_addr, &m_data);
-
- if(kerror){
- reply(535, "Error reading request: %s.", krb_get_err_text(kerror));
- free(cmd);
- return -1;
- }
-
- tmp = malloc(strlen(msg) + 1);
- if (tmp == NULL) {
- reply(451, "Failed to allocate memory.");
- free(cmd);
- return -1;
- }
- snprintf(tmp, strlen(msg) + 1, "%.*s", (int)m_data.app_length, m_data.app_data);
- if(!strstr(tmp, "\r\n"))
- strcat(tmp, "\r\n");
- new_ftp_command(tmp);
- free(cmd);
- return 0;
-}
-
-int krb4_read(int fd, void *data, int length)
-{
- static int left;
- static char *extra;
- static int eof;
- int len, bytes, tx = 0;
-
- MSG_DAT m_data;
- int kerror;
-
- if(eof){ /* if we haven't reported an end-of-file, do so */
- eof = 0;
- return 0;
- }
-
- if(left){
- if(length > left)
- bytes = left;
- else
- bytes = length;
- memmove(data, extra, bytes);
- left -= bytes;
- if(left)
- memmove(extra, extra + bytes, left);
- else
- free(extra);
- length -= bytes;
- tx += bytes;
- }
-
- while(length){
- unsigned char tmp[4];
- if(krb_net_read(fd, tmp, 4) < 4){
- reply(400, "Unexpected end of file.\n");
- return -1;
- }
- len = (tmp[0] << 24) | (tmp[1] << 16) | (tmp[2] << 8) | tmp[3];
- krb_net_read(fd, data_buffer, len);
- if(data_protection == prot_safe)
- kerror = krb_rd_safe(data_buffer, len, &auth_dat.session,
- &his_addr, &ctrl_addr, &m_data);
- else
- kerror = krb_rd_priv(data_buffer, len, schedule, &auth_dat.session,
- &his_addr, &ctrl_addr, &m_data);
-
- if(kerror){
- reply(400, "Failed to read data: %s.", krb_get_err_text(kerror));
- return -1;
- }
-
- bytes = m_data.app_length;
- if(bytes == 0){
- if(tx) eof = 1;
- return tx;
- }
- if(bytes > length){
- left = bytes - length;
- bytes = length;
- extra = malloc(left);
- memmove(extra, m_data.app_data + bytes, left);
- }
- memmove((unsigned char*)data + tx, m_data.app_data, bytes);
- tx += bytes;
- length -= bytes;
- }
- return tx;
-}
-
-int krb4_write(int fd, void *data, int length)
-{
- int len, bytes, tx = 0;
-
- len = buffer_size;
- if(data_protection == prot_safe)
- len -= 31; /* always 31 bytes overhead */
- else
- len -= 26; /* at most 26 bytes */
-
- do{
- if(length < len)
- len = length;
- if(data_protection == prot_safe)
- bytes = krb_mk_safe(data, data_buffer+4, len, &auth_dat.session,
- &ctrl_addr, &his_addr);
- else
- bytes = krb_mk_priv(data, data_buffer+4, len, schedule,
- &auth_dat.session,
- &ctrl_addr, &his_addr);
- if(bytes == -1){
- reply(535, "Failed to make packet: %s.", strerror(errno));
- return -1;
- }
- data_buffer[0] = (bytes >> 24) & 0xff;
- data_buffer[1] = (bytes >> 16) & 0xff;
- data_buffer[2] = (bytes >> 8) & 0xff;
- data_buffer[3] = bytes & 0xff;
- if(krb_net_write(fd, data_buffer, bytes+4) < 0)
- return -1;
- length -= len;
- data = (unsigned char*)data + len;
- tx += len;
- }while(length);
- return tx;
-}
-
-int krb4_userok(char *name)
-{
- if(!kuserok(&auth_dat, name)){
- do_login(232, name);
- }else{
- reply(530, "User %s access denied.", name);
- }
- return 0;
-}
-
-
-int
-krb4_vprintf(const char *fmt, va_list ap)
-{
- char buf[10240];
- char *p;
- char *enc;
- int code;
- int len;
-
- vsnprintf (buf, sizeof(buf), fmt, ap);
- enc = malloc(strlen(buf) + 31);
- if(prot_level == prot_safe){
- len = krb_mk_safe((u_char*)buf, (u_char*)enc, strlen(buf), &auth_dat.session,
- &ctrl_addr, &his_addr);
- code = 631;
- }else if(prot_level == prot_private){
- len = krb_mk_priv((u_char*)buf, (u_char*)enc, strlen(buf), schedule,
- &auth_dat.session, &ctrl_addr, &his_addr);
- code = 632;
- }else{
- len = 0; /* XXX */
- code = 631;
- }
- if(base64_encode(enc, len, &p) < 0) {
- fprintf(stdout, "451 base64-encode failed\r\n");
- } else {
- fprintf(stdout, "%d %s\r\n", code, p);
- free(p);
- }
- free(enc);
- return 0;
-}
diff --git a/appl/ftp/ftpd/krb4.h b/appl/ftp/ftpd/krb4.h
deleted file mode 100644
index 3fd93a8f58693566ae49e1b60952416c0506d73f..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/krb4.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifndef __KRB4_H__
-#define __KRB4_H__
-
-#include <stdarg.h>
-
-int krb4_auth(char *auth);
-int krb4_adat(char *auth);
-int krb4_pbsz(int size);
-int krb4_prot(int level);
-int krb4_ccc(void);
-int krb4_mic(char *msg);
-int krb4_conf(char *msg);
-int krb4_enc(char *msg);
-
-int krb4_read(int fd, void *data, int length);
-int krb4_write(int fd, void *data, int length);
-
-int krb4_userok(char *name);
-int krb4_vprintf(const char *fmt, va_list ap);
-
-#endif /* __KRB4_H__ */
diff --git a/appl/ftp/ftpd/logwtmp.c b/appl/ftp/ftpd/logwtmp.c
deleted file mode 100644
index 1479dbf4384f4cd2cfc4c5a89d7ecb18d73b0775..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/logwtmp.c
+++ /dev/null
@@ -1,142 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-#endif
-
-#include <stdio.h>
-#include <string.h>
-#ifdef TIME_WITH_SYS_TIME
-#include <sys/time.h>
-#include <time.h>
-#elif defined(HAVE_SYS_TIME_H)
-#include <sys/time.h>
-#else
-#include <time.h>
-#endif
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
-#ifdef HAVE_FCNTL_H
-#include <fcntl.h>
-#endif
-#ifdef HAVE_UTMP_H
-#include <utmp.h>
-#endif
-#ifdef HAVE_UTMPX_H
-#include <utmpx.h>
-#endif
-#include "extern.h"
-
-#ifndef WTMP_FILE
-#ifdef _PATH_WTMP
-#define WTMP_FILE _PATH_WTMP
-#else
-#define WTMP_FILE "/var/adm/wtmp"
-#endif
-#endif
-
-void
-logwtmp(char *line, char *name, char *host)
-{
- static int init = 0;
- static int fd;
-#ifdef WTMPX_FILE
- static int fdx;
-#endif
- struct utmp ut;
-#ifdef WTMPX_FILE
- struct utmpx utx;
-#endif
-
- memset(&ut, 0, sizeof(struct utmp));
-#ifdef HAVE_UT_TYPE
- if(name[0])
- ut.ut_type = USER_PROCESS;
- else
- ut.ut_type = DEAD_PROCESS;
-#endif
- strncpy(ut.ut_line, line, sizeof(ut.ut_line));
- strncpy(ut.ut_name, name, sizeof(ut.ut_name));
-#ifdef HAVE_UT_PID
- ut.ut_pid = getpid();
-#endif
-#ifdef HAVE_UT_HOST
- strncpy(ut.ut_host, host, sizeof(ut.ut_host));
-#endif
- ut.ut_time = time(NULL);
-
-#ifdef WTMPX_FILE
- strncpy(utx.ut_line, line, sizeof(utx.ut_line));
- strncpy(utx.ut_user, name, sizeof(utx.ut_user));
- strncpy(utx.ut_host, host, sizeof(utx.ut_host));
-#ifdef HAVE_UT_SYSLEN
- utx.ut_syslen = strlen(host) + 1;
- if (utx.ut_syslen > sizeof(utx.ut_host))
- utx.ut_syslen = sizeof(utx.ut_host);
-#endif
- {
- struct timeval tv;
-
- gettimeofday (&tv, 0);
- utx.ut_tv.tv_sec = tv.tv_sec;
- utx.ut_tv.tv_usec = tv.tv_usec;
- }
-
- if(name[0])
- utx.ut_type = USER_PROCESS;
- else
- utx.ut_type = DEAD_PROCESS;
-#endif
-
- if(!init){
- fd = open(WTMP_FILE, O_WRONLY|O_APPEND, 0);
-#ifdef WTMPX_FILE
- fdx = open(WTMPX_FILE, O_WRONLY|O_APPEND, 0);
-#endif
- init = 1;
- }
- if(fd >= 0) {
- write(fd, &ut, sizeof(struct utmp)); /* XXX */
-#ifdef WTMPX_FILE
- write(fdx, &utx, sizeof(struct utmpx));
-#endif
- }
-}
diff --git a/appl/ftp/ftpd/pathnames.h b/appl/ftp/ftpd/pathnames.h
deleted file mode 100644
index 1bd2be1a1efac7599e1eec7289a5629c880628f0..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/pathnames.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * 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.
- *
- * @(#)pathnames.h 8.1 (Berkeley) 6/4/93
- */
-
-#ifdef HAVE_PATHS_H
-#include <paths.h>
-#endif
-
-#ifndef _PATH_DEVNULL
-#define _PATH_DEVNULL "/dev/null"
-#endif
-
-#ifndef _PATH_NOLOGIN
-#define _PATH_NOLOGIN "/etc/nologin"
-#endif
-
-#ifndef _PATH_BSHELL
-#define _PATH_BSHELL "/bin/sh"
-#endif
-
-#define _PATH_FTPUSERS "/etc/ftpusers"
-#define _PATH_FTPCHROOT "/etc/ftpchroot"
-#define _PATH_FTPWELCOME "/etc/ftpwelcome"
-#define _PATH_FTPLOGINMESG "/etc/motd"
diff --git a/appl/ftp/ftpd/popen.c b/appl/ftp/ftpd/popen.c
deleted file mode 100644
index 62b005ec303ae91022dfa1a0c089c331750532d7..0000000000000000000000000000000000000000
--- a/appl/ftp/ftpd/popen.c
+++ /dev/null
@@ -1,224 +0,0 @@
-/*
- * Copyright (c) 1988, 1993, 1994
- * The Regents of the University of California. All rights reserved.
- *
- * This code is derived from software written by Ken Arnold and
- * published in UNIX Review, Vol. 6, No. 8.
- *
- * 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.
- *
- */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-RCSID("$Id$");
-#endif
-
-#include <sys/types.h>
-#ifdef TIME_WITH_SYS_TIME
-#include <sys/time.h>
-#include <time.h>
-#elif defined(HAVE_SYS_TIME_H)
-#include <sys/time.h>
-#else
-#include <time.h>
-#endif
-#ifdef HAVE_SYS_RESOURCE_H
-#include <sys/resource.h>
-#endif
-#include <sys/wait.h>
-
-#include <errno.h>
-#include <glob.h>
-#include <signal.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include "extern.h"
-
-#include <roken.h>
-
-/*
- * Special version of popen which avoids call to shell. This ensures
- * no one may create a pipe to a hidden program as a side effect of a
- * list or dir command.
- */
-static int *pids;
-static int fds;
-
-extern int dochroot;
-
-/* return path prepended with ~ftp if that file exists, otherwise
- * return path unchanged
- */
-
-const char *
-ftp_rooted(const char *path)
-{
- static char home[MaxPathLen] = "";
- static char newpath[MaxPathLen];
- struct passwd *pwd;
-
- if(!home[0])
- if((pwd = k_getpwnam("ftp")))
- strcpy(home, pwd->pw_dir);
- snprintf(newpath, sizeof(newpath), "%s/%s", home, path);
- if(access(newpath, X_OK))
- strcpy(newpath, path);
- return newpath;
-}
-
-
-FILE *
-ftpd_popen(char *program, char *type, int do_stderr, int no_glob)
-{
- char *cp;
- FILE *iop;
- int argc, gargc, pdes[2], pid;
- char **pop, *argv[100], *gargv[1000];
- char *foo;
-
- if (strcmp(type, "r") && strcmp(type, "w"))
- return (NULL);
-
- if (!pids) {
-
- /* This function is ugly and should be rewritten, in
- * modern unices there is no such thing as a maximum
- * filedescriptor.
- */
-
- fds = getdtablesize();
- pids = (int*)calloc(fds, sizeof(int));
- if(!pids)
- return NULL;
- }
- if (pipe(pdes) < 0)
- return (NULL);
-
- /* break up string into pieces */
- foo = NULL;
- for (argc = 0, cp = program;; cp = NULL) {
- if (!(argv[argc++] = strtok_r(cp, " \t\n", &foo)))
- break;
- }
-
- gargv[0] = (char*)ftp_rooted(argv[0]);
- /* glob each piece */
- for (gargc = argc = 1; argv[argc]; argc++) {
- glob_t gl;
- int flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE;
-
- memset(&gl, 0, sizeof(gl));
- if (no_glob || glob(argv[argc], flags, NULL, &gl))
- gargv[gargc++] = strdup(argv[argc]);
- else
- for (pop = gl.gl_pathv; *pop; pop++)
- gargv[gargc++] = strdup(*pop);
- globfree(&gl);
- }
- gargv[gargc] = NULL;
-
- iop = NULL;
- switch(pid = fork()) {
- case -1: /* error */
- close(pdes[0]);
- close(pdes[1]);
- goto pfree;
- /* NOTREACHED */
- case 0: /* child */
- if (*type == 'r') {
- if (pdes[1] != STDOUT_FILENO) {
- dup2(pdes[1], STDOUT_FILENO);
- close(pdes[1]);
- }
- if(do_stderr)
- dup2(STDOUT_FILENO, STDERR_FILENO);
- close(pdes[0]);
- } else {
- if (pdes[0] != STDIN_FILENO) {
- dup2(pdes[0], STDIN_FILENO);
- close(pdes[0]);
- }
- close(pdes[1]);
- }
- execv(gargv[0], gargv);
- gargv[0] = argv[0];
- execv(gargv[0], gargv);
- _exit(1);
- }
- /* parent; assume fdopen can't fail... */
- if (*type == 'r') {
- iop = fdopen(pdes[0], type);
- close(pdes[1]);
- } else {
- iop = fdopen(pdes[1], type);
- close(pdes[0]);
- }
- pids[fileno(iop)] = pid;
-
-pfree:
- for (argc = 1; gargv[argc] != NULL; argc++)
- free(gargv[argc]);
-
-
- return (iop);
-}
-
-int
-ftpd_pclose(FILE *iop)
-{
- int fdes, status;
- pid_t pid;
- sigset_t sigset, osigset;
-
- /*
- * pclose returns -1 if stream is not associated with a
- * `popened' command, or, if already `pclosed'.
- */
- if (pids == 0 || pids[fdes = fileno(iop)] == 0)
- return (-1);
- fclose(iop);
- sigemptyset(&sigset);
- sigaddset(&sigset, SIGINT);
- sigaddset(&sigset, SIGQUIT);
- sigaddset(&sigset, SIGHUP);
- sigprocmask(SIG_BLOCK, &sigset, &osigset);
- while ((pid = waitpid(pids[fdes], &status, 0)) < 0 && errno == EINTR)
- continue;
- sigprocmask(SIG_SETMASK, &osigset, NULL);
- pids[fdes] = 0;
- if (pid < 0)
- return (pid);
- if (WIFEXITED(status))
- return (WEXITSTATUS(status));
- return (1);
-}
diff --git a/appl/kx/Makefile.in b/appl/kx/Makefile.in
deleted file mode 100644
index b0a107b92267a1b20bff6074754dbc39e51013d2..0000000000000000000000000000000000000000
--- a/appl/kx/Makefile.in
+++ /dev/null
@@ -1,119 +0,0 @@
-# $Id$
-
-SHELL = /bin/sh
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-
-XINCS = @X_CFLAGS@
-XLIBS = @X_LIBS@ @LIB_XauReadAuth@ @X_PRE_LIBS@ @X_EXTRA_LIBS@
-
-CC = @CC@
-AR = ar
-DEFS = @DEFS@
-CFLAGS = @CFLAGS@
-CPPFLAGS= $(XINCS)
-LD_FLAGS = @LD_FLAGS@
-INSTALL = @INSTALL@
-INSTALL_PROGRAM = @INSTALL_PROGRAM@
-LN_S = @LN_S@
-LIBS = $(XLIBS) @LIBS@
-MKINSTALLDIRS = @top_srcdir@/mkinstalldirs
-
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-libdir = @libdir@
-libexecdir = @libexecdir@
-bindir = @bindir@
-transform=@program_transform_name@
-EXECSUFFIX=@EXECSUFFIX@
-
-X_PROGS_BIN = kx$(EXECSUFFIX) rxterm rxtelnet tenletxr
-X_PROGS_LIBEXEC = kxd$(EXECSUFFIX)
-
-PROG_BIN = @MAKE_X_PROGS_BIN@
-PROG_LIBEXEC = @MAKE_X_PROGS_LIBEXEC@
-PROGS = $(PROG_BIN) $(PROG_LIBEXEC)
-
-SOURCES_KX = kx.c @XauWriteAuth_c@
-SOURCES_KXD = kxd.c @XauWriteAuth_c@
-SOURCES_COMMON = common.c # encdata.c
-
-OBJECTS_KX = kx.o common.o encdata.o @XauWriteAuth_o@
-OBJECTS_KXD = kxd.o common.o encdata.o @XauWriteAuth_o@
-
-OBJECTS = $(OBJECTS_KX) $(OBJECTS_KXD)
-SOURCES = $(SOURCES_KX) $(SOURCES_KXD) $(SOURCES_COMMON)
-
-all: $(PROGS)
-
-Wall:
- make CFLAGS="-g -Wall -Wno-comment -Wmissing-prototypes -Wmissing-declarations -D__USE_FIXED_PROTOTYPES__"
-
-.c.o:
- $(CC) -c $(CPPFLAGS) $(DEFS) -I../../include -I$(srcdir) -I$(srcdir)/../kauth $(CFLAGS) $<
-
-install: all
- $(MKINSTALLDIRS) $(bindir)
- PROG_BIN='$(PROG_BIN)'; for x in $$PROG_BIN; do \
- $(INSTALL_PROGRAM) $$x $(bindir)/`echo $$x | sed '$(transform)'`; \
- done
- PROG_LIBEXEC='$(PROG_LIBEXEC)'; for x in $$PROG_LIBEXEC; do \
- $(INSTALL_PROGRAM) $$x $(libexecdir)/`echo $$x | sed '$(transform)'`; \
- done
-
-uninstall:
- PROG_BIN='$(PROG_BIN)'; for x in $$PROG_BIN; do \
- rm -f $(bindir)/`echo $$x | sed '$(transform)'`; \
- done
- PROG_LIBEXEC='$(PROG_LIBEXEC)'; for x in $$PROG_LIBEXEC; do \
- rm -f $(libexecdir)/`echo $$x | sed '$(transform)'`; \
- done
-
-TAGS: $(SOURCES)
- etags $(SOURCES)
-
-check:
-
-clean:
- rm -f *.a *.o $(PROGS)
-
-mostlyclean: clean
-
-distclean: clean
- rm -f Makefile *.tab.c *~
-
-realclean: distclean
- rm -f TAGS
-
-dist: $(DISTFILES)
- for file in $(DISTFILES); do \
- ln $$file ../`cat ../.fname`/lib \
- || cp -p $$file ../`cat ../.fname`/lib; \
- done
-
-KLIB= -L../../lib/krb -lkrb -L../../lib/des -ldes
-LIBROKEN=-L../../lib/roken -lroken
-
-encdata.c:
- $(LN_S) $(srcdir)/../kauth/encdata.c .
-
-kx$(EXECSUFFIX): $(OBJECTS_KX)
- $(CC) $(LD_FLAGS) $(LDFLAGS) -o $@ $(OBJECTS_KX) $(KLIB) $(LIBROKEN) $(LIBS) $(LIBROKEN)
-
-kxd$(EXECSUFFIX): $(OBJECTS_KXD)
- $(CC) $(LD_FLAGS) $(LDFLAGS) -o $@ $(OBJECTS_KXD) $(KLIB) $(LIBROKEN) $(LIBS) $(LIBROKEN)
-
-rxterm: rxterm.in
- sed -e "s!%bindir%!$(bindir)!" $(srcdir)/rxterm.in > $@
- chmod +x $@
-
-rxtelnet: rxtelnet.in
- sed -e "s!%bindir%!$(bindir)!" $(srcdir)/rxtelnet.in > $@
- chmod +x $@
-
-tenletxr: tenletxr.in
- sed -e "s!%bindir%!$(bindir)!" $(srcdir)/tenletxr.in > $@
- chmod +x $@
-
-$(OBJECTS): ../../include/config.h
diff --git a/appl/kx/common.c b/appl/kx/common.c
deleted file mode 100644
index 6122d04da25741e328ec84e75e0c36a6277fd7cf..0000000000000000000000000000000000000000
--- a/appl/kx/common.c
+++ /dev/null
@@ -1,461 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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 "kx.h"
-
-RCSID("$Id$");
-
-char x_socket[MaxPathLen];
-
-u_int32_t display_num;
-char display[MaxPathLen];
-int display_size = sizeof(display);
-char xauthfile[MaxPathLen];
-int xauthfile_size = sizeof(xauthfile);
-u_char cookie[16];
-size_t cookie_len = sizeof(cookie);
-
-static int
-do_enccopy (int fd1, int fd2, int mode, des_cblock *iv,
- des_key_schedule schedule, int *num)
-{
- int ret;
- u_char buf[BUFSIZ];
-
- ret = read (fd1, buf, sizeof(buf));
- if (ret == 0)
- return 0;
- if (ret < 0) {
- warn ("read");
- return ret;
- }
-#ifndef NOENCRYPTION
- des_cfb64_encrypt (buf, buf, ret, schedule, iv,
- num, mode);
-#endif
- ret = krb_net_write (fd2, buf, ret);
- if (ret < 0) {
- warn ("write");
- return ret;
- }
- return 1;
-}
-
-/*
- * Copy data from `fd1' to `fd2', encrypting it. Data in the other
- * direction is of course, decrypted.
- */
-
-int
-copy_encrypted (int fd1, int fd2, des_cblock *iv,
- des_key_schedule schedule)
-{
- des_cblock iv1, iv2;
- int num1 = 0, num2 = 0;
-
- memcpy (iv1, *iv, sizeof(iv1));
- memcpy (iv2, *iv, sizeof(iv2));
- for (;;) {
- fd_set fdset;
- int ret;
-
- FD_ZERO(&fdset);
- FD_SET(fd1, &fdset);
- FD_SET(fd2, &fdset);
-
- ret = select (max(fd1, fd2)+1, &fdset, NULL, NULL, NULL);
- if (ret < 0 && errno != EINTR) {
- warn ("select");
- return 1;
- }
- if (FD_ISSET(fd1, &fdset)) {
- ret = do_enccopy (fd1, fd2, DES_ENCRYPT, &iv1, schedule, &num1);
- if (ret <= 0)
- return ret;
- }
- if (FD_ISSET(fd2, &fdset)) {
- ret = do_enccopy (fd2, fd1, DES_DECRYPT, &iv2, schedule, &num2);
- if (ret <= 0)
- return ret;
- }
- }
-}
-
-#ifndef X_UNIX_PATH
-#define X_UNIX_PATH "/tmp/.X11-unix/X"
-#endif
-
-#ifndef INADDR_LOOPBACK
-#define INADDR_LOOPBACK 0x7f000001
-#endif
-
-/*
- * Allocate and listen on a local X server socket and a TCP socket.
- * Return the display number.
- */
-
-int
-get_xsockets (int *unix_socket, int *tcp_socket)
-{
- int unixfd, tcpfd = -1;
- struct sockaddr_un unixaddr;
- struct sockaddr_in tcpaddr;
- int dpy;
- int oldmask;
- struct in_addr local;
- char *dir, *p;
-
- if((dir = strdup (X_UNIX_PATH)) == NULL)
- errx (1, "strdup: out of memory");
- p = strrchr (dir, '/');
- if (p)
- *p = '\0';
-
- oldmask = umask(0);
- mkdir (dir, 01777);
- chmod (dir, 01777);
- umask (oldmask);
- free (dir);
-
- memset(&local, 0, sizeof(local));
- local.s_addr = htonl(INADDR_LOOPBACK);
-
- for(dpy = 4; dpy < 256; ++dpy) {
- unixfd = socket (AF_UNIX, SOCK_STREAM, 0);
- if (unixfd < 0)
- err (1, "socket AF_UNIX");
- memset (&unixaddr, 0, sizeof(unixaddr));
- unixaddr.sun_family = AF_UNIX;
- snprintf (unixaddr.sun_path, sizeof(unixaddr.sun_path),
- X_UNIX_PATH "%u", dpy);
- if(bind(unixfd,
- (struct sockaddr *)&unixaddr,
- sizeof(unixaddr)) < 0) {
- close (unixfd);
- if (errno == EADDRINUSE ||
- errno == EACCES) /* Cray return EACCESS */
- continue;
- else
- return -1;
- }
-
- if (tcp_socket) {
- int one = 1;
-
- tcpfd = socket (AF_INET, SOCK_STREAM, 0);
- if (tcpfd < 0)
- err (1, "socket AF_INET");
-#if defined(TCP_NODELAY) && defined(HAVE_SETSOCKOPT)
- setsockopt (tcpfd, IPPROTO_TCP, TCP_NODELAY, (void *)&one,
- sizeof(one));
-#endif
- memset (&tcpaddr, 0, sizeof(tcpaddr));
- tcpaddr.sin_family = AF_INET;
- tcpaddr.sin_addr = local;
- tcpaddr.sin_port = htons(6000 + dpy);
- if (bind (tcpfd, (struct sockaddr *)&tcpaddr,
- sizeof(tcpaddr)) < 0) {
- close (unixfd);
- close (tcpfd);
- if (errno == EADDRINUSE)
- continue;
- else
- return -1;
- }
- }
- break;
- }
- if (dpy == 256)
- errx (1, "no free x-servers");
- if (listen (unixfd, SOMAXCONN) < 0)
- err (1, "listen");
- if (tcp_socket)
- if (listen (tcpfd, SOMAXCONN) < 0)
- err (1, "listen");
- strcpy(x_socket, unixaddr.sun_path);
- *unix_socket = unixfd;
- if (tcp_socket)
- *tcp_socket = tcpfd;
- return dpy;
-}
-
-/*
- *
- */
-
-int
-connect_local_xsocket (unsigned dnr)
-{
- int fd;
- struct sockaddr_un addr;
-
- fd = socket (AF_UNIX, SOCK_STREAM, 0);
- if (fd < 0)
- err (1, "socket AF_UNIX");
- addr.sun_family = AF_UNIX;
- snprintf (addr.sun_path, sizeof(addr.sun_path),
- X_UNIX_PATH "%u", dnr);
- if (connect (fd, (struct sockaddr *)&addr, sizeof(addr)) < 0)
- err (1, "connect");
- return fd;
-}
-
-int
-create_and_write_cookie (char *xauthfile,
- size_t size,
- u_char *cookie,
- size_t sz)
-{
- Xauth auth;
- char tmp[64];
- int fd;
- FILE *f;
- char hostname[MaxHostNameLen];
- struct in_addr loopback;
- struct hostent *h;
-
- gethostname (hostname, sizeof(hostname));
- loopback.s_addr = htonl(INADDR_LOOPBACK);
-
- auth.family = FamilyLocal;
- auth.address = hostname;
- auth.address_length = strlen(auth.address);
- snprintf (tmp, sizeof(tmp), "%d", display_num);
- auth.number_length = strlen(tmp);
- auth.number = tmp;
- auth.name = COOKIE_TYPE;
- auth.name_length = strlen(auth.name);
- auth.data_length = sz;
- auth.data = (char*)cookie;
- des_rand_data (cookie, sz);
-
- strncpy(xauthfile, "/tmp/AXXXXXX", size);
- xauthfile[size-1] = 0;
- fd = mkstemp(xauthfile);
- if(fd < 0) {
- syslog(LOG_ERR, "create_and_write_cookie: mkstemp: %m");
- return 1;
- }
- f = fdopen(fd, "r+");
- if(f == NULL){
- close(fd);
- return 1;
- }
- if(XauWriteAuth(f, &auth) == 0) {
- fclose(f);
- return 1;
- }
-
- h = gethostbyname (hostname);
- if (h == NULL) {
- fclose (f);
- return 1;
- }
-
- /*
- * I would like to write a cookie for localhost:n here, but some
- * stupid code in libX11 will not look for cookies of that type,
- * so we are forced to use FamilyWild instead.
- */
-
- auth.family = FamilyWild;
- auth.address_length = 0;
-
-#if 0 /* XXX */
- auth.address = (char *)&loopback;
- auth.address_length = sizeof(loopback);
-#endif
-
- if (XauWriteAuth(f, &auth) == 0) {
- fclose (f);
- return 1;
- }
-
- if(fclose(f))
- return 1;
- return 0;
-}
-
-/*
- * Verify and remove cookies. Read and parse a X-connection from
- * `fd'. Check the cookie used is the same as in `cookie'. Remove the
- * cookie and copy the rest of it to `sock'.
- * Return 0 iff ok.
- */
-
-int
-verify_and_remove_cookies (int fd, int sock)
-{
- u_char beg[12];
- int bigendianp;
- unsigned n, d, npad, dpad;
- char *protocol_name, *protocol_data;
- u_char zeros[6] = {0, 0, 0, 0, 0, 0};
-
- if (krb_net_read (fd, beg, sizeof(beg)) != sizeof(beg))
- return 1;
- if (krb_net_write (sock, beg, 6) != 6)
- return 1;
- bigendianp = beg[0] == 'B';
- if (bigendianp) {
- n = (beg[6] << 8) | beg[7];
- d = (beg[8] << 8) | beg[9];
- } else {
- n = (beg[7] << 8) | beg[6];
- d = (beg[9] << 8) | beg[8];
- }
- npad = (4 - (n % 4)) % 4;
- dpad = (4 - (d % 4)) % 4;
- protocol_name = malloc(n + npad);
- if (protocol_name == NULL)
- return 1;
- protocol_data = malloc(d + dpad);
- if (protocol_data == NULL)
- goto fail;
- if (krb_net_read (fd, protocol_name, n + npad) != n + npad)
- goto fail;
- if (krb_net_read (fd, protocol_data, d + dpad) != d + dpad)
- goto fail;
- if (strncmp (protocol_name, COOKIE_TYPE, strlen(COOKIE_TYPE)) != 0)
- goto fail;
- if (d != cookie_len ||
- memcmp (protocol_data, cookie, cookie_len) != 0)
- goto fail;
- free (protocol_name);
- free (protocol_data);
- if (krb_net_write (sock, zeros, 6) != 6)
- return 1;
- return 0;
-fail:
- free (protocol_name);
- free (protocol_data);
- return 1;
-}
-
-/*
- * Get rid of the cookie that we were sent and get the correct one
- * from our own cookie file instead.
- */
-
-int
-replace_cookie(int xserver, int fd, char *filename)
-{
- u_char beg[12];
- int bigendianp;
- unsigned n, d, npad, dpad;
- Xauth *auth;
- FILE *f;
- u_char zeros[6] = {0, 0, 0, 0, 0, 0};
-
- if (krb_net_read (fd, beg, sizeof(beg)) != sizeof(beg))
- return 1;
- if (krb_net_write (xserver, beg, 6) != 6)
- return 1;
- bigendianp = beg[0] == 'B';
- if (bigendianp) {
- n = (beg[6] << 8) | beg[7];
- d = (beg[8] << 8) | beg[9];
- } else {
- n = (beg[7] << 8) | beg[6];
- d = (beg[9] << 8) | beg[8];
- }
- if (n != 0 || d != 0)
- return 1;
- f = fopen(filename, "r");
- if (f) {
- u_char len[6] = {0, 0, 0, 0, 0, 0};
-
- auth = XauReadAuth(f);
- fclose(f);
- n = auth->name_length;
- d = auth->data_length;
- if (bigendianp) {
- len[0] = n >> 8;
- len[1] = n & 0xFF;
- len[2] = d >> 8;
- len[3] = d & 0xFF;
- } else {
- len[0] = n & 0xFF;
- len[1] = n >> 8;
- len[2] = d & 0xFF;
- len[3] = d >> 8;
- }
- if (krb_net_write (xserver, len, 6) != 6)
- return 1;
- if(krb_net_write (xserver, auth->name, n) != n)
- return 1;
- npad = (4 - (n % 4)) % 4;
- if (npad) {
- if (krb_net_write (xserver, zeros, npad) != npad)
- return 1;
- }
- if (krb_net_write (xserver, auth->data, d) != d)
- return 1;
- dpad = (4 - (d % 4)) % 4;
- if (dpad) {
- if (krb_net_write (xserver, zeros, dpad) != dpad)
- return 1;
- }
- XauDisposeAuth(auth);
- } else {
- if(krb_net_write(xserver, zeros, 6) != 6)
- return 1;
- }
- return 0;
-}
-
-
-
-
-/*
- * Some simple controls on the address and corresponding socket
- */
-
-int
-suspicious_address (int sock, struct sockaddr_in addr)
-{
- char data[40];
- int len = sizeof(data);
-
- return addr.sin_addr.s_addr != htonl(INADDR_LOOPBACK)
-#if defined(IP_OPTIONS) && defined(HAVE_GETSOCKOPT)
- || getsockopt (sock, IPPROTO_IP, IP_OPTIONS, data, &len) < 0
- || len != 0
-#endif
- ;
-}
diff --git a/appl/kx/kx.1 b/appl/kx/kx.1
deleted file mode 100644
index 0566ce7388a109df41a2dc4db353acb67a441865..0000000000000000000000000000000000000000
--- a/appl/kx/kx.1
+++ /dev/null
@@ -1,62 +0,0 @@
-.\" $Id$
-.\"
-.Dd September 27, 1996
-.Dt KX 1
-.Os KTH-KRB
-.Sh NAME
-.Nm kx
-.Nd
-securely forward X conections
-.Sh SYNOPSIS
-.Ar kx
-.Op Fl l Ar username
-.Op Fl k
-.Op Fl d
-.Op Fl t
-.Op Fl p Ar port
-.Op Fl P
-.Ar host
-.Sh DESCRIPTION
-The
-.Nm
-program forwards a X connection from a remote client to a local screen
-through an authenticated and encrypted stream. Options supported by
-.Nm kx :
-.Bl -tag -width Ds
-.It Fl l
-Log in on remote the host as user
-.Ar username .
-.It Fl k
-Do not enable keep-alives on the TCP connections.
-.It Fl d
-Do not fork. This is mainly useful for debugging.
-.It Fl t
-Listen not only on a UNIX-domain socket but on a TCP socket as well.
-.It Fl p
-Use the port
-.Ar port .
-.It Fl P
-Force passive mode.
-.El
-.Pp
-This program is used by
-.Nm rxtelnet
-and
-.Nm rxterm
-and you should not need to run it directly.
-.Pp
-It connects to a
-.Nm kxd
-on the host
-.Ar host
-and then will relay the traffic from the remote X clients to the local
-server. When started, it prints the display and Xauthority-file to be
-used on host
-.Ar host
-and then goes to the background, waiting for connections from the
-remote
-.Nm kxd.
-.Sh SEE ALSO
-.Xr rxtelnet 1 ,
-.Xr rxterm 1 ,
-.Xr kxd 8
diff --git a/appl/kx/kx.c b/appl/kx/kx.c
deleted file mode 100644
index cf2acd1d330f8852651710206b8a333474b8c3b5..0000000000000000000000000000000000000000
--- a/appl/kx/kx.c
+++ /dev/null
@@ -1,616 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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 "kx.h"
-
-RCSID("$Id$");
-
-static int nchild;
-static int donep;
-
-/*
- * Signal handler that justs waits for the children when they die.
- */
-
-static RETSIGTYPE
-childhandler (int sig)
-{
- pid_t pid;
- int status;
-
- do {
- pid = waitpid (-1, &status, WNOHANG|WUNTRACED);
- if (pid > 0 && (WIFEXITED(status) || WIFSIGNALED(status)))
- if (--nchild == 0 && donep)
- exit (0);
- } while(pid > 0);
- signal (SIGCHLD, childhandler);
- SIGRETURN(0);
-}
-
-/*
- * Handler for SIGUSR1.
- * This signal means that we should wait until there are no children
- * left and then exit.
- */
-
-static RETSIGTYPE
-usr1handler (int sig)
-{
- donep = 1;
-
- SIGRETURN(0);
-}
-
-/*
- * Almost the same as for SIGUSR1, except we should exit immediately
- * if there are no active children.
- */
-
-static RETSIGTYPE
-usr2handler (int sig)
-{
- donep = 1;
- if (nchild == 0)
- exit (0);
-
- SIGRETURN(0);
-}
-
-/*
- * Establish authenticated connection
- */
-
-static int
-connect_host (char *host, char *user, des_cblock *key,
- des_key_schedule schedule, int port,
- struct sockaddr_in *thisaddr,
- struct sockaddr_in *thataddr)
-{
- CREDENTIALS cred;
- KTEXT_ST text;
- MSG_DAT msg;
- int status;
- int addrlen;
- struct hostent *hostent;
- int s;
- char **p;
-
- hostent = gethostbyname (host);
- if (hostent == NULL) {
- warnx ("gethostbyname '%s' failed: %s", host,
-#ifdef HAVE_H_ERRNO
- hstrerror(h_errno)
-#else
- "unknown error"
-#endif
- );
- return -1;
- }
-
- memset (thataddr, 0, sizeof(*thataddr));
- thataddr->sin_family = AF_INET;
- thataddr->sin_port = port;
- for(p = hostent->h_addr_list; *p; ++p) {
- memcpy (&thataddr->sin_addr, *p, sizeof(thataddr->sin_addr));
-
- s = socket (AF_INET, SOCK_STREAM, 0);
- if (s < 0)
- err (1, "socket");
-
- if (connect (s, (struct sockaddr *)thataddr, sizeof(*thataddr)) < 0) {
- warn ("connect(%s)", host);
- close (s);
- continue;
- } else {
- break;
- }
- }
- if (*p == NULL)
- return -1;
-
- addrlen = sizeof(*thisaddr);
- if (getsockname (s, (struct sockaddr *)thisaddr, &addrlen) < 0 ||
- addrlen != sizeof(*thisaddr))
- err(1, "getsockname(%s)", host);
- status = krb_sendauth (KOPT_DO_MUTUAL, s, &text, "rcmd",
- host, krb_realmofhost (host),
- getpid(), &msg, &cred, schedule,
- thisaddr, thataddr, KX_VERSION);
- if (status != KSUCCESS) {
- warnx ("%s: %s\n", host, krb_get_err_text(status));
- return -1;
- }
- memcpy(key, cred.session, sizeof(des_cblock));
- return s;
-}
-
-/*
- * Get rid of the cookie that we were sent and get the correct one
- * from our own cookie file instead.
- */
-
-static int
-passive_session (int xserver, int fd, des_cblock *iv,
- des_key_schedule schedule)
-{
- if (replace_cookie (xserver, fd, XauFileName()))
- return 1;
- else
- return copy_encrypted (xserver, fd, iv, schedule);
-}
-
-static int
-active_session (int xserver, int fd, des_cblock *iv,
- des_key_schedule schedule)
-{
- if (verify_and_remove_cookies (xserver, fd))
- return 1;
- else
- return copy_encrypted (xserver, fd, iv, schedule);
-}
-
-static void
-status_output (int debugp)
-{
- if(debugp)
- printf ("%u\t%s\t%s\n", (unsigned)getpid(), display, xauthfile);
- else {
- pid_t pid;
-
- pid = fork();
- if (pid < 0) {
- err(1, "fork");
- } else if (pid > 0) {
- printf ("%u\t%s\t%s\n", (unsigned)pid, display, xauthfile);
- exit (0);
- } else {
- fclose(stdout);
- }
- }
-}
-
-/*
- * Obtain an authenticated connection to `host' on `port'. Send a kx
- * message saying we are `user' and want to use passive mode. Wait
- * for answer on that connection and fork of a child for every new
- * connection we have to make.
- */
-
-static int
-doit_passive (char *host, char *user, int debugp, int keepalivep,
- int port)
-{
- des_key_schedule schedule;
- des_cblock key;
- int otherside;
- struct sockaddr_in me, him;
- u_char msg[1024], *p;
- int len;
- void *ret;
- u_int32_t tmp;
-
- otherside = connect_host (host, user, &key, schedule, port,
- &me, &him);
- if (otherside < 0)
- return 1;
-#if defined(SO_KEEPALIVE) && defined(HAVE_SETSOCKOPT)
- if (keepalivep) {
- int one = 1;
-
- setsockopt (otherside, SOL_SOCKET, SO_KEEPALIVE, (void *)&one,
- sizeof(one));
- }
-#endif
-
- p = msg;
- *p++ = INIT;
- len = strlen(user);
- p += krb_put_int (len, p, 4);
- strncpy(p, user, len);
- p += len;
- *p++ = PASSIVE | (keepalivep ? KEEP_ALIVE : 0);
- if (write_encrypted (otherside, msg, p - msg, schedule,
- &key, &me, &him) < 0)
- err (1, "write to %s", host);
- len = read_encrypted (otherside, msg, sizeof(msg), &ret,
- schedule, &key, &him, &me);
- if (len <= 0)
- errx (1,
- "error reading initial message from %s: "
- "this probably means it's using an old version.",
- host);
- p = (u_char *)ret;
- if (*p == ERROR) {
- p++;
- p += krb_get_int (p, &tmp, 4, 0);
- errx (1, "%s: %.*s", host, (int)tmp, p);
- } else if (*p != ACK) {
- errx (1, "%s: strange msg %d", host, *p);
- } else
- p++;
- p += krb_get_int (p, &tmp, 4, 0);
- strncpy(display, p, tmp);
- display[tmp] = '\0';
- p += tmp;
-
- p += krb_get_int (p, &tmp, 4, 0);
- strncpy(xauthfile, p, tmp);
- xauthfile[tmp] = '\0';
- p += tmp;
-
- status_output (debugp);
- for (;;) {
- pid_t child;
-
- len = read_encrypted (otherside, msg, sizeof(msg), &ret,
- schedule, &key, &him, &me);
- if (len < 0)
- err (1, "read from %s", host);
- else if (len == 0)
- return 0;
-
- p = (u_char *)ret;
- if (*p == ERROR) {
- p++;
- p += krb_get_int (p, &tmp, 4, 0);
- errx (1, "%s: %.*s", host, (int)tmp, p);
- } else if(*p != NEW_CONN) {
- errx (1, "%s: strange msg %d", host, *p);
- } else {
- p++;
- p += krb_get_int (p, &tmp, 4, 0);
- }
-
- ++nchild;
- child = fork ();
- if (child < 0) {
- warn("fork");
- continue;
- } else if (child == 0) {
- struct sockaddr_in addr;
- int fd;
- int xserver;
-
- addr = him;
- close (otherside);
-
- addr.sin_port = htons(tmp);
- fd = socket (AF_INET, SOCK_STREAM, 0);
- if (fd < 0)
- err(1, "socket");
-#if defined(TCP_NODELAY) && defined(HAVE_SETSOCKOPT)
- {
- int one = 1;
-
- setsockopt (fd, IPPROTO_TCP, TCP_NODELAY, (void *)&one,
- sizeof(one));
- }
-#endif
-#if defined(SO_KEEPALIVE) && defined(HAVE_SETSOCKOPT)
- if (keepalivep) {
- int one = 1;
-
- setsockopt (fd, SOL_SOCKET, SO_KEEPALIVE, (void *)&one,
- sizeof(one));
- }
-#endif
-
- if (connect (fd, (struct sockaddr *)&addr, sizeof(addr)) < 0)
- err(1, "connect(%s)", host);
- xserver = connect_local_xsocket (0);
- if (xserver < 0)
- return 1;
- return passive_session (xserver, fd, &key, schedule);
- } else {
- }
- }
-}
-
-/*
- * Allocate a local pseudo-xserver and wait for connections
- */
-
-static int
-doit_active (char *host, char *user,
- int debugpp, int keepalivep, int tcpp, int port)
-{
- des_key_schedule schedule;
- des_cblock key;
- int otherside;
- int rendez_vous1 = 0, rendez_vous2 = 0;
- struct sockaddr_in me, him;
- u_char msg[1024], *p;
- int len = strlen(user);
- void *ret;
- u_int32_t tmp;
- char *s;
-
- otherside = connect_host (host, user, &key, schedule, port,
- &me, &him);
- if (otherside < 0)
- return 1;
-#if defined(SO_KEEPALIVE) && defined(HAVE_SETSOCKOPT)
- if (keepalivep) {
- int one = 1;
-
- setsockopt (otherside, SOL_SOCKET, SO_KEEPALIVE, (void *)&one,
- sizeof(one));
- }
-#endif
- p = msg;
- *p++ = INIT;
- len = strlen(user);
- p += krb_put_int (len, p, 4);
- strncpy(p, user, len);
- p += len;
- *p++ = (keepalivep ? KEEP_ALIVE : 0);
-
- s = getenv("DISPLAY");
- if (s == NULL || (s = strchr(s, ':')) == NULL)
- s = ":0";
- len = strlen (s);
- p += krb_put_int (len, p, 4);
- strncpy (p, s, len);
- p += len;
-
- s = getenv("XAUTHORITY");
- if (s == NULL)
- s = "";
- len = strlen (s);
- p += krb_put_int (len, p, 4);
- strncpy (p, s, len);
- p += len;
-
- if (write_encrypted (otherside, msg, p - msg, schedule,
- &key, &me, &him) < 0)
- err (1, "write to %s", host);
-
- len = read_encrypted (otherside, msg, sizeof(msg), &ret,
- schedule, &key, &him, &me);
- if (len < 0)
- err (1, "read from %s", host);
- p = (u_char *)ret;
- if (*p == ERROR) {
- p++;
- p += krb_get_int (p, &tmp, 4, 0);
- errx (1, "%s: %.*s", host, (int)tmp, p);
- } else if (*p != ACK) {
- errx (1, "%s: strange msg %d", host, *p);
- } else
- p++;
-
- tmp = get_xsockets (&rendez_vous1,
- tcpp ? &rendez_vous2 : NULL);
- if (tmp < 0)
- return 1;
- display_num = tmp;
- if (tcpp)
- snprintf (display, display_size, "localhost:%u", display_num);
- else
- snprintf (display, display_size, ":%u", display_num);
- if (create_and_write_cookie (xauthfile, xauthfile_size, cookie, cookie_len))
- return 1;
- status_output (debugpp);
- for (;;) {
- fd_set fdset;
- pid_t child;
- int fd, thisfd;
- int zero = 0;
-
- FD_ZERO(&fdset);
- if (rendez_vous1)
- FD_SET(rendez_vous1, &fdset);
- if (rendez_vous2)
- FD_SET(rendez_vous2, &fdset);
- if (select(FD_SETSIZE, &fdset, NULL, NULL, NULL) <= 0)
- continue;
- if (rendez_vous1 && FD_ISSET(rendez_vous1, &fdset))
- thisfd = rendez_vous1;
- else if (rendez_vous2 && FD_ISSET(rendez_vous2, &fdset))
- thisfd = rendez_vous2;
- else
- continue;
-
- fd = accept (thisfd, NULL, &zero);
- if (fd < 0)
- if (errno == EINTR)
- continue;
- else
- err(1, "accept");
-
- p = msg;
- *p++ = NEW_CONN;
- if (write_encrypted (otherside, msg, p - msg, schedule,
- &key, &me, &him) < 0)
- err (1, "write to %s", host);
- len = read_encrypted (otherside, msg, sizeof(msg), &ret,
- schedule, &key, &him, &me);
- if (len < 0)
- err (1, "read from %s", host);
- p = (u_char *)ret;
- if (*p == ERROR) {
- p++;
- p += krb_get_int (p, &tmp, 4, 0);
- errx (1, "%s: %.*s", host, (int)tmp, p);
- } else if (*p != NEW_CONN) {
- errx (1, "%s: strange msg %d", host, *p);
- } else {
- p++;
- p += krb_get_int (p, &tmp, 4, 0);
- }
-
- ++nchild;
- child = fork ();
- if (child < 0) {
- warn("fork");
- continue;
- } else if (child == 0) {
- int s;
- struct sockaddr_in addr;
-
- if (rendez_vous1)
- close (rendez_vous1);
- if (rendez_vous2)
- close (rendez_vous2);
-
- addr = him;
- close (otherside);
-
- addr.sin_port = htons(tmp);
- s = socket (AF_INET, SOCK_STREAM, 0);
- if (s < 0)
- err(1, "socket");
-#if defined(TCP_NODELAY) && defined(HAVE_SETSOCKOPT)
- {
- int one = 1;
-
- setsockopt (s, IPPROTO_TCP, TCP_NODELAY, (void *)&one,
- sizeof(one));
- }
-#endif
-#if defined(SO_KEEPALIVE) && defined(HAVE_SETSOCKOPT)
- if (keepalivep) {
- int one = 1;
-
- setsockopt (s, SOL_SOCKET, SO_KEEPALIVE, (void *)&one,
- sizeof(one));
- }
-#endif
-
- if (connect (s, (struct sockaddr *)&addr, sizeof(addr)) < 0)
- err(1, "connect");
-
- return active_session (fd, s, &key, schedule);
- } else {
- close (fd);
- }
- }
-}
-
-/*
- *
- */
-
-static int
-check_for_passive (const char *disp)
-{
- char local_hostname[MaxHostNameLen];
-
- gethostname (local_hostname, sizeof(local_hostname));
-
- return disp != NULL &&
- (*disp == ':'
- || strncmp(disp, "unix", 4) == 0
- || strncmp(disp, "localhost", 9) == 0
- || strncmp(disp, local_hostname, strlen(local_hostname) == 0));
-}
-
-static void
-usage(void)
-{
- fprintf (stderr, "Usage: %s [-p port] [-d] [-t] [-l remoteuser] host\n",
- __progname);
- exit (1);
-}
-
-/*
- * kx - forward x connection over a kerberos-encrypted channel.
- *
- */
-
-int
-main(int argc, char **argv)
-{
- int force_passive = 0;
- int keepalivep = 1;
- char *user = NULL;
- int debugp = 0, tcpp = 0;
- int c;
- int port = 0;
-
- set_progname (argv[0]);
- while((c = getopt(argc, argv, "ktdl:p:P")) != EOF) {
- switch(c) {
- case 'd' :
- debugp = 1;
- break;
- case 'k':
- keepalivep = 0;
- break;
- case 't' :
- tcpp = 1;
- break;
- case 'l' :
- user = optarg;
- break;
- case 'p' :
- port = htons(atoi (optarg));
- break;
- case 'P' :
- force_passive = 1;
- break;
- case '?':
- default:
- usage();
- }
- }
-
- argc -= optind;
- argv += optind;
-
- if (argc != 1)
- usage ();
- if (user == NULL) {
- struct passwd *p = k_getpwuid (getuid ());
- if (p == NULL)
- errx(1, "Who are you?");
- user = strdup (p->pw_name);
- if (user == NULL)
- errx (1, "strdup: out of memory");
- }
- if (port == 0)
- port = k_getportbyname ("kx", "tcp", htons(KX_PORT));
- signal (SIGCHLD, childhandler);
- signal (SIGUSR1, usr1handler);
- signal (SIGUSR2, usr2handler);
- if (check_for_passive(getenv("DISPLAY")))
- return doit_passive (argv[0], user, debugp, keepalivep, port);
- else
- return doit_active (argv[0], user, debugp, keepalivep, tcpp, port);
-}
diff --git a/appl/kx/kx.h b/appl/kx/kx.h
deleted file mode 100644
index 7ad5c6ea9b445122da9faf1368a61c465f88b682..0000000000000000000000000000000000000000
--- a/appl/kx/kx.h
+++ /dev/null
@@ -1,162 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifdef HAVE_CONFIG_H
-#include "config.h"
-#endif /* HAVE_CONFIG_H */
-
-#include <stdio.h>
-#include <stdarg.h>
-#include <stdlib.h>
-#include <string.h>
-#include <signal.h>
-#include <errno.h>
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
-#ifdef HAVE_PWD_H
-#include <pwd.h>
-#endif
-#ifdef HAVE_GRP_H
-#include <grp.h>
-#endif
-#ifdef HAVE_SYSLOG_H
-#include <syslog.h>
-#endif
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef TIME_WITH_SYS_TIME
-#include <sys/time.h>
-#include <time.h>
-#elif defined(HAVE_SYS_TIME_H)
-#include <sys/time.h>
-#else
-#include <time.h>
-#endif
-#ifdef HAVE_SYS_RESOURCE_H
-#include <sys/resource.h>
-#endif
-#ifdef HAVE_SYS_SELECT_H
-#include <sys/select.h>
-#endif
-#ifdef HAVE_SYS_WAIT_H
-#include <sys/wait.h>
-#endif
-#ifdef HAVE_SYS_STAT_H
-#include <sys/stat.h>
-#endif
-#ifdef HAVE_SYS_SOCKET_H
-#include <sys/socket.h>
-#endif
-#ifdef HAVE_NETINET_IN_H
-#include <netinet/in.h>
-#endif
-#ifdef HAVE_NETINET_TCP_H
-#include <netinet/tcp.h>
-#endif
-#ifdef HAVE_ARPA_INET_H
-#include <arpa/inet.h>
-#endif
-#ifdef HAVE_NETDB_H
-#include <netdb.h>
-#endif
-#ifdef HAVE_SYS_UN_H
-#include <sys/un.h>
-#endif
-#include <X11/X.h>
-#include <X11/Xlib.h>
-#include <X11/Xauth.h>
-
-#ifdef SOCKS
-#include <socks.h>
-#endif
-
-#include <krb.h>
-
-#include <err.h>
-#include <roken.h>
-
-int copy_encrypted (int fd1, int fd2, des_cblock *iv,
- des_key_schedule schedule);
-
-extern char x_socket[];
-extern u_int32_t display_num;
-extern char display[];
-extern int display_size;
-extern char xauthfile[];
-extern int xauthfile_size;
-extern u_char cookie[];
-extern size_t cookie_len;
-
-int get_xsockets (int *unix_socket, int *tcp_socket);
-int connect_local_xsocket (unsigned dnr);
-int create_and_write_cookie (char *xauthfile,
- size_t size,
- u_char *cookie,
- size_t sz);
-int verify_and_remove_cookies (int fd, int sock);
-int replace_cookie(int xserver, int fd, char *filename);
-
-int suspicious_address (int sock, struct sockaddr_in addr);
-
-int
-write_encrypted (int fd, void *buf, size_t len, des_key_schedule schedule,
- des_cblock *session, struct sockaddr_in *me,
- struct sockaddr_in *him);
-
-int
-read_encrypted (int fd, void *buf, size_t len, void **ret,
- des_key_schedule schedule, des_cblock *session,
- struct sockaddr_in *him, struct sockaddr_in *me);
-
-
-#define KX_PORT 2111
-
-#define KX_OLD_VERSION "KXSERV.1"
-#define KX_VERSION "KXSERV.2"
-
-#define COOKIE_TYPE "MIT-MAGIC-COOKIE-1"
-
-enum { INIT = 0, ACK = 1, NEW_CONN = 2, ERROR = 3 };
-
-enum kx_flags { PASSIVE = 1, KEEP_ALIVE = 2 };
-
-typedef enum kx_flags kx_flags;
diff --git a/appl/kx/kxd.8 b/appl/kx/kxd.8
deleted file mode 100644
index 6d6b45c1ab6cc04e63455cd8d1994ff06507b5bc..0000000000000000000000000000000000000000
--- a/appl/kx/kxd.8
+++ /dev/null
@@ -1,54 +0,0 @@
-.\" $Id$
-.\"
-.Dd September 27, 1996
-.Dt KXD 8
-.Os KTH-KRB
-.Sh NAME
-.Nm kxd
-.Nd
-securely forward X conections
-.Sh SYNOPSIS
-.Ar kxd
-.Op Fl t
-.Op Fl i
-.Op Fl p Ar port
-.Sh DESCRIPTION
-This is the daemon for
-.Nm kx .
-.Pp
-Options supported by
-.Nm kxd :
-.Bl -tag -width Ds
-.It Fl t
-TCP. Normally
-.Nm kxd
-will only listen for X connections on a UNIX socket, but some machines
-(for example, Cray) have X libraries that are not able to use UNIX
-sockets and thus you need to use TCP to talk to the pseudo-xserver
-created by
-.Nm kxd.
-This option decreases the security significantly and should only be
-used when it is necessary and you have considered the consequences of
-doing so.
-.It Fl i
-Interactive. Do not expect to be started by
-.Nm inetd,
-but allocate and listen to the socket yourself. Handy for testing
-and debugging.
-.It Fl p
-Port. Listen on the port
-.Ar port .
-Only usable with
-.Fl i .
-.El
-
-.Sh EXAMPLES
-Put the following in
-.Pa /etc/inetd.conf :
-.Bd -literal
-kx stream tcp nowait root /usr/athena/libexec/kxd kxd
-.Ed
-.Sh SEE ALSO
-.Xr kx 1 ,
-.Xr rxtelnet 1 ,
-.Xr rxterm 1
diff --git a/appl/kx/kxd.c b/appl/kx/kxd.c
deleted file mode 100644
index 6bfcb2156663eed59a84cef95f8e96c456351678..0000000000000000000000000000000000000000
--- a/appl/kx/kxd.c
+++ /dev/null
@@ -1,534 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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 "kx.h"
-
-RCSID("$Id$");
-
-/*
- * Signal handler that justs waits for the children when they die.
- */
-
-static RETSIGTYPE
-childhandler (int sig)
-{
- pid_t pid;
- int status;
-
- do {
- pid = waitpid (-1, &status, WNOHANG|WUNTRACED);
- } while(pid > 0);
- signal (SIGCHLD, childhandler);
- SIGRETURN(0);
-}
-
-static void
-fatal(int, des_cblock *, des_key_schedule,
- struct sockaddr_in *, struct sockaddr_in *,
- char *format, ...)
-#ifdef __GNUC__
-__attribute__ ((format (printf, 6, 7)))
-#endif
-;
-
-static void
-fatal (int fd, des_cblock *key, des_key_schedule schedule,
- struct sockaddr_in *thisaddr,
- struct sockaddr_in *thataddr,
- char *format, ...)
-{
- u_char msg[1024];
- u_char *p;
- va_list args;
- int len;
-
- va_start(args, format);
- p = msg;
- *p++ = ERROR;
- vsnprintf (p + 4, sizeof(msg) - 5, format, args);
- syslog (LOG_ERR, p + 4);
- len = strlen (p + 4);
- p += krb_put_int (len, p, 4);
- p += len;
- write_encrypted (fd, msg, p - msg, schedule, key, thisaddr, thataddr);
- va_end(args);
- exit (1);
-}
-
-static void
-cleanup(void)
-{
- if(xauthfile[0])
- unlink(xauthfile);
- if(x_socket[0])
- unlink(x_socket);
-}
-
-static int
-recv_conn (int sock, des_cblock *key, des_key_schedule schedule,
- struct sockaddr_in *thisaddr,
- struct sockaddr_in *thataddr)
-{
- int status;
- KTEXT_ST ticket;
- AUTH_DAT auth;
- char user[ANAME_SZ + 1];
- char instance[INST_SZ + 1];
- int addrlen;
- char version[KRB_SENDAUTH_VLEN + 1];
- struct passwd *passwd;
- char remotehost[MaxHostNameLen];
- void *ret;
- int len;
- u_char msg[1024], *p;
- u_int32_t tmp;
- int flags;
-
- addrlen = sizeof(*thisaddr);
- if (getsockname (sock, (struct sockaddr *)thisaddr, &addrlen) < 0 ||
- addrlen != sizeof(*thisaddr)) {
- syslog (LOG_ERR, "getsockname: %m");
- exit (1);
- }
- addrlen = sizeof(*thataddr);
- if (getpeername (sock, (struct sockaddr *)thataddr, &addrlen) < 0 ||
- addrlen != sizeof(*thataddr)) {
- syslog (LOG_ERR, "getpeername: %m");
- exit (1);
- }
-
- inaddr2str (thataddr->sin_addr, remotehost, sizeof(remotehost));
-
- k_getsockinst (sock, instance, sizeof(instance));
- status = krb_recvauth (KOPT_DO_MUTUAL, sock, &ticket, "rcmd", instance,
- thataddr, thisaddr, &auth, "", schedule,
- version);
- if (status != KSUCCESS) {
- syslog (LOG_ERR, "krb_recvauth: %s",
- krb_get_err_text(status));
- exit(1);
- }
- if( strncmp(version, KX_VERSION, KRB_SENDAUTH_VLEN) != 0) {
- /* Try to be nice to old kx's */
- if (strncmp (version, KX_OLD_VERSION, KRB_SENDAUTH_VLEN) == 0) {
- char *old_errmsg = "\001Old version of kx. Please upgrade.";
-
- syslog (LOG_ERR, "Old version client (%s)", version);
-
- krb_net_read (sock, user, sizeof(user));
- krb_net_write (sock, old_errmsg, strlen(old_errmsg) + 1);
- exit (1);
- }
-
- fatal(sock, key, schedule, thisaddr, thataddr,
- "Bad version %s", version);
- }
- memcpy(key, &auth.session, sizeof(des_cblock));
-
- len = read_encrypted (sock, msg, sizeof(msg), &ret,
- schedule, key, thataddr, thisaddr);
- if (len < 0)
- return 1;
- p = (u_char *)ret;
- if (*p != INIT)
- fatal(sock, key, schedule, thisaddr, thataddr,
- "Bad message");
- p++;
- p += krb_get_int (p, &tmp, 4, 0);
- len = min(sizeof(user), tmp);
- strncpy (user, p, len);
- p += tmp;
- user[len] = '\0';
-
- passwd = k_getpwnam (user);
- if (passwd == NULL)
- fatal (sock, key, schedule, thisaddr, thataddr,
- "Cannot find uid");
- if (kuserok(&auth, user) != 0)
- fatal (sock, key, schedule, thisaddr, thataddr,
- "%s is not allowed to login as %s",
- krb_unparse_name_long (auth.pname,
- auth.pinst,
- auth.prealm),
- user);
- if (setgid (passwd->pw_gid) ||
- initgroups(passwd->pw_name, passwd->pw_gid) ||
- setuid(passwd->pw_uid)) {
- fatal (sock, key, schedule, thisaddr, thataddr,
- "Cannot set uid");
- }
- syslog (LOG_INFO, "from %s(%s): %s -> %s",
- remotehost,
- inet_ntoa(thataddr->sin_addr),
- krb_unparse_name_long (auth.pname, auth.pinst, auth.prealm),
- user);
- umask(077);
- flags = *p++;
- if (!(flags & PASSIVE)) {
- p += krb_get_int (p, &tmp, 4, 0);
- len = min(tmp, display_size);
- strncpy (display, p, len);
- display[len] = '\0';
- p += tmp;
- p += krb_get_int (p, &tmp, 4, 0);
- len = min(tmp, xauthfile_size);
- strncpy (xauthfile, p, len);
- p += tmp;
- }
-#if defined(SO_KEEPALIVE) && defined(HAVE_SETSOCKOPT)
- if (flags & KEEP_ALIVE) {
- int one = 1;
-
- setsockopt (sock, SOL_SOCKET, SO_KEEPALIVE, (void *)&one,
- sizeof(one));
- }
-#endif
- return flags;
-}
-
-/*
- *
- */
-
-static int
-passive_session (int fd, int sock, des_cblock *key,
- des_key_schedule schedule)
-{
- if (verify_and_remove_cookies (fd, sock))
- return 1;
- else
- return copy_encrypted (fd, sock, key, schedule);
-}
-
-static int
-active_session (int fd, int sock, des_cblock *key,
- des_key_schedule schedule)
-{
- fd = connect_local_xsocket(0);
-
- if (replace_cookie (fd, sock, xauthfile))
- return 1;
- else
- return copy_encrypted (fd, sock, key, schedule);
-}
-
-static int
-doit_conn (int fd, int meta_sock, int flags,
- des_cblock *key, des_key_schedule schedule,
- struct sockaddr_in *thisaddr,
- struct sockaddr_in *thataddr)
-{
- int sock, sock2;
- struct sockaddr_in addr;
- int addrlen;
- u_char msg[1024], *p;
-
- sock = socket (AF_INET, SOCK_STREAM, 0);
- if (sock < 0) {
- syslog (LOG_ERR, "socket: %m");
- return 1;
- }
-#if defined(TCP_NODELAY) && defined(HAVE_SETSOCKOPT)
- {
- int one = 1;
- setsockopt (sock, IPPROTO_TCP, TCP_NODELAY, (void *)&one, sizeof(one));
- }
-#endif
-#if defined(SO_KEEPALIVE) && defined(HAVE_SETSOCKOPT)
- if (flags & KEEP_ALIVE) {
- int one = 1;
-
- setsockopt (sock, SOL_SOCKET, SO_KEEPALIVE, (void *)&one,
- sizeof(one));
- }
-#endif
- memset (&addr, 0, sizeof(addr));
- addr.sin_family = AF_INET;
- if (bind (sock, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
- syslog (LOG_ERR, "bind: %m");
- return 1;
- }
- addrlen = sizeof(addr);
- if (getsockname (sock, (struct sockaddr *)&addr,
- &addrlen) < 0) {
- syslog (LOG_ERR, "getsockname: %m");
- return 1;
- }
- if (listen (sock, SOMAXCONN) < 0) {
- syslog (LOG_ERR, "listen: %m");
- return 1;
- }
- p = msg;
- *p++ = NEW_CONN;
- p += krb_put_int (ntohs(addr.sin_port), p, 4);
-
- if (write_encrypted (meta_sock, msg, p - msg, schedule, key,
- thisaddr, thataddr) < 0) {
- syslog (LOG_ERR, "write: %m");
- return 1;
- }
-
- sock2 = accept (sock, (struct sockaddr *)thisaddr, &addrlen);
- if (sock2 < 0) {
- syslog (LOG_ERR, "accept: %m");
- return 1;
- }
- close (sock);
- close (meta_sock);
-
- if (flags & PASSIVE)
- return passive_session (fd, sock2, key, schedule);
- else
- return active_session (fd, sock2, key, schedule);
-}
-
-/*
- *
- */
-
-static void
-check_user_console (int fd, des_cblock *key, des_key_schedule schedule,
- struct sockaddr_in *thisaddr,
- struct sockaddr_in *thataddr)
-{
- struct stat sb;
-
- if (stat ("/dev/console", &sb) < 0)
- fatal (fd, key, schedule, thisaddr, thataddr,
- "Cannot stat /dev/console");
- if (getuid() != sb.st_uid)
- fatal (fd, key, schedule, thisaddr, thataddr,
- "Permission denied");
-}
-
-/*
- * Receive a connection on `sock' and process it.
- */
-
-static int
-doit(int sock, int tcpp)
-{
- des_key_schedule schedule;
- des_cblock key;
- int localx, tcpx;
- struct sockaddr_in me, him;
- int flags;
- u_char msg[1024], *p;
-
- flags = recv_conn (sock, &key, schedule, &me, &him);
-
- if (flags & PASSIVE) {
- int tmp;
- int len;
-
- tmp = get_xsockets (&localx, tcpp ? &tcpx : NULL);
- if (tmp < 0)
- return 1;
- display_num = tmp;
- if (tcpp)
- snprintf (display, display_size, "localhost:%u", display_num);
- else
- snprintf (display, display_size, ":%u", display_num);
- if(create_and_write_cookie (xauthfile, xauthfile_size,
- cookie, cookie_len)) {
- syslog(LOG_ERR, "create_and_write_cookie: %m");
- fatal (sock, &key, schedule, &me, &him,
- "Cookie-creation failed with: %s",
- strerror(errno));
- cleanup();
- return 1;
- }
-
- p = msg;
- *p++ = ACK;
- len = strlen (display);
- p += krb_put_int (len, p, 4);
- strncpy (p, display, len);
- p += len;
- len = strlen (xauthfile);
- p += krb_put_int (len, p, 4);
- strncpy (p, xauthfile, len);
- p += len;
-
- if(write_encrypted (sock, msg, p - msg, schedule, &key,
- &me, &him) < 0) {
- syslog (LOG_ERR, "write: %m");
- cleanup();
- return 1;
- }
- for (;;) {
- pid_t child;
- int fd;
- int zero = 0;
- fd_set fds;
-
- FD_ZERO(&fds);
- FD_SET(localx, &fds);
- FD_SET(sock, &fds);
- if (tcpp)
- FD_SET(tcpx, &fds);
- if(select(FD_SETSIZE, &fds, NULL, NULL, NULL) <=0)
- continue;
- if(FD_ISSET(sock, &fds)){
- /* there are no processes left on the remote side
- */
- cleanup();
- exit(0);
- } else if(FD_ISSET(localx, &fds))
- fd = accept (localx, NULL, &zero);
- else if(tcpp && FD_ISSET(tcpx, &fds)) {
- struct sockaddr_in peer;
- int len = sizeof(peer);
-
- fd = accept (tcpx, (struct sockaddr *)&peer, &len);
- /* XXX */
- if (fd >= 0 && suspicious_address (fd, peer)) {
- close (fd);
- continue;
- }
- } else
- continue;
- if (fd < 0)
- if (errno == EINTR)
- continue;
- else {
- syslog (LOG_ERR, "accept: %m");
- return 1;
- }
-
- child = fork ();
- if (child < 0) {
- syslog (LOG_ERR, "fork: %m");
- return 1;
- } else if (child == 0) {
- close (localx);
- if (tcpp)
- close (tcpx);
- return doit_conn (fd, sock, flags,
- &key, schedule, &me, &him);
- } else {
- close (fd);
- }
- }
- } else {
- check_user_console (sock, &key, schedule, &me, &him);
-
- p = msg;
- *p++ = ACK;
-
- if(write_encrypted (sock, msg, p - msg, schedule, &key,
- &me, &him) < 0) {
- syslog (LOG_ERR, "write: %m");
- return 1;
- }
- for (;;) {
- pid_t child;
- int len;
- void *ret;
-
- len = read_encrypted (sock, msg, sizeof(msg), &ret,
- schedule, &key,
- &him, &me);
- if (len < 0) {
- syslog (LOG_ERR, "read: %m");
- return 1;
- }
- p = (u_char *)ret;
- if (*p != NEW_CONN) {
- syslog (LOG_ERR, "bad_message: %d", *p);
- return 1;
- }
-
- child = fork ();
- if (child < 0) {
- syslog (LOG_ERR, "fork: %m");
- return 1;
- } else if (child == 0) {
- return doit_conn (localx, sock, flags,
- &key, schedule, &me, &him);
- } else {
- }
- }
- }
-}
-
-static void
-usage (void)
-{
- fprintf (stderr, "Usage: %s [-i] [-t] [-p port]\n", __progname);
- exit (1);
-}
-
-/*
- * kxd - receive a forwarded X conncection
- */
-
-int
-main (int argc, char **argv)
-{
- int c;
- int no_inetd = 0;
- int tcpp = 0;
- int port = 0;
-
- set_progname (argv[0]);
-
- while( (c = getopt (argc, argv, "itp:")) != EOF) {
- switch (c) {
- case 'i':
- no_inetd = 1;
- break;
- case 't':
- tcpp = 1;
- break;
- case 'p':
- port = htons(atoi (optarg));
- break;
- case '?':
- default:
- usage ();
- }
- }
-
- if (no_inetd)
- mini_inetd (port ? port : k_getportbyname("kx", "tcp",
- htons(KX_PORT)));
- openlog(__progname, LOG_PID|LOG_CONS, LOG_DAEMON);
- signal (SIGCHLD, childhandler);
- return doit(STDIN_FILENO, tcpp);
-}
diff --git a/appl/kx/rxtelnet.1 b/appl/kx/rxtelnet.1
deleted file mode 100644
index f0cd33b3902ed01138508372e5efef54cc2d494e..0000000000000000000000000000000000000000
--- a/appl/kx/rxtelnet.1
+++ /dev/null
@@ -1,77 +0,0 @@
-.\" $Id$
-.\"
-.Dd September 27, 1996
-.Dt RXTELNET 1
-.Os KTH_KRB
-.Sh NAME
-.Nm rxtelnet
-.Nd
-start a telnet and forward X-connections.
-.Sh SYNOPSIS
-.Nm rxtelnet
-.Op Fl l Ar username
-.Op Fl k
-.Op Fl t Ar telnet_args
-.Op Fl x Ar xterm_args
-.Op Fl w Ar term_emulator
-.Ar host
-.Op Ar port
-.Sh DESCRIPTION
-The
-.Nm
-program starts a
-.Nm xterm
-window with a telnet to host
-.Ar host .
-From this window you will also be able to run X clients that will be
-able to connect securily to your X server. If
-.Ar port
-is given, that port will be used instead of the default.
-.Pp
-The supported options are:
-.Bl -tag -width Ds
-.It Fl l
-Log in on the remote host as user
-.Ar username
-.It Fl k
-Disables keep-alives
-.It Fl t
-Send
-.Ar telnet_args
-as arguments to
-.Nm telnet
-.It Fl x
-Send
-.Ar xterm_args
-as arguments to
-.Nm xterm
-.It Fl w
-Use
-.Ar term_emulator
-instead of xterm.
-.El
-.Sh EXAMPLE
-To login from host
-.Va foo
-(where your display is)
-to host
-.Va bar ,
-you might do the following.
-.Bl -enum
-.It
-On foo:
-.Nm
-.Va bar
-.It
-You will get a new window with a
-.Nm telnet
-to
-.Va bar .
-In this window you will be able to start X clients.
-.El
-.Sh SEE ALSO
-.Xr rxterm 1 ,
-.Xr tenletxr 1 ,
-.Xr kx 1 ,
-.Xr kxd 8 ,
-.Xr telnet 1
diff --git a/appl/kx/rxtelnet.in b/appl/kx/rxtelnet.in
deleted file mode 100644
index a35632e4c22cd1eead90bff192cdda3247d5bf70..0000000000000000000000000000000000000000
--- a/appl/kx/rxtelnet.in
+++ /dev/null
@@ -1,57 +0,0 @@
-#!/bin/sh
-# $Id$
-#
-usage="Usage: $0 [-l username] [-k] [-t args_to_telnet] [-x args_to_xterm] [-w term_emulator] host [port]"
-term=
-kx_args=-P
-while true
-do
- case $1 in
- -l) telnet_args="${telnet_args} -l $2 "; kx_args="${kx_args} -l $2"; title="${2}@"; shift 2;;
- -t) telnet_args="${telnet_args} $2 "; shift 2;;
- -x) xterm_args="${xterm_args} $2 "; shift 2;;
- -k) kx_args="${kx_args} -k"; shift;;
- -w) term=$2; shift 2;;
- -*) echo "$0: Bad option $1"; echo $usage; exit 1;;
- *) break;;
- esac
-done
-if test $# -lt 1; then
- echo $usage
- exit 1
-fi
-host=$1
-port=$2
-title="${title}${host}"
-bindir=%bindir%
-pdc_trams=`dirname $0`
-PATH=$pdc_trams:$bindir:$PATH
-export PATH
-set -- `kx $kx_args $host`
-if test $# -ne 3; then
- exit 1
-fi
-screen=`echo $DISPLAY | sed -ne 's/[^:]*:[0-9]*\(\.[0-9]*\)/\1/p'`
-pid=$1
-disp=${2}${screen}
-auth=$3
-oldifs=$IFS
-IFS=:
-set -- $PATH
-IFS=$oldifs
-if test -z "$term"; then
- for j in xterm dtterm aixterm dxterm hpterm; do
- for i in $*; do
- test -n "$i" || i="."
- if test -x $i/$j; then
- term=$j; break 2
- fi
- done
- done
-fi
-if test -n "$term"; then
- ($term -title $title -n $title $xterm_args -e env DISPLAY=$disp XAUTHORITY=$auth telnet -D $telnet_args $host $port; kill -USR2 $pid) &
-else
- env DISPLAY=$disp XAUTHORITY=$auth telnet -D $telnet_args $host $port
- kill -USR2 $pid
-fi
diff --git a/appl/kx/rxterm.1 b/appl/kx/rxterm.1
deleted file mode 100644
index 4fde08e3b65535c3b898007184d1f194657fb865..0000000000000000000000000000000000000000
--- a/appl/kx/rxterm.1
+++ /dev/null
@@ -1,77 +0,0 @@
-.\" $Id$
-.\"
-.Dd September 27, 1996
-.Dt RXTERM 1
-.Os KTH_KRB
-.Sh NAME
-.Nm rxterm
-.Nd
-start a secure remote xterm
-.Sh SYNOPSIS
-.Nm rxterm
-.Op Fl l Ar username
-.Op Fl k
-.Op Fl r Ar rsh_args
-.Op Fl x Ar xterm_args
-.Op Fl w Ar term_emulator
-.Ar host
-.Op Ar port
-.Sh DESCRIPTION
-The
-.Nm
-program starts a
-.Nm xterm
-window on host
-.Ar host .
-From this window you will also be able to run X clients that will be
-able to connect securily to your X server. If
-.Ar port
-is given, that port will be used instead of the default.
-.Pp
-The supported options are:
-.Bl -tag -width Ds
-.It Fl l
-Log in on the remote host as user
-.Ar username
-.It Fl k
-Disable keep-alives
-.It Fl r
-Send
-.Ar rsh_args
-as arguments to
-.Nm rsh
-.It Fl x
-Send
-.Ar xterm_args
-as arguments to
-.Nm xterm
-.It Fl w
-Use
-.Ar term_emulator
-instead of xterm.
-.El
-.Sh EXAMPLE
-To login from host
-.Va foo
-(where your display is)
-to host
-.Va bar ,
-you might do the following.
-.Bl -enum
-.It
-On foo:
-.Nm
-.Va bar
-.It
-You will get a new window running an
-.Nm xterm
-on host
-.Va bar .
-In this window you will be able to start X clients.
-.El
-.Sh SEE ALSO
-.Xr rxtelnet 1 ,
-.Xr tenletxr 1 ,
-.Xr kx 1 ,
-.Xr kxd 8 ,
-.Xr rsh 1
diff --git a/appl/kx/rxterm.in b/appl/kx/rxterm.in
deleted file mode 100644
index 8d4e9e2d88df8d769d51c03986e5862099945ff9..0000000000000000000000000000000000000000
--- a/appl/kx/rxterm.in
+++ /dev/null
@@ -1,37 +0,0 @@
-#!/bin/sh
-# $Id$
-#
-usage="Usage: $0 [-l username] [-k] [-r rsh_args] [-x xterm_args] [-w term_emulator] host"
-term=xterm
-while true
-do
- case $1 in
- -l) rsh_args="${rsh_args} -l $2 "; kx_args="${kx_args} -l $2"; title="${2}@"; shift 2;;
- -r) rsh_args="${rsh_args} $2 "; shift 2;;
- -x) xterm_args="${xterm_args} $2 "; shift 2;;
- -k) kx_args="${kx_args} -k"; shift;;
- -w) term=$2; shift 2;;
- -*) echo "$0: Bad option $1"; echo $usage; exit 1;;
- *) break;;
- esac
-done
-if test $# -lt 1; then
- echo "Usage: $0 host [arguments to $term]"
- exit 1
-fi
-host=$1
-title="${title}${host}"
-bindir=%bindir%
-pdc_trams=`dirname $0`
-PATH=$pdc_trams:$bindir:$PATH
-export PATH
-set -- `kx $kx_args $host`
-if test $# -ne 3; then
- exit 1
-fi
-screen=`echo $DISPLAY | sed -ne 's/[^:]*:[0-9]*\(\.[0-9]*\)/\1/p'`
-pid=$1
-disp=${2}${screen}
-auth=$3
-kill -USR1 $pid
-rsh -n $rsh_args $host "env DISPLAY=$disp XAUTHORITY=$auth $term -T $title -n $title $xterm_args &"
diff --git a/appl/kx/tenletxr.1 b/appl/kx/tenletxr.1
deleted file mode 100644
index 0038ca54dfc726a7930d160b46ea79a07c322f50..0000000000000000000000000000000000000000
--- a/appl/kx/tenletxr.1
+++ /dev/null
@@ -1,61 +0,0 @@
-.\" $Id$
-.\"
-.Dd March 31, 1997
-.Dt TENLETXR 1
-.Os KTH_KRB
-.Sh NAME
-.Nm tenletxr
-.Nd
-forward X-connections backwards.
-.Sh SYNOPSIS
-.Nm tenletxr
-.Op Fl l Ar username
-.Op Fl k
-.Ar host
-.Op Ar port
-.Sh DESCRIPTION
-The
-.Nm
-program
-enables forwarding of X-connections from this machine to host
-.Ar host .
-If
-.Ar port
-is given, that port will be used instead of the default.
-.Pp
-The supported options are:
-.Bl -tag -width Ds
-.It Fl l
-Log in on the remote host as user
-.Ar username
-.It Fl k
-Disables keep-alives.
-.El
-.Sh EXAMPLE
-To login from host
-.Va foo
-to host
-.Va bar
-(where your display is),
-you might do the following.
-.Bl -enum
-.It
-On foo:
-.Nm
-.Va bar
-.It
-You will get a new shell where you will be able to start X clients
-that will show their windows on
-.Va bar .
-.El
-.Sh BUGS
-It currently checks if you have permission to run it by checking if
-you own
-.Pa /dev/console
-on the remote host.
-.Sh SEE ALSO
-.Xr rxtelnet 1 ,
-.Xr rxterm 1 ,
-.Xr kx 1 ,
-.Xr kxd 8 ,
-.Xr telnet 1
diff --git a/appl/kx/tenletxr.in b/appl/kx/tenletxr.in
deleted file mode 100644
index bed9871853b53ee592a885da1f50edea7f4d6458..0000000000000000000000000000000000000000
--- a/appl/kx/tenletxr.in
+++ /dev/null
@@ -1,33 +0,0 @@
-#!/bin/sh
-# $Id$
-#
-usage="Usage: $0 [-l username] [-k] host [port]"
-while true
-do
- case $1 in
- -l) kx_args="${kx_args} -l $2"; shift 2;;
- -k) kx_args="${kx_args} -k"; shift;;
- -*) echo "$0: Bad option $1"; echo $usage; exit 1;;
- *) break;;
- esac
-done
-if test $# -lt 1; then
- echo $usage
- exit 1
-fi
-host=$1
-port=$2
-bindir=%bindir%
-pdc_trams=`dirname $0`
-PATH=$pdc_trams:$bindir:$PATH
-export PATH
-set -- `kx $kx_args $host`
-if test $# -ne 3; then
- exit 1
-fi
-screen=`echo $DISPLAY | sed -ne 's/[^:]*:[0-9]*\(\.[0-9]*\)/\1/p'`
-pid=$1
-disp=${2}${screen}
-auth=$3
-env DISPLAY=$disp XAUTHORITY=$auth $SHELL
-kill -USR2 $pid
diff --git a/appl/kx/writeauth.c b/appl/kx/writeauth.c
deleted file mode 100644
index 3c9d829b0c53010067a9743b3b9bd696f55c9b53..0000000000000000000000000000000000000000
--- a/appl/kx/writeauth.c
+++ /dev/null
@@ -1,82 +0,0 @@
-/* $XConsortium: AuWrite.c,v 1.6 94/04/17 20:15:45 gildea Exp $ */
-
-/*
-
-Copyright (c) 1988 X Consortium
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
-AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-Except as contained in this notice, the name of the X Consortium shall not be
-used in advertising or otherwise to promote the sale, use or other dealings
-in this Software without prior written authorization from the X Consortium.
-
-*/
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-RCSID("$Id$");
-#endif
-
-#include <X11/Xauth.h>
-
-static
-write_short (s, file)
-unsigned short s;
-FILE *file;
-{
- unsigned char file_short[2];
-
- file_short[0] = (s & (unsigned)0xff00) >> 8;
- file_short[1] = s & 0xff;
- if (fwrite (file_short, sizeof (file_short), 1, file) != 1)
- return 0;
- return 1;
-}
-
-static
-write_counted_string (count, string, file)
-unsigned short count;
-char *string;
-FILE *file;
-{
- if (write_short (count, file) == 0)
- return 0;
- if (fwrite (string, (int) sizeof (char), (int) count, file) != count)
- return 0;
- return 1;
-}
-
-int
-XauWriteAuth (auth_file, auth)
-FILE *auth_file;
-Xauth *auth;
-{
- char *malloc ();
-
- if (write_short (auth->family, auth_file) == 0)
- return 0;
- if (write_counted_string (auth->address_length, auth->address, auth_file) == 0)
- return 0;
- if (write_counted_string (auth->number_length, auth->number, auth_file) == 0)
- return 0;
- if (write_counted_string (auth->name_length, auth->name, auth_file) == 0)
- return 0;
- if (write_counted_string (auth->data_length, auth->data, auth_file) == 0)
- return 0;
- return 1;
-}
diff --git a/appl/popper/popper.8 b/appl/popper/popper.8
deleted file mode 100644
index 30dc5b93fcf84a6303a25ae3f60f1ec4d51845fc..0000000000000000000000000000000000000000
--- a/appl/popper/popper.8
+++ /dev/null
@@ -1,179 +0,0 @@
-.\" Copyright (c) 1980 Regents of the University of California.
-.\" All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms are permitted
-.\" provided that this notice is preserved and that due credit is given
-.\" to the University of California at Berkeley. The name of the University
-.\" may not be used to endorse or promote products derived from this
-.\" software without specific prior written permission. This software
-.\" is provided ``as is'' without express or implied warranty.
-.\"
-.\" @(#)@(#)popper.8 2.3 2.3 (CCS) 4/2/91 Copyright (c) 1990 Regents of the University of California.\nAll rights reserved.\n
-.\"
-.TH popper 8 "August 1990"
-.UC 6
-.ad
-.SH NAME
-popper \- pop 3 server
-.SH SYNOPSIS
-.B /usr/etc/popper
-[ -d ]
-[ -a ]
-[ -k ]
-[ -t trace-file]
-[ -i ]
-[ -p portnum]
-.SH DESCRIPTION
-.I Popper
-is an implementation of the Post Office Protocol server that runs on a
-variety of Unix computers to manage electronic mail for Macintosh
-and MS-DOS computers. The server was developed at the University of
-California at Berkeley and conforms fully to the specifications in RFC
-1081 and RFC 1082. The Berkeley server also has extensions to
-send electronic mail on behalf of a client.
-.PP
-The
-.B \-d
-flag sets the socket to debugging and turns on debugging. All debugging
-information is saved using syslog(8).
-.PP
-The
-.B \-t trace\-file
-flag turns on debugging and saves the trace information in
-.I trace\-file
-using fprintf(s).
-.PP
-The
-.B \-k
-flag tells popper to talk the kerberised POP protocol (KPOP).
-.PP
-The
-.B \-a
-flag tells popper not to accept any cleartext passwords, but only OTPs.
-.PP
-The
-.B \-i
-flag tells popper it has not been started by inetd and should create
-its own socket and listen on it. This is useful for debugging.
-.PP
-The
-.B \-p portnum
-flag tells popper on which port it should listen for connections when
-creating a socket.
-.SH HOW TO OBTAIN THE SERVER
-.PP
-The POP server is available via anonymous ftp from ftp.CC.Berkeley.EDU
-(128.32.136.9, 128.32.206.12). It is in two files in the pub directory:
-a compressed
-tar file popper.tar.Z and a Macintosh StuffIt archive in BinHex format
-called MacPOP.sit.hqx.
-.SH THE POP TRANSACTION CYCLE
-.PP
-The Berkeley POP server is a single program (called popper) that is
-launched by inetd when it gets a service request on the POP TCP port.
-(The official port number specified in RFC 1081 for POP version 3 is
-port 110. However, some POP3 clients attempt to contact the server at
-port 109, the POP version 2 port. Unless you are running both POP2 and
-POP3 servers, you can simply define both ports for use by the POP3
-server. This is explained in the installation instructions later on.)
-The popper program initializes and verifies that the peer IP address is
-registered in the local domain, logging a warning message when a
-connection is made to a client whose IP address does not have a
-canonical name. For systems using BSD 4.3 bind, it also checks to see
-if a cannonical name lookup for the client returns the same peer IP
-address, logging a warning message if it does not. The the server
-enters the authorization state, during which the client must correctly
-identify itself by providing a valid Unix userid and password on the
-server's host machine. No other exchanges are allowed during this
-state (other than a request to quit.) If authentication fails, a
-warning message is logged and the session ends. Once the user is
-identified, popper changes its user and group ids to match that of the
-user and enters the transaction state. The server makes a temporary
-copy of the user's maildrop (ordinarily in /usr/spool/mail) which is
-used for all subsequent transactions. These include the bulk of POP
-commands to retrieve mail, delete mail, undelete mail, and so forth. A
-Berkeley extension also allows the user to submit a mail parcel to the
-server who mails it using the sendmail program (this extension is
-supported in the HyperMail client distributed with the server). When
-the client quits, the server enters the final update state during which
-the network connection is terminated and the user's maildrop is updated
-with the (possibly) modified temporary maildrop.
-.SH LOGGING
-.PP
-The POP server uses syslog to keep a record of its activities. On
-systems with BSD 4.3 syslogging, the server logs (by default) to the
-"local0" facility at priority "notice" for all messages except
-debugging which is logged at priority "debug". The default log file is
-/usr/spool/mqueue/POPlog. These can be changed, if desired. On
-systems with 4.2 syslogging all messages are logged to the local log
-file, usually /usr/spool/mqueue/syslog.
-.SH DEBUGGING
-.PP
-The popper program will log debugging information when the -d parameter
-is specified after its invocation in the inetd.conf file. Care should
-be exercised in using this option since it generates considerable
-output in the syslog file. Alternatively, the "-t <file-name>" option
-will place debugging information into file "<file-name>" using fprintf
-instead of syslog.
-.PP
-For SunOS version 3.5, the popper program is launched by inetd from
-/etc/servers. This file does not allow you to specify command line
-arguments. Therefore, if you want to enable debugging, you can specify
-a shell script in /etc/servers to be launched instead of popper and in
-this script call popper with the desired arguments.
-.PP
-You can confirm that the POP server is running on Unix by telneting to
-port 110 (or 109 if you set it up that way). For example:
-.PP
-.nf
-%telnet myhost 110
-Trying...
-Connected to myhost.berkeley.edu.
-Escape character is '^]'.
-+OK UCB Pop server (version 1.6) at myhost starting.
-quit
-Connection closed by foreign host.
-.fi
-.SH VERSION 1.7 RELEASE NOTES
-Extensive re-write of the maildrop processing code contributed by
-Viktor Dukhovni <viktor@math.princeton.edu> that greatly reduces the
-possibility that the maildrop can be corrupted as the result of
-simultaneous access by two or more processes.
-.PP
-Added "pop_dropcopy" module to create a temporary maildrop from
-the existing, standard maildrop as root before the setuid and
-setgid for the user is done. This allows the temporary maildrop
-to be created in a mail spool area that is not world read-writable.
-.PP
-This version does *not* send the sendmail "From " delimiter line
-in response to a TOP or RETR command.
-.PP
-Encased all debugging code in #ifdef DEBUG constructs. This code can
-be included by specifying the DEGUG compiler flag. Note: You still
-need to use the -d or -t option to obtain debugging output.
-.SH LIMITATIONS
-The POP server copies the user's entire maildrop to /tmp and
-then operates on that copy. If the maildrop is particularly
-large, or inadequate space is available in /tmp, then the
-server will refuse to continue and terminate the connection.
-.PP
-Simultaneous modification of a single maildrop can result in
-confusing results. For example, manipulating messages in a
-maildrop using the Unix /usr/ucb/mail command while a copy of
-it is being processed by the POP server can cause the changes
-made by one program to be lost when the other terminates. This
-problem is being worked on and will be fixed in a later
-release.
-.SH FILES
-.nf
-/usr/spool/mail mail files
-/etc/inetd.conf pop program invocation
-/etc/syslog.conf logging specifications
-.fi
-.SH "SEE ALSO"
-inetd(8),
-RFC1081,
-RFC1082
-.SH AUTHORS
-Bob Campbell, Edward Moy, Austin Shelton, Marshall T Rose, and cast of
-thousands at Rand, UDel, UCI, and elsewhere
diff --git a/appl/telnet/telnet/telnet.1 b/appl/telnet/telnet/telnet.1
deleted file mode 100644
index 2b3198ec110ae2b0233fe17bb2b27107aabe4023..0000000000000000000000000000000000000000
--- a/appl/telnet/telnet/telnet.1
+++ /dev/null
@@ -1,1369 +0,0 @@
-.\" Copyright (c) 1983, 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.
-.\"
-.\" @(#)telnet.1 8.6 (Berkeley) 6/1/94
-.\"
-.Dd June 1, 1994
-.Dt TELNET 1
-.Os BSD 4.2
-.Sh NAME
-.Nm telnet
-.Nd user interface to the
-.Tn TELNET
-protocol
-.Sh SYNOPSIS
-.Nm telnet
-.Op Fl 78EFKLacdfrx
-.Op Fl S Ar tos
-.Op Fl X Ar authtype
-.Op Fl e Ar escapechar
-.Op Fl k Ar realm
-.Op Fl l Ar user
-.Op Fl n Ar tracefile
-.Oo
-.Ar host
-.Op port
-.Oc
-.Sh DESCRIPTION
-The
-.Nm telnet
-command
-is used to communicate with another host using the
-.Tn TELNET
-protocol.
-If
-.Nm telnet
-is invoked without the
-.Ar host
-argument, it enters command mode,
-indicated by its prompt
-.Pq Nm telnet\&> .
-In this mode, it accepts and executes the commands listed below.
-If it is invoked with arguments, it performs an
-.Ic open
-command with those arguments.
-.Pp
-Options:
-.Bl -tag -width indent
-.It Fl 8
-Specifies an 8-bit data path. This causes an attempt to
-negotiate the
-.Dv TELNET BINARY
-option on both input and output.
-.It Fl 7
-Do not try to negotiate
-.Dv TELNET BINARY
-option.
-.It Fl E
-Stops any character from being recognized as an escape character.
-.It Fl F
-If Kerberos V5 authentication is being used, the
-.Fl F
-option allows the local credentials to be forwarded
-to the remote system, including any credentials that
-have already been forwarded into the local environment.
-.It Fl K
-Specifies no automatic login to the remote system.
-.It Fl L
-Specifies an 8-bit data path on output. This causes the
-BINARY option to be negotiated on output.
-.It Fl S Ar tos
-Sets the IP type-of-service (TOS) option for the telnet
-connection to the value
-.Ar tos,
-which can be a numeric TOS value
-or, on systems that support it, a symbolic
-TOS name found in the /etc/iptos file.
-.It Fl X Ar atype
-Disables the
-.Ar atype
-type of authentication.
-.It Fl a
-Attempt automatic login.
-Currently, this sends the user name via the
-.Ev USER
-variable
-of the
-.Ev ENVIRON
-option if supported by the remote system.
-The name used is that of the current user as returned by
-.Xr getlogin 2
-if it agrees with the current user ID,
-otherwise it is the name associated with the user ID.
-.It Fl c
-Disables the reading of the user's
-.Pa \&.telnetrc
-file. (See the
-.Ic toggle skiprc
-command on this man page.)
-.It Fl d
-Sets the initial value of the
-.Ic debug
-toggle to
-.Dv TRUE
-.It Fl e Ar escape char
-Sets the initial
-.Nm
-.Nm telnet
-escape character to
-.Ar escape char.
-If
-.Ar escape char
-is omitted, then
-there will be no escape character.
-.It Fl f
-If Kerberos V5 authentication is being used, the
-.Fl f
-option allows the local credentials to be forwarded to the remote system.
-.ne 1i
-.It Fl k Ar realm
-If Kerberos authentication is being used, the
-.Fl k
-option requests that telnet obtain tickets for the remote host in
-realm realm instead of the remote host's realm, as determined
-by
-.Xr krb_realmofhost 3 .
-.It Fl l Ar user
-When connecting to the remote system, if the remote system
-understands the
-.Ev ENVIRON
-option, then
-.Ar user
-will be sent to the remote system as the value for the variable USER.
-This option implies the
-.Fl a
-option.
-This option may also be used with the
-.Ic open
-command.
-.It Fl n Ar tracefile
-Opens
-.Ar tracefile
-for recording trace information.
-See the
-.Ic set tracefile
-command below.
-.It Fl r
-Specifies a user interface similar to
-.Xr rlogin 1 .
-In this
-mode, the escape character is set to the tilde (~) character,
-unless modified by the -e option.
-.It Fl x
-Turns on encryption of the data stream if possible. This is
-currently the default and when it fails a warning is issued.
-.It Ar host
-Indicates the official name, an alias, or the Internet address
-of a remote host.
-.It Ar port
-Indicates a port number (address of an application). If a number is
-not specified, the default
-.Nm telnet
-port is used.
-.El
-.Pp
-When in rlogin mode, a line of the form ~. disconnects from the
-remote host; ~ is the telnet escape character.
-Similarly, the line ~^Z suspends the telnet session.
-The line ~^] escapes to the normal telnet escape prompt.
-.Pp
-Once a connection has been opened,
-.Nm telnet
-will attempt to enable the
-.Dv TELNET LINEMODE
-option.
-If this fails, then
-.Nm telnet
-will revert to one of two input modes:
-either \*(Lqcharacter at a time\*(Rq
-or \*(Lqold line by line\*(Rq
-depending on what the remote system supports.
-.Pp
-When
-.Dv LINEMODE
-is enabled, character processing is done on the
-local system, under the control of the remote system. When input
-editing or character echoing is to be disabled, the remote system
-will relay that information. The remote system will also relay
-changes to any special characters that happen on the remote
-system, so that they can take effect on the local system.
-.Pp
-In \*(Lqcharacter at a time\*(Rq mode, most
-text typed is immediately sent to the remote host for processing.
-.Pp
-In \*(Lqold line by line\*(Rq mode, all text is echoed locally,
-and (normally) only completed lines are sent to the remote host.
-The \*(Lqlocal echo character\*(Rq (initially \*(Lq^E\*(Rq) may be used
-to turn off and on the local echo
-(this would mostly be used to enter passwords
-without the password being echoed).
-.Pp
-If the
-.Dv LINEMODE
-option is enabled, or if the
-.Ic localchars
-toggle is
-.Dv TRUE
-(the default for \*(Lqold line by line\*(Lq; see below),
-the user's
-.Ic quit ,
-.Ic intr ,
-and
-.Ic flush
-characters are trapped locally, and sent as
-.Tn TELNET
-protocol sequences to the remote side.
-If
-.Dv LINEMODE
-has ever been enabled, then the user's
-.Ic susp
-and
-.Ic eof
-are also sent as
-.Tn TELNET
-protocol sequences,
-and
-.Ic quit
-is sent as a
-.Dv TELNET ABORT
-instead of
-.Dv BREAK
-There are options (see
-.Ic toggle
-.Ic autoflush
-and
-.Ic toggle
-.Ic autosynch
-below)
-which cause this action to flush subsequent output to the terminal
-(until the remote host acknowledges the
-.Tn TELNET
-sequence) and flush previous terminal input
-(in the case of
-.Ic quit
-and
-.Ic intr ) .
-.Pp
-While connected to a remote host,
-.Nm telnet
-command mode may be entered by typing the
-.Nm telnet
-\*(Lqescape character\*(Rq (initially \*(Lq^]\*(Rq).
-When in command mode, the normal terminal editing conventions are available.
-.Pp
-The following
-.Nm telnet
-commands are available.
-Only enough of each command to uniquely identify it need be typed
-(this is also true for arguments to the
-.Ic mode ,
-.Ic set ,
-.Ic toggle ,
-.Ic unset ,
-.Ic slc ,
-.Ic environ ,
-and
-.Ic display
-commands).
-.Pp
-.Bl -tag -width "mode type"
-.It Ic auth Ar argument ...
-The auth command manipulates the information sent through the
-.Dv TELNET AUTHENTICATE
-option. Valid arguments for the
-auth command are as follows:
-.Bl -tag -width "disable type"
-.It Ic disable Ar type
-Disables the specified type of authentication. To
-obtain a list of available types, use the
-.Ic auth disable \&?
-command.
-.It Ic enable Ar type
-Enables the specified type of authentication. To
-obtain a list of available types, use the
-.Ic auth enable \&?
-command.
-.It Ic status
-Lists the current status of the various types of
-authentication.
-.El
-.It Ic close
-Close a
-.Tn TELNET
-session and return to command mode.
-.It Ic display Ar argument ...
-Displays all, or some, of the
-.Ic set
-and
-.Ic toggle
-values (see below).
-.It Ic encrypt Ar argument ...
-The encrypt command manipulates the information sent through the
-.Dv TELNET ENCRYPT
-option.
-.Pp
-Note: Because of export controls, the
-.Dv TELNET ENCRYPT
-option is not supported outside of the United States and Canada.
-.Pp
-Valid arguments for the encrypt command are as follows:
-.Bl -tag -width Ar
-.It Ic disable Ar type Ic [input|output]
-Disables the specified type of encryption. If you
-omit the input and output, both input and output
-are disabled. To obtain a list of available
-types, use the
-.Ic encrypt disable \&?
-command.
-.It Ic enable Ar type Ic [input|output]
-Enables the specified type of encryption. If you
-omit input and output, both input and output are
-enabled. To obtain a list of available types, use the
-.Ic encrypt enable \&?
-command.
-.It Ic input
-This is the same as the
-.Ic encrypt start input
-command.
-.It Ic -input
-This is the same as the
-.Ic encrypt stop input
-command.
-.It Ic output
-This is the same as the
-.Ic encrypt start output
-command.
-.It Ic -output
-This is the same as the
-.Ic encrypt stop output
-command.
-.It Ic start Ic [input|output]
-Attempts to start encryption. If you omit
-.Ic input
-and
-.Ic output,
-both input and output are enabled. To
-obtain a list of available types, use the
-.Ic encrypt enable \&?
-command.
-.It Ic status
-Lists the current status of encryption.
-.It Ic stop Ic [input|output]
-Stops encryption. If you omit input and output,
-encryption is on both input and output.
-.It Ic type Ar type
-Sets the default type of encryption to be used
-with later
-.Ic encrypt start
-or
-.Ic encrypt stop
-commands.
-.El
-.It Ic environ Ar arguments...
-The
-.Ic environ
-command is used to manipulate the
-the variables that my be sent through the
-.Dv TELNET ENVIRON
-option.
-The initial set of variables is taken from the users
-environment, with only the
-.Ev DISPLAY
-and
-.Ev PRINTER
-variables being exported by default.
-The
-.Ev USER
-variable is also exported if the
-.Fl a
-or
-.Fl l
-options are used.
-.br
-Valid arguments for the
-.Ic environ
-command are:
-.Bl -tag -width Fl
-.It Ic define Ar variable value
-Define the variable
-.Ar variable
-to have a value of
-.Ar value.
-Any variables defined by this command are automatically exported.
-The
-.Ar value
-may be enclosed in single or double quotes so
-that tabs and spaces may be included.
-.It Ic undefine Ar variable
-Remove
-.Ar variable
-from the list of environment variables.
-.It Ic export Ar variable
-Mark the variable
-.Ar variable
-to be exported to the remote side.
-.It Ic unexport Ar variable
-Mark the variable
-.Ar variable
-to not be exported unless
-explicitly asked for by the remote side.
-.It Ic list
-List the current set of environment variables.
-Those marked with a
-.Cm *
-will be sent automatically,
-other variables will only be sent if explicitly requested.
-.It Ic \&?
-Prints out help information for the
-.Ic environ
-command.
-.El
-.It Ic logout
-Sends the
-.Dv TELNET LOGOUT
-option to the remote side.
-This command is similar to a
-.Ic close
-command; however, if the remote side does not support the
-.Dv LOGOUT
-option, nothing happens.
-If, however, the remote side does support the
-.Dv LOGOUT
-option, this command should cause the remote side to close the
-.Tn TELNET
-connection.
-If the remote side also supports the concept of
-suspending a user's session for later reattachment,
-the logout argument indicates that you
-should terminate the session immediately.
-.It Ic mode Ar type
-.Ar Type
-is one of several options, depending on the state of the
-.Tn TELNET
-session.
-The remote host is asked for permission to go into the requested mode.
-If the remote host is capable of entering that mode, the requested
-mode will be entered.
-.Bl -tag -width Ar
-.It Ic character
-Disable the
-.Dv TELNET LINEMODE
-option, or, if the remote side does not understand the
-.Dv LINEMODE
-option, then enter \*(Lqcharacter at a time\*(Lq mode.
-.It Ic line
-Enable the
-.Dv TELNET LINEMODE
-option, or, if the remote side does not understand the
-.Dv LINEMODE
-option, then attempt to enter \*(Lqold-line-by-line\*(Lq mode.
-.It Ic isig Pq Ic \-isig
-Attempt to enable (disable) the
-.Dv TRAPSIG
-mode of the
-.Dv LINEMODE
-option.
-This requires that the
-.Dv LINEMODE
-option be enabled.
-.It Ic edit Pq Ic \-edit
-Attempt to enable (disable) the
-.Dv EDIT
-mode of the
-.Dv LINEMODE
-option.
-This requires that the
-.Dv LINEMODE
-option be enabled.
-.It Ic softtabs Pq Ic \-softtabs
-Attempt to enable (disable) the
-.Dv SOFT_TAB
-mode of the
-.Dv LINEMODE
-option.
-This requires that the
-.Dv LINEMODE
-option be enabled.
-.ne 1i
-.It Ic litecho Pq Ic \-litecho
-Attempt to enable (disable) the
-.Dv LIT_ECHO
-mode of the
-.Dv LINEMODE
-option.
-This requires that the
-.Dv LINEMODE
-option be enabled.
-.It Ic \&?
-Prints out help information for the
-.Ic mode
-command.
-.El
-.It Xo
-.Ic open Ar host
-.Oo Op Fl l
-.Ar user
-.Oc Ns Oo Fl
-.Ar port Oc
-.Xc
-Open a connection to the named host.
-If no port number
-is specified,
-.Nm telnet
-will attempt to contact a
-.Tn TELNET
-server at the default port.
-The host specification may be either a host name (see
-.Xr hosts 5 )
-or an Internet address specified in the \*(Lqdot notation\*(Rq (see
-.Xr inet 3 ) .
-The
-.Op Fl l
-option may be used to specify the user name
-to be passed to the remote system via the
-.Ev ENVIRON
-option.
-When connecting to a non-standard port,
-.Nm telnet
-omits any automatic initiation of
-.Tn TELNET
-options. When the port number is preceded by a minus sign,
-the initial option negotiation is done.
-After establishing a connection, the file
-.Pa \&.telnetrc
-in the
-users home directory is opened. Lines beginning with a # are
-comment lines. Blank lines are ignored. Lines that begin
-without white space are the start of a machine entry. The
-first thing on the line is the name of the machine that is
-being connected to. The rest of the line, and successive
-lines that begin with white space are assumed to be
-.Nm telnet
-commands and are processed as if they had been typed
-in manually to the
-.Nm telnet
-command prompt.
-.It Ic quit
-Close any open
-.Tn TELNET
-session and exit
-.Nm telnet .
-An end of file (in command mode) will also close a session and exit.
-.It Ic send Ar arguments
-Sends one or more special character sequences to the remote host.
-The following are the arguments which may be specified
-(more than one argument may be specified at a time):
-.Pp
-.Bl -tag -width escape
-.It Ic abort
-Sends the
-.Dv TELNET ABORT
-(Abort
-processes)
-sequence.
-.It Ic ao
-Sends the
-.Dv TELNET AO
-(Abort Output) sequence, which should cause the remote system to flush
-all output
-.Em from
-the remote system
-.Em to
-the user's terminal.
-.It Ic ayt
-Sends the
-.Dv TELNET AYT
-(Are You There)
-sequence, to which the remote system may or may not choose to respond.
-.It Ic brk
-Sends the
-.Dv TELNET BRK
-(Break) sequence, which may have significance to the remote
-system.
-.It Ic ec
-Sends the
-.Dv TELNET EC
-(Erase Character)
-sequence, which should cause the remote system to erase the last character
-entered.
-.It Ic el
-Sends the
-.Dv TELNET EL
-(Erase Line)
-sequence, which should cause the remote system to erase the line currently
-being entered.
-.It Ic eof
-Sends the
-.Dv TELNET EOF
-(End Of File)
-sequence.
-.It Ic eor
-Sends the
-.Dv TELNET EOR
-(End of Record)
-sequence.
-.It Ic escape
-Sends the current
-.Nm telnet
-escape character (initially \*(Lq^\*(Rq).
-.It Ic ga
-Sends the
-.Dv TELNET GA
-(Go Ahead)
-sequence, which likely has no significance to the remote system.
-.It Ic getstatus
-If the remote side supports the
-.Dv TELNET STATUS
-command,
-.Ic getstatus
-will send the subnegotiation to request that the server send
-its current option status.
-.ne 1i
-.It Ic ip
-Sends the
-.Dv TELNET IP
-(Interrupt Process) sequence, which should cause the remote
-system to abort the currently running process.
-.It Ic nop
-Sends the
-.Dv TELNET NOP
-(No OPeration)
-sequence.
-.It Ic susp
-Sends the
-.Dv TELNET SUSP
-(SUSPend process)
-sequence.
-.It Ic synch
-Sends the
-.Dv TELNET SYNCH
-sequence.
-This sequence causes the remote system to discard all previously typed
-(but not yet read) input.
-This sequence is sent as
-.Tn TCP
-urgent
-data (and may not work if the remote system is a
-.Bx 4.2
-system -- if
-it doesn't work, a lower case \*(Lqr\*(Rq may be echoed on the terminal).
-.It Ic do Ar cmd
-.It Ic dont Ar cmd
-.It Ic will Ar cmd
-.It Ic wont Ar cmd
-Sends the
-.Dv TELNET DO
-.Ar cmd
-sequence.
-.Ar Cmd
-can be either a decimal number between 0 and 255,
-or a symbolic name for a specific
-.Dv TELNET
-command.
-.Ar Cmd
-can also be either
-.Ic help
-or
-.Ic \&?
-to print out help information, including
-a list of known symbolic names.
-.It Ic \&?
-Prints out help information for the
-.Ic send
-command.
-.El
-.It Ic set Ar argument value
-.It Ic unset Ar argument value
-The
-.Ic set
-command will set any one of a number of
-.Nm telnet
-variables to a specific value or to
-.Dv TRUE .
-The special value
-.Ic off
-turns off the function associated with
-the variable, this is equivalent to using the
-.Ic unset
-command.
-The
-.Ic unset
-command will disable or set to
-.Dv FALSE
-any of the specified functions.
-The values of variables may be interrogated with the
-.Ic display
-command.
-The variables which may be set or unset, but not toggled, are
-listed here. In addition, any of the variables for the
-.Ic toggle
-command may be explicitly set or unset using
-the
-.Ic set
-and
-.Ic unset
-commands.
-.Bl -tag -width escape
-.It Ic ayt
-If
-.Tn TELNET
-is in localchars mode, or
-.Dv LINEMODE
-is enabled, and the status character is typed, a
-.Dv TELNET AYT
-sequence (see
-.Ic send ayt
-preceding) is sent to the
-remote host. The initial value for the "Are You There"
-character is the terminal's status character.
-.It Ic echo
-This is the value (initially \*(Lq^E\*(Rq) which, when in
-\*(Lqline by line\*(Rq mode, toggles between doing local echoing
-of entered characters (for normal processing), and suppressing
-echoing of entered characters (for entering, say, a password).
-.It Ic eof
-If
-.Nm telnet
-is operating in
-.Dv LINEMODE
-or \*(Lqold line by line\*(Rq mode, entering this character
-as the first character on a line will cause this character to be
-sent to the remote system.
-The initial value of the eof character is taken to be the terminal's
-.Ic eof
-character.
-.It Ic erase
-If
-.Nm telnet
-is in
-.Ic localchars
-mode (see
-.Ic toggle
-.Ic localchars
-below),
-.Sy and
-if
-.Nm telnet
-is operating in \*(Lqcharacter at a time\*(Rq mode, then when this
-character is typed, a
-.Dv TELNET EC
-sequence (see
-.Ic send
-.Ic ec
-above)
-is sent to the remote system.
-The initial value for the erase character is taken to be
-the terminal's
-.Ic erase
-character.
-.It Ic escape
-This is the
-.Nm telnet
-escape character (initially \*(Lq^[\*(Rq) which causes entry
-into
-.Nm telnet
-command mode (when connected to a remote system).
-.It Ic flushoutput
-If
-.Nm telnet
-is in
-.Ic localchars
-mode (see
-.Ic toggle
-.Ic localchars
-below)
-and the
-.Ic flushoutput
-character is typed, a
-.Dv TELNET AO
-sequence (see
-.Ic send
-.Ic ao
-above)
-is sent to the remote host.
-The initial value for the flush character is taken to be
-the terminal's
-.Ic flush
-character.
-.It Ic forw1
-.It Ic forw2
-If
-.Tn TELNET
-is operating in
-.Dv LINEMODE ,
-these are the
-characters that, when typed, cause partial lines to be
-forwarded to the remote system. The initial value for
-the forwarding characters are taken from the terminal's
-eol and eol2 characters.
-.It Ic interrupt
-If
-.Nm telnet
-is in
-.Ic localchars
-mode (see
-.Ic toggle
-.Ic localchars
-below)
-and the
-.Ic interrupt
-character is typed, a
-.Dv TELNET IP
-sequence (see
-.Ic send
-.Ic ip
-above)
-is sent to the remote host.
-The initial value for the interrupt character is taken to be
-the terminal's
-.Ic intr
-character.
-.It Ic kill
-If
-.Nm telnet
-is in
-.Ic localchars
-mode (see
-.Ic toggle
-.Ic localchars
-below),
-.Ic and
-if
-.Nm telnet
-is operating in \*(Lqcharacter at a time\*(Rq mode, then when this
-character is typed, a
-.Dv TELNET EL
-sequence (see
-.Ic send
-.Ic el
-above)
-is sent to the remote system.
-The initial value for the kill character is taken to be
-the terminal's
-.Ic kill
-character.
-.It Ic lnext
-If
-.Nm telnet
-is operating in
-.Dv LINEMODE
-or \*(Lqold line by line\*(Lq mode, then this character is taken to
-be the terminal's
-.Ic lnext
-character.
-The initial value for the lnext character is taken to be
-the terminal's
-.Ic lnext
-character.
-.It Ic quit
-If
-.Nm telnet
-is in
-.Ic localchars
-mode (see
-.Ic toggle
-.Ic localchars
-below)
-and the
-.Ic quit
-character is typed, a
-.Dv TELNET BRK
-sequence (see
-.Ic send
-.Ic brk
-above)
-is sent to the remote host.
-The initial value for the quit character is taken to be
-the terminal's
-.Ic quit
-character.
-.It Ic reprint
-If
-.Nm telnet
-is operating in
-.Dv LINEMODE
-or \*(Lqold line by line\*(Lq mode, then this character is taken to
-be the terminal's
-.Ic reprint
-character.
-The initial value for the reprint character is taken to be
-the terminal's
-.Ic reprint
-character.
-.It Ic rlogin
-This is the rlogin escape character.
-If set, the normal
-.Tn TELNET
-escape character is ignored unless it is
-preceded by this character at the beginning of a line.
-This character, at the beginning of a line followed by
-a "." closes the connection; when followed by a ^Z it
-suspends the telnet command. The initial state is to
-disable the rlogin escape character.
-.It Ic start
-If the
-.Dv TELNET TOGGLE-FLOW-CONTROL
-option has been enabled,
-then this character is taken to
-be the terminal's
-.Ic start
-character.
-The initial value for the kill character is taken to be
-the terminal's
-.Ic start
-character.
-.It Ic stop
-If the
-.Dv TELNET TOGGLE-FLOW-CONTROL
-option has been enabled,
-then this character is taken to
-be the terminal's
-.Ic stop
-character.
-The initial value for the kill character is taken to be
-the terminal's
-.Ic stop
-character.
-.It Ic susp
-If
-.Nm telnet
-is in
-.Ic localchars
-mode, or
-.Dv LINEMODE
-is enabled, and the
-.Ic suspend
-character is typed, a
-.Dv TELNET SUSP
-sequence (see
-.Ic send
-.Ic susp
-above)
-is sent to the remote host.
-The initial value for the suspend character is taken to be
-the terminal's
-.Ic suspend
-character.
-.ne 1i
-.It Ic tracefile
-This is the file to which the output, caused by
-.Ic netdata
-or
-.Ic option
-tracing being
-.Dv TRUE ,
-will be written. If it is set to
-.Dq Fl ,
-then tracing information will be written to standard output (the default).
-.It Ic worderase
-If
-.Nm telnet
-is operating in
-.Dv LINEMODE
-or \*(Lqold line by line\*(Lq mode, then this character is taken to
-be the terminal's
-.Ic worderase
-character.
-The initial value for the worderase character is taken to be
-the terminal's
-.Ic worderase
-character.
-.It Ic \&?
-Displays the legal
-.Ic set
-.Pq Ic unset
-commands.
-.El
-.It Ic slc Ar state
-The
-.Ic slc
-command (Set Local Characters) is used to set
-or change the state of the the special
-characters when the
-.Dv TELNET LINEMODE
-option has
-been enabled. Special characters are characters that get
-mapped to
-.Tn TELNET
-commands sequences (like
-.Ic ip
-or
-.Ic quit )
-or line editing characters (like
-.Ic erase
-and
-.Ic kill ) .
-By default, the local special characters are exported.
-.Bl -tag -width Fl
-.It Ic check
-Verify the current settings for the current special characters.
-The remote side is requested to send all the current special
-character settings, and if there are any discrepancies with
-the local side, the local side will switch to the remote value.
-.It Ic export
-Switch to the local defaults for the special characters. The
-local default characters are those of the local terminal at
-the time when
-.Nm telnet
-was started.
-.It Ic import
-Switch to the remote defaults for the special characters.
-The remote default characters are those of the remote system
-at the time when the
-.Tn TELNET
-connection was established.
-.It Ic \&?
-Prints out help information for the
-.Ic slc
-command.
-.El
-.It Ic status
-Show the current status of
-.Nm telnet .
-This includes the peer one is connected to, as well
-as the current mode.
-.It Ic toggle Ar arguments ...
-Toggle (between
-.Dv TRUE
-and
-.Dv FALSE )
-various flags that control how
-.Nm telnet
-responds to events.
-These flags may be set explicitly to
-.Dv TRUE
-or
-.Dv FALSE
-using the
-.Ic set
-and
-.Ic unset
-commands listed above.
-More than one argument may be specified.
-The state of these flags may be interrogated with the
-.Ic display
-command.
-Valid arguments are:
-.Bl -tag -width Ar
-.It Ic authdebug
-Turns on debugging information for the authentication code.
-.It Ic autoflush
-If
-.Ic autoflush
-and
-.Ic localchars
-are both
-.Dv TRUE ,
-then when the
-.Ic ao ,
-or
-.Ic quit
-characters are recognized (and transformed into
-.Tn TELNET
-sequences; see
-.Ic set
-above for details),
-.Nm telnet
-refuses to display any data on the user's terminal
-until the remote system acknowledges (via a
-.Dv TELNET TIMING MARK
-option)
-that it has processed those
-.Tn TELNET
-sequences.
-The initial value for this toggle is
-.Dv TRUE
-if the terminal user had not
-done an "stty noflsh", otherwise
-.Dv FALSE
-(see
-.Xr stty 1 ) .
-.It Ic autodecrypt
-When the
-.Dv TELNET ENCRYPT
-option is negotiated, by
-default the actual encryption (decryption) of the data
-stream does not start automatically. The autoencrypt
-(autodecrypt) command states that encryption of the
-output (input) stream should be enabled as soon as
-possible.
-.sp
-.Pp
-Note: Because of export controls, the
-.Dv TELNET ENCRYPT
-option is not supported outside the United States and Canada.
-.It Ic autologin
-If the remote side supports the
-.Dv TELNET AUTHENTICATION
-option
-.Tn TELNET
-attempts to use it to perform automatic authentication. If the
-.Dv AUTHENTICATION
-option is not supported, the user's login
-name are propagated through the
-.Dv TELNET ENVIRON
-option.
-This command is the same as specifying
-.Ar a
-option on the
-.Ic open
-command.
-.It Ic autosynch
-If
-.Ic autosynch
-and
-.Ic localchars
-are both
-.Dv TRUE ,
-then when either the
-.Ic intr
-or
-.Ic quit
-characters is typed (see
-.Ic set
-above for descriptions of the
-.Ic intr
-and
-.Ic quit
-characters), the resulting
-.Tn TELNET
-sequence sent is followed by the
-.Dv TELNET SYNCH
-sequence.
-This procedure
-.Ic should
-cause the remote system to begin throwing away all previously
-typed input until both of the
-.Tn TELNET
-sequences have been read and acted upon.
-The initial value of this toggle is
-.Dv FALSE .
-.It Ic binary
-Enable or disable the
-.Dv TELNET BINARY
-option on both input and output.
-.It Ic inbinary
-Enable or disable the
-.Dv TELNET BINARY
-option on input.
-.It Ic outbinary
-Enable or disable the
-.Dv TELNET BINARY
-option on output.
-.It Ic crlf
-If this is
-.Dv TRUE ,
-then carriage returns will be sent as
-.Li <CR><LF> .
-If this is
-.Dv FALSE ,
-then carriage returns will be send as
-.Li <CR><NUL> .
-The initial value for this toggle is
-.Dv FALSE .
-.It Ic crmod
-Toggle carriage return mode.
-When this mode is enabled, most carriage return characters received from
-the remote host will be mapped into a carriage return followed by
-a line feed.
-This mode does not affect those characters typed by the user, only
-those received from the remote host.
-This mode is not very useful unless the remote host
-only sends carriage return, but never line feed.
-The initial value for this toggle is
-.Dv FALSE .
-.It Ic debug
-Toggles socket level debugging (useful only to the
-.Ic super user ) .
-The initial value for this toggle is
-.Dv FALSE .
-.It Ic encdebug
-Turns on debugging information for the encryption code.
-.It Ic localchars
-If this is
-.Dv TRUE ,
-then the
-.Ic flush ,
-.Ic interrupt ,
-.Ic quit ,
-.Ic erase ,
-and
-.Ic kill
-characters (see
-.Ic set
-above) are recognized locally, and transformed into (hopefully) appropriate
-.Tn TELNET
-control sequences
-(respectively
-.Ic ao ,
-.Ic ip ,
-.Ic brk ,
-.Ic ec ,
-and
-.Ic el ;
-see
-.Ic send
-above).
-The initial value for this toggle is
-.Dv TRUE
-in \*(Lqold line by line\*(Rq mode,
-and
-.Dv FALSE
-in \*(Lqcharacter at a time\*(Rq mode.
-When the
-.Dv LINEMODE
-option is enabled, the value of
-.Ic localchars
-is ignored, and assumed to always be
-.Dv TRUE .
-If
-.Dv LINEMODE
-has ever been enabled, then
-.Ic quit
-is sent as
-.Ic abort ,
-and
-.Ic eof and
-.B suspend
-are sent as
-.Ic eof and
-.Ic susp ,
-see
-.Ic send
-above).
-.It Ic netdata
-Toggles the display of all network data (in hexadecimal format).
-The initial value for this toggle is
-.Dv FALSE .
-.It Ic options
-Toggles the display of some internal
-.Nm telnet
-protocol processing (having to do with
-.Tn TELNET
-options).
-The initial value for this toggle is
-.Dv FALSE .
-.ne 1i
-.It Ic prettydump
-When the
-.Ic netdata
-toggle is enabled, if
-.Ic prettydump
-is enabled the output from the
-.Ic netdata
-command will be formatted in a more user readable format.
-Spaces are put between each character in the output, and the
-beginning of any
-.Tn TELNET
-escape sequence is preceded by a '*' to aid in locating them.
-.It Ic skiprc
-When the skiprc toggle is
-.Dv TRUE ,
-.Tn TELNET
-skips the reading of the
-.Pa \&.telnetrc
-file in the users home
-directory when connections are opened. The initial
-value for this toggle is
-.Dv FALSE.
-.It Ic termdata
-Toggles the display of all terminal data (in hexadecimal format).
-The initial value for this toggle is
-.Dv FALSE .
-.It Ic verbose_encrypt
-When the
-.Ic verbose_encrypt
-toggle is
-.Dv TRUE ,
-.Tn TELNET
-prints out a message each time encryption is enabled or
-disabled. The initial value for this toggle is
-.Dv FALSE.
-Note: Because of export controls, data encryption
-is not supported outside of the United States and Canada.
-.It Ic \&?
-Displays the legal
-.Ic toggle
-commands.
-.El
-.It Ic z
-Suspend
-.Nm telnet .
-This command only works when the user is using the
-.Xr csh 1 .
-.It Ic \&! Op Ar command
-Execute a single command in a subshell on the local
-system. If
-.Ic command
-is omitted, then an interactive
-subshell is invoked.
-.It Ic \&? Op Ar command
-Get help. With no arguments,
-.Nm telnet
-prints a help summary.
-If a command is specified,
-.Nm telnet
-will print the help information for just that command.
-.El
-.Sh ENVIRONMENT
-.Nm Telnet
-uses at least the
-.Ev HOME ,
-.Ev SHELL ,
-.Ev DISPLAY ,
-and
-.Ev TERM
-environment variables.
-Other environment variables may be propagated
-to the other side via the
-.Dv TELNET ENVIRON
-option.
-.Sh FILES
-.Bl -tag -width ~/.telnetrc -compact
-.It Pa ~/.telnetrc
-user customized telnet startup values
-.El
-.Sh HISTORY
-The
-.Nm Telnet
-command appeared in
-.Bx 4.2 .
-.Sh NOTES
-.Pp
-On some remote systems, echo has to be turned off manually when in
-\*(Lqold line by line\*(Rq mode.
-.Pp
-In \*(Lqold line by line\*(Rq mode or
-.Dv LINEMODE
-the terminal's
-.Ic eof
-character is only recognized (and sent to the remote system)
-when it is the first character on a line.
diff --git a/appl/telnet/telnetd/telnetd.8 b/appl/telnet/telnetd/telnetd.8
deleted file mode 100644
index b90a19a910e4d31bac0df4caefd5d95ef4908b58..0000000000000000000000000000000000000000
--- a/appl/telnet/telnetd/telnetd.8
+++ /dev/null
@@ -1,520 +0,0 @@
-.\" Copyright (c) 1983, 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.
-.\"
-.\" @(#)telnetd.8 8.4 (Berkeley) 6/1/94
-.\"
-.Dd June 1, 1994
-.Dt TELNETD 8
-.Os BSD 4.2
-.Sh NAME
-.Nm telnetd
-.Nd DARPA
-.Tn TELNET
-protocol server
-.Sh SYNOPSIS
-.Nm telnetd
-.Op Fl BUhkln
-.Op Fl D Ar debugmode
-.Op Fl S Ar tos
-.Op Fl X Ar authtype
-.Op Fl a Ar authmode
-.Op Fl r Ns Ar lowpty-highpty
-.Op Fl u Ar len
-.Op Fl debug
-.Op Fl L Ar /bin/login
-.Op Ar port
-.Sh DESCRIPTION
-The
-.Nm telnetd
-command is a server which supports the
-.Tn DARPA
-standard
-.Tn TELNET
-virtual terminal protocol.
-.Nm Telnetd
-is normally invoked by the internet server (see
-.Xr inetd 8 )
-for requests to connect to the
-.Tn TELNET
-port as indicated by the
-.Pa /etc/services
-file (see
-.Xr services 5 ) .
-The
-.Fl debug
-option may be used to start up
-.Nm telnetd
-manually, instead of through
-.Xr inetd 8 .
-If started up this way,
-.Ar port
-may be specified to run
-.Nm telnetd
-on an alternate
-.Tn TCP
-port number.
-.Pp
-The
-.Nm telnetd
-command accepts the following options:
-.Bl -tag -width "-a authmode"
-.It Fl a Ar authmode
-This option may be used for specifying what mode should
-be used for authentication.
-Note that this option is only useful if
-.Nm telnetd
-has been compiled with support for the
-.Dv AUTHENTICATION
-option.
-There are several valid values for
-.Ar authmode:
-.Bl -tag -width debug
-.It debug
-Turns on authentication debugging code.
-.It user
-Only allow connections when the remote user
-can provide valid authentication information
-to identify the remote user,
-and is allowed access to the specified account
-without providing a password.
-.It valid
-Only allow connections when the remote user
-can provide valid authentication information
-to identify the remote user.
-The
-.Xr login 1
-command will provide any additional user verification
-needed if the remote user is not allowed automatic
-access to the specified account.
-.It other
-Only allow connections that supply some authentication information.
-This option is currently not supported
-by any of the existing authentication mechanisms,
-and is thus the same as specifying
-.Fl a
-.Cm valid .
-.It none
-This is the default state.
-Authentication information is not required.
-If no or insufficient authentication information
-is provided, then the
-.Xr login 1
-program will provide the necessary user
-verification.
-.It off
-This disables the authentication code.
-All user verification will happen through the
-.Xr login 1
-program.
-.El
-.It Fl B
-Ignored.
-.It Fl D Ar debugmode
-This option may be used for debugging purposes.
-This allows
-.Nm telnetd
-to print out debugging information
-to the connection, allowing the user to see what
-.Nm telnetd
-is doing.
-There are several possible values for
-.Ar debugmode:
-.Bl -tag -width exercise
-.It Cm options
-Prints information about the negotiation of
-.Tn TELNET
-options.
-.It Cm report
-Prints the
-.Cm options
-information, plus some additional information
-about what processing is going on.
-.It Cm netdata
-Displays the data stream received by
-.Nm telnetd.
-.It Cm ptydata
-Displays data written to the pty.
-.It Cm exercise
-Has not been implemented yet.
-.El
-.It Fl h
-Disables the printing of host-specific information before
-login has been completed.
-.It Fl k
-.It Fl l
-Ignored.
-.It Fl n
-Disable
-.Dv TCP
-keep-alives. Normally
-.Nm telnetd
-enables the
-.Tn TCP
-keep-alive mechanism to probe connections that
-have been idle for some period of time to determine
-if the client is still there, so that idle connections
-from machines that have crashed or can no longer
-be reached may be cleaned up.
-.It Fl r Ar lowpty-highpty
-This option is only enabled when
-.Nm telnetd
-is compiled for
-.Dv UNICOS.
-It specifies an inclusive range of pseudo-terminal devices to
-use. If the system has sysconf variable
-.Dv _SC_CRAY_NPTY
-configured, the default pty search range is 0 to
-.Dv _SC_CRAY_NPTY;
-otherwise, the default range is 0 to 128. Either
-.Ar lowpty
-or
-.Ar highpty
-may be omitted to allow changing
-either end of the search range. If
-.Ar lowpty
-is omitted, the - character is still required so that
-.Nm telnetd
-can differentiate
-.Ar highpty
-from
-.Ar lowpty .
-.It Fl S Ar tos
-.It Fl u Ar len
-This option is used to specify the size of the field
-in the
-.Dv utmp
-structure that holds the remote host name.
-If the resolved host name is longer than
-.Ar len ,
-the dotted decimal value will be used instead.
-This allows hosts with very long host names that
-overflow this field to still be uniquely identified.
-Specifying
-.Fl u0
-indicates that only dotted decimal addresses
-should be put into the
-.Pa utmp
-file.
-.ne 1i
-.It Fl U
-This option causes
-.Nm telnetd
-to refuse connections from addresses that
-cannot be mapped back into a symbolic name
-via the
-.Xr gethostbyaddr 3
-routine.
-.It Fl X Ar authtype
-This option is only valid if
-.Nm telnetd
-has been built with support for the authentication option.
-It disables the use of
-.Ar authtype
-authentication, and
-can be used to temporarily disable
-a specific authentication type without having to recompile
-.Nm telnetd .
-.It Fl L pathname
-Specify pathname to an alternative login program.
-.El
-.Pp
-.Nm Telnetd
-operates by allocating a pseudo-terminal device (see
-.Xr pty 4 )
-for a client, then creating a login process which has
-the slave side of the pseudo-terminal as
-.Dv stdin ,
-.Dv stdout
-and
-.Dv stderr .
-.Nm Telnetd
-manipulates the master side of the pseudo-terminal,
-implementing the
-.Tn TELNET
-protocol and passing characters
-between the remote client and the login process.
-.Pp
-When a
-.Tn TELNET
-session is started up,
-.Nm telnetd
-sends
-.Tn TELNET
-options to the client side indicating
-a willingness to do the
-following
-.Tn TELNET
-options, which are described in more detail below:
-.Bd -literal -offset indent
-DO AUTHENTICATION
-WILL ENCRYPT
-DO TERMINAL TYPE
-DO TSPEED
-DO XDISPLOC
-DO NEW-ENVIRON
-DO ENVIRON
-WILL SUPPRESS GO AHEAD
-DO ECHO
-DO LINEMODE
-DO NAWS
-WILL STATUS
-DO LFLOW
-DO TIMING-MARK
-.Ed
-.Pp
-The pseudo-terminal allocated to the client is configured
-to operate in \*(lqcooked\*(rq mode, and with
-.Dv XTABS and
-.Dv CRMOD
-enabled (see
-.Xr tty 4 ) .
-.Pp
-.Nm Telnetd
-has support for enabling locally the following
-.Tn TELNET
-options:
-.Bl -tag -width "DO AUTHENTICATION"
-.It "WILL ECHO"
-When the
-.Dv LINEMODE
-option is enabled, a
-.Dv WILL ECHO
-or
-.Dv WONT ECHO
-will be sent to the client to indicate the
-current state of terminal echoing.
-When terminal echo is not desired, a
-.Dv WILL ECHO
-is sent to indicate that
-.Tn telnetd
-will take care of echoing any data that needs to be
-echoed to the terminal, and then nothing is echoed.
-When terminal echo is desired, a
-.Dv WONT ECHO
-is sent to indicate that
-.Tn telnetd
-will not be doing any terminal echoing, so the
-client should do any terminal echoing that is needed.
-.It "WILL BINARY"
-Indicates that the client is willing to send a
-8 bits of data, rather than the normal 7 bits
-of the Network Virtual Terminal.
-.It "WILL SGA"
-Indicates that it will not be sending
-.Dv IAC GA,
-go ahead, commands.
-.It "WILL STATUS"
-Indicates a willingness to send the client, upon
-request, of the current status of all
-.Tn TELNET
-options.
-.It "WILL TIMING-MARK"
-Whenever a
-.Dv DO TIMING-MARK
-command is received, it is always responded
-to with a
-.Dv WILL TIMING-MARK
-.ne 1i
-.It "WILL LOGOUT"
-When a
-.Dv DO LOGOUT
-is received, a
-.Dv WILL LOGOUT
-is sent in response, and the
-.Tn TELNET
-session is shut down.
-.It "WILL ENCRYPT"
-Only sent if
-.Nm telnetd
-is compiled with support for data encryption, and
-indicates a willingness to decrypt
-the data stream.
-.El
-.Pp
-.Nm Telnetd
-has support for enabling remotely the following
-.Tn TELNET
-options:
-.Bl -tag -width "DO AUTHENTICATION"
-.It "DO BINARY"
-Sent to indicate that
-.Tn telnetd
-is willing to receive an 8 bit data stream.
-.It "DO LFLOW"
-Requests that the client handle flow control
-characters remotely.
-.It "DO ECHO"
-This is not really supported, but is sent to identify a 4.2BSD
-.Xr telnet 1
-client, which will improperly respond with
-.Dv WILL ECHO.
-If a
-.Dv WILL ECHO
-is received, a
-.Dv DONT ECHO
-will be sent in response.
-.It "DO TERMINAL-TYPE"
-Indicates a desire to be able to request the
-name of the type of terminal that is attached
-to the client side of the connection.
-.It "DO SGA"
-Indicates that it does not need to receive
-.Dv IAC GA,
-the go ahead command.
-.It "DO NAWS"
-Requests that the client inform the server when
-the window (display) size changes.
-.It "DO TERMINAL-SPEED"
-Indicates a desire to be able to request information
-about the speed of the serial line to which
-the client is attached.
-.It "DO XDISPLOC"
-Indicates a desire to be able to request the name
-of the X windows display that is associated with
-the telnet client.
-.It "DO NEW-ENVIRON"
-Indicates a desire to be able to request environment
-variable information, as described in RFC 1572.
-.It "DO ENVIRON"
-Indicates a desire to be able to request environment
-variable information, as described in RFC 1408.
-.It "DO LINEMODE"
-Only sent if
-.Nm telnetd
-is compiled with support for linemode, and
-requests that the client do line by line processing.
-.It "DO TIMING-MARK"
-Only sent if
-.Nm telnetd
-is compiled with support for both linemode and
-kludge linemode, and the client responded with
-.Dv WONT LINEMODE.
-If the client responds with
-.Dv WILL TM,
-the it is assumed that the client supports
-kludge linemode.
-Note that the
-.Op Fl k
-option can be used to disable this.
-.It "DO AUTHENTICATION"
-Only sent if
-.Nm telnetd
-is compiled with support for authentication, and
-indicates a willingness to receive authentication
-information for automatic login.
-.It "DO ENCRYPT"
-Only sent if
-.Nm telnetd
-is compiled with support for data encryption, and
-indicates a willingness to decrypt
-the data stream.
-.Sh ENVIRONMENT
-.Sh FILES
-.Pa /etc/services
-.br
-.Pa /etc/inittab
-(UNICOS systems only)
-.br
-.Pa /etc/iptos
-(if supported)
-.br
-.Sh "SEE ALSO"
-.Xr telnet 1 ,
-.Xr login 1
-.Sh STANDARDS
-.Bl -tag -compact -width RFC-1572
-.It Cm RFC-854
-.Tn TELNET
-PROTOCOL SPECIFICATION
-.It Cm RFC-855
-TELNET OPTION SPECIFICATIONS
-.It Cm RFC-856
-TELNET BINARY TRANSMISSION
-.It Cm RFC-857
-TELNET ECHO OPTION
-.It Cm RFC-858
-TELNET SUPPRESS GO AHEAD OPTION
-.It Cm RFC-859
-TELNET STATUS OPTION
-.It Cm RFC-860
-TELNET TIMING MARK OPTION
-.It Cm RFC-861
-TELNET EXTENDED OPTIONS - LIST OPTION
-.It Cm RFC-885
-TELNET END OF RECORD OPTION
-.It Cm RFC-1073
-Telnet Window Size Option
-.It Cm RFC-1079
-Telnet Terminal Speed Option
-.It Cm RFC-1091
-Telnet Terminal-Type Option
-.It Cm RFC-1096
-Telnet X Display Location Option
-.It Cm RFC-1123
-Requirements for Internet Hosts -- Application and Support
-.It Cm RFC-1184
-Telnet Linemode Option
-.It Cm RFC-1372
-Telnet Remote Flow Control Option
-.It Cm RFC-1416
-Telnet Authentication Option
-.It Cm RFC-1411
-Telnet Authentication: Kerberos Version 4
-.It Cm RFC-1412
-Telnet Authentication: SPX
-.It Cm RFC-1571
-Telnet Environment Option Interoperability Issues
-.It Cm RFC-1572
-Telnet Environment Option
-.Sh BUGS
-Some
-.Tn TELNET
-commands are only partially implemented.
-.Pp
-Because of bugs in the original 4.2 BSD
-.Xr telnet 1 ,
-.Nm telnetd
-performs some dubious protocol exchanges to try to discover if the remote
-client is, in fact, a 4.2 BSD
-.Xr telnet 1 .
-.Pp
-Binary mode
-has no common interpretation except between similar operating systems
-(Unix in this case).
-.Pp
-The terminal type name received from the remote client is converted to
-lower case.
-.Pp
-.Nm Telnetd
-never sends
-.Tn TELNET
-.Dv IAC GA
-(go ahead) commands.
diff --git a/cache.h b/cache.h
deleted file mode 100644
index 05bdc30cb112458f0e240fbc0ac0f6f71892cb42..0000000000000000000000000000000000000000
--- a/cache.h
+++ /dev/null
@@ -1,93 +0,0 @@
-#ifndef __CACHE_H__
-#define __CACHE_H__
-
-krb5_error_code
-krb5_cc_resolve(krb5_context context,
- const char *residual,
- krb5_ccache *id);
-
-char *
-krb5_cc_get_name (krb5_context context,
- krb5_ccache id);
-
-char *
-krb5_cc_default_name (krb5_context context);
-
-krb5_error_code
-krb5_cc_default (krb5_context context,
- krb5_ccache *id);
-
-krb5_error_code
-krb5_cc_initialize (krb5_context context,
- krb5_ccache id,
- krb5_principal primary_principal);
-
-krb5_error_code
-krb5_cc_destroy (krb5_context context,
- krb5_ccache id);
-
-krb5_error_code
-krb5_cc_close (krb5_context context,
- krb5_ccache id);
-
-krb5_error_code
-krb5_cc_store_cred (krb5_context context,
- krb5_ccache id,
- krb5_creds *creds);
-
-krb5_error_code
-krb5_cc_retrieve_cred (krb5_context context,
- krb5_ccache id,
- krb5_flags whichfields,
- krb5_creds *mcreds,
- krb5_creds *creds);
-
-krb5_error_code
-krb5_cc_get_principal (krb5_context context,
- krb5_ccache id,
- krb5_principal *principal);
-
-krb5_error_code
-krb5_cc_get_first (krb5_context context,
- krb5_ccache id,
- krb5_cc_cursor *cursor);
-
-krb5_error_code
-krb5_cc_get_next (krb5_context context,
- krb5_ccache id,
- krb5_creds *creds,
- krb5_cc_cursor *cursor);
-
-krb5_error_code
-krb5_cc_end_get (krb5_context context,
- krb5_ccache id,
- krb5_cc_cursor *cursor);
-
-krb5_error_code
-krb5_cc_remove_cred (krb5_context context,
- krb5_ccache id,
- krb5_flags which,
- krb5_creds *cred);
-
-krb5_error_code
-krb5_cc_set_flags (krb5_context context,
- krb5_ccache id,
- krb5_flags flags);
-
-krb5_error_code
-krb5_cc_start_seq_get (krb5_context context,
- krb5_ccache id,
- krb5_cc_cursor *cursor);
-
-krb5_error_code
-krb5_cc_next_cred (krb5_context context,
- krb5_ccache id,
- krb5_creds *creds,
- krb5_cc_cursor *cursor);
-
-krb5_error_code
-krb5_cc_end_seq_get (krb5_context context,
- krb5_ccache id,
- krb5_cc_cursor *cursor);
-
-#endif /* __CACHE_H__ */
diff --git a/doc/standardisation/draft-foo b/doc/standardisation/draft-foo
deleted file mode 100644
index 8174d4678f8d4722b9db54f2a727574c5394ec22..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-foo
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group Assar Westerlund
-<draft-ietf-cat-krb5-ipv6.txt> SICS
-Internet-Draft October, 1997
-Expire in six months
-
- Kerberos over IPv6
-
-Status of this Memo
-
- This document is an Internet-Draft. 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."
-
- To view the entire list of current Internet-Drafts, please check the
- "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
- Distribution of this memo is unlimited. Please send comments to the
- <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
- This document specifies the address types and transport types
- necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].
-
-Specification
-
- IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
- order. The type of IPv6 addresses is twenty-four (24).
-
- The following addresses (see [RFC1884]) MUST not appear in any
- Kerberos packet:
-
- the Unspecified Address
- the Loopback Address
- Link-Local addresses
-
- IPv4-mapped IPv6 addresses MUST be represented as addresses of type
- 2.
-
-
-
-
-Westerlund [Page 1]
-
-Internet Draft Kerberos over IPv6 October, 1997
-
-
- Communication with the KDC over IPv6 MUST be done as in section 8.2.1
- of [RFC1510].
-
-Discussion
-
- [RFC1510] suggests using the address family constants in
- <sys/socket.h> from BSD. This cannot be done for IPv6 as these
- numbers have diverged and are different on different BSD-derived
- systems. [RFC2133] does not either specify a value for AF_INET6.
- Thus a value has to be decided and the implementations have to
- convert between the value used in Kerberos HostAddress and the local
- AF_INET6.
-
- There are a few different address types in IPv6, see [RFC1884]. Some
- of these are used for quite special purposes and it makes no sense to
- include them in Kerberos packets.
-
- It is necessary to represent IPv4-mapped addresses as Internet
- addresses (type 2) to be compatible with Kerberos implementations
- that only support IPv4.
-
-Security considerations
-
- This memo does not introduce any known security considerations in
- addition to those mentioned in [RFC1510].
-
-References
-
- [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
- Authentication Service (V5)", RFC 1510, September 1993.
-
- [RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
- (IPv6) Specification", RFC 1883, December 1995.
-
- [RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
- Architecture", RFC 1884, December 1995.
-
- [RFC2133] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
- Socket Interface Extensions for IPv6", RFC2133, April 1997.
-
-Author's Address
-
- Assar Westerlund
- Swedish Institute of Computer Science
- Box 1263
- S-164 29 KISTA
- Sweden
-
-
-
-
-Westerlund [Page 2]
-
-Internet Draft Kerberos over IPv6 October, 1997
-
-
- Phone: +46-8-7521526
- Fax: +46-8-7517230
- EMail: assar@sics.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Westerlund [Page 3]
-
diff --git a/doc/standardisation/draft-foo.ms b/doc/standardisation/draft-foo.ms
deleted file mode 100644
index 62b109afa52c9fabcbe0aef0fdb639b6baff70bd..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-foo.ms
+++ /dev/null
@@ -1,136 +0,0 @@
-.pl 10.0i
-.po 0
-.ll 7.2i
-.lt 7.2i
-.nr LL 7.2i
-.nr LT 7.2i
-.ds LF Westerlund
-.ds RF [Page %]
-.ds CF
-.ds LH Internet Draft
-.ds RH October, 1997
-.ds CH Kerberos over IPv6
-.hy 0
-.ad l
-.in 0
-.ta \n(.luR
-Network Working Group Assar Westerlund
-<draft-ietf-cat-krb5-ipv6.txt> SICS
-Internet-Draft October, 1997
-Expire in six months
-
-.ce
-Kerberos over IPv6
-
-.ti 0
-Status of this Memo
-
-.in 3
-This document is an Internet-Draft. 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."
-
-To view the entire list of current Internet-Drafts, please check
-the "1id-abstracts.txt" listing contained in the Internet-Drafts
-Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
-(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
-Coast), or ftp.isi.edu (US West Coast).
-
-Distribution of this memo is unlimited. Please send comments to the
-<cat-ietf@mit.edu> mailing list.
-
-.ti 0
-Abstract
-
-.in 3
-This document specifies the address types and transport types
-necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].
-
-.ti 0
-Specification
-
-.in 3
-IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
-order. The type of IPv6 addresses is twenty-four (24).
-
-The following addresses (see [RFC1884]) MUST not appear in any
-Kerberos packet:
-
-the Unspecified Address
-.br
-the Loopback Address
-.br
-Link-Local addresses
-
-IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
-
-Communication with the KDC over IPv6 MUST be done as in section
-8.2.1 of [RFC1510].
-
-.ti 0
-Discussion
-
-.in 3
-[RFC1510] suggests using the address family constants in
-<sys/socket.h> from BSD. This cannot be done for IPv6 as these
-numbers have diverged and are different on different BSD-derived
-systems. [RFC2133] does not either specify a value for AF_INET6.
-Thus a value has to be decided and the implementations have to convert
-between the value used in Kerberos HostAddress and the local AF_INET6.
-
-There are a few different address types in IPv6, see [RFC1884]. Some
-of these are used for quite special purposes and it makes no sense to
-include them in Kerberos packets.
-
-It is necessary to represent IPv4-mapped addresses as Internet
-addresses (type 2) to be compatible with Kerberos implementations that
-only support IPv4.
-
-.ti 0
-Security considerations
-
-.in 3
-This memo does not introduce any known security considerations in
-addition to those mentioned in [RFC1510].
-
-.ti 0
-References
-
-.in 3
-[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-Authentication Service (V5)", RFC 1510, September 1993.
-
-[RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
-(IPv6) Specification", RFC 1883, December 1995.
-
-[RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
-Architecture", RFC 1884, December 1995.
-
-[RFC2133] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
-Socket Interface Extensions for IPv6", RFC2133, April 1997.
-
-.ti 0
-Author's Address
-
-Assar Westerlund
-.br
-Swedish Institute of Computer Science
-.br
-Box 1263
-.br
-S-164 29 KISTA
-.br
-Sweden
-
-Phone: +46-8-7521526
-.br
-Fax: +46-8-7517230
-.br
-EMail: assar@sics.se
diff --git a/doc/standardisation/draft-foo2 b/doc/standardisation/draft-foo2
deleted file mode 100644
index 0fa695f640f87912af369f7c047bd0b9a3326964..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-foo2
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group Assar Westerlund
-<draft-ietf-cat-krb5-tcp.txt> SICS
-Internet-Draft Johan Danielsson
-November, 1997 PDC, KTH
-Expire in six months
-
- Kerberos over TCP
-
-Status of this Memo
-
- This document is an Internet-Draft. 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."
-
- To view the entire list of current Internet-Drafts, please check the
- "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
- Distribution of this memo is unlimited. Please send comments to the
- <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
- This document specifies how the communication should be done between
- a client and a KDC using Kerberos [RFC1510] with TCP as the transport
- protocol.
-
-Specification
-
- This draft specifies an extension to section 8.2.1 of RFC1510.
-
- A Kerberos server MAY accept requests on TCP port 88 (decimal).
-
- The data sent from the client to the KDC should consist of 4 bytes
- containing the length, in network byte order, of the Kerberos
- request, followed by the request (AS-REQ or TGS-REQ) itself. The
- reply from the KDC should consist of the length of the reply packet
- (4 bytes, network byte order) followed by the packet itself (AS-REP,
- TGS-REP, or KRB-ERROR).
-
-
-
-
-Westerlund, Danielsson [Page 1]
-
-Internet Draft Kerberos over TCP November, 1997
-
-
- C->S: Open connection to TCP port 88 at the server
- C->S: length of request
- C->S: AS-REQ or TGS-REQ
- S->C: length of reply
- S->C: AS-REP, TGS-REP, or KRB-ERROR
-
-Discussion
-
- Even though the preferred way of sending kerberos packets is over UDP
- there are several occasions when it's more practical to use TCP.
-
- Mainly, it's usually much less cumbersome to get TCP through
- firewalls than UDP.
-
- In theory, there's no reason for having explicit length fields, that
- information is already encoded in the ASN1 encoding of the Kerberos
- packets. But having explicit lengths makes it unnecessary to have to
- decode the ASN.1 encoding just to know how much data has to be read.
-
- Another way of signaling the end of the request of the reply would be
- to do a half-close after the request and a full-close after the
- reply. This does not work well with all kinds of firewalls.
-
-Security considerations
-
- This memo does not introduce any known security considerations in
- addition to those mentioned in [RFC1510].
-
-References
-
- [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
- Authentication Service (V5)", RFC 1510, September 1993.
-
-Authors' Addresses
-
- Assar Westerlund
- Swedish Institute of Computer Science
- Box 1263
- S-164 29 KISTA
- Sweden
-
- Phone: +46-8-7521526
- Fax: +46-8-7517230
- EMail: assar@sics.se
-
- Johan Danielsson
- PDC, KTH
- S-100 44 STOCKHOLM
-
-
-
-Westerlund, Danielsson [Page 2]
-
-Internet Draft Kerberos over TCP November, 1997
-
-
- Sweden
-
- Phone: +46-8-7907885
- Fax: +46-8-247784
- EMail: joda@pdc.kth.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Westerlund, Danielsson [Page 3]
-
diff --git a/doc/standardisation/draft-foo2.ms b/doc/standardisation/draft-foo2.ms
deleted file mode 100644
index 7e0fa0a6281b39e60b7477a5efb889bf5b0ee2cf..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-foo2.ms
+++ /dev/null
@@ -1,145 +0,0 @@
-.pl 10.0i
-.po 0
-.ll 7.2i
-.lt 7.2i
-.nr LL 7.2i
-.nr LT 7.2i
-.ds LF Westerlund, Danielsson
-.ds RF [Page %]
-.ds CF
-.ds LH Internet Draft
-.ds RH November, 1997
-.ds CH Kerberos over TCP
-.hy 0
-.ad l
-.in 0
-.ta \n(.luR
-.nf
-Network Working Group Assar Westerlund
-<draft-ietf-cat-krb5-tcp.txt> SICS
-Internet-Draft Johan Danielsson
-November, 1997 PDC, KTH
-Expire in six months
-.fi
-
-.ce
-Kerberos over TCP
-
-.ti 0
-Status of this Memo
-
-.in 3
-This document is an Internet-Draft. 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."
-
-To view the entire list of current Internet-Drafts, please check
-the "1id-abstracts.txt" listing contained in the Internet-Drafts
-Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
-(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
-Coast), or ftp.isi.edu (US West Coast).
-
-Distribution of this memo is unlimited. Please send comments to the
-<cat-ietf@mit.edu> mailing list.
-
-.ti 0
-Abstract
-
-.in 3
-This document specifies how the communication should be done between a
-client and a KDC using Kerberos [RFC1510] with TCP as the transport
-protocol.
-
-.ti 0
-Specification
-
-This draft specifies an extension to section 8.2.1 of RFC1510.
-
-A Kerberos server MAY accept requests on TCP port 88 (decimal).
-
-The data sent from the client to the KDC should consist of 4 bytes
-containing the length, in network byte order, of the Kerberos request,
-followed by the request (AS-REQ or TGS-REQ) itself. The reply from
-the KDC should consist of the length of the reply packet (4 bytes,
-network byte order) followed by the packet itself (AS-REP, TGS-REP, or
-KRB-ERROR).
-
-.nf
-C->S: Open connection to TCP port 88 at the server
-C->S: length of request
-C->S: AS-REQ or TGS-REQ
-S->C: length of reply
-S->C: AS-REP, TGS-REP, or KRB-ERROR
-.fi
-
-.ti 0
-Discussion
-
-Even though the preferred way of sending kerberos packets is over UDP
-there are several occasions when it's more practical to use TCP.
-
-Mainly, it's usually much less cumbersome to get TCP through firewalls
-than UDP.
-
-In theory, there's no reason for having explicit length fields, that
-information is already encoded in the ASN1 encoding of the Kerberos
-packets. But having explicit lengths makes it unnecessary to have to
-decode the ASN.1 encoding just to know how much data has to be read.
-
-Another way of signaling the end of the request of the reply would be
-to do a half-close after the request and a full-close after the reply.
-This does not work well with all kinds of firewalls.
-
-.ti 0
-Security considerations
-
-.in 3
-This memo does not introduce any known security considerations in
-addition to those mentioned in [RFC1510].
-
-.ti 0
-References
-
-.in 3
-[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-Authentication Service (V5)", RFC 1510, September 1993.
-
-.ti 0
-Authors' Addresses
-
-Assar Westerlund
-.br
-Swedish Institute of Computer Science
-.br
-Box 1263
-.br
-S-164 29 KISTA
-.br
-Sweden
-
-Phone: +46-8-7521526
-.br
-Fax: +46-8-7517230
-.br
-EMail: assar@sics.se
-
-Johan Danielsson
-.br
-PDC, KTH
-.br
-S-100 44 STOCKHOLM
-.br
-Sweden
-
-Phone: +46-8-7907885
-.br
-Fax: +46-8-247784
-.br
-EMail: joda@pdc.kth.se
diff --git a/doc/standardisation/draft-foo3 b/doc/standardisation/draft-foo3
deleted file mode 100644
index 2b8b7bb5775c5ce193e28f922bee9e9371068ad9..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-foo3
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group Assar Westerlund
-<draft-ietf-cat-krb5-firewalls.txt> SICS
-Internet-Draft Johan Danielsson
-November, 1997 PDC, KTH
-Expire in six months
-
- Kerberos vs firewalls
-
-Status of this Memo
-
- This document is an Internet-Draft. 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."
-
- To view the entire list of current Internet-Drafts, please check the
- "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
- Distribution of this memo is unlimited. Please send comments to the
- <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
-Introduction
-
- Kerberos[RFC1510] is a protocol for authenticating parties
- communicating over insecure networks.
-
- Firewalling is a technique for achieving an illusion of security by
- putting restrictions on what kinds of packets and how these are sent
- between the internal (so called "secure") network and the global (or
- "insecure") Internet.
-
-Definitions
-
- client: the user, process, and host acquiring tickets from the KDC
- and authenticating itself to the kerberised server.
-
- KDC: the Kerberos Key Distribution Center
-
-
-
-
-Westerlund, Danielsson [Page 1]
-
-Internet Draft Kerberos vs firewalls November, 1997
-
-
- Kerberised server: the server using Kerberos to authenticate the
- client, for example telnetd.
-
-Firewalls
-
- A firewall is usually placed between the "inside" and the "outside"
- networks, and is supposed to protect the inside from the evils on the
- outside. There are different kinds of firewalls. The main
- differences are in the way they forward packets.
-
- o+ The most straight forward type is the one that just imposes
- restrictions on incoming packets. Such a firewall could be
- described as a router that filters packets that match some
- criteria.
-
- o+ They may also "hide" some or all addresses on the inside of the
- firewall, replacing the addresses in the outgoing packets with the
- address of the firewall (aka network address translation, or NAT).
- NAT can also be used without any packet filtering, for instance
- when you have more than one host sharing a single address (for
- example, with a dialed-in PPP connection).
-
- There are also firewalls that does NAT both on the inside and the
- outside (a server on the inside will see this as a connection from
- the firewall).
-
- o+ A third type is the proxy type firewall, that parses the contents
- of the packets, basically acting as a server to the client, and as
- a client to the server (man-in-the-middle). If Kerberos is to be
- used with this kind of firewall, a protocol module that handles
- KDC requests has to be written.
-
- This type of firewall might also cause extra trouble when used with
- kerberised versions of protocols that the proxy understands, in
- addition to the ones mentioned below. This is the case with the FTP
- Security Extensions [RFC2228], that adds a new set of commands to the
- FTP protocol [RFC959], for integrity, confidentiality, and privacy
- protecting commands. When transferring data, the FTP protocol uses a
- separate data channel, and an FTP proxy will have to look out for
- commands that start a data transfer. If all commands are encrypted,
- this is impossible. A protocol that doesn't suffer from this is the
- Telnet Authentication Option [RFC1416] that does all authentication
- and encryption in-bound.
-
-Scenarios
-
- Here the different scenarios we have considered are described, the
- problems they introduce and the proposed ways of solving them.
-
-
-
-Westerlund, Danielsson [Page 2]
-
-Internet Draft Kerberos vs firewalls November, 1997
-
-
- Combinations of these can also occur.
-
- Client behind firewall
-
- This is the most typical and common scenario. First of all the
- client needs some way of communicating with the KDC. This can be
- done with whatever means and is usually much simpler when the KDC is
- able to communicate over TCP.
-
- Apart from that, the client needs to be sure that the ticket it will
- acquire from the KDC can be used to authenticate to a server outside
- its firewall. For this, it needs to add the address(es) of potential
- firewalls between itself and the KDC/server, to the list of its own
- addresses when requesting the ticket. We are not aware of any
- protocol for determining this set of addresses, thus this will have
- to be manually configured in the client.
-
- The client could also request a ticket with no addresses, but some
- KDCs and servers might not accept such a ticket.
-
- With the ticket in possession, communication with the kerberised
- server will not need to be any different from communicating between a
- non-kerberised client and server.
-
- Kerberised server behind firewall
-
- The kerberised server does not talk to the KDC at all so nothing
- beyond normal firewall-traversal techniques for reaching the server
- itself needs to be applied.
-
- The kerberised server needs to be able to retrieve the original
- address (before its firewall) that the request was sent for. If this
- is done via some out-of-band mechanism or it's directly able to see
- it doesn't matter.
-
- KDC behind firewall
-
- The same restrictions applies for a KDC as for any other server.
-
-Specification
-
-Security considerations
-
- This memo does not introduce any known security considerations in
- addition to those mentioned in [RFC1510].
-
-References
-
-
-
-
-Westerlund, Danielsson [Page 3]
-
-Internet Draft Kerberos vs firewalls November, 1997
-
-
- [RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)",
- RFC 969, October 1985
-
- [RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416,
- February 1993.
-
- [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
- Authentication Service (V5)", RFC 1510, September 1993.
-
- [RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions",
- RFC2228, October 1997.
-
-Authors' Addresses
-
- Assar Westerlund
- Swedish Institute of Computer Science
- Box 1263
- S-164 29 KISTA
- Sweden
-
- Phone: +46-8-7521526
- Fax: +46-8-7517230
- EMail: assar@sics.se
-
- Johan Danielsson
- PDC, KTH
- S-100 44 STOCKHOLM
- Sweden
-
- Phone: +46-8-7907885
- Fax: +46-8-247784
- EMail: joda@pdc.kth.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Westerlund, Danielsson [Page 4]
-
diff --git a/doc/standardisation/draft-foo3.ms b/doc/standardisation/draft-foo3.ms
deleted file mode 100644
index 940f651dd306775588543fcfe6cf167140025f94..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-foo3.ms
+++ /dev/null
@@ -1,233 +0,0 @@
-.pl 10.0i
-.po 0
-.ll 7.2i
-.lt 7.2i
-.nr LL 7.2i
-.nr LT 7.2i
-.ds LF Westerlund, Danielsson
-.ds RF [Page %]
-.ds CF
-.ds LH Internet Draft
-.ds RH November, 1997
-.ds CH Kerberos vs firewalls
-.de Ip
-.in 6
-.ta 3
-.ti -3
-\\$1\t\c
-..
-.hy 0
-.ad l
-.in 0
-.ta \n(.luR
-.nf
-Network Working Group Assar Westerlund
-<draft-ietf-cat-krb5-firewalls.txt> SICS
-Internet-Draft Johan Danielsson
-November, 1997 PDC, KTH
-Expire in six months
-.fi
-
-.ce
-Kerberos vs firewalls
-
-.ti 0
-Status of this Memo
-
-.in 3
-This document is an Internet-Draft. 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
-\*Qwork in progress.\*U
-
-To view the entire list of current Internet-Drafts, please check
-the \*Q1id-abstracts.txt\*U listing contained in the Internet-Drafts
-Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
-(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
-Coast), or ftp.isi.edu (US West Coast).
-
-Distribution of this memo is unlimited. Please send comments to the
-<cat-ietf@mit.edu> mailing list.
-
-.ti 0
-Abstract
-
-.ti 0
-Introduction
-
-Kerberos[RFC1510] is a protocol for authenticating parties
-communicating over insecure networks.
-
-Firewalling is a technique for achieving an illusion of security by
-putting restrictions on what kinds of packets and how these are sent
-between the internal (so called \*Qsecure\*U) network and the global (or
-\*Qinsecure\*U) Internet.
-
-.ti 0
-Definitions
-
-client: the user, process, and host acquiring tickets from the KDC and
-authenticating itself to the kerberised server.
-
-KDC: the Kerberos Key Distribution Center
-
-Kerberised server: the server using Kerberos to authenticate the
-client, for example telnetd.
-
-.ti 0
-Firewalls
-
-A firewall is usually placed between the \*Qinside\*U and the
-\*Qoutside\*U networks, and is supposed to protect the inside from the
-evils on the outside. There are different kinds of firewalls. The
-main differences are in the way they forward packets.
-
-.Ip \(bu
-The most straight forward type is the one that just imposes
-restrictions on incoming packets. Such a firewall could be described
-as a router that filters packets that match some criteria.
-
-.Ip \(bu
-They may also \*Qhide\*U some or all addresses on the inside of the
-firewall, replacing the addresses in the outgoing packets with the
-address of the firewall (aka network address translation, or NAT). NAT
-can also be used without any packet filtering, for instance when you
-have more than one host sharing a single address (for example, with a
-dialed-in PPP connection).
-
-.in 3
-There are also firewalls that does NAT both on the inside and the
-outside (a server on the inside will see this as a connection from the
-firewall).
-
-.Ip \(bu
-A third type is the proxy type firewall, that parses the contents of
-the packets, basically acting as a server to the client, and as a
-client to the server (man-in-the-middle). If Kerberos is to be used
-with this kind of firewall, a protocol module that handles KDC
-requests has to be written.
-
-.in 3
-This type of firewall might also cause extra trouble when used with
-kerberised versions of protocols that the proxy understands, in
-addition to the ones mentioned below. This is the case with the FTP
-Security Extensions [RFC2228], that adds a new set of commands to the
-FTP protocol [RFC959], for integrity, confidentiality, and privacy
-protecting commands. When transferring data, the FTP protocol uses a
-separate data channel, and an FTP proxy will have to look out for
-commands that start a data transfer. If all commands are encrypted,
-this is impossible. A protocol that doesn't suffer from this is the
-Telnet Authentication Option [RFC1416] that does all authentication
-and encryption in-bound.
-
-.ti 0
-Scenarios
-
-Here the different scenarios we have considered are described, the
-problems they introduce and the proposed ways of solving them.
-Combinations of these can also occur.
-
-.ti 1
-Client behind firewall
-
-This is the most typical and common scenario. First of all the client
-needs some way of communicating with the KDC. This can be done with
-whatever means and is usually much simpler when the KDC is able to
-communicate over TCP.
-
-Apart from that, the client needs to be sure that the ticket it will
-acquire from the KDC can be used to authenticate to a server outside
-its firewall. For this, it needs to add the address(es) of potential
-firewalls between itself and the KDC/server, to the list of its own
-addresses when requesting the ticket. We are not aware of any
-protocol for determining this set of addresses, thus this will have to
-be manually configured in the client.
-
-The client could also request a ticket with no addresses, but some
-KDCs and servers might not accept such a ticket.
-
-With the ticket in possession, communication with the kerberised
-server will not need to be any different from communicating between a
-non-kerberised client and server.
-
-.ti 1
-Kerberised server behind firewall
-
-The kerberised server does not talk to the KDC at all so nothing
-beyond normal firewall-traversal techniques for reaching the server
-itself needs to be applied.
-
-The kerberised server needs to be able to retrieve the original
-address (before its firewall) that the request was sent for. If this
-is done via some out-of-band mechanism or it's directly able to see it
-doesn't matter.
-
-.ti 1
-KDC behind firewall
-
-The same restrictions applies for a KDC as for any other server.
-
-.ti 0
-Specification
-
-.ti 0
-Security considerations
-
-.in 3
-Since the whole network behind a NAT-type firewall looks like one
-computer from the outside, any security added by the addresses in the
-ticket will be lost.
-
-.ti 0
-References
-
-[RFC959] Postel, J. and Reynolds, J., \*QFile Transfer Protocol
-(FTP)\*U, RFC 969, October 1985
-
-[RFC1416] Borman, D., \*QTelnet Authentication Option\*U, RFC 1416,
-February 1993.
-
-[RFC1510] Kohl, J. and Neuman, C., \*QThe Kerberos Network
-Authentication Service (V5)\*U, RFC 1510, September 1993.
-
-[RFC2228] Horowitz, M. and Lunt, S., \*QFTP Security Extensions\*U,
-RFC2228, October 1997.
-
-.ti 0
-Authors' Addresses
-
-Assar Westerlund
-.br
-Swedish Institute of Computer Science
-.br
-Box 1263
-.br
-S-164 29 KISTA
-.br
-Sweden
-
-Phone: +46-8-7521526
-.br
-Fax: +46-8-7517230
-.br
-EMail: assar@sics.se
-
-Johan Danielsson
-.br
-PDC, KTH
-.br
-S-100 44 STOCKHOLM
-.br
-Sweden
-
-Phone: +46-8-7907885
-.br
-Fax: +46-8-247784
-.br
-EMail: joda@pdc.kth.se
diff --git a/doc/standardisation/draft-ietf-cat-gssv2-08.txt b/doc/standardisation/draft-ietf-cat-gssv2-08.txt
deleted file mode 100644
index ccba35eeb4ab043fcb968860155c3eaf662850f0..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-ietf-cat-gssv2-08.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-
-
-A new Request for Comments is now available in online RFC libraries.
-
-
- RFC 2078
-
- Title: Generic Security Service Application Program
- Interface, Version 2
- Author: J. Linn
- Date: January 1997
- Mailbox: John.Linn@ov.com
- Pages: 85
- Characters: 185990
- Obsoletes: 1508
-
- URL: ftp://ds.internic.net/rfc/rfc2078.txt
-
-
-This memo revises RFC-1508, making specific, incremental changes in
-response to implementation experience and liaison requests. It is
-intended, therefore, that this memo or a successor version thereto
-will become the basis for subsequent progression of the GSS-API
-specification on the standards track. This document is a product of
-the Common Authentication Technology Working Group.
-
-This is now a Proposed Standard Protocol.
-
-This document specifies an Internet standards track protocol for the
-Internet community, and requests discussion and suggestions for
-improvements. Please refer to the current edition of the "Internet
-Official Protocol Standards" (STD 1) for the standardization state and
-status of this protocol. Distribution of this memo is unlimited.
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@ISI.EDU.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@ISI.EDU with the message body
-help: ways_to_get_rfcs. For example:
-
- To: rfc-info@ISI.EDU
- Subject: getting rfcs
-
- help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.
-
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC
-Authors, for further information.
-
-
-Joyce K. Reynolds and Mary Kennedy
-USC/Information Sciences Institute
-
diff --git a/doc/standardisation/draft-ietf-cat-gssv2-cbind-04.txt b/doc/standardisation/draft-ietf-cat-gssv2-cbind-04.txt
deleted file mode 100644
index 518f4c63d17125bd167316ccfdae57918a94c8d7..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-ietf-cat-gssv2-cbind-04.txt
+++ /dev/null
@@ -1,6188 +0,0 @@
-
- Internet draft J.Wray
- IETF Common Authentication Technology WG Digital Equipment Corporation
- <draft-ietf-cat-gssv2-cbind-04.txt> March 1997
-
-
-
- Generic Security Service API Version 2 : C-bindings
-
-
- 1. STATUS OF THIS MEMO
-
- This document is an Internet Draft. 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. Internet Drafts may be updated, replaced,
- or obsoleted by other documents at any time. It is not appropriate to
- use Internet Drafts as reference material or to cite them other than as
- a "working draft" or "work in progress." Please check the I-D abstract
- listing contained in each Internet Draft directory to learn the current
- status of this or any other Internet Draft.
-
- Comments on this document should be sent to "cat-ietf@MIT.EDU", the IETF
- Common Authentication Technology WG discussion list.
-
-
- 2. ABSTRACT
-
- This draft document specifies C language bindings for Version 2 of the
- Generic Security Service Application Program Interface (GSSAPI), which
- is described at a language-independent conceptual level in other drafts
- [GSSAPI]. It revises RFC-1509, making specific incremental changes in
- response to implementation experience and liaison requests. It is
- intended, therefore, that this draft or a successor version thereof will
- become the basis for subsequent progression of the GSS-API specification
- on the standards track.
-
- The Generic Security Service Application Programming Interface provides
- security services to its callers, and is intended for implementation
- atop a variety of underlying cryptographic mechanisms. Typically,
- GSSAPI callers will be application protocols into which security
- enhancements are integrated through invocation of services provided by
- the GSSAPI. The GSSAPI allows a caller application to authenticate a
- principal identity associated with a peer application, to delegate
- rights to a peer, and to apply security services such as confidentiality
- and integrity on a per-message basis.
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 1]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 3. INTRODUCTION
-
- The Generic Security Service Application Programming Interface [GSSAPI]
- provides security services to calling applications. It allows a
- communicating application to authenticate the user associated with
- another application, to delegate rights to another application, and to
- apply security services such as confidentiality and integrity on a per-
- message basis.
-
- There are four stages to using the GSSAPI:
-
- (a) The application acquires a set of credentials with which it may
- prove its identity to other processes. The application's
- credentials vouch for its global identity, which may or may not be
- related to any local username under which it may be running.
-
- (b) A pair of communicating applications establish a joint security
- context using their credentials. The security context is a pair
- of GSSAPI data structures that contain shared state information,
- which is required in order that per-message security services may
- be provided. Examples of state that might be shared between
- applications as part of a security context are cryptographic keys,
- and message sequence numbers. As part of the establishment of a
- security context, the context initiator is authenticated to the
- responder, and may require that the responder is authenticated in
- turn. The initiator may optionally give the responder the right
- to initiate further security contexts, acting as an agent or
- delegate of the initiator. This transfer of rights is termed
- delegation, and is achieved by creating a set of credentials,
- similar to those used by the initiating application, but which may
- be used by the responder.
-
- To establish and maintain the shared information that makes up the
- security context, certain GSSAPI calls will return a token data
- structure, which is a cryptographically protected opaque data
- type. The caller of such a GSSAPI routine is responsible for
- transferring the token to the peer application, encapsulated if
- necessary in an application-application protocol. On receipt of
- such a token, the peer application should pass it to a
- corresponding GSSAPI routine which will decode the token and
- extract the information, updating the security context state
- information accordingly.
-
- (c) Per-message services are invoked to apply either:
-
- (i) integrity and data origin authentication, or
-
- (ii) confidentiality, integrity and data origin authentication
-
- to application data, which are treated by GSSAPI as arbitrary
- octet-strings. An application transmitting a message that it
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 2]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- wishes to protect will call the appropriate GSSAPI routine
- (gss_get_mic or gss_wrap) to apply protection, specifying the
- appropriate security context, and send the resulting token to the
- receiving application. The receiver will pass the received token
- (and, in the case of data protected by gss_get_mic, the
- accompanying message-data) to the corresponding decoding routine
- (gss_verify_mic or gss_unwrap) to remove the protection and
- validate the data.
-
- (d) At the completion of a communications session (which may extend
- across several transport connections), each application calls a
- GSSAPI routine to delete the security context. Multiple contexts
- may also be used (either successively or simultaneously) within a
- single communications association, at the option of the
- applications.
-
-
- 4. GSSAPI ROUTINES
-
- This section lists the routines that make up the GSSAPI, and offers a
- brief description of the purpose of each routine. Detailed descriptions
- of each routine are listed in alphabetical order in section 7.
-
- Table 4-1 GSSAPI Credential-management Routines
-
- ROUTINE SECTION FUNCTION
-
- gss_acquire_cred 7.2 Assume a global identity;
- Obtain a GSSAPI credential
- handle for pre-existing
- credentials.
-
- gss_add_cred 7.3 Construct credentials
- incrementally
-
- gss_inquire_cred 7.21 Obtain information about
- a credential.
-
- gss_inquire_cred_by_mech 7.22 Obtain per-mechanism information
- about a credential.
-
- gss_release_cred 7.27 Discard a credential handle.
-
-
-
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 3]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Table 4-2 GSSAPI Context-level Routines
-
- ROUTINE SECTION FUNCTION
-
- gss_init_sec_context 7.19 Initiate a security context
- with a peer application
-
-
- gss_accept_sec_context 7.1 Accept a security context
- initiated by a peer
- application
-
- gss_delete_sec_context 7.9 Discard a security context
-
- gss_process_context_token 7.25 Process a token on a security
- context from a peer
- application
-
- gss_context_time 7.7 Determine for how long a
- context will remain valid
-
- gss_inquire_context 7.20 Obtain information about a
- security context
-
- gss_wrap_size_limit 7.33 Determine token-size limit for
- gss_wrap on a context
-
- gss_export_sec_context 7.14 Transfer a security context to
- another process
-
- gss_import_sec_context 7.17 Import a transferred context
-
-
-
-
- Table 4-3 GSSAPI Per-message Routines
-
- ROUTINE SECTION FUNCTION
-
- gss_get_mic 7.15 Calculate a cryptographic
- Message Integrity Code (MIC)
- for a message; integrity service
-
- gss_verify_mic 7.32 Check a MIC against a message;
- verify integrity of a received
- message
-
- gss_wrap 7.36 Attach a MIC to a message, and
- optionally encrypt the message
- content; confidentiality service
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 4]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- gss_unwrap 7.31 Verify a message with attached
- MIC, and decrypt message
- content if necessary.
-
-
-
-
- Table 4-4 GSSAPI Name manipulation Routines
-
- ROUTINE SECTION FUNCTION
-
- gss_import_name 7.16 Convert a contiguous string name
- to internal-form
-
- gss_display_name 7.10 Convert internal-form name
- to text
-
- gss_compare_name 7.6 Compare two internal-form names
-
- gss_release_name 7.28 Discard an internal-form name
-
- gss_inquire_names_for_mech 7.24 List the name-types supported
- by a specified mechanism
-
- gss_inquire_mechs_for_name 7.23 List mechanisms that support
- a given nametype
-
- gss_canonicalize_name 7.5 Convert an internal name to
- an MN.
-
- gss_export_name 7.13 Convert an MN to export form
-
- gss_duplicate_name 7.12 Create a copy of an internal name
-
-
-
-
- Table 4-5 GSSAPI Miscellaneous Routines
-
- ROUTINE SECTION FUNCTION
-
- gss_display_status 7.11 Convert a GSSAPI status code
- to text
-
- gss_indicate_mechs 7.18 Determine available underlying
- authentication mechanisms
-
- gss_release_buffer 7.26 Discard a buffer
-
- gss_release_oid_set 7.29 Discard a set of object
- identifiers
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 5]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- gss_create_empty_oid_set 7.8 Create a set containing no
- object identifiers
-
- gss_add_oid_set_member 7.4 Add an object identifier to
- a set
-
- gss_test_oid_set_member 7.30 Determines whether an object
- identifier is a member of a set
-
-
-
-
-
- Individual GSSAPI implementations may augment these routines by
- providing additional mechanism-specific routines if required
- functionality is not available from the generic forms. Applications are
- encouraged to use the generic routines wherever possible on portability
- grounds.
-
-
- 5. DATA TYPES AND CALLING CONVENTIONS
-
- The following conventions are used by the GSSAPI C-language bindings:
-
- 5.1. Integer types
-
- GSSAPI uses the following integer data type:
-
- OM_uint32 32-bit unsigned integer
-
- Where guaranteed minimum bit-count is important, this portable data type
- is used by the GSSAPI routine definitions. Individual GSSAPI
- implementations will include appropriate typedef definitions to map this
- type onto a built-in data type. If the platform supports the X/Open
- xom.h header file, the OM_uint32 definition contained therein should be
- used; the GSSAPI header file in Appendix A contains logic that will
- detect the prior inclusion of xom.h, and will not attempt to re-declare
- OM_uint32. If the X/Open header file is not available on the platform,
- the GSSAPI implementation should use the smallest natural unsigned
- integer type that provides at least 32 bits of precision.
-
- 5.2. String and similar data
-
- Many of the GSSAPI routines take arguments and return values that
- describe contiguous octet-strings. All such data is passed between the
- GSSAPI and the caller using the gss_buffer_t data type. This data type
- is a pointer to a buffer descriptor, which consists of a length field
- that contains the total number of bytes in the datum, and a value field
- which contains a pointer to the actual datum:
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 6]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- typedef struct gss_buffer_desc_struct {
- size_t length;
- void *value;
- } gss_buffer_desc, *gss_buffer_t;
-
- Storage for data returned to the application by a GSSAPI routine using
- the gss_buffer_t conventions is allocated by the GSSAPI routine. The
- application may free this storage by invoking the gss_release_buffer
- routine. Allocation of the gss_buffer_desc object is always the
- responsibility of the application; unused gss_buffer_desc objects may
- be initialized to the value GSS_C_EMPTY_BUFFER.
-
- 5.2.1. Opaque data types
-
- Certain multiple-word data items are considered opaque data types at the
- GSSAPI, because their internal structure has no significance either to
- the GSSAPI or to the caller. Examples of such opaque data types are the
- input_token parameter to gss_init_sec_context (which is opaque to the
- caller), and the input_message parameter to gss_wrap (which is opaque to
- the GSSAPI). Opaque data is passed between the GSSAPI and the
- application using the gss_buffer_t datatype.
-
- 5.2.2. Character strings
-
- Certain multiple-word data items may be regarded as simple ISO Latin-1
- character strings. Examples are the printable strings passed to
- gss_import_name via the input_name_buffer parameter. Some GSSAPI
- routines also return character strings. All such character strings are
- passed between the application and the GSSAPI implementation using the
- gss_buffer_t datatype, which is a pointer to a gss_buffer_desc object.
-
- When a gss_buffer_desc object describes a printable string, the length
- field of the gss_buffer_desc should only count printable characters
- within the string. In particular, a trailing NUL character should NOT
- be included in the length count, nor should either the GSSAPI
- implementation or the application assume the presence of an uncounted
- trailing NUL.
-
- 5.3. Object Identifiers
-
- Certain GSSAPI procedures take parameters of the type gss_OID, or Object
- identifier. This is a type containing ISO-defined tree-structured
- values, and is used by the GSSAPI caller to select an underlying
- security mechanism and to specify namespaces. A value of type gss_OID
- has the following structure:
-
- typedef struct gss_OID_desc_struct {
- OM_uint32 length;
- void *elements;
- } gss_OID_desc, *gss_OID;
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 7]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- The elements field of this structure points to the first byte of an
- octet string containing the ASN.1 BER encoding of the value portion of
- the normal BER TLV encoding of the gss_OID. The length field contains
- the number of bytes in this value. For example, the gss_OID value
- corresponding to {iso(1) identified-organization(3) icd-ecma(12)
- member-company(2) dec(1011) cryptoAlgorithms(7) DASS(5)}, meaning the
- DASS X.509 authentication mechanism, has a length field of 7 and an
- elements field pointing to seven octets containing the following octal
- values: 53,14,2,207,163,7,5. GSSAPI implementations should provide
- constant gss_OID values to allow applications to request any supported
- mechanism, although applications are encouraged on portability grounds
- to accept the default mechanism. gss_OID values should also be provided
- to allow applications to specify particular name types (see section
- 5.10). Applications should treat gss_OID_desc values returned by GSSAPI
- routines as read-only. In particular, the application should not
- attempt to deallocate them with free(). The gss_OID_desc datatype is
- equivalent to the X/Open OM_object_identifier datatype[XOM].
-
- 5.4. Object Identifier Sets
-
- Certain GSSAPI procedures take parameters of the type gss_OID_set. This
- type represents one or more object identifiers (section 5.3). A
- gss_OID_set object has the following structure:
-
- typedef struct gss_OID_set_desc_struct {
- size_t count;
- gss_OID elements;
- } gss_OID_set_desc, *gss_OID_set;
-
- The count field contains the number of OIDs within the set. The
- elements field is a pointer to an array of gss_OID_desc objects, each of
- which describes a single OID. gss_OID_set values are used to name the
- available mechanisms supported by the GSSAPI, to request the use of
- specific mechanisms, and to indicate which mechanisms a given credential
- supports.
-
- All OID sets returned to the application by GSSAPI are dynamic objects
- (the gss_OID_set_desc, the "elements" array of the set, and the
- "elements" array of each member OID are all dynamically allocated), and
- this storage must be deallocated by the application using the
- gss_release_oid_set() routine.
-
-
- 5.5. Credentials
-
- A credential handle is a caller-opaque atomic datum that identifies a
- GSSAPI credential data structure. It is represented by the caller-
- opaque type gss_cred_id_t, which should be implemented as a pointer or
- arithmetic type. If a pointer implementation is chosen, care must be
- taken to ensure that two gss_cred_id_t values may be compared with the
- == operator.
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 8]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSSAPI credentials can contain mechanism-specific principal
- authentication data for multiple mechanisms. A GSSAPI credential is
- composed of a set of credential-elements, each of which is applicable to
- a single mechanism. A credential may contain at most one credential-
- element for each supported mechanism. A credential-element identifies
- the data needed by a single mechanism to authenticate a single
- principal, and conceptually contains two credential-references that
- describing the actual mechanism-specific authentication data, one to be
- used by GSSAPI for initiating contexts, and one to be used for
- accepting contexts. For mechanisms that do not distinguish between
- acceptor and initiator credentials, both references would point to the
- same underlying mechanism-specific authentication data.
-
- Credentials describe a set of mechanism-specific principals, and give
- their holder the ability to act as any of those principals. All
- principal identities asserted by a single GSSAPI credential should
- belong to the same entity, although enforcement of this property is an
- implementation-specific matter. The GSSAPI does not make the actual
- credentials available to applications; instead a credential handle is
- used to identify a particular credential, held internally by GSSAPI.
- The combination of GSSAPI credential handle and mechanism identifies the
- principal whose identity will be asserted by the credential when used
- with that mechanism.
-
- The gss_init_sec_context and gss_accept_sec_context routines allow the
- value GSS_C_NO_CREDENTIAL to be specified as their credential handle
- parameter. This special credential-handle indicates a desire by the
- application to act as a default principal. While individual GSSAPI
- implementations are free to determine such default behavior as
- appropriate to the mechanism, the following default behavior by these
- routines is recommended for portability:
-
- (a) gss_init_sec_context
-
- (i) If there is only a single principal capable of initiating
- security contexts for the chosen mechanism that the
- application is authorized to act on behalf of, then that
- principal shall be used, otherwise
-
- (ii) If the platform maintains a concept of a default network-
- identity for the chosen mechanism, and if the application is
- authorized to act on behalf of that identity for the purpose
- of initiating security contexts, then the principal
- corresponding to that identity shall be used, otherwise
-
- (iii) If the platform maintains a concept of a default local
- identity, and provides a means to map local identities into
- network-identities for the chosen mechanism, and if the
- application is authorized to act on behalf of the network-
- identity image of the default local identity for the purpose
- of initiating security contexts using the chosen mechanism,
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 9]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- then the principal corresponding to that identity shall be
- used, otherwise
-
- (iv) A user-configurable default identity should be used.
-
- (b) gss_accept_sec_context
-
- (i) If there is only a single authorized principal identity
- capable of accepting security contexts for the chosen
- mechanism, then that principal shall be used, otherwise
-
- (ii) If the mechanism can determine the identity of the target
- principal by examining the context-establishment token, and
- if the accepting application is authorized to act as that
- principal for the purpose of accepting security contexts
- using the chosen mechanism, then that principal identity
- shall be used, otherwise
-
- (iii) If the mechanism supports context acceptance by any
- principal, and if mutual authentication was not requested,
- any principal that the application is authorized to accept
- security contexts under using the chosen mechanism may be
- used, otherwise
-
- (iv) A user-configurable default identity shall be used.
-
- The purpose of the above rules is to allow security contexts to be
- established by both initiator and acceptor using the default behavior
- wherever possible. Applications requesting default behavior are likely
- to be more portable across mechanisms and platforms than ones that use
- gss_acquire_cred to request a specific identity.
-
- 5.6. Contexts
-
- The gss_ctx_id_t data type contains a caller-opaque atomic value that
- identifies one end of a GSSAPI security context. It should be
- implemented as a pointer or arithmetic type. If a pointer type is
- chosen, care should be taken to ensure that two gss_ctx_id_t values may
- be compared with the == operator.
-
- The security context holds state information about each end of a peer
- communication, including cryptographic state information.
-
- 5.7. Authentication tokens
-
- A token is a caller-opaque type that GSSAPI uses to maintain
- synchronization between the context data structures at each end of a
- GSSAPI security context. The token is a cryptographically protected
- octet-string, generated by the underlying mechanism at one end of a
- GSSAPI security context for use by the peer mechanism at the other end.
- Encapsulation (if required) and transfer of the token are the
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 10]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- responsibility of the peer applications. A token is passed between the
- GSSAPI and the application using the gss_buffer_t conventions.
-
- 5.8. Interprocess tokens
-
- Certain GSSAPI routines are intended to transfer data between processes
- in multi-process programs. These routines use a caller-opaque octet-
- string, generated by the GSSAPI in one process for use by the GSSAPI in
- another process. The calling application is responsible for
- transferring such tokens between processes in an OS-specific manner.
- Note that, while GSSAPI implementors are encouraged to avoid placing
- sensitive information within interprocess tokens, or to
- cryptographically protect them, many implementations will be unable to
- avoid placing key material or other sensitive data within them. It is
- the application's responsibility to ensure that interprocess tokens are
- protected in transit, and transferred only to processes that are
- trustworthy. An interprocess token is passed between the GSSAPI and the
- application using the gss_buffer_t conventions.
-
- 5.9. Status values
-
- One or more status codes are returned by each GSSAPI routine. Two
- distinct sorts of status codes are returned. These are termed GSS
- status codes and Mechanism status codes.
-
- 5.9.1. GSS status codes
-
- GSSAPI routines return GSS status codes as their OM_uint32 function
- value. These codes indicate errors that are independent of the
- underlying mechanism(s) used to provide the security service. The
- errors that can be indicated via a GSS status code are either generic
- API routine errors (errors that are defined in the GSS-API
- specification) or calling errors (errors that are specific to these
- language bindings).
-
- A GSS status code can indicate a single fatal generic API error from the
- routine and a single calling error. In addition, supplementary status
- information may be indicated via the setting of bits in the
- supplementary info field of a GSS status code.
-
- These errors are encoded into the 32-bit GSS status code as follows:
-
- MSB LSB
- |------------------------------------------------------------|
- | Calling Error | Routine Error | Supplementary Info |
- |------------------------------------------------------------|
- Bit 31 24 23 16 15 0
-
-
- Hence if a GSS-API routine returns a GSS status code whose upper 16 bits
- contain a non-zero value, the call failed. If the calling error field
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 11]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- is non-zero, the invoking application's call of the routine was
- erroneous. Calling errors are defined in table 5-1. If the routine
- error field is non-zero, the routine failed for one of the routine-
- specific reasons listed below in table 5-2. Whether or not the upper 16
- bits indicate a failure or a success, the routine may indicate
- additional information by setting bits in the supplementary info field
- of the status code. The meaning of individual bits is listed below in
- table 5-3.
-
- Table 5-1 Calling Errors
-
- Name Value in Meaning
- Field
- GSS_S_CALL_INACCESSIBLE_READ 1 A required input
- parameter could
- not be read.
- GSS_S_CALL_INACCESSIBLE_WRITE 2 A required output
- parameter could
- not be written.
- GSS_S_CALL_BAD_STRUCTURE 3 A parameter was
- malformed
-
-
-
-
- Table 5-2 Routine Errors
-
- Name Value in Meaning
- Field
-
- GSS_S_BAD_MECH 1 An unsupported mechanism was
- requested
- GSS_S_BAD_NAME 2 An invalid name was supplied
- GSS_S_BAD_NAMETYPE 3 A supplied name was of an
- unsupported type
- GSS_S_BAD_BINDINGS 4 Incorrect channel bindings
- were supplied
- GSS_S_BAD_STATUS 5 An invalid status code was
- supplied
- GSS_S_BAD_SIG 6 A token had an invalid
- GSS_S_BAD_MIC MIC
- GSS_S_NO_CRED 7 No credentials were supplied,
- or the credentials were
- unavailable or inaccessible.
- GSS_S_NO_CONTEXT 8 No context has been
- established
- GSS_S_DEFECTIVE_TOKEN 9 A token was invalid
- GSS_S_DEFECTIVE_CREDENTIAL 10 A credential was invalid
- GSS_S_CREDENTIALS_EXPIRED 11 The referenced credentials
- have expired
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 12]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_CONTEXT_EXPIRED 12 The context has expired
- GSS_S_FAILURE 13 Miscellaneous failure
- (see text)
- GSS_S_BAD_QOP 14 The quality-of-protection
- requested could not be
- provide
- GSS_S_UNAUTHORIZED 15 The operation is forbidden by
- local security policy
- GSS_S_UNAVAILABLE 16 The operation or option is not
- available
- GSS_S_DUPLICATE_ELEMENT 17 The requested credential element
- already exists
- GSS_S_NAME_NOT_MN 18 The provided name was not a
- mechanism name.
-
-
-
-
-
- Table 5-3 Supplementary Status Bits
-
- Name Bit Number Meaning
- GSS_S_CONTINUE_NEEDED 0 (LSB) The routine must be called
- again to complete its function.
- See routine documentation for
- detailed description.
- GSS_S_DUPLICATE_TOKEN 1 The token was a duplicate of
- an earlier token
- GSS_S_OLD_TOKEN 2 The token's validity period
- has expired
- GSS_S_UNSEQ_TOKEN 3 A later token has already been
- processed
- GSS_S_GAP_TOKEN 4 An expected per-message token
- was not received
-
-
- The routine documentation also uses the name GSS_S_COMPLETE, which is a
- zero value, to indicate an absence of any API errors or supplementary
- information bits.
-
- All GSS_S_xxx symbols equate to complete OM_uint32 status codes, rather
- than to bitfield values. For example, the actual value of the symbol
- GSS_S_BAD_NAMETYPE (value 3 in the routine error field) is 3 << 16.
-
- The macros GSS_CALLING_ERROR(), GSS_ROUTINE_ERROR() and
- GSS_SUPPLEMENTARY_INFO() are provided, each of which takes a GSS status
- code and removes all but the relevant field. For example, the value
- obtained by applying GSS_ROUTINE_ERROR to a status code removes the
- calling errors and supplementary info fields, leaving only the routine
- errors field. The values delivered by these macros may be directly
- compared with a GSS_S_xxx symbol of the appropriate type. The macro
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 13]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_ERROR() is also provided, which when applied to a GSS status code
- returns a non-zero value if the status code indicated a calling or
- routine error, and a zero value otherwise. All macros defined by GSS-
- API evaluate their argument(s) exactly once.
-
- A GSS-API implementation may choose to signal calling errors in a
- platform-specific manner instead of, or in addition to the routine
- value; routine errors and supplementary info should be returned via
- routine status values only.
-
- 5.9.2. Mechanism-specific status codes
-
- GSS-API routines return a minor_status parameter, which is used to
- indicate specialized errors from the underlying security mechanism.
- This parameter may contain a single mechanism-specific error, indicated
- by a OM_uint32 value.
-
- The minor_status parameter will always be set by a GSS-API routine, even
- if it returns a calling error or one of the generic API errors indicated
- above as fatal, although most other output parameters may remain unset
- in such cases. However, output parameters that are expected to return
- pointers to storage allocated by a routine must always be set by the
- routine, even in the event of an error, although in such cases the GSS-
- API routine may elect to set the returned parameter value to NULL to
- indicate that no storage was actually allocated. Any length field
- associated with such pointers (as in a gss_buffer_desc structure) should
- also be set to zero in such cases.
-
- The GSS status code GSS_S_FAILURE is used to indicate that the
- underlying mechanism detected an error for which no specific GSS status
- code is defined. The mechanism status code will provide more details
- about the error.
-
- 5.10. Names
-
- A name is used to identify a person or entity. GSS-API authenticates
- the relationship between a name and the entity claiming the name.
-
- Since different authentication mechanisms may employ different
- namespaces for identifying their principals, GSSAPI's naming support is
- necessarily complex in multi-mechanism environments (or even in some
- single-mechanism environments where the underlying mechanism supports
- multiple namespaces).
-
- Two distinct representations are defined for names:
-
- (a) An internal form. This is the GSSAPI "native" format for names,
- represented by the implementation-specific gss_name_t type. It is
- opaque to GSSAPI callers. A single gss_name_t object may contain
- multiple names from different namespaces, but all names should
- refer to the same entity. An example of such an internal name
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 14]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- would be the name returned from a call to the gss_inquire_cred
- routine, when applied to a credential containing credential
- elements for multiple authentication mechanisms employing
- different namespaces. This gss_name_t object will contain a
- distinct name for the entity for each authentication mechanism.
-
- For GSSAPI implementations supporting multiple namespaces, objects
- of type gss_name_t must contain sufficient information to
- determine the namespace to which each primitive name belongs.
-
- (b) Mechanism-specific contiguous octet-string forms. A format
- capable of containing a single name (from a single namespace).
- Contiguous string names are always accompanied by an object
- identifier specifying the namespace to which the name belongs, and
- their format is dependent on the authentication mechanism that
- employs the name. Many, but not all, contiguous string names will
- be printable, and may therefore be used by GSSAPI applications for
- communication with their users.
-
- Routines (gss_import_name and gss_display_name) are provided to convert
- names between contiguous string representations and the internal
- gss_name_t type. gss_import_name may support multiple syntaxes for each
- supported namespace, allowing users the freedom to choose a preferred
- name representation. gss_display_name should use an implementation-
- chosen printable syntax for each supported name-type.
-
- If an application calls gss_display_name(), passing the internal name
- resulting from a call to gss_import_name(), there is no guarantee the
- the resulting contiguous string name will be the same as the original
- imported string name. Nor do name-space identifiers necessarily survive
- unchanged after a journey through the internal name-form. An example of
- this might be a mechanism that authenticates X.500 names, but provides
- an algorithmic mapping of Internet DNS names into X.500. That
- mechanism's implementation of gss_import_name() might, when presented
- with a DNS name, generate an internal name that contained both the
- original DNS name and the equivalent X.500 name. Alternatively, it might
- only store the X.500 name. In the latter case, gss_display_name() would
- most likely generate a printable X.500 name, rather than the original
- DNS name.
-
- The process of authentication delivers to the context acceptor an
- internal name. Since this name has been authenticated by a single
- mechanism, it contains only a single name (even if the internal name
- presented by the context initiator to gss_init_sec_context had multiple
- components). Such names are termed internal mechanism names, or "MN"s
- and the names emitted by gss_accept_sec_context() are always of this
- type. Since some applications may require MNs without wanting to incur
- the overhead of an authentication operation, a second function,
- gss_canonicalize_name(), is provided to convert a general internal name
- into an MN.
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 15]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Comparison of internal-form names may be accomplished via the
- gss_compare_name() routine, which returns true if the two names being
- compared refer to the same entity. This removes the need for the
- application program to understand the syntaxes of the various printable
- names that a given GSS-API implementation may support. Since GSSAPI
- assumes that all primitive names contained within a given internal name
- refer to the same entity, gss_compare_name() can return true if the two
- names have at least one primitive name in common. If the implementation
- embodies knowledge of equivalence relationships between names taken from
- different namespaces, this knowledge may also allow successful
- comparison of internal names containing no overlapping primitive
- elements.
-
- When used in large access control lists, the overhead of invoking
- gss_import_name() and gss_compare_name() on each name from the ACL may
- be prohibitive. As an alternative way of supporting this case, GSSAPI
- defines a special form of the contiguous string name which may be
- compared directly (e.g. with memcmp()). Contigous names suitable for
- comparison are generated by the gss_export_name() routine, which
- requires an MN as input. Exported names may be re-imported by the
- gss_import_name() routine, and the resulting internal name will also be
- an MN. The gss_OID constant GSS_C_NT_EXPORT_NAME indentifies the
- "export name" type, and the value of this constant is given in Appendix
- A. Structurally, an exported name object consists of a header
- containing an OID identifying the mechanism that authenticated the name,
- and a trailer containing the name itself, where the syntax of the
- trailer is defined by the individual mechanism specification. The
- precise format of an export name is defined in the language-independent
- GSSAPI specification [GSSAPI].
-
- Note that the results obtained by using gss_compare_name() will in
- general be different from those obtained by invoking
- gss_canonicalize_name() and gss_export_name(), and then comparing the
- exported names. The first series of operation determines whether two
- (unauthenticated) names identify the same principal; the second whether
- a particular mechanism would authenticate them as the same principal.
- These two operations will in general give the same results only for MNs.
-
- The gss_name_t datatype should be implemented as a pointer type. To
- allow the compiler to aid the application programmer by performing
- type-checking, the use of (void *) is discouraged. A pointer to an
- implementation-defined type is the preferred choice.
-
- Storage is allocated by routines that return gss_name_t values. A
- procedure, gss_release_name, is provided to free storage associated with
- an internal-form name.
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 16]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 5.11. Channel Bindings
-
- GSS-API supports the use of user-specified tags to identify a given
- context to the peer application. These tags are intended to be used to
- identify the particular communications channel that carries the context.
- Channel bindings are communicated to the GSS-API using the following
- structure:
-
- typedef struct gss_channel_bindings_struct {
- OM_uint32 initiator_addrtype;
- gss_buffer_desc initiator_address;
- OM_uint32 acceptor_addrtype;
- gss_buffer_desc acceptor_address;
- gss_buffer_desc application_data;
- } *gss_channel_bindings_t;
-
- The initiator_addrtype and acceptor_addrtype fields denote the type of
- addresses contained in the initiator_address and acceptor_address
- buffers. The address type should be one of the following:
-
- GSS_C_AF_UNSPEC Unspecified address type
- GSS_C_AF_LOCAL Host-local address type
- GSS_C_AF_INET Internet address type (e.g. IP)
- GSS_C_AF_IMPLINK ARPAnet IMP address type
- GSS_C_AF_PUP pup protocols (eg BSP) address type
- GSS_C_AF_CHAOS MIT CHAOS protocol address type
- GSS_C_AF_NS XEROX NS address type
- GSS_C_AF_NBS nbs address type
- GSS_C_AF_ECMA ECMA address type
- GSS_C_AF_DATAKIT datakit protocols address type
- GSS_C_AF_CCITT CCITT protocols
- GSS_C_AF_SNA IBM SNA address type
- GSS_C_AF_DECnet DECnet address type
- GSS_C_AF_DLI Direct data link interface address type
- GSS_C_AF_LAT LAT address type
- GSS_C_AF_HYLINK NSC Hyperchannel address type
- GSS_C_AF_APPLETALK AppleTalk address type
- GSS_C_AF_BSC BISYNC 2780/3780 address type
- GSS_C_AF_DSS Distributed system services address type
- GSS_C_AF_OSI OSI TP4 address type
- GSS_C_AF_X25 X25
- GSS_C_AF_NULLADDR No address specified
-
- Note that these symbols name address families rather than specific
- addressing formats. For address families that contain several
- alternative address forms, the initiator_address and acceptor_address
- fields must contain sufficient information to determine which address
- form is used. When not otherwise specified, addresses should be
- specified in network byte-order (that is, native byte-ordering for the
- address family).
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 17]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Conceptually, the GSS-API concatenates the initiator_addrtype,
- initiator_address, acceptor_addrtype, acceptor_address and
- application_data to form an octet string. The mechanism calculates a
- MIC over this octet string, and binds the MIC to the context
- establishment token emitted by gss_init_sec_context. The same bindings
- are presented by the context acceptor to gss_accept_sec_context, and a
- MIC is calculated in the same way. The calculated MIC is compared with
- that found in the token, and if the MICs differ, gss_accept_sec_context
- will return a GSS_S_BAD_BINDINGS error, and the context will not be
- established. Some mechanisms may include the actual channel binding
- data in the token (rather than just a MIC); applications should
- therefore not use confidential data as channel-binding components.
- Individual mechanisms may impose additional constraints on addresses and
- address types that may appear in channel bindings. For example, a
- mechanism may verify that the initiator_address field of the channel
- bindings presented to gss_init_sec_context contains the correct network
- address of the host system. Portable applications should therefore
- ensure that they either provide correct information for the address
- fields, or omit addressing information, specifying GSS_C_AF_NULLADDR as
- the address-types.
-
- 5.12. Optional parameters
-
- Various parameters are described as optional. This means that they
- follow a convention whereby a default value may be requested. The
- following conventions are used for omitted parameters. These
- conventions apply only to those parameters that are explicitly
- documented as optional.
-
- 5.12.1. gss_buffer_t types
-
- Specify GSS_C_NO_BUFFER as a value. For an input parameter this
- signifies that default behavior is requested, while for an output
- parameter it indicates that the information that would be returned via
- the parameter is not required by the application.
-
- 5.12.2. Integer types (input)
-
- Individual parameter documentation lists values to be used to indicate
- default actions.
-
- 5.12.3. Integer types (output)
-
- Specify NULL as the value for the pointer.
-
- 5.12.4. Pointer types
-
- Specify NULL as the value.
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 18]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 5.12.5. Object IDs
-
- Specify GSS_C_NO_OID as the value.
-
- 5.12.6. Object ID Sets
-
- Specify GSS_C_NO_OID_SET as the value.
-
- 5.12.7. Channel Bindings
-
- Specify GSS_C_NO_CHANNEL_BINDINGS to indicate that channel bindings are
- not to be used.
-
-
- 6. ADDITIONAL CONTROLS
-
- This section discusses the optional services that a context initiator
- may request of the GSS-API at context establishment. Each of these
- services is requested by setting a flag in the req_flags input parameter
- to gss_init_sec_context.
-
- The optional services currently defined are:
-
- Delegation - The (usually temporary) transfer of rights from initiator
- to acceptor, enabling the acceptor to authenticate itself as an
- agent of the initiator.
-
- Mutual Authentication - In addition to the initiator authenticating its
- identity to the context acceptor, the context acceptor should also
- authenticate itself to the initiator.
-
- Replay detection - In addition to providing message integrity services,
- gss_get_mic and gss_wrap should include message numbering
- information to enable gss_verify_mic and gss_unwrap to detect if a
- message has been duplicated.
-
- Out-of-sequence detection - In addition to providing message integrity
- services, gss_get_mic and gss_wrap should include message
- sequencing information to enable gss_verify_mic and gss_unwrap to
- detect if a message has been received out of sequence.
-
- Anonymous authentication - The establishment of the security context
- should not reveal the initiator's identity to the context
- acceptor.
-
- Any currently undefined bits within such flag arguments should be
- ignored by GSS-API implementations when presented by an application, and
- should be set to zero when returned to the application by the GSS-API
- implementation.
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 19]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Some mechanisms may not support all optional services, and some
- mechanisms may only support some services in conjunction with others.
- Both gss_init_sec_context and gss_accept_sec_context inform the
- applications which services will be available from the context when the
- establishment phase is complete, via the ret_flags output parameter. In
- general, if the security mechanism is capable of providing a requested
- service, it should do so, even if additional services must be enabled in
- order to provide the requested service. If the mechanism is incapable
- of providing a requested service, it should proceed without the service,
- leaving the application to abort the context establishment process if it
- considers the requested service to be mandatory.
-
- Some mechanisms may specify that support for some services is optional,
- and that implementors of the mechanism need not provide it. This is
- most commonly true of the confidentiality service, often because of
- legal restrictions on the use of data-encryption, but may apply to any
- of the services. Such mechanisms are required to send at least one
- token from acceptor to initiator during context establishment when the
- initiator indicates a desire to use such a service, so that the
- initiating GSSAPI can correctly indicate whether the service is
- supported by the acceptor's GSSAPI.
-
- 6.1. Delegation
-
- The GSS-API allows delegation to be controlled by the initiating
- application via a boolean parameter to gss_init_sec_context(), the
- routine that establishes a security context. Some mechanisms do not
- support delegation, and for such mechanisms attempts by an application
- to enable delegation are ignored.
-
- The acceptor of a security context for which the initiator enabled
- delegation will receive (via the delegated_cred_handle parameter of
- gss_accept_sec_context) a credential handle that contains the delegated
- identity, and this credential handle may be used to initiate subsequent
- GSSAPI security contexts as an agent or delegate of the initiator. If
- the original initiator's identity is "A" and the delegate's identity is
- "B", then, depending on the underlying mechanism, the identity embodied
- by the delegated credential may be either "A" or "B acting for A".
-
- For many mechanisms that support delegation, a simple boolean does not
- provide enough control. Examples of additional aspects of delegation
- control that a mechanism might provide to an application are duration of
- delegation, network addresses from which delegation is valid, and
- constraints on the tasks that may be performed by a delegate. Such
- controls are presently outside the scope of the GSS-API. GSS-API
- implementations supporting mechanisms offering additional controls
- should provide extension routines that allow these controls to be
- exercised (perhaps by modifying the initiator's GSS-API credential prior
- to its use in establishing a context). However, the simple delegation
- control provided by GSS-API should always be able to over-ride other
- mechanism-specific delegation controls - If the application instructs
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 20]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- gss_init_sec_context() that delegation is not desired, then the
- implementation must not permit delegation to occur. This is an
- exception to the general rule that a mechanism may enable services even
- if they are not requested - delegation may only be provide at the
- explicit request of the application.
-
- 6.2. Mutual authentication
-
- Usually, a context acceptor will require that a context initiator
- authenticate itself so that the acceptor may make an access-control
- decision prior to performing a service for the initiator. In some
- cases, the initiator may also request that the acceptor authenticate
- itself. GSS-API allows the initiating application to request this
- mutual authentication service by setting a flag when calling
- gss_init_sec_context.
-
- The initiating application is informed as to whether or not mutual
- authentication is being requested of the context acceptor. Note that
- some mechanisms may not support mutual authentication, and other
- mechanisms may always perform mutual authentication, whether or not the
- initiating application requests it. In particular, mutual
- authentication my be required by some mechanisms in order to support
- replay or out-of-sequence message detection, and for such mechanisms a
- request for either of these services will automatically enable mutual
- authentication.
-
- 6.3. Replay and out-of-sequence detection
-
- The GSS-API may provide detection of mis-ordered message once a security
- context has been established. Protection may be applied to messages by
- either application, by calling either gss_get_mic or gss_wrap, and
- verified by the peer application by calling gss_verify_mic or
- gss_unwrap.
-
- gss_get_mic calculates a cryptographic checksum of an application
- message, and returns that checksum in a token. The application should
- pass both the token and the message to the peer application, which
- presents them to gss_verify_mic.
-
- gss_wrap calculates a cryptographic checksum of an application message,
- and places both the checksum and the message inside a single token. The
- application should pass the token to the peer application, which
- presents it to gss_unwrap to extract the message and verify the
- checksum.
-
- Either pair of routines may be capable of detecting out-of-sequence
- message delivery, or duplication of messages. Details of such mis-
- ordered messages are indicated through supplementary status bits in the
- major status code returned by gss_verify_mic or gss_unwrap. The
- relevant supplementary bits are:
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 21]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_DUPLICATE_TOKEN - The token is a duplicate of one that has already
- been received and processed. Contexts that do not claim to
- provide replay detection may still set this bit if the duplicate
- message is processed immediately after the original, with no
- intervening messages.
-
- GSS_S_OLD_TOKEN - The token is too old to determine whether or not it is
- a duplicate. Contexts supporting out-of-sequence detection but
- not replay detection should always set this bit if
- GSS_S_UNSEQ_TOKEN is set; contexts that support replay detection
- should only set this bit if the token is so old that it cannot be
- checked for duplication.
-
- GSS_S_UNSEQ_TOKEN - A later token has already been processed.
-
- GSS_S_GAP_TOKEN - An earlier token has not yet been received.
-
- A mechanism need not maintain a list of all tokens that have been
- processed in order to support these status codes. A typical mechanism
- might retain information about only the most recent "N" tokens
- processed, allowing it to distinguish duplicates and missing tokens
- within the most recent "N" messages; the receipt of a token older than
- the most recent "N" would result in a GSS_S_OLD_TOKEN status.
-
- 6.4. Anonymous Authentication
-
- In certain situations, an application may wish to initiate the
- authentication process to authenticate a peer, without revealing its own
- identity. As an example, consider an application providing access to a
- database containing medical information, and offering unrestricted
- access to the service. A client of such a service might wish to
- authenticate the service (in order to establish trust in any information
- retrieved from it), but might not wish the service to be able to obtain
- the client's identity (perhaps due to privacy concerns about the
- specific inquiries, or perhaps simply to avoid being placed on mailing-
- lists).
-
- In normal use of the GSS-API, the initiator's identity is made available
- to the acceptor as a result of the context establishment process.
- However, context initiators may request that their identity not be
- revealed to the context acceptor. Many mechanisms do not support
- anonymous authentication, and for such mechanisms the request will not
- be honored. An authentication token will be still be generated, but the
- application is always informed if a requested service is unavailable,
- and has the option to abort context establishment if anonymity is valued
- above the other security services that would require a context to be
- established.
-
- In addition to informing the application that a context is established
- anonymously (via the ret_flags outputs from gss_init_sec_context and
- gss_accept_sec_context), the optional src_name output from
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 22]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- gss_accept_sec_context and gss_inquire_context will, for such contexts,
- return a reserved internal-form name, defined by the implementation.
- When presented to gss_display_name, this reserved internal-form name
- will result in a printable name that is syntactically distinguishable
- from any valid principal name supported by the implementation,
- associated with a name-type object identifier with the value
- GSS_C_NT_ANONYMOUS, whose value us given in Appendix A. The printable
- form of an anonymous name should be chosen such that it implies
- anonymity, since this name may appear in, for example, audit logs. For
- example, the string "<anonymous>" might be a good choice, if no valid
- printable names supported by the implementation can begin with "<" and
- end with ">".
-
- 6.5. Confidentiality
-
- If a context supports the confidentiality service, gss_wrap may be used
- to encrypt application messages. Messages are selectively encrypted,
- under the control of the conf_req_flag input parameter to gss_wrap.
-
- 6.6. Inter-process context transfer
-
- GSSAPI V2 provides routines (gss_export_sec_context and
- gss_import_sec_context) which allow a security context to be transferred
- between processes on a single machine. The most common use for such a
- feature is a client-server design where the server is implemented as a
- single process that accepts incoming security contexts, which then
- launches child processes to deal with the data on these contexts. In
- such a design, the child processes must have access to the security
- context data structure created within the parent by its call to
- gss_accept_sec_context so that they can use per-message protection
- services and delete the security context when the communication session
- ends.
-
- Since the security context data structure is expected to contain
- sequencing information, it is impractical in general to share a context
- between processes. Thus GSSAPI provides a call (gss_export_sec_context)
- that the process which currently owns the context can call to declare
- that it has no intention to use the context subsequently, and to create
- an inter-process token containing information needed by the adopting
- process to successfully import the context. After successful completion
- of this call, the original security context is made inaccessible to the
- calling process by GSSAPI, and any context handles referring to this
- context are no longer valid. The originating process transfers the
- inter-process token to the adopting process, which passes it to
- gss_import_sec_context, and a fresh gss_ctx_id_t is created such that it
- is functionally identical to the original context.
-
- The inter-process token may contain sensitive data from the original
- security context (including cryptographic keys). Applications using
- inter-process tokens to transfer security contexts must take appropriate
- steps to protect these tokens in transit.
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 23]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Implementations are not required to support the inter-process transfer
- of security contexts. The ability to transfer a security context is
- indicated when the context is created, by gss_init_sec_context or
- gss_accept_sec_context setting the GSS_C_TRANS_FLAG bit in their
- ret_flags parameter.
-
-
- 6.7. The use of incomplete contexts
-
- Some mechanisms may allow the per-message services to be used before the
- context establishment process is complete. For example, a mechanism may
- include sufficient information in its initial context-level token for
- the context acceptor to immediately decode messages protected with
- gss_wrap or gss_get_mic. For such a mechanism, the initiating
- application need not wait until subsequent context-level tokens have
- been sent and received before invoking the per-message protection
- services.
-
- The ability of a context to provide per-message services in advance of
- complete context establishment is indicated by the setting of the
- GSS_C_PROT_READY_FLAG bit in the ret_flags parameter from
- gss_init_sec_context and gss_accept_sec_context. Applications wishing
- to use per-message protection services on partially-established contexts
- should check this flag before attempting to invoke gss_wrap or
- gss_get_mic.
-
-
-
- 7. GSS-API routine descriptions
-
- In addition to the explicit major status codes documented here, the code
- GSS_S_FAILURE may be returned by any routine, indicating an
- implementation-specific or mechanism-specific error condition, further
- details of which are reported via the minor_status parameter.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 24]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 7.1. gss_accept_sec_context
-
- OM_uint32 gss_accept_sec_context (
- OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- const gss_cred_id_t acceptor_cred_handle,
- const gss_buffer_t input_token_buffer,
- const gss_channel_bindings_t
- input_chan_bindings,
- const gss_name_t * src_name,
- gss_OID * mech_type,
- gss_buffer_t output_token,
- OM_uint32 * ret_flags,
- OM_uint32 * time_rec,
- gss_cred_id_t * delegated_cred_handle)
-
- Purpose:
-
- Allows a remotely initiated security context between the application and
- a remote peer to be established. The routine may return a output_token
- which should be transferred to the peer application, where the peer
- application will present it to gss_init_sec_context. If no token need
- be sent, gss_accept_sec_context will indicate this by setting the length
- field of the output_token argument to zero. To complete the context
- establishment, one or more reply tokens may be required from the peer
- application; if so, gss_accept_sec_context will return a status flag of
- GSS_S_CONTINUE_NEEDED, in which case it should be called again when the
- reply token is received from the peer application, passing the token to
- gss_accept_sec_context via the input_token parameters.
-
- Portable applications should be constructed to use the token length and
- return status to determine whether a token needs to be sent or waited
- for. Thus a typical portable caller should always invoke
- gss_accept_sec_context within a loop:
-
- gss_ctx_id_t context_hdl = GSS_C_NO_CONTEXT;
- ...
-
- do {
- receive_token_from_peer(input_token);
- maj_stat = gss_accept_sec_context(&min_stat,
- &context_hdl,
- cred_hdl,
- input_token,
- input_bindings,
- &client_name,
- &mech_type,
- output_token,
- &ret_flags,
- &time_rec,
- &deleg_cred);
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 25]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- if (GSS_ERROR(maj_stat)) {
- report_error(maj_stat, min_stat);
- };
- if (output_token->length != 0) {
- send_token_to_peer(output_token);
- gss_release_buffer(&min_stat,
- output_token)
- };
- if (GSS_ERROR(maj_stat)) {
- if (context_hdl != GSS_C_NO_CONTEXT)
- gss_delete_sec_context(&min_stat,
- &context_hdl,
- GSS_C_NO_BUFFER);
- break;
- };
- } while (maj_stat & GSS_S_CONTINUE_NEEDED);
-
-
- Whenever the routine returns a major status that includes the value
- GSS_S_CONTINUE_NEEDED, the context is not fully established and the
- following restrictions apply to the output parameters:
-
- (a) The value returned via the time_rec parameter is undefined
-
- (b) Unless the accompanying ret_flags parameter contains the bit
- GSS_C_PROT_READY_FLAG, indicating that per-message services may be
- applied in advance of a successful completion status, the value
- returned via the mech_type parameter may be undefined until the
- routine returns a major status value of GSS_S_COMPLETE.
-
- (c) The values of the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG,
- GSS_C_REPLAY_FLAG, GSS_C_SEQUENCE_FLAG, GSS_C_CONF_FLAG,
- GSS_C_INTEG_FLAG and GSS_C_ANON_FLAG bits returned via the
- ret_flags parameter should contain the values that the
- implementation expects would be valid if context establishment
- were to succeed.
-
- The values of the GSS_C_PROT_READY_FLAG and GSS_C_TRANS_FLAG bits
- within ret_flags should indicate the actual state at the time
- gss_accept_sec_context returns, whether or not the context is
- fully established.
-
- Although this requires that GSSAPI implementations set the
- GSS_C_PROT_READY_FLAG in the final ret_flags returned to a caller
- (i.e. when accompanied by a GSS_S_COMPLETE status code),
- applications should not rely on this behavior as the flag was not
- defined in Version 1 of the GSSAPI. Instead, applications should
- be prepared to use per-message services after a successful context
- establishment, according to the GSS_C_INTEG_FLAG and
- GSS_C_CONF_FLAG values.
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 26]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- All other bits within the ret_flags argument should be set to
- zero.
-
-
- While the routine returns GSS_S_CONTINUE_NEEDED, the values returned via
- the ret_flags argument indicate the services that the implementation
- expects to be available from the established context.
-
- If the initial call of gss_accept_sec_context() fails, the
- implementation should not create a context object, and should leave the
- value of the context_handle parameter set to GSS_C_NO_CONTEXT to
- indicate this. In the event of a failure on a subsequent call, the
- implementation is permitted to delete the "half-built" security context
- (in which case it should set the context_handle parameter to
- GSS_C_NO_CONTEXT), but the preferred behavior is to leave the security
- context (and the context_handle parameter) untouched for the application
- to delete (using gss_delete_sec_context).
-
- Parameters:
-
- context_handle gss_ctx_id_t, read/modify
- context handle for new context. Supply
- GSS_C_NO_CONTEXT for first call; use value
- returned in subsequent calls. Once
- gss_accept_sec_context() has returned a value
- via this parameter, resources have been assigned
- to the corresponding context, and must be
- freed by the application after use with a call
- to gss_delete_sec_context().
-
-
- acceptor_cred_handle gss_cred_id_t, read
- Credential handle claimed by context acceptor.
- Specify GSS_C_NO_CREDENTIAL to accept the
- context as a default principal. If
- GSS_C_NO_CREDENTIAL is specified, but no
- default acceptor principal is defined,
- GSS_S_NO_CRED will be returned.
-
- input_token_buffer buffer, opaque, read
- token obtained from remote application.
-
- input_chan_bindings channel bindings, read, optional
- Application-specified bindings. Allows
- application to securely bind channel
- identification information to the security
- context. If channel bindings are not
- used, specify GSS_C_NO_CHANNEL_BINDINGS.
-
- src_name gss_name_t, modify, optional
- Authenticated name of context initiator.
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 27]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- After use, this name should be deallocated by
- passing it to gss_release_name(). If not
- required, specify NULL.
-
- mech_type Object ID, modify, optional
- Security mechanism used. The returned
- OID value will be a pointer into static
- storage, and should be treated as read-only
- by the caller (in particular, it does not
- need to be freed). If not required, specify
- NULL.
-
- output_token buffer, opaque, modify
- Token to be passed to peer application. If the
- length field of the returned token buffer is 0,
- then no token need be passed to the peer
- application. If a non-zero length field is
- returned, the associated storage must be freed
- after use by the application with a call to
- gss_release_buffer().
-
- ret_flags bit-mask, modify, optional
- Contains various independent flags, each of
- which indicates that the context supports a
- specific service option. If not needed,
- specify NULL. Symbolic names are
- provided for each flag, and the symbolic names
- corresponding to the required flags
- should be logically-ANDed with the ret_flags
- value to test whether a given option is
- supported by the context. The flags are:
- GSS_C_DELEG_FLAG
- True - Delegated credentials are available
- via the delegated_cred_handle
- parameter
- False - No credentials were delegated
- GSS_C_MUTUAL_FLAG
- True - Remote peer asked for mutual
- authentication
- False - Remote peer did not ask for mutual
- authentication
- GSS_C_REPLAY_FLAG
- True - replay of protected messages
- will be detected
- False - replayed messages will not be
- detected
- GSS_C_SEQUENCE_FLAG
- True - out-of-sequence protected
- messages will be detected
- False - out-of-sequence messages will not
- be detected
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 28]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_C_CONF_FLAG
- True - Confidentiality service may be invoked
- by calling the gss_wrap routine
- False - No confidentiality service (via
- gss_wrap) available. gss_wrap will
- provide message encapsulation,
- data-origin authentication and
- integrity services only.
- GSS_C_INTEG_FLAG
- True - Integrity service may be invoked by
- calling either gss_get_mic or gss_wrap
- routines.
- False - Per-message integrity service
- unavailable.
- GSS_C_ANON_FLAG
- True - The initiator does not wish to
- be authenticated; the src_name
- parameter (if requested) contains
- an anonymous internal name.
- False - The initiator has been
- authenticated normally.
- GSS_C_PROT_READY_FLAG
- True - Protection services (as specified
- by the states of the GSS_C_CONF_FLAG
- and GSS_C_INTEG_FLAG) are available
- if the accompanying major status return
- value is either GSS_S_COMPLETE or
- GSS_S_CONTINUE_NEEDED.
- False - Protection services (as specified
- by the states of the GSS_C_CONF_FLAG
- and GSS_C_INTEG_FLAG) are available
- only if the accompanying major status
- return value is GSS_S_COMPLETE.
- GSS_C_TRANS_FLAG
- True - The resultant security context may
- be transferred to other processes via
- a call to gss_export_sec_context().
- False - The security context is not
- transferrable.
- All other bits should be set to zero.
-
- time_rec Integer, modify, optional
- number of seconds for which the context
- will remain valid. Specify NULL if not required.
-
- delegated_cred_handle
- gss_cred_id_t, modify, optional
- credential handle for credentials received from
- context initiator. Only valid if deleg_flag in
- ret_flags is true, in which case an explicit
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 29]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- credential handle (i.e. not GSS_C_NO_CREDENTIAL)
- will be returned; if deleg_flag is false,
- gss_accept_context() will set this parameter to
- GSS_C_NO_CREDENTIAL. If a credential handle is
- returned, the associated resources must be released
- by the application after use with a call to
- gss_release_cred(). Specify NULL if not required.
-
-
- minor_status Integer, modify
- Mechanism specific status code.
-
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTINUE_NEEDED Indicates that a token from the peer application
- is required to complete the context, and that
- gss_accept_sec_context must be called again with that
- token.
-
- GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed on the
- input_token failed.
-
- GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks performed
- on the credential failed.
-
- GSS_S_NO_CRED The supplied credentials were not valid for context
- acceptance, or the credential handle did not reference
- any credentials.
-
- GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
-
- GSS_S_BAD_BINDINGS The input_token contains different channel bindings
- to those specified via the input_chan_bindings
- parameter.
-
- GSS_S_NO_CONTEXT Indicates that the supplied context handle did not
- refer to a valid context.
-
- GSS_S_BAD_SIG The input_token contains an invalid MIC.
-
- GSS_S_OLD_TOKEN The input_token was too old. This is a fatal error
- during context establishment.
-
- GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate of a
- token already processed. This is a fatal error during
- context establishment.
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 30]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_BAD_MECH The received token specified a mechanism that is not
- supported by the implementation or the provided
- credential.
-
-
-
-
-
-
-
- 7.2. gss_acquire_cred
-
-
- OM_uint32 gss_acquire_cred (
- OM_uint32 * minor_status,
- const gss_name_t desired_name,
- OM_uint32 time_req,
- const gss_OID_set desired_mechs,
- gss_cred_usage_t cred_usage,
- gss_cred_id_t * output_cred_handle,
- gss_OID_set * actual_mechs,
- OM_uint32 * time_rec)
-
- Purpose:
-
- Allows an application to acquire a handle for a pre-existing credential
- by name. GSS-API implementations must impose a local access-control
- policy on callers of this routine to prevent unauthorized callers from
- acquiring credentials to which they are not entitled. This routine is
- not intended to provide a ``login to the network'' function, as such a
- function would involve the creation of new credentials rather than
- merely acquiring a handle to existing credentials. Such functions, if
- required, should be defined in implementation-specific extensions to the
- API.
-
- If desired_name is GSS_C_NO_NAME, the call is interpreted as a request
- for a credential handle that will invoke default behavior when passed to
- gss_init_sec_context() (if cred_usage is GSS_C_INITIATE or GSS_C_BOTH)
- or gss_accept_sec_context() (if cred_usage is GSS_C_ACCEPT or
- GSS_C_BOTH).
-
- This routine is expected to be used primarily by context acceptors,
- since implementations are likely to provide mechanism-specific ways of
- obtaining GSS-API initiator credentials from the system login process.
- Some implementations may therefore not support the acquisition of
- GSS_C_INITIATE or GSS_C_BOTH credentials via gss_acquire_cred for any
- name other than an empty name.
-
- If credential acquisition is time-consuming for a mechanism, the
- mechanism may chooses to delay the actual acquisition until the
- credential is required (e.g. by gss_init_sec_context or
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 31]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- gss_accept_sec_context). Such mechanism-specific implementation
- decisions should be invisible to the calling application; thus a call of
- gss_inquire_cred immediately following the call of gss_acquire_cred must
- return valid credential data, and may therefore incur the overhead of a
- deferred credential acquisition.
-
- Parameters:
-
- desired_name gss_name_t, read
- Name of principal whose credential
- should be acquired
-
- time_req Integer, read, optional
- number of seconds that credentials
- should remain valid. Specify GSS_C_INDEFINITE
- to request that the credentials have the maximum
- permitted lifetime.
-
- desired_mechs Set of Object IDs, read, optional
- set of underlying security mechanisms that
- may be used. GSS_C_NO_OID_SET may be used
- to obtain an implementation-specific default.
-
- cred_usage gss_cred_usage_t, read
- GSS_C_BOTH - Credentials may be used
- either to initiate or accept
- security contexts.
- GSS_C_INITIATE - Credentials will only be
- used to initiate security
- contexts.
- GSS_C_ACCEPT - Credentials will only be used to
- accept security contexts.
-
- output_cred_handle gss_cred_id_t, modify
- The returned credential handle. Resources
- associated with this credential handle must
- be released by the application after use
- with a call to gss_release_cred().
-
- actual_mechs Set of Object IDs, modify, optional
- The set of mechanisms for which the
- credential is valid. Storage associated
- with the returned OID-set must be released by
- the application after use with a call to
- gss_release_oid_set(). Specify NULL if not
- required.
-
- time_rec Integer, modify, optional
- Actual number of seconds for which the
- returned credentials will remain valid. If the
- implementation does not support expiration of
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 32]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- credentials, the value GSS_C_INDEFINITE will
- be returned. Specify NULL if not required
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_MECH Unavailable mechanism requested
-
- GSS_S_BAD_NAMETYPE Type contained within desired_name parameter is not
- supported
-
- GSS_S_BAD_NAME Value supplied for desired_name parameter is ill-
- formed.
-
- GSS_S_CREDENTIALS_EXPIRED The credentials could not be acquired because
- they have expired.
-
- GSS_S_NO_CRED No credentials were found for the specified name.
-
-
-
-
-
-
-
- 7.3. gss_add_cred
-
-
- OM_uint32 gss_add_cred (
- OM_uint32 * minor_status,
- const gss_cred_id_t input_cred_handle,
- const gss_name_t desired_name,
- const gss_OID desired_mech,
- gss_cred_usage_t cred_usage,
- OM_uint32 initiator_time_req,
- OM_uint32 acceptor_time_req,
- gss_cred_id_t * output_cred_handle,
- gss_OID_set * actual_mechs,
- OM_uint32 * initiator_time_rec,
- OM_uint32 * acceptor_time_rec)
-
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 33]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Purpose:
-
- Adds a credential-element to a credential. The credential-element is
- identified by the name of the principal to which it refers. GSSAPI
- implementations must impose a local access-control policy on callers of
- this routine to prevent unauthorized callers from acquiring credential-
- elements to which they are not entitled. This routine is not intended to
- provide a ``login to the network'' function, as such a function would
- involve the creation of new mechanism-specific authentication data,
- rather than merely acquiring a GSSAPI handle to existing data. Such
- functions, if required, should be defined in implementation-specific
- extensions to the API.
-
- This routine is expected to be used primarily by context acceptors,
- since implementations are likely to provide mechanism-specific ways of
- obtaining GSS-API initiator credentials from the system login process.
- Some implementations may therefore not support the acquisition of
- GSS_C_INITIATE or GSS_C_BOTH credentials via gss_acquire_cred.
-
- If credential acquisition is time-consuming for a mechanism, the
- mechanism may chooses to delay the actual acquisition until the
- credential is required (e.g. by gss_init_sec_context or
- gss_accept_sec_context). Such mechanism-specific implementation
- decisions should be invisible to the calling application; thus a call of
- gss_inquire_cred immediately following the call of gss_acquire_cred must
- return valid credential data, and may therefore incur the overhead of a
- deferred credential acquisition.
-
- This routine can be used to either create a new credential containing
- all credential-elements of the original in addition to the newly-acquire
- credential-element, or to add the new credential-element to an existing
- credential. If NULL is specified for the output_cred_handle parameter
- argument, the new credential-element will be added to the credential
- identified by input_cred_handle; if a valid pointer is specified for the
- output_cred_handle parameter, a new credential and handle will be
- created.
-
- If GSS_C_NO_CREDENTIAL is specified as the input_cred_handle, the
- gss_add_cred will create its output_cred_handle based on default
- behavior. That is, the call will have the same effect as if the
- application had first made a call to gss_acquire_cred(), specifying the
- same usage and passing GSS_C_NO_NAME as the desired_name parameter to
- obtain an explicit credential handle embodying default behavior, passed
- this credential handle to gss_add_cred(), and finally called
- gss_release_cred() on the first credential handle.
-
- If GSS_C_NO_CREDENTIAL is specified as the input_cred_handle parameter,
- a non-NULL output_cred_handle must be supplied.
-
- Parameters:
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 34]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- input_cred_handle gss_cred_id_t, read, optional
- The credential to which a credential-element
- will be added. If GSS_C_NO_CREDENTIAL is
- specified, the routine will create the new
- credential based on default behavior (see
- description above). Note that, while the
- credential-handle is not modified by
- gss_add_cred(), the underlying credential
- will be modified if output_credential_handle
- is NULL.
-
- desired_name gss_name_t, read.
- Name of principal whose credential
- should be acquired.
-
- desired_mech Object ID, read
- Underlying security mechanism with which the
- credential may be used.
-
- cred_usage gss_cred_usage_t, read
- GSS_C_BOTH - Credential may be used
- either to initiate or accept
- security contexts.
- GSS_C_INITIATE - Credential will only be
- used to initiate security
- contexts.
- GSS_C_ACCEPT - Credential will only be used to
- accept security contexts.
-
- initiator_time_req Integer, read, optional
- number of seconds that the credential
- should remain valid for initiating security
- contexts. This argument is ignored if the
- created credentials are of type GSS_C_ACCEPT.
- Specify GSS_C_INDEFINITE to request that the
- credentials have the maximum permitted initiator
- lifetime.
-
- acceptor_time_req Integer, read, optional
- number of seconds that the credential
- should remain valid for accepting security
- contexts. This argument is ignored if the
- created credentials are of type GSS_C_INITIATE.
- Specify GSS_C_INDEFINITE to request that the
- credentials have the maximum permitted initiator
- lifetime.
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 35]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- output_cred_handle gss_cred_id_t, modify, optional
- The returned credential handle, containing
- the new credential-element and all the
- credential-elements from input_cred_handle.
- If a valid pointer to a gss_cred_id_t is
- supplied for this parameter, gss_add_cred
- creates a new credential handle containing all
- credential-elements from the input_cred_handle
- and the newly acquired credential-element; if
- NULL is specified for this parameter, the newly
- acquired credential-element will be added
- to the credential identified by input_cred_handle.
- The resources associated with any credential
- handle returned via this parameter must be
- released by the application after use with a
- call to gss_release_cred().
-
- actual_mechs Set of Object IDs, modify, optional
- The complete set of mechanisms for which
- the new credential is valid. Storage for
- the returned OID-set must be freed by the
- application after use with a call to
- gss_release_oid_set(). Specify NULL if
- not required.
-
- initiator_time_rec Integer, modify, optional
- Actual number of seconds for which the
- returned credentials will remain valid for
- initiating contexts using the specified
- mechanism. If the implementation or mechanism
- does not support expiration of credentials, the
- value GSS_C_INDEFINITE will be returned. Specify
- NULL if not required
-
- acceptor_time_rec Integer, modify, optional
- Actual number of seconds for which the
- returned credentials will remain valid for
- accepting security contexts using the specified
- mechanism. If the implementation or mechanism
- does not support expiration of credentials, the
- value GSS_C_INDEFINITE will be returned. Specify
- NULL if not required
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_MECH Unavailable mechanism requested
-
- GSS_S_BAD_NAMETYPE Type contained within desired_name parameter is not
- supported
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 36]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_BAD_NAME Value supplied for desired_name parameter is ill-
- formed.
-
- GSS_S_DUPLICATE_ELEMENT The credential already contains an element for
- the requested mechanism with overlapping usage and
- validity period.
-
- GSS_S_CREDENTIALS_EXPIRED The required credentials could not be added
- because they have expired.
-
- GSS_S_NO_CRED No credentials were found for the specified name.
-
-
-
-
-
-
-
- 7.4. gss_add_oid_set_member
-
- OM_uint32 gss_add_oid_set_member (
- OM_uint32 * minor_status,
- const gss_OID member_oid,
- gss_OID_set * oid_set)
-
- Purpose:
-
- Add an Object Identifier to an Object Identifier set. This routine is
- intended for use in conjunction with gss_create_empty_oid_set when
- constructing a set of mechanism OIDs for input to gss_acquire_cred.
-
- The oid_set parameter must refer to an OID-set that was created by
- GSSAPI (e.g. a set returned by gss_create_empty_oid_set()). GSSAPI
- creates a copy of the member_oid and inserts this copy into the set,
- expanding the storage allocated to the OID-set's elements array if
- necessary. The routine may add the new member OID anywhere within the
- elements array, and implementations should verify that the new
- member_oid is not already contained within the elements array.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- member_oid Object ID, read
- The object identifier to copied into
- the set.
-
- oid_set Set of Object ID, modify
- The set in which the object identifier
- should be inserted.
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 37]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-
-
-
-
-
-
- 7.5. gss_canonicalize_name
-
- OM_uint32 gss_canonicalize_name (
- OM_uint32 * minor_status,
- const gss_name_t input_name,
- const gss_OID mech_type,
- gss_name_t * output_name)
-
- Purpose:
-
- Generate a canonical mechanism name (MN) from an arbitrary internal
- name. The mechanism name is the name that would be returned to a
- context acceptor on successful authentication of a context where the
- initiator used the input_name in a successful call to gss_acquire_cred,
- specifying an OID set containing <mech_type> as its only member,
- followed by a call to gss_init_sec_context, specifying <mech_type> as
- the authentication mechanism.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- input_name gss_name_t, read
- The name for which a canonical form is
- desired
-
- mech_type Object ID, read
- The authentication mechanism for which the
- canonical form of the name is desired. The
- desired mechanism must be specified explicitly;
- no default is provided.
-
- output_name gss_name_t, modify
- The resultant canonical name. Storage
- associated with this name must be freed by
- the application after use with a call to
- gss_release_name().
-
- Function value: GSS status code
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 38]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_COMPLETE Successful completion.
-
- GSS_S_BAD_MECH The identified mechanism is not supported.
-
- GSS_S_BAD_NAMETYPE The provided internal name contains no elements that
- could be processed by the sepcified mechanism.
-
- GSS_S_BAD_NAME The provided internal name was ill-formed.
-
-
-
-
-
-
-
- 7.6. gss_compare_name
-
- OM_uint32 gss_compare_name (
- OM_uint32 * minor_status,
- const gss_name_t name1,
- const gss_name_t name2,
- int * name_equal)
-
- Purpose:
-
- Allows an application to compare two internal-form names to determine
- whether they refer to the same entity.
-
- If either name presented to gss_compare_name denotes an anonymous
- principal, the routines should indicate that the two names do not refer
- to the same identity.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- name1 gss_name_t, read
- internal-form name
-
- name2 gss_name_t, read
- internal-form name
-
- name_equal boolean, modify
- non-zero - names refer to same entity
- zero - names refer to different entities
- (strictly, the names are not known
- to refer to the same identity).
-
- Function value: GSS status code
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 39]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAMETYPE The two names were of incomparable types.
-
- GSS_S_BAD_NAME One or both of name1 or name2 was ill-formed
-
-
-
-
-
-
-
- 7.7. gss_context_time
-
- OM_uint32 gss_context_time (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- OM_uint32 * time_rec)
-
- Purpose:
-
- Determines the number of seconds for which the specified context will
- remain valid.
-
- Parameters:
-
- minor_status Integer, modify
- Implementation specific status code.
-
- context_handle gss_ctx_id_t, read
- Identifies the context to be interrogated.
-
- time_rec Integer, modify
- Number of seconds that the context will remain
- valid. If the context has already expired,
- zero will be returned.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a valid
- context
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 40]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 7.8. gss_create_empty_oid_set
-
- OM_uint32 gss_create_empty_oid_set (
- OM_uint32 * minor_status,
- gss_OID_set * oid_set)
-
- Purpose:
-
- Create an object-identifier set containing no object identifiers, to
- which members may be subsequently added using the
- gss_add_oid_set_member() routine. These routines are intended to be
- used to construct sets of mechanism object identifiers, for input to
- gss_acquire_cred.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- oid_set Set of Object IDs, modify
- The empty object identifier set.
- The routine will allocate the
- gss_OID_set_desc object, which the
- application must free after use with
- a call to gss_release_oid_set().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-
-
-
-
-
-
- 7.9. gss_delete_sec_context
-
- OM_uint32 gss_delete_sec_context (
- OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- gss_buffer_t output_token)
-
- Purpose:
-
- Delete a security context. gss_delete_sec_context will delete the local
- data structures associated with the specified security context, and may
- generate an output_token, which when passed to the peer
- gss_process_context_token will instruct it to do likewise. If no token
- is required by the mechanism, the GSS-API should set the length field of
- the output_token (if provided) to zero. No further security services
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 41]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- may be obtained using the context specified by context_handle.
-
- In addition to deleting established security contexts,
- gss_delete_sec_context must also be able to delete "half-built" security
- contexts resulting from an incomplete sequence of
- gss_init_sec_context()/gss_accept_sec_context() calls.
-
- The output_token parameter is retained for compatibility with version 1
- of the GSS-API. It is recommended that both peer applications invoke
- gss_delete_sec_context passing the value GSS_C_NO_BUFFER for the
- output_token parameter, indicating that no token is required, and that
- gss_delete_sec_context should simply delete local context data
- structures. If the application does pass a valid buffer to
- gss_delete_sec_context, mechanisms are encouraged to return a zero-
- length token, indicating that no peer action is necessary, and that no
- token should be transferred by the application.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- context_handle gss_ctx_id_t, modify
- context handle identifying context to delete.
- After deleting the context, the GSSAPI will set
- this context handle to GSS_C_NO_CONTEXT.
-
- output_token buffer, opaque, modify, optional
- token to be sent to remote application to
- instruct it to also delete the context. It
- is recommended that applications specify
- GSS_C_NO_BUFFER for this parameter, requesting
- local deletion only. If a buffer parameter is
- provided by the application, the mechanism may
- return a token in it; mechanisms that implement
- only local deletion should set the length field of
- this token to zero to indicate to the application
- that no token is to be sent to the peer.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_NO_CONTEXT No valid context was supplied
-
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 42]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 7.10. gss_display_name
-
- OM_uint32 gss_display_name (
- OM_uint32 * minor_status,
- const gss_name_t input_name,
- gss_buffer_t output_name_buffer,
- gss_OID * output_name_type)
-
- Purpose:
-
- Allows an application to obtain a textual representation of an opaque
- internal-form name for display purposes. The syntax of a printable
- name is defined by the GSS-API implementation.
-
- If input_name denotes an anonymous principal, the implementation should
- return the gss_OID value GSS_C_NT_ANONYMOUS as the output_name_type, and
- a textual name that is syntactically distinct from all valid supported
- printable names in output_name_buffer.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- input_name gss_name_t, read
- name to be displayed
-
- output_name_buffer buffer, character-string, modify
- buffer to receive textual name string.
- The application must free storage associated
- with this name after use with a call to
- gss_release_buffer().
-
- output_name_type Object ID, modify, optional
- The type of the returned name. The returned
- gss_OID will be a pointer into static storage,
- and should be treated as read-only by the caller
- (in particular, it does not need to be freed).
- Specify NULL if not required.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAME input_name was ill-formed
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 43]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 7.11. gss_display_status
-
- OM_uint32 gss_display_status (
- OM_uint32 * minor_status,
- OM_uint32 status_value,
- int status_type,
- const gss_OID mech_type,
- OM_uint32 * message_context,
- gss_buffer_t status_string)
-
- Purpose:
-
- Allows an application to obtain a textual representation of a GSS-API
- status code, for display to the user or for logging purposes. Since
- some status values may indicate multiple conditions, applications may
- need to call gss_display_status multiple times, each call generating a
- single text string. The message_context parameter is used by
- gss_acquire_cred to store state information about which error messages
- have already been extracted from a given status_value; message_context
- must be initialized to 0 by the application prior to the first call, and
- gss_display_status will return a non-zero value in this parameter if
- there are further messages to extract. The message_context parameter
- contains all state information required by gss_display_status in order
- to extract further messages from the status_value; even when a non-zero
- value is returned in this parameter, the application is not required to
- call gss_display_status again unless subsequent messages are desired.
- The following code extracts all messages from a given status code and
- prints them to stderr:
-
-
- OM_uint32 message_context;
- OM_uint32 status_code;
- OM_uint32 maj_status;
- OM_uint32 min_status;
- gss_buffer_desc status_string;
-
- ...
-
- message_context = 0;
-
- do {
-
- maj_status = gss_display_status (&min_status,
- status_code,
- GSS_C_GSS_CODE,
- GSS_C_NO_OID,
- &message_context,
- &status_string)
-
- fprintf(stderr,
- "%.*s\n",
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 44]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- status_string.length,
- status_string.value);
-
- gss_release_buffer(&min_status,
- &status_string);
-
- } while (message_context != 0);
-
-
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- status_value Integer, read
- Status value to be converted
-
- status_type Integer, read
- GSS_C_GSS_CODE - status_value is a GSS status
- code
- GSS_C_MECH_CODE - status_value is a mechanism
- status code
-
- mech_type Object ID, read, optional
- Underlying mechanism (used to interpret a
- minor status value) Supply GSS_C_NO_OID to
- obtain the system default.
-
- message_context Integer, read/modify
- Should be initialized to zero by the
- application prior to the first call.
- On return from gss_display_status(),
- a non-zero status_value parameter indicates
- that additional messages may be extracted
- from the status code via subsequent calls
- to gss_display_status(), passing the same
- status_value, status_type, mech_type, and
- message_context parameters.
-
- status_string buffer, character string, modify
- textual interpretation of the status_value.
- Storage associated with this parameter must
- be freed by the application after use with
- a call to gss_release_buffer().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 45]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_BAD_MECH Indicates that translation in accordance with an
- unsupported mechanism type was requested
-
- GSS_S_BAD_STATUS The status value was not recognized, or the status
- type was neither GSS_C_GSS_CODE nor GSS_C_MECH_CODE.
-
-
-
-
-
-
-
- 7.12. gss_duplicate_name
-
- OM_uint32 gss_duplicate_name (
- OM_uint32 * minor_status,
- const gss_name_t src_name,
- gss_name_t * dest_name)
-
- Purpose:
-
- Create an exact duplicate of the existing internal name src_name. The
- new dest_name will be independent of src_name (i.e. src_name and
- dest_name must both be released, and the release of one shall not affect
- the validity of the other).
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- src_name gss_name_t, read
- internal name to be duplicated.
-
- dest_name gss_name_t, modify
- The resultant copy of <src_name>.
- Storage associated with this name must
- be freed by the application after use
- with a call to gss_release_name().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAME The src_name parameter was ill-formed.
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 46]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 7.13. gss_export_name
-
- OM_uint32 gss_export_name (
- OM_uint32 * minor_status,
- const gss_name_t input_name,
- gss_buffer_t exported_name)
-
- Purpose:
-
- To produce a canonical contiguous string representation of a mechanism
- name (MN), suitable for direct comparison (e.g. with memcmp) for use in
- authorization functions (e.g. matching entries in an access-control
- list).
-
- The <input_name> parameter must specify a valid MN (i.e. an internal
- name generated by gss_accept_sec_context or by gss_canonicalize_name).
-
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- input_name gss_name_t, read
- The MN to be exported
-
- exported_name gss_buffer_t, octet-string, modify
- The canonical contiguous string form of
- <input_name>. Storage associated with
- this string must freed by the application
- after use with gss_release_buffer().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_NAME_NOT_MN The provided internal name was not a mechanism name.
-
- GSS_S_BAD_NAME The provide internal name was ill-formed.
-
- GSS_S_BAD_NAMETYPE The internal name was of a type not supported by the
- GSSAPI implementation.
-
-
-
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 47]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 7.14. gss_export_sec_context
-
- OM_uint32 gss_export_sec_context (
- OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- gss_buffer_t interprocess_token)
-
- Purpose:
-
- Provided to support the sharing of work between multiple processes.
- This routine will typically be used by the context-acceptor, in an
- application where a single process receives incoming connection requests
- and accepts security contexts over them, then passes the established
- context to one or more other processes for message exchange.
- gss_export_sec_context() deactivates the security context for the
- calling process and creates an interprocess token which, when passed to
- gss_import_sec_context in another process, will re-activate the context
- in the second process. Only a single instantiation of a given context
- may be active at any one time; a subsequent attempt by a context
- exporter to access the exported security context will fail.
-
- The implementation may constrain the set of processes by which the
- interprocess token may be imported, either as a function of local
- security policy, or as a result of implementation decisions. For
- example, some implementations may constrain contexts to be passed only
- between processes that run under the same account, or which are part of
- the same process group.
-
- The interprocess token may contain security-sensitive information (for
- example cryptographic keys). While mechanisms are encouraged to either
- avoid placing such sensitive information within interprocess tokens, or
- to encrypt the token before returning it to the application, in a
- typical object-library GSSAPI implementation this may not be possible.
- Thus the application must take care to protect the interprocess token,
- and ensure that any process to which the token is transferred is
- trustworthy.
-
- If creation of the interprocess token is succesful, the implementation
- shall deallocate all process-wide resources associated with the security
- context, and set the context_handle to GSS_C_NO_CONTEXT. In the event
- of an error that makes it impossible to complete the export of the
- security context, the implementation must not return an interprocess
- token, and should strive to leave the security context referenced by the
- context_handle parameter untouched. If this is impossible, it is
- permissible for the implementation to delete the security context,
- providing it also sets the context_handle parameter to GSS_C_NO_CONTEXT.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 48]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- context_handle gss_ctx_id_t, modify
- context handle identifying the context to transfer.
-
- interprocess_token buffer, opaque, modify
- token to be transferred to target process.
- Storage associated with this token must be
- freed by the application after use with a
- call to gss_release_buffer().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTEXT_EXPIRED The context has expired
-
- GSS_S_NO_CONTEXT The context was invalid
-
- GSS_S_UNAVAILABLE The operation is not supported.
-
-
-
-
-
-
-
- 7.15. gss_get_mic
-
- OM_uint32 gss_get_mic (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- gss_qop_t qop_req,
- const gss_buffer_t message_buffer,
- gss_buffer_t msg_token)
-
- Purpose:
-
- Generates a cryptographic MIC for the supplied message, and places the
- MIC in a token for transfer to the peer application. The qop_req
- parameter allows a choice between several cryptographic algorithms, if
- supported by the chosen mechanism.
-
- Parameters:
-
- minor_status Integer, modify
- Implementation specific status code.
-
- context_handle gss_ctx_id_t, read
- identifies the context on which the message
- will be sent
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 49]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
- qop_req gss_qop_t, read, optional
- Specifies requested quality of protection.
- Callers are encouraged, on portability grounds,
- to accept the default quality of protection
- offered by the chosen mechanism, which may be
- requested by specifying GSS_C_QOP_DEFAULT for
- this parameter. If an unsupported protection
- strength is requested, gss_get_mic will return a
- major_status of GSS_S_BAD_QOP.
-
- message_buffer buffer, opaque, read
- message to be protected
-
- msg_token buffer, opaque, modify
- buffer to receive token. The application must
- free storage associated with this buffer after
- use with a call to gss_release_buffer().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a valid
- context
-
- GSS_S_BAD_QOP The specified QOP is not supported by the mechanism.
-
-
-
-
-
-
-
- 7.16. gss_import_name
-
- OM_uint32 gss_import_name (
- OM_uint32 * minor_status,
- const gss_buffer_t input_name_buffer,
- const gss_OID input_name_type,
- gss_name_t * output_name)
-
- Purpose:
-
- Convert a contiguous string name to internal form. In general, the
- internal name returned (via the <output_name> parameter) will not be an
- MN; the exception to this is if the <input_name_type> indicates that the
- contiguous string provided via the <input_name_buffer> parameter is of
- type GSS_C_NT_EXPORT_NAME, in which case the returned internal name will
- be an MN for the mechanism that exported the name.
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 50]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- input_name_buffer buffer, octet-string, read
- buffer containing contiguous string name to convert
-
- input_name_type Object ID, read, optional
- Object ID specifying type of printable
- name. Applications may specify either
- GSS_C_NO_OID to use a mechanism-specific
- default printable syntax, or an OID registered
- by the GSS-API implementation to name a
- specific namespace.
-
- output_name gss_name_t, modify
- returned name in internal form. Storage
- associated with this name must be freed
- by the application after use with a call
- to gss_release_name().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAMETYPE The input_name_type was unrecognized
-
- GSS_S_BAD_NAME The input_name parameter could not be interpreted as a
- name of the specified type
-
-
-
-
-
-
-
-
- 7.17. gss_import_sec_context
-
- OM_uint32 gss_import_sec_context (
- OM_uint32 * minor_status,
- const gss_buffer_t interprocess_token,
- gss_ctx_id_t * context_handle)
-
- Purpose:
-
- Allows a process to import a security context established by another
- process. A given interprocess token may be imported only once. See
- gss_export_sec_context.
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 51]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- interprocess_token buffer, opaque, modify
- token received from exporting process
-
- context_handle gss_ctx_id_t, modify
- context handle of newly reactivated context.
- Resources associated with this context handle
- must be released by the application after use
- with a call to gss_delete_sec_context().
-
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion.
-
- GSS_S_NO_CONTEXT The token did not contain a valid context reference.
-
- GSS_S_DEFECTIVE_TOKEN The token was invalid.
-
- GSS_S_UNAVAILABLE The operation is unavailable.
-
- GSS_S_UNAUTHORIZED Local policy prevents the import of this context by
- the current process..
-
-
-
-
-
-
-
- 7.18. gss_indicate_mechs
-
- OM_uint32 gss_indicate_mechs (
- OM_uint32 * minor_status,
- gss_OID_set * mech_set)
-
- Purpose:
-
- Allows an application to determine which underlying security mechanisms
- are available.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 52]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
- mech_set set of Object IDs, modify
- set of implementation-supported mechanisms.
- The returned gss_OID_set value will be a
- dynamically-allocated OID set, that should
- be released by the caller after use with a
- call to gss_release_oid_set().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-
-
-
-
-
-
- 7.19. gss_init_sec_context
-
- OM_uint32 gss_init_sec_context (
- OM_uint32 * minor_status,
- const gss_cred_id_t initiator_cred_handle,
- gss_ctx_id_t * context_handle,
- const gss_name_t target_name,
- const gss_OID mech_type,
- OM_uint32 req_flags,
- OM_uint32 time_req,
- const gss_channel_bindings_t
- input_chan_bindings,
- const gss_buffer_t input_token
- gss_OID * actual_mech_type,
- gss_buffer_t output_token,
- OM_uint32 * ret_flags,
- OM_uint32 * time_rec )
-
- Purpose:
-
- Initiates the establishment of a security context between the
- application and a remote peer. Initially, the input_token parameter
- should be specified either as GSS_C_NO_BUFFER, or as a pointer to a
- gss_buffer_desc object whose length field contains the value zero. The
- routine may return a output_token which should be transferred to the
- peer application, where the peer application will present it to
- gss_accept_sec_context. If no token need be sent, gss_init_sec_context
- will indicate this by setting the length field of the output_token
- argument to zero. To complete the context establishment, one or more
- reply tokens may be required from the peer application; if so,
- gss_init_sec_context will return a status containing the supplementary
- information bit GSS_S_CONTINUE_NEEDED. In this case,
- gss_init_sec_context should be called again when the reply token is
- received from the peer application, passing the reply token to
- gss_init_sec_context via the input_token parameters.
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 53]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Portable applications should be constructed to use the token length and
- return status to determine whether a token needs to be sent or waited
- for. Thus a typical portable caller should always invoke
- gss_init_sec_context within a loop:
-
- int context_established = 0;
- gss_ctx_id_t context_hdl = GSS_C_NO_CONTEXT;
- ...
- input_token->length = 0;
-
- while (!context_established) {
- maj_stat = gss_init_sec_context(&min_stat,
- cred_hdl,
- &context_hdl,
- target_name,
- desired_mech,
- desired_services,
- desired_time,
- input_bindings,
- input_token,
- &actual_mech,
- output_token,
- &actual_services,
- &actual_time);
- if (GSS_ERROR(maj_stat)) {
- report_error(maj_stat, min_stat);
- };
- if (output_token->length != 0) {
- send_token_to_peer(output_token);
- gss_release_buffer(&min_stat,
- output_token)
- };
- if (GSS_ERROR(maj_stat)) {
- if (context_hdl != GSS_C_NO_CONTEXT)
- gss_delete_sec_context(&min_stat,
- &context_hdl,
- GSS_C_NO_BUFFER);
- break;
- };
- if (maj_stat & GSS_S_CONTINUE_NEEDED) {
- receive_token_from_peer(input_token);
- } else {
- context_established = 1;
- };
- };
-
- Whenever the routine returns a major status that includes the value
- GSS_S_CONTINUE_NEEDED, the context is not fully established and the
- following restrictions apply to the output parameters:
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 54]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- (a) The value returned via the time_rec parameter is undefined
-
- (b) Unless the accompanying ret_flags parameter contains the bit
- GSS_C_PROT_READY_FLAG, indicating that per-message services may be
- applied in advance of a successful completion status, the value
- returned via the actual_mech_type parameter is undefined until the
- routine returns a major status value of GSS_S_COMPLETE.
-
- (c) The values of the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG,
- GSS_C_REPLAY_FLAG, GSS_C_SEQUENCE_FLAG, GSS_C_CONF_FLAG,
- GSS_C_INTEG_FLAG and GSS_C_ANON_FLAG bits returned via the
- ret_flags parameter should contain the values that the
- implementation expects would be valid if context establishment
- were to succeed. In particular, if the application has requested
- a service such as delegation or anonymous authentication via the
- req_flags argument, and such a service is unavailable from the
- underlying mechanism, gss_init_sec_context should generate a token
- that will not provide the service, and indicate via the ret_flags
- argument that the service will not be supported. The application
- may choose to abort the context establishment by calling
- gss_delete_sec_context (if it cannot continue in the absence of
- the service), or it may choose to transmit the token and continue
- context establishment (if the service was merely desired but not
- mandatory).
-
- The values of the GSS_C_PROT_READY_FLAG and GSS_C_TRANS_FLAG bits
- within ret_flags should indicate the actual state at the time
- gss_init_sec_context returns, whether or not the context is fully
- established.
-
- Although this requires that GSSAPI implementations set the
- GSS_C_PROT_READY_FLAG in the final ret_flags returned to a caller
- (i.e. when accompanied by a GSS_S_COMPLETE status code),
- applications should not rely on this behavior as the flag was not
- defined in Version 1 of the GSSAPI. Instead, applications should
- be prepared to use per-message services after a successful context
- establishment, according to the GSS_C_INTEG_FLAG and
- GSS_C_CONF_FLAG values.
-
- All other bits within the ret_flags argument should be set to
- zero.
-
- If the initial call of gss_init_sec_context() fails, the implementation
- should not create a context object, and should leave the value of the
- context_handle parameter set to GSS_C_NO_CONTEXT to indicate this. In
- the event of a failure on a subsequent call, the implementation is
- permitted to delete the "half-built" security context (in which case it
- should set the context_handle parameter to GSS_C_NO_CONTEXT), but the
- preferred behavior is to leave the security context untouched for the
- application to delete (using gss_delete_sec_context).
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 55]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- initiator_cred_handle gss_cred_id_t, read, optional
- handle for credentials claimed. Supply
- GSS_C_NO_CREDENTIAL to act as a default
- initiator principal. If no default
- initiator is defined, the function will
- return GSS_S_NO_CRED.
-
- context_handle gss_ctx_id_t, read/modify
- context handle for new context. Supply
- GSS_C_NO_CONTEXT for first call; use value
- returned by first call in continuation calls.
- Resources associated with this context-handle
- must be released by the application after use
- with a call to gee_delete_sec_context().
-
- target_name gss_name_t, read
- Name of target
-
- mech_type OID, read, optional
- Object ID of desired mechanism. Supply
- GSS_C_NO_OID to obtain an implementation
- specific default
-
- req_flags bit-mask, read
- Contains various independent flags, each of
- which requests that the context support a
- specific service option. Symbolic
- names are provided for each flag, and the
- symbolic names corresponding to the required
- flags should be logically-ORed
- together to form the bit-mask value. The
- flags are:
-
- GSS_C_DELEG_FLAG
- True - Delegate credentials to remote peer
- False - Don't delegate
- GSS_C_MUTUAL_FLAG
- True - Request that remote peer
- authenticate itself
- False - Authenticate self to remote peer
- only
- GSS_C_REPLAY_FLAG
- True - Enable replay detection for
- messages protected with gss_wrap
- or gss_get_mic
- False - Don't attempt to detect
- replayed messages
-
-
- Wray Document Expiration: 1 September 1997 [Page 56]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_C_SEQUENCE_FLAG
- True - Enable detection of out-of-sequence
- protected messages
- False - Don't attempt to detect
- out-of-sequence messages
- GSS_C_ANON_FLAG
- True - Do not reveal the initiator's
- identity to the acceptor.
- False - Authenticate normally.
-
- time_req Integer, read, optional
- Desired number of seconds for which context
- should remain valid. Supply 0 to request a
- default validity period.
-
- input_chan_bindings channel bindings, read, optional
- Application-specified bindings. Allows
- application to securely bind channel
- identification information to the security
- context. Specify GSS_C_NO_CHANNEL_BINDINGS
- if channel bindings are not used.
-
- input_token buffer, opaque, read, optional (see text)
- Token received from peer application.
- Supply GSS_C_NO_BUFFER, or a pointer to
- a buffer containing the value GSS_C_EMPTY_BUFFER
- on initial call.
-
- actual_mech_type OID, modify, optional
- Actual mechanism used. The OID returned via
- this parameter will be a pointer to static
- storage that should be treated as read-only;
- In particular the application should not attempt
- to free it. Specify NULL if not required.
-
- output_token buffer, opaque, modify
- token to be sent to peer application. If
- the length field of the returned buffer is
- zero, no token need be sent to the peer
- application. Storage associated with this
- buffer must be freed by the application
- after use with a call to gss_release_buffer().
-
- ret_flags bit-mask, modify, optional
- Contains various independent flags, each of which
- indicates that the context supports a specific
- service option. Specify NULL if not
- required. Symbolic names are provided
- for each flag, and the symbolic names
- corresponding to the required flags should be
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 57]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- logically-ANDed with the ret_flags value to test
- whether a given option is supported by the
- context. The flags are:
-
- GSS_C_DELEG_FLAG
- True - Credentials were delegated to
- the remote peer
- False - No credentials were delegated
- GSS_C_MUTUAL_FLAG
- True - Remote peer has been asked to
- authenticated itself
- False - Remote peer has not been asked to
- authenticate itself
- GSS_C_REPLAY_FLAG
- True - replay of protected messages
- will be detected
- False - replayed messages will not be
- detected
- GSS_C_SEQUENCE_FLAG
- True - out-of-sequence protected
- messages will be detected
- False - out-of-sequence messages will
- not be detected
- GSS_C_CONF_FLAG
- True - Confidentiality service may be
- invoked by calling gss_wrap routine
- False - No confidentiality service (via
- gss_wrap) available. gss_wrap will
- provide message encapsulation,
- data-origin authentication and
- integrity services only.
- GSS_C_INTEG_FLAG
- True - Integrity service may be invoked by
- calling either gss_get_mic or gss_wrap
- routines.
- False - Per-message integrity service
- unavailable.
- GSS_C_ANON_FLAG
- True - The initiator's identity has not been
- revealed, and will not be revealed if
- any emitted token is passed to the
- acceptor.
- False - The initiator's identity has been or
- will be authenticated normally.
- GSS_C_PROT_READY_FLAG
- True - Protection services (as specified
- by the states of the GSS_C_CONF_FLAG
- and GSS_C_INTEG_FLAG) are available for
- use if the accompanying major status
- return value is either GSS_S_COMPLETE or
- GSS_S_CONTINUE_NEEDED.
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 58]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- False - Protection services (as specified
- by the states of the GSS_C_CONF_FLAG
- and GSS_C_INTEG_FLAG) are available
- only if the accompanying major status
- return value is GSS_S_COMPLETE.
- GSS_C_TRANS_FLAG
- True - The resultant security context may
- be transferred to other processes via
- a call to gss_export_sec_context().
- False - The security context is not
- transferrable.
- All other bits should be set to zero.
-
- time_rec Integer, modify, optional
- number of seconds for which the context
- will remain valid. If the implementation does
- not support context expiration, the value
- GSS_C_INDEFINITE will be returned. Specify
- NULL if not required.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTINUE_NEEDED Indicates that a token from the peer application
- is required to complete the context, and that
- gss_init_sec_context must be called again with that
- token.
-
- GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed on the
- input_token failed
-
- GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks performed
- on the credential failed.
-
- GSS_S_NO_CRED The supplied credentials were not valid for context
- initiation, or the credential handle did not reference
- any credentials.
-
- GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired
-
- GSS_S_BAD_BINDINGS The input_token contains different channel bindings
- to those specified via the input_chan_bindings
- parameter
-
- GSS_S_BAD_SIG The input_token contains an invalid MIC, or a MIC that
- could not be verified
-
- GSS_S_OLD_TOKEN The input_token was too old. This is a fatal error
- during context establishment
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 59]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate of a
- token already processed. This is a fatal error during
- context establishment.
-
- GSS_S_NO_CONTEXT Indicates that the supplied context handle did not
- refer to a valid context
-
- GSS_S_BAD_NAMETYPE The provided target_name parameter contained an
- invalid or unsupported type of name
-
- GSS_S_BAD_NAME The provided target_name parameter was ill-formed.
-
- GSS_S_BAD_MECH The specified mechanism is not supported by the
- provided credential, or is unrecognized by the
- implementation.
-
-
-
-
-
-
-
- 7.20. gss_inquire_context
-
- OM_uint32 gss_inquire_context (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- gss_name_t * src_name,
- gss_name_t * targ_name,
- OM_uint32 * lifetime_rec,
- gss_OID * mech_type,
- OM_uint32 * ctx_flags,
- int * locally_initiated,
- int * open )
-
- Purpose:
-
- Obtains information about a security context. The caller must already
- have obtained a handle that refers to the context, although the context
- need not be fully established.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- context_handle gss_ctx_id_t, read
- A handle that refers to the security context.
-
- src_name gss_name_t, modify, optional
- The name of the context initiator.
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 60]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- If the context was established using anonymous
- authentication, and if the application invoking
- gss_inquire_context is the context acceptor,
- an anonymous name will be returned. Storage
- associated with this name must be freed by the
- application after use with a call to
- gss_release_name(). Specify NULL if not
- required.
-
- targ_name gss_name_t, modify, optional
- The name of the context acceptor.
- Storage associated with this name must be
- freed by the application after use with a call
- to gss_release_name(). Specify NULL if not
- Specify NULL if not required.
-
- lifetime_rec Integer, modify, optional
- The number of seconds for which the context
- will remain valid. If the context has
- expired, this parameter will be set to zero.
- If the implementation does not support
- context expiration, the value
- GSS_C_INDEFINITE will be returned. Specify
- NULL if not required.
-
- mech_type gss_OID, modify, optional
- The security mechanism providing the
- context. The returned OID will be a
- pointer to static storage that should
- be treated as read-only by the application;
- in particular the application should not
- attempt to free it. Specify NULL if not
- required.
-
- ctx_flags bit-mask, modify, optional
- Contains various independent flags, each of
- which indicates that the context supports
- (or is expected to support, if ctx_open is
- false) a specific service option. If not
- needed, specify NULL. Symbolic names are
- provided for each flag, and the symbolic names
- corresponding to the required flags
- should be logically-ANDed with the ret_flags
- value to test whether a given option is
- supported by the context. The flags are:
-
- GSS_C_DELEG_FLAG
- True - Credentials were delegated from
- the initiator to the acceptor.
- False - No credentials were delegated
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 61]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
- GSS_C_MUTUAL_FLAG
- True - The acceptor was authenticated
- to the initiator
- False - The acceptor did not authenticate
- itself.
- GSS_C_REPLAY_FLAG
- True - replay of protected messages
- will be detected
- False - replayed messages will not be
- detected
- GSS_C_SEQUENCE_FLAG
- True - out-of-sequence protected
- messages will be detected
- False - out-of-sequence messages will not
- be detected
- GSS_C_CONF_FLAG
- True - Confidentiality service may be invoked
- by calling gss_wrap routine
- False - No confidentiality service (via
- gss_wrap) available. gss_wrap will
- provide message encapsulation,
- data-origin authentication and
- integrity services only.
- GSS_C_INTEG_FLAG
- True - Integrity service may be invoked by
- calling either gss_get_mic or gss_wrap
- routines.
- False - Per-message integrity service
- unavailable.
- GSS_C_ANON_FLAG
- True - The initiator's identity will not
- be revealed to the acceptor.
- The src_name parameter (if
- requested) contains an anonymous
- internal name.
- False - The initiator has been
- authenticated normally.
- GSS_C_PROT_READY_FLAG
- True - Protection services (as specified
- by the states of the GSS_C_CONF_FLAG
- and GSS_C_INTEG_FLAG) are available
- for use.
- False - Protection services (as specified
- by the states of the GSS_C_CONF_FLAG
- and GSS_C_INTEG_FLAG) are available
- only if the context is fully
- established (i.e. if the open parameter
- is non-zero).
- GSS_C_TRANS_FLAG
- True - The resultant security context may
- be transferred to other processes via
- a call to gss_export_sec_context().
- False - The security context is not
- transferrable.
-
- Wray Document Expiration: 1 September 1997 [Page 62]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
-
-
- locally_initiated Boolean, modify
- Non-zero if the invoking application is the
- context initiator.
- Specify NULL if not required.
-
- open Boolean, modify
- Non-zero if the context is fully established;
- Zero if a context-establishment token
- is expected from the peer application.
- Specify NULL if not required.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_NO_CONTEXT The referenced context could not be accessed.
-
- GSS_S_CONTEXT_EXPIRED The context has expired. If the lifetime_rec
- parameter was requested, it will be set to 0.
-
-
-
-
-
-
-
- 7.21. gss_inquire_cred
-
- OM_uint32 gss_inquire_cred (
- OM_uint32 * minor_status,
- const gss_cred_id_t cred_handle,
- gss_name_t * name,
- OM_uint32 * lifetime,
- gss_cred_usage_t * cred_usage,
- gss_OID_set * mechanisms )
-
- Purpose:
-
- Obtains information about a credential. The caller must already have
- obtained a handle that refers to the credential.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- cred_handle gss_cred_id_t, read
- A handle that refers to the target credential.
- Specify GSS_C_NO_CREDENTIAL to inquire about
- the default initiator principal.
-
-
- Wray Document Expiration: 1 September 1997 [Page 63]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
-
- name gss_name_t, modify, optional
- The name whose identity the credential asserts.
- Storage associated with this name should be freed
- by the application after use with a call to
- gss_release_name(). Specify NULL if not required.
-
- lifetime Integer, modify, optional
- The number of seconds for which the credential
- will remain valid. If the credential has
- expired, this parameter will be set to zero.
- If the implementation does not support
- credential expiration, the value
- GSS_C_INDEFINITE will be returned. Specify
- NULL if not required.
-
- cred_usage gss_cred_usage_t, modify, optional
- How the credential may be used. One of the
- following:
- GSS_C_INITIATE
- GSS_C_ACCEPT
- GSS_C_BOTH
- Specify NULL if not required.
-
- mechanisms gss_OID_set, modify, optional
- Set of mechanisms supported by the credential.
- Storage associated with this OID set must be
- freed by the application after use with a call
- to gss_release_oid_set(). Specify NULL if not
- required.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_NO_CRED The referenced credentials could not be accessed.
-
- GSS_S_DEFECTIVE_CREDENTIAL The referenced credentials were invalid.
-
- GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired. If
- the lifetime parameter was not passed as NULL, it will
- be set to 0.
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 64]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 7.22. gss_inquire_cred_by_mech
-
- OM_uint32 gss_inquire_cred_by_mech (
- OM_uint32 * minor_status,
- const gss_cred_id_t cred_handle,
- const gss_OID mech_type,
- gss_name_t * name,
- OM_uint32 * initiator_lifetime,
- OM_uint32 * acceptor_lifetime,
- gss_cred_usage_t * cred_usage )
-
- Purpose:
-
- Obtains per-mechanism information about a credential. The caller must
- already have obtained a handle that refers to the credential.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- cred_handle gss_cred_id_t, read
- A handle that refers to the target credential.
- Specify GSS_C_NO_CREDENTIAL to inquire about
- the default initiator principal.
-
- mech_type gss_OID, read
- The mechanism for which information should be
- returned.
-
- name gss_name_t, modify, optional
- The name whose identity the credential asserts.
- Storage associated with this name must be
- freed by the application after use with a call
- to gss_release_name(). Specify NULL if not
- required.
-
- initiator_lifetime Integer, modify, optional
- The number of seconds for which the credential
- will remain capable of initiating security contexts
- under the specified mechanism. If the credential
- can no longer be used to initiate contexts, or if
- the credential usage for this mechanism is
- GSS_C_ACCEPT,
- this parameter will be set to zero. If the
- implementation does not support expiration of
- initiator credentials, the value GSS_C_INDEFINITE
- will be returned. Specify NULL if not required.
-
- acceptor_lifetime Integer, modify, optional
- The number of seconds for which the credential
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 65]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- will remain capable of accepting security contexts
- under the specified mechanism. If the credential
- can no longer be used to accept contexts, or if
- the credential usage for this mechanism is
- GSS_C_INITIATE, this parameter will be set to zero.
- If the implementation does not support expiration
- of acceptor credentials, the value GSS_C_INDEFINITE
- will be returned. Specify NULL if not required.
-
- cred_usage gss_cred_usage_t, modify, optional
- How the credential may be used with the specified
- mechanism. One of the following:
- GSS_C_INITIATE
- GSS_C_ACCEPT
- GSS_C_BOTH
- Specify NULL if not required.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_NO_CRED The referenced credentials could not be accessed.
-
- GSS_S_DEFECTIVE_CREDENTIAL The referenced credentials were invalid.
-
- GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired. If
- the lifetime parameter was not passed as NULL, it will
- be set to 0.
-
-
-
-
-
-
-
- 7.23. gss_inquire_mechs_for_name
-
- OM_uint32 gss_inquire_mechs_for_name (
- OM_uint32 * minor_status,
- const gss_name_t input_name,
- gss_OID_set * mech_types )
-
- Purpose:
-
- Returns the set of mechanisms supported by the GSSAPI implementation
- that may be able to process the specified name.
-
- Each mechanism returned will recognize at least one element within the
- name. It is permissible for this routine to be implemented within a
- mechanism-independent GSSAPI layer, using the type information contained
- within the presented name, and based on registration information
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 66]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- provided by individual mechanism implementations. This means that the
- returned mech_types set may indicate that a particular mechanism will
- understand the name when in fact it would refuse to accept the name as
- input to gss_canonicalize_name, gss_init_sec_context, gss_acquire_cred
- or gss_add_cred (due to some property of the specific name, as opposed
- to the name type). Thus this routine should be used only as a pre-
- filter for a call to a subsequent mechanism-specific routine.
-
-
-
- Parameters:
-
- minor_status Integer, modify
- Implementation specific status code.
-
- input_name gss_name_t, read
- The name to which the inquiry relates.
-
- mech_types gss_OID_set, modify
- Set of mechanisms that may support the
- specified name. The returned OID set
- must be freed by the caller after use
- with a call to gss_release_oid_set().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAME The input_name parameter was ill-formed.
-
- GSS_S_BAD_NAMETYPE The input_name parameter contained an invalid or
- unsupported type of name
-
-
-
-
-
-
- 7.24. gss_inquire_names_for_mech
-
- OM_uint32 gss_inquire_names_for_mech (
- OM_uint32 * minor_status,
- const gss_OID mechanism,
- gss_OID_set * name_types)
-
- Purpose:
-
- Returns the set of nametypes supported by the specified mechanism.
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 67]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Parameters:
-
- minor_status Integer, modify
- Implementation specific status code.
-
- mechanism gss_OID, read
- The mechanism to be interrogated.
-
- name_types gss_OID_set, modify
- Set of name-types supported by the specified
- mechanism. The returned OID set must be
- freed by the application after use with a
- call to gss_release_oid_set().
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-
-
-
-
-
-
- 7.25. gss_process_context_token
-
- OM_uint32 gss_process_context_token (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- const gss_buffer_t token_buffer)
-
- Purpose:
-
- Provides a way to pass a token to the security service. Used with
- tokens emitted by gss_delete_sec_context. Note that mechanisms are
- encouraged to perform local deletion, and not emit tokens from
- gss_delete_sec_context. This routine, therefore, is primarily for
- backwards compatibility with V1 applications.
-
- Parameters:
-
- minor_status Integer, modify
- Implementation specific status code.
-
- context_handle gss_ctx_id_t, read
- context handle of context on which token is to
- be processed
-
- token_buffer buffer, opaque, read
- token to process
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 68]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed on the
- token failed
-
- GSS_S_NO_CONTEXT The context_handle did not refer to a valid context
-
-
-
-
-
-
-
- 7.26. gss_release_buffer
-
- OM_uint32 gss_release_buffer (
- OM_uint32 * minor_status,
- gss_buffer_t buffer)
-
- Purpose:
-
- Free storage associated with a buffer. The storage must have been
- allocated by a GSS-API routine. In addition to freeing the associated
- storage, the routine will zero the length field in the descriptor to
- which the buffer parameter refers.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- buffer buffer, modify
- The storage associated with the buffer will be
- deleted. The gss_buffer_desc object will not
- be freed, but its length field will be zeroed.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-
-
-
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 69]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 7.27. gss_release_cred
-
- OM_uint32 gss_release_cred (
- OM_uint32 * minor_status,
- gss_cred_id_t * cred_handle)
-
- Purpose:
-
- Informs GSS-API that the specified credential handle is no longer
- required by the application, and frees associated resources.
-
- Parameters:
-
- cred_handle gss_cred_id_t, modify, optional
- Opaque handle identifying credential
- to be released. If GSS_C_NO_CREDENTIAL
- is supplied, the routine will complete
- successfully, but will do nothing.
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_NO_CRED Credentials could not be accessed.
-
-
-
-
-
-
-
- 7.28. gss_release_name
-
- OM_uint32 gss_release_name (
- OM_uint32 * minor_status,
- gss_name_t * name)
-
- Purpose:
-
- Free GSSAPI-allocated storage by associated with an internal-form name.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- name gss_name_t, modify
- The name to be deleted
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 70]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAME The name parameter did not contain a valid name
-
-
-
-
-
-
-
- 7.29. gss_release_oid_set
-
- OM_uint32 gss_release_oid_set (
- OM_uint32 * minor_status,
- gss_OID_set * set)
-
- Purpose:
-
- Free storage associated with a GSSAPI-generated gss_OID_set object. The
- set parameter must refer to an OID-set that was returned from a GSSAPI
- routine. gss_release_oid_set() will free the storage associated with
- each individual member OID, the OID set's elements array, and the
- gss_OID_set_desc.
-
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- set Set of Object IDs, modify
- The storage associated with the gss_OID_set
- will be deleted.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 71]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- 7.30. gss_test_oid_set_member
-
- OM_uint32 gss_test_oid_set_member (
- OM_uint32 * minor_status,
- const gss_OID member,
- const gss_OID_set set,
- int * present)
-
- Purpose:
-
- Interrogate an Object Identifier set to determine whether a specified
- Object Identifier is a member. This routine is intended to be used with
- OID sets returned by gss_indicate_mechs(), gss_acquire_cred(), and
- gss_inquire_cred(), but will also work with user-generated sets.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- member Object ID, read
- The object identifier whose presence
- is to be tested.
-
- set Set of Object ID, read
- The Object Identifier set.
-
- present Boolean, modify
- non-zero if the specified OID is a member
- of the set, zero if not.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-
-
-
-
-
-
- 7.31. gss_unwrap
-
- OM_uint32 gss_unwrap (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- const gss_buffer_t input_message_buffer,
- gss_buffer_t output_message_buffer,
- int * conf_state,
- gss_qop_t * qop_state)
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 72]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Purpose:
-
- Converts a message previously protected by gss_wrap back to a usable
- form, verifying the embedded MIC. The conf_state parameter indicates
- whether the message was encrypted; the qop_state parameter indicates the
- strength of protection that was used to provide the confidentiality and
- integrity services.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- context_handle gss_ctx_id_t, read
- Identifies the context on which the message
- arrived
-
- input_message_buffer buffer, opaque, read
- protected message
-
- output_message_buffer buffer, opaque, modify
- Buffer to receive unwrapped message.
- Storage associated with this buffer must
- be freed by the application after use use
- with a call to gss_release_buffer().
-
- conf_state boolean, modify, optional
- Non-zero - Confidentiality and integrity protection
- were used
- Zero - Integrity service only was used
- Specify NULL if not required
-
- qop_state gss_qop_t, modify, optional
- Quality of protection gained from MIC.
- Specify NULL if not required
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
-
- GSS_S_BAD_SIG The MIC was incorrect
-
- GSS_S_DUPLICATE_TOKEN The token was valid, and contained a correct MIC
- for the message, but it had already been processed
-
- GSS_S_OLD_TOKEN The token was valid, and contained a correct MIC for
- the message, but it is too old to check for
- duplication.
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 73]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct MIC for
- the message, but has been verified out of sequence; a
- later token has already been received.
-
- GSS_S_GAP_TOKEN The token was valid, and contained a correct MIC for
- the message, but has been verified out of sequence;
- an earlier expected token has not yet been received.
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a valid
- context
-
-
-
-
-
-
-
- 7.32. gss_verify_mic
-
- OM_uint32 gss_verify_mic (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- const gss_buffer_t message_buffer,
- const gss_buffer_t token_buffer,
- gss_qop_t * qop_state)
-
- Purpose:
-
- Verifies that a cryptographic MIC, contained in the token parameter,
- fits the supplied message. The qop_state parameter allows a message
- recipient to determine the strength of protection that was applied to
- the message.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- context_handle gss_ctx_id_t, read
- Identifies the context on which the message
- arrived
-
- message_buffer buffer, opaque, read
- Message to be verified
-
- token_buffer buffer, opaque, read
- Token associated with message
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 74]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
- qop_state gss_qop_t, modify, optional
- quality of protection gained from MIC
- Specify NULL if not required
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
-
- GSS_S_BAD_SIG The MIC was incorrect
-
- GSS_S_DUPLICATE_TOKEN The token was valid, and contained a correct MIC
- for the message, but it had already been processed
-
- GSS_S_OLD_TOKEN The token was valid, and contained a correct MIC for
- the message, but it is too old to check for
- duplication.
-
- GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct MIC for
- the message, but has been verified out of sequence; a
- later token has already been received.
-
- GSS_S_GAP_TOKEN The token was valid, and contained a correct MIC for
- the message, but has been verified out of sequence;
- an earlier expected token has not yet been received.
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a valid
- context
-
-
-
-
-
-
-
- 7.33. gss_wrap
-
- OM_uint32 gss_wrap (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- int conf_req_flag,
- gss_qop_t qop_req
- const gss_buffer_t input_message_buffer,
- int * conf_state,
- gss_buffer_t output_message_buffer )
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 75]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- Purpose:
-
- Attaches a cryptographic MIC and optionally encrypts the specified
- input_message. The output_message contains both the MIC and the
- message. The qop_req parameter allows a choice between several
- cryptographic algorithms, if supported by the chosen mechanism.
-
- Since some application-level protocols may wish to use tokens emitted by
- gss_wrap() to provide "secure framing", implementations should support
- the wrapping of zero-length messages.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code.
-
- context_handle gss_ctx_id_t, read
- Identifies the context on which the message
- will be sent
-
- conf_req_flag boolean, read
- Non-zero - Both confidentiality and integrity
- services are requested
- Zero - Only integrity service is requested
-
- qop_req gss_qop_t, read, optional
- Specifies required quality of protection. A
- mechanism-specific default may be requested by
- setting qop_req to GSS_C_QOP_DEFAULT. If an
- unsupported protection strength is requested,
- gss_wrap will return a major_status of
- GSS_S_BAD_QOP.
-
- input_message_buffer buffer, opaque, read
- Message to be protected
-
- conf_state boolean, modify, optional
- Non-zero - Confidentiality, data origin
- authentication and integrity
- services have been applied
- Zero - Integrity and data origin services only
- has been applied.
- Specify NULL if not required
-
- output_message_buffer buffer, opaque, modify
- Buffer to receive protected message.
- Storage associated with this message must
- be freed by the application after use with
- a call to gss_release_buffer().
-
- Function value: GSS status code
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 76]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a valid
- context
-
- GSS_S_BAD_QOP The specified QOP is not supported by the mechanism.
-
-
-
-
-
-
-
- 7.34. gss_wrap_size_limit
-
- OM_uint32 gss_wrap_size_limit (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- int conf_req_flag,
- gss_qop_t qop_req,
- OM_uint32 req_output_size,
- OM_uint32 * max_input_size)
-
- Purpose:
-
- Allows an application to determine the maximum message size that, if
- presented to gss_wrap with the same conf_req_flag and qop_req
- parameters, will result in an output token containing no more than
- req_output_size bytes.
-
- This call is intended for use by applications that communicate over
- protocols that impose a maximum message size. It enables the
- application to fragment messages prior to applying protection.
-
- Successful completion of this call does not guarantee that gss_wrap will
- be able to protect a message of length max_input_size bytes, since this
- ability may depend on the availability of system resources at the time
- that gss_wrap is called. However, if the implementation itself imposes
- an upper limit on the length of messages that may be processed by
- gss_wrap, the implementation should not return a value via
- max_input_bytes that is greater than this length.
-
- Parameters:
-
- minor_status Integer, modify
- Mechanism specific status code
-
- context_handle gss_ctx_id_t, read
- A handle that refers to the security over
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 77]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- which the messages will be sent.
-
- conf_req_flag Boolean, read
- Indicates whether gss_wrap will be asked
- to apply confidentiality protection in
- addition to integrity protection. See
- the routine description for gss_wrap
- for more details.
-
- qop_req gss_qop_t, read
- Indicates the level of protection that
- gss_wrap will be asked to provide. See
- the routine description for gss_wrap for
- more details.
-
- req_output_size Integer, read
- The desired maximum size for tokens emitted
- by gss_wrap.
-
- max_input_size Integer, modify
- The maximum input message size that may
- be presented to gss_wrap in order to
- guarantee that the emitted token shall
- be no larger than req_output_size bytes.
-
- Function value: GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_NO_CONTEXT The referenced context could not be accessed.
-
- GSS_S_CONTEXT_EXPIRED The context has expired.
-
- GSS_S_BAD_QOP The specified QOP is not supported by the mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 78]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- APPENDIX A. GSS-API C header file gssapi.h
-
- C-language GSS-API implementations should include a copy of the
- following header-file.
-
- #ifndef GSSAPI_H_
- #define GSSAPI_H_
-
-
-
- /*
- * First, include stddef.h to get size_t defined.
- */
- #include <stddef.h>
-
- /*
- * If the platform supports the xom.h header file, it should be
- * included here.
- */
- #include <xom.h>
-
-
-
- /*
- * Now define the three implementation-dependent types.
- */
- typedef <platform-specific> gss_ctx_id_t;
- typedef <platform-specific> gss_cred_id_t;
- typedef <platform-specific> gss_name_t;
-
- /*
- * The following type must be defined as the smallest natural
- * unsigned integer supported by the platform that has at least
- * 32 bits of precision.
- */
- typedef <platform-specific> gss_uint32;
-
-
- #ifdef OM_STRING
- /*
- * We have included the xom.h header file. Verify that OM_uint32
- * is defined correctly.
- */
-
- #if sizeof(gss_uint32) != sizeof(OM_uint32)
- #error Incompatible definition of OM_uint32 from xom.h
- #endif
-
- typedef OM_object_identifier gss_OID_desc, *gss_OID;
-
- #else
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 79]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- /*
- * We can't use X/Open definitions, so roll our own.
- */
-
- typedef gss_uint32 OM_uint32;
-
- typedef struct gss_OID_desc_struct {
- OM_uint32 length;
- void *elements;
- } gss_OID_desc, *gss_OID;
-
- #endif
-
- typedef struct gss_OID_set_desc_struct {
- size_t count;
- gss_OID elements;
- } gss_OID_set_desc, *gss_OID_set;
-
- typedef struct gss_buffer_desc_struct {
- size_t length;
- void *value;
- } gss_buffer_desc, *gss_buffer_t;
-
- typedef struct gss_channel_bindings_struct {
- OM_uint32 initiator_addrtype;
- gss_buffer_desc initiator_address;
- OM_uint32 acceptor_addrtype;
- gss_buffer_desc acceptor_address;
- gss_buffer_desc application_data;
- } *gss_channel_bindings_t;
-
-
- /*
- * For now, define a QOP-type as an OM_uint32
- */
- typedef OM_uint32 gss_qop_t;
-
- typedef int gss_cred_usage_t;
-
- /*
- * Flag bits for context-level services.
- */
- #define GSS_C_DELEG_FLAG 1
- #define GSS_C_MUTUAL_FLAG 2
- #define GSS_C_REPLAY_FLAG 4
- #define GSS_C_SEQUENCE_FLAG 8
- #define GSS_C_CONF_FLAG 16
- #define GSS_C_INTEG_FLAG 32
- #define GSS_C_ANON_FLAG 64
- #define GSS_C_PROT_READY_FLAG 128
- #define GSS_C_TRANS_FLAG 256
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 80]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- /*
- * Credential usage options
- */
- #define GSS_C_BOTH 0
- #define GSS_C_INITIATE 1
- #define GSS_C_ACCEPT 2
-
- /*
- * Status code types for gss_display_status
- */
- #define GSS_C_GSS_CODE 1
- #define GSS_C_MECH_CODE 2
-
- /*
- * The constant definitions for channel-bindings address families
- */
- #define GSS_C_AF_UNSPEC 0
- #define GSS_C_AF_LOCAL 1
- #define GSS_C_AF_INET 2
- #define GSS_C_AF_IMPLINK 3
- #define GSS_C_AF_PUP 4
- #define GSS_C_AF_CHAOS 5
- #define GSS_C_AF_NS 6
- #define GSS_C_AF_NBS 7
- #define GSS_C_AF_ECMA 8
- #define GSS_C_AF_DATAKIT 9
- #define GSS_C_AF_CCITT 10
- #define GSS_C_AF_SNA 11
- #define GSS_C_AF_DECnet 12
- #define GSS_C_AF_DLI 13
- #define GSS_C_AF_LAT 14
- #define GSS_C_AF_HYLINK 15
- #define GSS_C_AF_APPLETALK 16
- #define GSS_C_AF_BSC 17
- #define GSS_C_AF_DSS 18
- #define GSS_C_AF_OSI 19
- #define GSS_C_AF_X25 21
-
- #define GSS_C_AF_NULLADDR 255
-
- /*
- * Various Null values
- */
- #define GSS_C_NO_NAME ((gss_name_t) 0)
- #define GSS_C_NO_BUFFER ((gss_buffer_t) 0)
- #define GSS_C_NO_OID ((gss_OID) 0)
- #define GSS_C_NO_OID_SET ((gss_OID_set) 0)
- #define GSS_C_NO_CONTEXT ((gss_ctx_id_t) 0)
- #define GSS_C_NO_CREDENTIAL ((gss_cred_id_t) 0)
- #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
- #define GSS_C_EMPTY_BUFFER {0, NULL}
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 81]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- /*
- * Some alternate names for a couple of the above
- * values. These are defined for V1 compatibility.
- */
- #define GSS_C_NULL_OID GSS_C_NO_OID
- #define GSS_C_NULL_OID_SET GSS_C_NO_OID_SET
-
- /*
- * Define the default Quality of Protection for per-message
- * services. Note that an implementation that offers multiple
- * levels of QOP may define GSS_C_QOP_DEFAULT to be either zero
- * (as done here) to mean "default protection", or to a specific
- * explicit QOP value. However, a value of 0 should always be
- * interpreted by a GSSAPI implementation as a request for the
- * default protection level.
- */
- #define GSS_C_QOP_DEFAULT 0
-
- /*
- * Expiration time of 2^32-1 seconds means infinite lifetime for a
- * credential or security context
- */
- #define GSS_C_INDEFINITE 0xfffffffful
-
- /*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- * "\x01\x02\x01\x01"},
- * corresponding to an object-identifier value of
- * {iso(1) member-body(2) United States(840) mit(113554)
- * infosys(1) gssapi(2) generic(1) user_name(1)}. The constant
- * GSS_C_NT_USER_NAME should be initialized to point
- * to that gss_OID_desc.
- */
- extern gss_OID GSS_C_NT_USER_NAME;
-
- /*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- * "\x01\x02\x01\x02"},
- * corresponding to an object-identifier value of
- * {iso(1) member-body(2) United States(840) mit(113554)
- * infosys(1) gssapi(2) generic(1) machine_uid_name(2)}.
- * The constant GSS_C_NT_MACHINE_UID_NAME should be
- * initialized to point to that gss_OID_desc.
- */
- extern gss_OID GSS_C_NT_MACHINE_UID_NAME;
-
- /*
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 82]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- * "\x01\x02\x01\x03"},
- * corresponding to an object-identifier value of
- * {iso(1) member-body(2) United States(840) mit(113554)
- * infosys(1) gssapi(2) generic(1) string_uid_name(3)}.
- * The constant GSS_C_NT_STRING_UID_NAME should be
- * initialized to point to that gss_OID_desc.
- */
- extern gss_OID GSS_C_NT_STRING_UID_NAME;
-
- /*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {6, (void *)"\x2b\x06\x01\x05\x06\x02"},
- * corresponding to an object-identifier value of
- * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
- * 6(nametypes), 2(gss-host-based-services)}. The constant
- * GSS_C_NT_HOSTBASED_SERVICE should be initialized to point
- * to that gss_OID_desc.
- */
- extern gss_OID GSS_C_NT_HOSTBASED_SERVICE;
-
- /*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {6, (void *)"\x2b\x06\01\x05\x06\x03"},
- * corresponding to an object identifier value of
- * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
- * 6(nametypes), 3(gss-anonymous-name)}. The constant
- * and GSS_C_NT_ANONYMOUS should be initialized to point
- * to that gss_OID_desc.
- */
- extern gss_OID GSS_C_NT_ANONYMOUS;
-
-
-
- /*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {6, (void *)"\x2b\x06\x01\x05\x06\x04"},
- * corresponding to an object-identifier value of
- * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
- * 6(nametypes), 4(gss-api-exported-name)}. The constant
- * GSS_C_NT_EXPORT_NAME should be initialized to point
- * to that gss_OID_desc.
- */
- extern gss_OID GSS_C_NT_EXPORT_NAME;
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 83]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- /* Major status codes */
-
- #define GSS_S_COMPLETE 0
-
- /*
- * Some "helper" definitions to make the status code macros obvious.
- */
- #define GSS_C_CALLING_ERROR_OFFSET 24
- #define GSS_C_ROUTINE_ERROR_OFFSET 16
- #define GSS_C_SUPPLEMENTARY_OFFSET 0
- #define GSS_C_CALLING_ERROR_MASK 0377ul
- #define GSS_C_ROUTINE_ERROR_MASK 0377ul
- #define GSS_C_SUPPLEMENTARY_MASK 0177777ul
-
- /*
- * The macros that test status codes for error conditions.
- * Note that the GSS_ERROR() macro has changed slightly from
- * the V1 GSSAPI so that it now evaluates its argument
- * only once.
- */
- #define GSS_CALLING_ERROR(x) \
- (x & (GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET))
- #define GSS_ROUTINE_ERROR(x) \
- (x & (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET))
- #define GSS_SUPPLEMENTARY_INFO(x) \
- (x & (GSS_C_SUPPLEMENTARY_MASK << GSS_C_SUPPLEMENTARY_OFFSET))
- #define GSS_ERROR(x) \
- (x & ((GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET) | \
- (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET)))
-
-
- /*
- * Now the actual status code definitions
- */
-
- /*
- * Calling errors:
- */
- #define GSS_S_CALL_INACCESSIBLE_READ \
- (1ul << GSS_C_CALLING_ERROR_OFFSET)
- #define GSS_S_CALL_INACCESSIBLE_WRITE \
- (2ul << GSS_C_CALLING_ERROR_OFFSET)
- #define GSS_S_CALL_BAD_STRUCTURE \
- (3ul << GSS_C_CALLING_ERROR_OFFSET)
-
- /*
- * Routine errors:
- */
- #define GSS_S_BAD_MECH (1ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_NAME (2ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_NAMETYPE (3ul << GSS_C_ROUTINE_ERROR_OFFSET)
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 84]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- #define GSS_S_BAD_BINDINGS (4ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_STATUS (5ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_SIG (6ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_MIC GSS_S_BAD_SIG
- #define GSS_S_NO_CRED (7ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_NO_CONTEXT (8ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_DEFECTIVE_CREDENTIAL (10ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_CREDENTIALS_EXPIRED (11ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_CONTEXT_EXPIRED (12ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_FAILURE (13ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_QOP (14ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_UNAUTHORIZED (15ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_UNAVAILABLE (16ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_DUPLICATE_ELEMENT (17ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_NAME_NOT_MN (18ul << GSS_C_ROUTINE_ERROR_OFFSET)
-
- /*
- * Supplementary info bits:
- */
- #define GSS_S_CONTINUE_NEEDED (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 0))
- #define GSS_S_DUPLICATE_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 1))
- #define GSS_S_OLD_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 2))
- #define GSS_S_UNSEQ_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 3))
- #define GSS_S_GAP_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 4))
-
-
- /*
- * Finally, function prototypes for the GSS-API routines.
- */
-
- OM_uint32 gss_acquire_cred
- (OM_uint32 *, /* minor_status */
- const gss_name_t, /* desired_name */
- OM_uint32, /* time_req */
- const gss_OID_set, /* desired_mechs */
- gss_cred_usage_t, /* cred_usage */
- gss_cred_id_t *, /* output_cred_handle */
- gss_OID_set *, /* actual_mechs */
- OM_uint32 * /* time_rec */
- );
-
- OM_uint32 gss_release_cred
- (OM_uint32 *, /* minor_status */
- gss_cred_id_t * /* cred_handle */
- );
-
- OM_uint32 gss_init_sec_context
- (OM_uint32 *, /* minor_status */
- const gss_cred_id_t, /* initiator_cred_handle */
- gss_ctx_id_t *, /* context_handle */
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 85]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- const gss_name_t, /* target_name */
- const gss_OID, /* mech_type */
- OM_uint32, /* req_flags */
- OM_uint32, /* time_req */
- const gss_channel_bindings_t,
- /* input_chan_bindings */
- const gss_buffer_t, /* input_token */
- gss_OID *, /* actual_mech_type */
- gss_buffer_t, /* output_token */
- OM_uint32 *, /* ret_flags */
- OM_uint32 * /* time_rec */
- );
-
- OM_uint32 gss_accept_sec_context
- (OM_uint32 *, /* minor_status */
- gss_ctx_id_t *, /* context_handle */
- const gss_cred_id_t, /* acceptor_cred_handle */
- const gss_buffer_t, /* input_token_buffer */
- const gss_channel_bindings_t,
- /* input_chan_bindings */
- gss_name_t *, /* src_name */
- gss_OID *, /* mech_type */
- gss_buffer_t, /* output_token */
- OM_uint32 *, /* ret_flags */
- OM_uint32 *, /* time_rec */
- gss_cred_id_t * /* delegated_cred_handle */
- );
-
- OM_uint32 gss_process_context_token
- (OM_uint32 *, /* minor_status */
- const gss_ctx_id_t, /* context_handle */
- const gss_buffer_t /* token_buffer */
- );
-
- OM_uint32 gss_delete_sec_context
- (OM_uint32 *, /* minor_status */
- gss_ctx_id_t *, /* context_handle */
- gss_buffer_t /* output_token */
- );
-
- OM_uint32 gss_context_time
- (OM_uint32 *, /* minor_status */
- const gss_ctx_id_t, /* context_handle */
- OM_uint32 * /* time_rec */
- );
-
- OM_uint32 gss_get_mic
- (OM_uint32 *, /* minor_status */
- const gss_ctx_id_t, /* context_handle */
- gss_qop_t, /* qop_req */
- const gss_buffer_t, /* message_buffer */
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 86]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- gss_buffer_t /* message_token */
- );
-
-
- OM_uint32 gss_verify_mic
- (OM_uint32 *, /* minor_status */
- const gss_ctx_id_t, /* context_handle */
- const gss_buffer_t, /* message_buffer */
- const gss_buffer_t, /* token_buffer */
- gss_qop_t * /* qop_state */
- );
-
- OM_uint32 gss_wrap
- (OM_uint32 *, /* minor_status */
- const gss_ctx_id_t, /* context_handle */
- int, /* conf_req_flag */
- gss_qop_t, /* qop_req */
- const gss_buffer_t, /* input_message_buffer */
- int *, /* conf_state */
- gss_buffer_t /* output_message_buffer */
- );
-
-
- OM_uint32 gss_unwrap
- (OM_uint32 *, /* minor_status */
- const gss_ctx_id_t, /* context_handle */
- const gss_buffer_t, /* input_message_buffer */
- gss_buffer_t, /* output_message_buffer */
- int *, /* conf_state */
- gss_qop_t * /* qop_state */
- );
-
-
-
- OM_uint32 gss_display_status
- (OM_uint32 *, /* minor_status */
- OM_uint32, /* status_value */
- int, /* status_type */
- const gss_OID, /* mech_type */
- OM_uint32 *, /* message_context */
- gss_buffer_t /* status_string */
- );
-
- OM_uint32 gss_indicate_mechs
- (OM_uint32 *, /* minor_status */
- gss_OID_set * /* mech_set */
- );
-
- OM_uint32 gss_compare_name
- (OM_uint32 *, /* minor_status */
- const gss_name_t, /* name1 */
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 87]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- const gss_name_t, /* name2 */
- int * /* name_equal */
- );
-
- OM_uint32 gss_display_name
- (OM_uint32 *, /* minor_status */
- const gss_name_t, /* input_name */
- gss_buffer_t, /* output_name_buffer */
- gss_OID * /* output_name_type */
- );
-
- OM_uint32 gss_import_name
- (OM_uint32 *, /* minor_status */
- const gss_buffer_t, /* input_name_buffer */
- const gss_OID, /* input_name_type */
- gss_name_t * /* output_name */
- );
-
- OM_uint32 gss_export_name
- (OM_uint32 *, /* minor_status */
- const gss_name_t, /* input_name */
- gss_buffer_t /* exported_name */
- );
-
- OM_uint32 gss_release_name
- (OM_uint32 *, /* minor_status */
- gss_name_t * /* input_name */
- );
-
- OM_uint32 gss_release_buffer
- (OM_uint32 *, /* minor_status */
- gss_buffer_t /* buffer */
- );
-
- OM_uint32 gss_release_oid_set
- (OM_uint32 *, /* minor_status */
- gss_OID_set * /* set */
- );
-
- OM_uint32 gss_inquire_cred
- (OM_uint32 *, /* minor_status */
- const gss_cred_id_t, /* cred_handle */
- gss_name_t *, /* name */
- OM_uint32 *, /* lifetime */
- gss_cred_usage_t *, /* cred_usage */
- gss_OID_set * /* mechanisms */
- );
-
- OM_uint32 gss_inquire_context (
- OM_uint32 *, /* minor_status */
- const gss_ctx_id_t, /* context_handle */
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 88]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- gss_name_t *, /* src_name */
- gss_name_t *, /* targ_name */
- OM_uint32 *, /* lifetime_rec */
- gss_OID *, /* mech_type */
- OM_uint32 *, /* ctx_flags */
- int *, /* locally_initiated */
- int * /* open */
- );
-
- OM_uint32 gss_wrap_size_limit (
- OM_uint32 *, /* minor_status */
- const gss_ctx_id_t, /* context_handle */
- int, /* conf_req_flag */
- gss_qop_t, /* qop_req */
- OM_uint32, /* req_output_size */
- OM_uint32 * /* max_input_size */
- );
-
-
- OM_uint32 gss_add_cred (
- OM_uint32 *, /* minor_status */
- const gss_cred_id_t, /* input_cred_handle */
- const gss_name_t, /* desired_name */
- const gss_OID, /* desired_mech */
- gss_cred_usage_t, /* cred_usage */
- OM_uint32, /* initiator_time_req */
- OM_uint32, /* acceptor_time_req */
- gss_cred_id_t *, /* output_cred_handle */
- gss_OID_set *, /* actual_mechs */
- OM_uint32 *, /* initiator_time_rec */
- OM_uint32 * /* acceptor_time_rec */
- );
-
-
- OM_uint32 gss_inquire_cred_by_mech (
- OM_uint32 *, /* minor_status */
- const gss_cred_id_t, /* cred_handle */
- const gss_OID, /* mech_type */
- gss_name_t *, /* name */
- OM_uint32 *, /* initiator_lifetime */
- OM_uint32 *, /* acceptor_lifetime */
- gss_cred_usage_t * /* cred_usage */
- );
-
- OM_uint32 gss_export_sec_context (
- OM_uint32 *, /* minor_status */
- gss_ctx_id_t *, /* context_handle */
- gss_buffer_t /* interprocess_token */
- );
-
- OM_uint32 gss_import_sec_context (
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 89]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- OM_uint32 *, /* minor_status */
- const gss_buffer_t, /* interprocess_token */
- gss_ctx_id_t * /* context_handle */
- );
-
- OM_uint32 gss_create_empty_oid_set (
- OM_uint32 *, /* minor_status */
- gss_OID_set * /* oid_set */
- );
-
- OM_uint32 gss_add_oid_set_member (
- OM_uint32 *, /* minor_status */
- const gss_OID, /* member_oid */
- gss_OID_set * /* oid_set */
- );
-
- OM_uint32 gss_test_oid_set_member (
- OM_uint32 *, /* minor_status */
- const gss_OID, /* member */
- const gss_OID_set, /* set */
- int * /* present */
- );
-
- OM_uint32 gss_inquire_names_for_mech (
- OM_uint32 *, /* minor_status */
- const gss_OID, /* mechanism */
- gss_OID_set * /* name_types */
- );
-
- OM_uint32 gss_inquire_mechs_for_name (
- OM_uint32 *, /* minor_status */
- const gss_name_t, /* input_name */
- gss_OID_set * /* mech_types */
- );
-
- OM_uint32 gss_canonicalize_name (
- OM_uint32 *, /* minor_status */
- const gss_name_t, /* input_name */
- const gss_OID, /* mech_type */
- gss_name_t * /* output_name */
- );
-
- OM_uint32 gss_duplicate_name (
- OM_uint32 *, /* minor_status */
- const gss_name_t, /* src_name */
- gss_name_t * /* dest_name */
- );
-
- /*
- * The following routines are obsolete variants of gss_get_mic,
- * gss_verify_mic, gss_wrap and gss_unwrap. They should be
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 90]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- * provided by GSSAPI V2 implementations for backwards
- * compatibility with V1 applications. Distinct entrypoints
- * (as opposed to #defines) should be provided, both to allow
- * GSSAPI V1 applications to link against GSSAPI V2 implementations,
- * and to retain the slight parameter type differences between the
- * obsolete versions of these routines and their current forms.
- */
-
- OM_uint32 gss_sign
- (OM_uint32 *, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- int, /* qop_req */
- gss_buffer_t, /* message_buffer */
- gss_buffer_t /* message_token */
- );
-
-
- OM_uint32 gss_verify
- (OM_uint32 *, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- gss_buffer_t, /* message_buffer */
- gss_buffer_t, /* token_buffer */
- int * /* qop_state */
- );
-
- OM_uint32 gss_seal
- (OM_uint32 *, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- int, /* conf_req_flag */
- int, /* qop_req */
- gss_buffer_t, /* input_message_buffer */
- int *, /* conf_state */
- gss_buffer_t /* output_message_buffer */
- );
-
-
- OM_uint32 gss_unseal
- (OM_uint32 *, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- gss_buffer_t, /* input_message_buffer */
- gss_buffer_t, /* output_message_buffer */
- int *, /* conf_state */
- int * /* qop_state */
- );
-
-
-
-
- #endif /* GSSAPI_H_ */
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 91]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- APPENDIX B. Additional constraints for application binary portability
-
- The purpose of this C-bindings document is to encourage source-level
- portability of applications across GSS-API implementations on different
- platforms and atop different mechanisms. Additional goals that have not
- been explicitly addressed by this document are link-time and run-time
- portability.
-
- Link-time portability provides the ability to compile an application
- against one implementation of GSS-API, and then link it against a
- different implementation on the same platform. It is a stricter
- requirement than source-level portability.
-
- Run-time portability differs from link-time portability only on those
- platforms that implement dynamically loadable GSS-API implementations,
- but do not offer load-time symbol resolution. On such platforms, run-
- time portability is a stricter requirement than link-time portability,
- and will typically include the precise placement of the various GSS-API
- routines within library entrypoint vectors.
-
- Individual platforms will impose their own rules that must be followed
- to achieve link-time (and run-time, if different) portability. In order
- to ensure either form of binary portability, an ABI specification must
- be written for GSS-API implementations on that platform. However, it is
- recognized that there are some issues that are likely to be common to
- all such ABI specifications. This appendix is intended to be a
- repository for such common issues, and contains some suggestions that
- individual ABI specifications may choose to reference. Since machine
- architectures vary greatly, it may not be possible or desirable to
- follow these suggestions on all platforms.
-
- B.1. Pointers
-
- While ANSI-C provides a single pointer type for each declared type, plus
- a single (void *) type, some platforms (notably those using segmented
- memory architectures) augment this with various modified pointer types
- (e.g. far pointers, near pointers). These language bindings assume
- ANSI-C, and thus do not address such non-standard implementations.
- GSS-API implementations for such platforms must choose an appropriate
- memory model, and should use it consistently throughout. For example,
- if a memory model is chosen that requires the use of far pointers when
- passing routine parameters, then far pointers should also be used within
- the structures defined by GSS-API.
-
- B.2. Internal structure alignment
-
- GSS-API defines several data-structures containing differently-sized
- fields. An ABI specification should include a detailed description of
- how the fields of such structures are aligned, and if there is any
- internal padding in these data structures. The use of compiler defaults
- for the platform is recommended.
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 92]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- B.3. Handle types
-
- The C bindings specify that the gss_cred_id_t and gss_ctx_id_t types
- should be implemented as either pointer or arithmetic types, and that if
- pointer types are used, care should be taken to ensure that two handles
- may be compared with the == operator. Note that ANSI-C does not
- guarantee that two pointer values may be compared with the == operator
- unless either the two pointers point to members of a single array, or at
- least one of the pointers contains a NULL value.
-
- For binary portability, additional constraints are required. The
- following is an attempt at defining platform-independent constraints.
-
- (a) The size of the handle type must be the same as sizeof(void *),
- using the appropriate memory model.
-
- (b) The == operator for the chosen type must be a simple bit-wise
- comparison. That is, for two in-memory handle objects h1 and h2,
- the boolean value of the expression
-
- (h1 == h2)
-
- should always be the same as the boolean value of the expression
-
- (memcmp(&h1, &h2, sizeof(h1)) == 0)
-
- (c) The actual use of the type (void *) for handle types is
- discouraged, not for binary portability reasons, but since it
- effectively disables much of the compile-time type-checking that
- the compiler can otherwise perform, and is therefore not
- "programmer-friendly". If a pointer implementation is desired,
- and if the platform's implementation of pointers permits, the
- handles should be implemented as pointers to distinct
- implementation-defined types.
-
- B.4. The gss_name_t type
-
- The gss_name_t type, representing the internal name object, should be
- implemented as a pointer type. The use of the (void *) type is
- discouraged as it does not allow the compiler to perform strong type-
- checking. However, the pointer type chosen should be of the same size
- as the (void *) type. Provided this rule is obeyed, ABI specifications
- need not further constrain the implementation of gss_name_t objects.
-
- B.5. The int and size_t types
-
- Some platforms may support differently sized implementations of the
- "int" and "size_t" types, perhaps chosen through compiler switches, and
- perhaps dependent on memory model. An ABI specification for such a
- platform should include required implementations for these types. It is
- recommended that the default implementation (for the chosen memory
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 93]
-
-
-
-
-
-
-
- INTERNET-DRAFT GSS-API V2 - C bindings March 1997
-
-
-
- model, if appropriate) is chosen.
-
- B.6. Procedure-calling conventions
-
- Some platforms support a variety of different binary conventions for
- calling procedures. Such conventions cover things like the format of
- the stack frame, the order in which the routine parameters are pushed
- onto the stack, whether or not a parameter count is pushed onto the
- stack, whether some argument(s) or return values are to be passed in
- registers, and whether the called routine or the caller is responsible
- for removing the stack frame on return. For such platforms, an ABI
- specification should specify which calling convention is to be used for
- GSSAPI implementations.
-
-
- REFERENCES
-
- [GSSAPI] J. Linn, "Generic Security Service Application Program
- Interface, Version 2", Internet-Draft draft-ietf-cat-gssv2-
- 08, 26 August 1996. (This Internet-Draft, like all other
- Internet-Drafts, is not an archival document and is subject
- to change or deletion. It is available at the time of this
- writing by anonymous ftp from ds.internic.net, directory
- internet-drafts. Would-be readers should check for successor
- Internet-Draft versions or Internet RFCs before relying on
- this document.)
-
- [XOM] OSI Object Management API Specification, Version 2.0 t",
- X.400 API Association & X/Open Company Limited, August 24,
- 1990. Specification of datatypes and routines for
- manipulating information objects.
-
-
- AUTHOR'S ADDRESS
-
- John Wray Internet email: Wray@tuxedo.enet.dec.com
- Digital Equipment Corporation Telephone: +1-508-486-5210
- 550 King Street, LKG2-2/Z7
- Littleton, MA 01460
- USA
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Wray Document Expiration: 1 September 1997 [Page 94]
-
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt b/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt
deleted file mode 100644
index 2583a84da0a4750dc6a97aa20dcf7f94ca494bd4..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt
+++ /dev/null
@@ -1,127 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Horowitz
-<draft-ietf-cat-kerb-des3-hmac-sha1-00.txt> Cygnus Solutions
-Internet-Draft November, 1996
-
-
- Triple DES with HMAC-SHA1 Kerberos Encryption Type
-
-Status of this Memo
-
- This document is an Internet-Draft. 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.''
-
- To learn the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ds.internic.net (US East Coast), nic.nordu.net
- (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
- Rim).
-
- Distribution of this memo is unlimited. Please send comments to the
- <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
- This document defines a new encryption type and a new checksum type
- for use with Kerberos V5 [RFC1510]. This encryption type is based on
- the Triple DES cryptosystem and the HMAC-SHA1 [Krawczyk96] message
- authentication algorithm.
-
- The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
- The hmac-sha1-des3 checksum type has been assigned the value 12.
-
-
-Encryption Type des3-cbc-hmac-sha1
-
- EncryptedData using this type must be generated as described in
- [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC
- mode. The keyed hash algorithm is HMAC-SHA1. 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 Type hmac-sha1-des3
-
- Checksums using this type must be generated as described in
- [Horowitz96]. The keyed hash algorithm is HMAC-SHA1.
-
-
-
-Horowitz [Page 1]
-
-Internet Draft Kerberos Triple DES with HMAC-SHA1 November, 1996
-
-
-Common Requirements
-
- Where the Triple DES key is represented as an EncryptionKey, it shall
- be represented as three DES keys, with parity bits, concatenated
- together. The key shall be represented with the most significant bit
- first.
-
- When keys are generated by the derivation function, a key length of
- 168 bits shall be used. The output bit string will be converted to a
- valid Triple DES key by inserting DES parity bits after every seventh
- bit.
-
- Any implementation which implements either of the encryption or
- checksum types in this document must support both.
-
-
-Security Considerations
-
- This entire document defines encryption and checksum types for use
- with Kerberos V5.
-
-
-References
-
- [Horowitz96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
- horowitz-kerb-key-derivation-00.txt, November 1996.
- [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
- Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
- md5-01.txt, August, 1996.
- [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
- Authentication Service (V5)", RFC 1510, September 1993.
-
-
-Author's Address
-
- Marc Horowitz
- Cygnus Solutions
- 955 Massachusetts Avenue
- Cambridge, MA 02139
-
- Phone: +1 617 354 7688
- Email: marc@cygnus.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz [Page 2]
-
diff --git a/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt b/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
deleted file mode 100644
index 46a41585270632f1d0184f9ae41191ed7bb83864..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
+++ /dev/null
@@ -1,250 +0,0 @@
-
-
-
-
-
-Network Working Group M. Horowitz
-<draft-ietf-cat-kerb-key-derivation-00.txt> Cygnus Solutions
-Internet-Draft November, 1996
-
-
- Key Derivation for Kerberos V5
-
-Status of this Memo
-
- This document is an Internet-Draft. 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.''
-
- To learn the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ds.internic.net (US East Coast), nic.nordu.net
- (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
- Rim).
-
- Distribution of this memo is unlimited. Please send comments to the
- <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
- In the Kerberos protocol [RFC1510], 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.
-
-
-Overview
-
- Under RFC1510 as stated, key derivation could be specified as a set
- of encryption types which share the same key type. The constant for
- each derivation would be a function of the encryption type. However,
- it is generally accepted that, for interoperability, key types and
- encryption types must map one-to-one onto each other. (RFC 1510 is
- being revised to address this issue.) Therefore, to use key
- derivcation with Kerberos V5 requires a small change to the
- specification.
-
- For each place where a key is used in Kerberos, a ``key usage'' must
- be specified for that purpose. The key, key usage, and
- encryption/checksum type together describe the transformation from
- plaintext to ciphertext, or plaintext to checksum. For backward
-
-
-
-Horowitz [Page 1]
-
-Internet Draft Key Derivation for Kerberos V5 November, 1996
-
-
- compatibility, old encryption types would be defined independently of
- the key usage.
-
-
-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)
-
- 16. Data which is defined in some specification outside of
- Kerberos to be encrypted using an RFC1510 encryption type.
- 17. Data which is defined in some specification outside of
- Kerberos to be checksummed using an RFC1510 checksum type.
-
- 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
-
-
-
-Horowitz [Page 2]
-
-Internet Draft Key Derivation for Kerberos V5 November, 1996
-
-
- 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 16 and 17 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 shall 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 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 | length | plaintext | padding) |
- H(Ki, confounder | length | 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, length | 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
- recommended for use as H.
-
-
-Security Considerations
-
- This entire document addresses shortcomings in the use of
- cryptographic keys in Kerberos V5.
-
-
-
-
-Horowitz [Page 3]
-
-Internet Draft Key Derivation for Kerberos V5 November, 1996
-
-
-Acknowledgements
-
- I would like to thank Uri Blumenthal, Sam Hartman, and Bill
- Sommerfeld for their contributions to this document.
-
-
-References
-
- [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
- Integrity, and Privacy", draft-horowitz-key-derivation-00.txt,
- November 1996. [RFC1510] Kohl, J. and Neuman, C., "The Kerberos
- Network Authentication Service (V5)", RFC 1510, September 1993.
-
-
-Author's Address
-
- Marc Horowitz
- Cygnus Solutions
- 955 Massachusetts Avenue
- Cambridge, MA 02139
-
- Phone: +1 617 354 7688
- Email: marc@cygnus.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz [Page 4]
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt b/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt
deleted file mode 100644
index c5e4d05e7e3eaae049449b11b73a495ca836ef64..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt
+++ /dev/null
@@ -1,252 +0,0 @@
-
-INTERNET-DRAFT Ari Medvinsky
-draft-ietf-cat-kerberos-err-msg-00.txt Matt Hur
-Updates: RFC 1510 Dominique Brezinski
-expires September 30, 1997 CyberSafe Corporation
- Gene Tsudik
- Brian Tung
- ISI
-
-Integrity Protection for the Kerberos Error Message
-
-0. Status Of this Memo
-
- This document is an Internet-Draft. 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."
-
- To learn the current status of any Internet-Draft, please check
- the "1id-abstracts.txt" listing contained in the Internet-Drafts
- Shadow Directories on ds.internic.net (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-03.txt, and expires June xx, 1997.
- Please send comments to the authors.
-
-1. Abstract
-
- The Kerberos error message, as defined in RFC 1510, is transmitted
- to the client without any integrity assurance. Therefore, the
- client has no means to distinguish between a valid error message
- sent from the KDC and one sent by an attacker. This draft describes
- a method for assuring the integrity of Kerberos error messages, and
- proposes a consistent format for the e-data field in the KRB_ERROR
- message. This e-data format enables the storage of cryptographic
- checksums by providing an extensible mechanism for specifying e-data
- types.
-
-
-2. Motivation
-
- In the Kerberos protocol [1], if an error occurs for AS_REQ,
- TGS_REQ, or AP_REQ, a clear text error message is returned to the
- client. An attacker may exploit this vulnerability by sending a
- false error message as a reply to any of the above requests. For
- example, an attacker may send the KDC_ERR_KEY_EXPIRED error message
- in order to force a user to change their password in hope that the
- new key will not be as strong as the current key, and thus, easier
- to break.
-
- Since false error messages may be utilized by an attacker, a
- Kerberos client should have a means for determining how much trust
- to place in a given error message. The rest of this draft
- describes a method for assuring the integrity of Kerberos error
- messages.
-
-
-3. Approach
-
- We propose taking a cryptographic checksum over the entire KRB-ERROR
- message. This checksum would be returned as part of the error
- message and would enable the client to verify the integrity of the
- error message. For interoperability reasons, no new fields are
- added to the KRB-ERROR message. Instead, the e-data field (see
- figure 1) is utilized to carry the cryptographic checksum.
-
-
-3.1 Cryptographic checksums in error messages for AS_REQ,
- TGS_REQ & AP_REQ
-
- If an error occurs for the AS request, the only key that is
- available to the KDC is the shared secret (the key derived from the
- clients password) registered in the KDCs database. The KDC will
- use this key to sign the error message, if and only if, the client
- already proved knowledge of the shared secret in the AS request
- (e.g. via PA-ENC-TIMESTAMP in preauth data). This policy is needed
- to prevent an attacker from getting the KDC to send a signed error
- message and then launching an off-line attack in order to obtain a
- key of a given principal.
-
- If an error occurs for a TGS or an AP request, the server will use
- the session key sealed in the clients ticket granting ticket to
- compute the checksum over the error message. If the checksum could
- not be computed (e.g. error while decrypting the ticket) the error
- message is returned to the client without the checksum. The client
- then has the option to treat unprotected error messages differently.
-
-
- 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
- }
- Figure 1
-
-
-3.2 Format of the e-data field
-
- We propose to place the cryptographic checksum in the e-data field.
- First, we review the format of the e-data field, as specified in
- RFC 1510. The format of e-data is specified only in two cases [2].
- "If the error code is KDC_ERR_PREAUTH_REQUIRED, then the e-data
- field will contain an encoding of a sequence of padata fields":
-
- METHOD-DATA ::= SEQUENCE of PA-DATA
- PA-DATA ::= SEQUENCE {
- padata-type [1] INTEGER,
- padata-value [2] OCTET STRING
- }
-
- The second case deals with the KRB_AP_ERR_METHOD error code. The
- e-data field will contain an encoding of the following sequence:
-
- METHOD-DATA ::= SEQUENCE {
- method-type [0] INTEGER,
- method-data [1] OCTET STRING OPTIONAL
- }
-
- method-type indicates the required alternate authentication method.
-
- It should be noted that, in the case of KRB_AP_ERR_METHOD, a signed
- checksum is not returned as part of the error message, since the
- error code indicates that the Kerberos credentials provided in the
- AP_REQ message are unacceptable.
-
- We propose that the e-data field have the following format for all
- error-codes (except KRB_AP_ERR_METHOD):
-
- E-DATA ::= SEQUENCE {
- data-type [1] INTEGER,
- data-value [2] OCTET STRING,
- }
-
- The data-type field specifies the type of information that is
- carried in the data-value field. Thus, to send a cryptographic
- checksum back to the client, the data-type is set to CHECKSUM, the
- data-value is set to the ASN.1 encoding of the following sequence:
-
- Checksum ::= SEQUENCE {
- cksumtype [0] INTEGER,
- checksum [1] OCTET STRING
- }
-
-
-3.3 Computing the checksum
-
- After the error message is filled out, the error structure is
- converted into ASN.1 representation. A cryptographic checksum is
- then taken over the encoded error message; the result is placed in
- the error message structure, as the last item in the e-data field.
- To send the error message, ASN.1 encoding is again performed over
- the error message, which now includes the cryptographic checksum.
-
-
-3.4 Verifying the integrity of the error message
-
- In addition to verifying the cryptographic checksum for the error
- message, the client must verify that the error message is bound to
- its request. This is done by comparing the ctime field in the
- error message to its counterpart in the request message.
-
-
-4. E-DATA types
-
- Since the e-data types must not conflict with preauthentication data
- types, we propose that the preauthentication data types in the range
- of 2048 and above be reserved for use as e-data types.
-
- We define the following e-data type in support of integrity checking
- for the Kerberos error message:
-
- CHECKSUM = 2048 -- the keyed checksum described above
-
-
-5. Discussion
-
-
-5.1 e-data types
-
- The extension for Kerberos error messages, as outlined above, is
- extensible to allow for definition of other error data types.
- We propose that the following e-data types be reserved:
-
- KDCTIME = 2049
- The error data would consist of the KDCs time in KerberosTime.
- This data would be used by the client to adjust for clock skew.
-
- REDIRECT = 2050
- The error data would consist of a hostname. The hostname would
- indicate the authoritative KDC from which to obtain a TGT.
-
-
-5.2 e-data types vs. error code specific data formats
-
- Since RFC 1510 does not define an error data type, the data format
- must be explicitly specified for each error code. This draft has
- proposed an extension to RFC 1510 that would introduce the concept
- of error data types. This would allow for a manageable set of data
- types to be used for any error message. The authors assume that
- the introduction of this e-data structure will not break any
- existing Kerberos implementations.
-
-
-6. Bibliography
-
- [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
- Service (V5). Request for Comments: 1510
- [2] J. Kohl, C. Neuman. The Kerberos Network Authentication
- Service (V5). Request for Comments: 1510 p.67
-
-
-7. Authors
-
- Ari Medvinsky <ari.medvinsky@cybersafe.com>
- Matthew Hur <matt.hur@cybersafe.com>
- Dominique Brezinski <dominique.brezinski@cybersafe.com>
-
- CyberSafe Corporation
- 1605 NW Sammamish Road
- Suite 310
- Issaquah, WA 98027-5378
- Phone: (206) 391-6000
- Fax: (206) 391-0508
- http:/www.cybersafe.com
-
-
- Brian Tung <brian@isi.edu>
- Gene Tsudik <gts@isi.edu>
-
- USC Information Sciences Institute
- 4676 Admiralty Way Suite 1001
- Marina del Rey CA 90292-6695
- Phone: (310) 822-1511
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt
deleted file mode 100644
index 4b193c57390c3b6bd8f13791cb0479701493c7c0..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt
+++ /dev/null
@@ -1,282 +0,0 @@
-INTERNET-DRAFT Brian Tung
-draft-ietf-cat-kerberos-pk-cross-01.txt Tatyana Ryutov
-Updates: RFC 1510 Clifford Neuman
-expires September 30, 1997 Gene Tsudik
- ISI
- Bill Sommerfeld
- Hewlett-Packard
- Ari Medvinsky
- Matthew Hur
- CyberSafe Corporation
-
-
- Public Key Cryptography for Cross-Realm Authentication in Kerberos
-
-
-0. Status Of this Memo
-
- This document is an Internet-Draft. 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.''
-
- To learn the current status of any Internet-Draft, please check
- the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
- Shadow Directories on ds.internic.net (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-01.txt, and expires September 30,
- 1997. Please send comments to the authors.
-
-
-1. Abstract
-
- This document defines extensions to the Kerberos protocol
- specification (RFC 1510, "The Kerberos Network Authentication
- Service (V5)", September 1993) to provide a method for using
- public key cryptography during 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. Motivation
-
- The advantages provided by public key cryptography--ease of
- recoverability in the event of a compromise, the possibility of
- an autonomous authentication infrastructure, to name a few--have
- produced a demand for use by Kerberos authentication protocol. A
- draft describing the use of public key cryptography in the initial
- authentication exchange in Kerberos has already been submitted.
- This draft describes its use in cross-realm authentication.
-
- The principal advantage provided by public key cryptography in
- cross-realm authentication lies in the ability to leverage the
- existing public key infrastructure. It frees the Kerberos realm
- administrator from having to maintain separate keys for each other
- realm with which it wishes to exchange authentication information,
- or to utilize a hierarchical arrangement, which may pose problems
- of trust.
-
- 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.
-
- The methods described in this draft allow a realm to specify, at
- the time of authentication, which certification paths it will
- trust. A shared key for cross-realm authentication can be
- established, for a period of time. Furthermore, these methods are
- transparent to the client, so that only the KDC's need to be
- modified to use them.
-
- It is not necessary to implement the changes described in the
- "Public Key Cryptography for Initial Authentication" draft to make
- use of the changes in this draft. We solicit comments about the
- interaction between the two protocol changes, but as of this
- writing, the authors do not perceive any obstacles to using both.
-
-
-3. Protocol Amendments
-
- We assume that the user has already obtained a TGT. To perform
- cross-realm authentication, the user sends a request to the local
- KDC as per RFC 1510. If the two realms share a secret key, then
- cross-realm authentication proceeds as usual. Otherwise, the
- local KDC may attempt to establish a shared key with the remote
- KDC using public key cryptography, and exchange this key through
- the cross-realm ticket granting ticket.
-
- We will consider the specific channel on which the message
- exchanges take place in Section 5 below.
-
-
-3.1. Changes to the Cross-Realm Ticket Granting Ticket
-
- In order to avoid the need for changes to the "installed base" of
- Kerberos application clients and servers, the only protocol change
- is to the way in which cross-realm ticket granting tickets (TGTs)
- are encrypted; as these tickets are opaque to clients and servers,
- the only change visible to them will be the increased size of the
- tickets.
-
- Cross-realm TGTs are granted by a local KDC to authenticate a user
- to a remote KDC's ticket granting service. In standard Kerberos,
- they are encrypted using a shared secret key manually configured
- into each KDC.
-
- In order to incorporate public key cryptography, we define a new
- encryption type, "ENCTYPE_PK_CROSS". Operationally, this encryption
- type transforms an OCTET STRING of plaintext (normally an EncTktPart)
- into the following SEQUENCE:
-
- PKCrossOutput ::= SEQUENCE {
- certificate [0] OCTET STRING OPTIONAL,
- -- public key certificate
- -- of local KDC
- encSharedKey [1] EncryptedData,
- -- of type EncryptionKey
- -- containing random symmetric key
- -- encrypted using public key
- -- of remote KDC
- sigSharedKey [2] Signature,
- -- of encSharedKey
- -- using signature key
- -- of local KDC
- pkEncData [3] EncryptedData,
- -- (normally) of type EncTktPart
- -- encrypted using encryption key
- -- found in encSharedKey
- }
-
- PKCROSS operates as follows: when a client submits a request for
- cross-realm authentication, the local KDC checks to see if it has
- a long-term shared key established for that realm. If so, it uses
- this key as per RFC 1510.
-
- If not, it sends a request for information to the remote KDC. The
- content of this message is immaterial, as it does not need to be
- processed by the remote KDC; for the sake of consistency, we define
- it as follows:
-
- RemoteRequest ::= [APPLICATION 41] SEQUENCE {
- nonce [0] INTEGER
- }
-
- The remote KDC replies with a list of all trusted certifiers and
- all its (the remote KDC's) certificates. We note that this response
- is universal and does not depend on which KDC makes the request:
-
- RemoteReply ::= [APPLICATION 42] SEQUENCE {
- trustedCertifiers [0] SEQUENCE OF PrincipalName,
- certificates[1] SEQUENCE OF Certificate,
- encTypeToUse [1] SEQUENCE OF INTEGER
- -- encryption types usable
- -- for encrypting pkEncData
- }
-
- Certificate ::= SEQUENCE {
- CertType [0] INTEGER,
- -- type of certificate
- -- 1 = X.509v3 (DER encoding)
- -- 2 = PGP (per PGP draft)
- CertData [1] OCTET STRING
- -- actual certificate
- -- type determined by CertType
- } -- from pk-init draft
-
- Upon receiving this reply, the local KDC determines whether it has
- a certificate the remote KDC trusts, and whether the remote KDC has
- a certificate the local KDC trusts. If so, it issues a ticket
- encrypted using the ENCTYPE_PK_CROSS encryption type defined above.
-
-
-3.2. Profile Caches
-
- We observe that using PKCROSS as specified above requires two
- private key operations: a signature generation by the local KDC and
- a decryption by the remote KDC. This cost can be reduced in the
- long term by judicious caching of the encSharedKey and the
- sigSharedKey.
-
- Let us define a "profile" as the encSharedKey and sigSharedKey, in
- conjunction with the associated remote realm name and decrypted
- shared key (the key encrypted in the encSharedKey).
-
- To optimize these interactions, each KDC maintains two caches, one
- for outbound profiles and one for inbound profiles. When generating
- an outbound TGT for another realm, the local KDC first checks to see
- if the corresponding entry exists in the outbound profile cache; if
- so, it uses its contents to form the first three fields of the
- PKCrossOutput; the shared key is used to encrypt the data for the
- fourth field. If not, the components are generated fresh and stored
- in the outbound profile cache.
-
- Upon receipt of the TGT, the remote realm checks its inbound profile
- cache for the corresponding entry. If it exists, then it uses the
- contents of the entry to decrypt the data encrypted in the pkEncData.
- If not, then it goes through the full process of verifying and
- extracting the shared key; if this is successful, then a new entry
- is created in the inbound profile cache.
-
- The inbound profile cache should support multiple entries per realm,
- in the event that the initiating realm is replicated.
-
-
-4. Finding Realms Supporting PKCROSS
-
- If either the local realm or the destination realm does not support
- PKCROSS, or both do not, the mechanism specified in Section 3 can
- still be used in obtaining the desired remote TGT.
-
- In the reference Kerberos implementations, the default behavior is
- to traverse a path up and down the realm name hierarchy, if the
- two realms do not share a key. There is, however, the possibility
- of using cross links--i.e., keys shared between two realms that
- are non-contiguous in the realm name hierarchy--to shorten the
- path, both to minimize delay and the number of intermediate realms
- that need to be trusted.
-
- PKCROSS can be used as a way to provide cross-links even in the
- absence of shared keys. If the client is aware that one or two
- intermediate realms support PKCROSS, then a combination of
- PKCROSS and conventional cross-realm authentication can be used
- to reach the final destination realm.
-
- We solicit discussion on the best methods for clients and KDCs to
- determine or advertise support for PKCROSS.
-
-
-5. Message Ports
-
- We have not specified the port on which KDCs supporting PKCROSS
- should listen to receive the request for information messages noted
- above. We solicit discussion on which port should be used. We
- propose to use the standard Kerberos ports (well-known 88 or 750),
- but another possibility is to use a completely different port.
-
- We also solicit discussion on what other approaches can be taken to
- obtain the information in the RemoteReply (e.g., secure DNS or some
- other repository).
-
-
-6. Expiration Date
-
- This Internet-Draft will expire on September 30, 1997.
-
-
-7. Authors' Addresses
-
- 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
-
- Bill Sommerfeld
- Hewlett Packard
- 300 Apollo Drive
- Chelmsford MA 01824
- Phone: +1 508 436 4352
- E-Mail: sommerfeld@apollo.hp.com
-
- Ari Medvinsky
- Matthew Hur
- CyberSafe Corporation
- 1605 NW Sammamish Road Suite 310
- Issaquah WA 98027-5378
- Phone: +1 206 391 6000
- E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
deleted file mode 100644
index d91c087dddf9c821a66baa1fba135f11265ae62b..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
+++ /dev/null
@@ -1,589 +0,0 @@
-
-INTERNET-DRAFT Clifford Neuman
-draft-ietf-cat-kerberos-pk-init-03.txt Brian Tung
-Updates: RFC 1510 ISI
-expires September 30, 1997 John Wray
- Digital Equipment Corporation
- Ari Medvinsky
- Matthew Hur
- CyberSafe Corporation
- Jonathan Trostle
- Novell
-
-
- Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0. Status Of this Memo
-
- This document is an Internet-Draft. 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."
-
- To learn the current status of any Internet-Draft, please check
- the "1id-abstracts.txt" listing contained in the Internet-Drafts
- Shadow Directories on ds.internic.net (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-03.txt, and expires September 30,
- 1997. 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 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.
-
- One of the guiding principles in the design of PKINIT is that
- changes should be as minimal as possible. As a result, the basic
- mechanism of PKINIT is as follows: The user sends a request to the
- KDC as before, except that if that user is to use public key
- cryptography in the initial authentication step, his certificate
- accompanies 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 instead
- of being encrypted in the user's long-term key (which is derived
- from a password), it is encrypted in a randomly-generated key. This
- random key is in turn encrypted using the public key certificate
- that came with the request and signed using the KDC's signature key,
- and accompanies the reply, in the preauthentication fields.
-
- PKINIT also allows for users with only digital signature keys to
- authenticate using those keys, and for users to store and retrieve
- private keys on the KDC.
-
- The PKINIT specification may also be used for direct peer to peer
- authentication without contacting a central KDC. This application
- of PKINIT is described in PKTAPP [4] and is based on concepts
- introduced in [5, 6]. 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 SSL [7] 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 [8]).
-
-
-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 changes to RFC 1510 are 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.
- --> Users may store private keys on the KDC for retrieval during
- Kerberos initial authentication.
-
- This proposal addresses two ways that users may use public key
- cryptography for initial authentication. Users may present public
- key certificates, or they may generate their own session key,
- signed by their digital signature key. In either case, the end
- result is that the user 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 and 3.3 describe the extensions for the two initial
- authentication methods. Section 3.3 describes a way for the user to
- store and retrieve his private key on the KDC.
-
-
-3.1. Definitions
-
- Hash and encryption types will be specified using ENCTYPE tags; we
- propose the addition of the following types:
-
- #define ENCTYPE_SIGN_DSA_GENERATE 0x0011
- #define ENCTYPE_SIGN_DSA_VERIFY 0x0012
- #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021
- #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022
-
- allowing further signature types to be defined in the range 0x0011
- through 0x001f, and further encryption types to be defined in the
- range 0x0021 through 0x002f.
-
- The extensions involve new preauthentication fields. The
- preauthentication data types are in the range 17 through 21.
- These values are also specified along with their corresponding
- ASN.1 definition.
-
- #define PA-PK-AS-REQ 17
- #define PA-PK-AS-REP 18
- #define PA-PK-AS-SIGN 19
- #define PA-PK-KEY-REQ 20
- #define PA-PK-KEY-REP 21
-
- The extensions also involve new error types. The new error types
- are in the range 227 through 229. They are:
-
- #define KDC_ERROR_CLIENT_NOT_TRUSTED 227
- #define KDC_ERROR_KDC_NOT_TRUSTED 228
- #define KDC_ERROR_INVALID_SIG 229
-
- In the exposition below, we use the following terms: encryption key,
- decryption key, signature key, verification key. It should be
- understood that encryption and verification keys are essentially
- public keys, and decryption and signature keys are essentially
- private keys. The fact that they are logically distinct does
- not preclude the assignment of bitwise identical keys.
-
-
-3.2. Standard Public Key Authentication
-
- Implementation of the changes in this section is REQUIRED for
- compliance with pk-init.
-
- It is assumed that all public keys are signed by some certification
- authority (CA). The initial authentication request is sent as per
- RFC 1510, except that a preauthentication field containing data
- signed by the user's signature key accompanies the request:
-
- PA-PK-AS-REQ ::- SEQUENCE {
- -- PA TYPE 17
- signedPKAuth [0] SignedPKAuthenticator,
- userCert [1] SEQUENCE OF Certificate OPTIONAL,
- -- the user's certificate
- -- optionally followed by that
- -- certificate's certifier chain
- trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL
- -- CAs that the client trusts
- }
-
- SignedPKAuthenticator ::= SEQUENCE {
- pkAuth [0] PKAuthenticator,
- pkAuthSig [1] Signature,
- -- of pkAuth
- -- using user's signature key
- }
-
- PKAuthenticator ::= SEQUENCE {
- cusec [0] INTEGER,
- -- for replay prevention
- ctime [1] KerberosTime,
- -- for replay prevention
- nonce [2] INTEGER,
- -- binds response to this request
- kdcName [3] PrincipalName,
- clientPubValue [4] SubjectPublicKeyInfo OPTIONAL,
- -- for Diffie-Hellman algorithm
- }
-
- Signature ::= SEQUENCE {
- signedHash [0] EncryptedData
- -- of type Checksum
- -- encrypted under signature key
- }
-
- Checksum ::= SEQUENCE {
- cksumtype [0] INTEGER,
- checksum [1] OCTET STRING
- } -- as specified by RFC 1510
-
- SubjectPublicKeyInfo ::= SEQUENCE {
- algorithm [0] algorithmIdentifier,
- subjectPublicKey [1] BIT STRING
- } -- as specified by the X.509 recommendation [9]
-
- Certificate ::= SEQUENCE {
- CertType [0] INTEGER,
- -- type of certificate
- -- 1 = X.509v3 (DER encoding)
- -- 2 = PGP (per PGP draft)
- CertData [1] OCTET STRING
- -- actual certificate
- -- type determined by CertType
- }
-
- Note: If the signature uses RSA keys, then it is to be performed
- as per PKCS #1.
-
- The PKAuthenticator carries information to foil replay attacks,
- to bind the request and response, and to optionally pass the
- client's Diffie-Hellman public value (i.e. for using DSA in
- combination with Diffie-Hellman). The PKAuthenticator is signed
- with the private key corresponding to the public key in the
- certificate found in userCert (or cached by the KDC).
-
- In the PKAuthenticator, the client may specify the KDC name in one
- of two ways: 1) a Kerberos principal name, or 2) the name in the
- KDC's certificate (e.g., an X.500 name, or a PGP name). Note that
- case #1 requires that the certificate name and the Kerberos principal
- name be bound together (e.g., via an X.509v3 extension).
-
- The userCert field is a sequence of certificates, the first of which
- must be the user's public key certificate. Any subsequent
- certificates will be certificates of the certifiers of the user's
- certificate. These cerificates may be used by the KDC to verify the
- user's public key. This field is empty if the KDC already has the
- user's certifcate.
-
- 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.
-
- 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 certification path does not match one of
- the KDC's trusted certifiers, the KDC sends back an error message of
- type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data
- field a list of its own trusted certifiers, upon which the client
- resends the request.
-
- If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
- verifies that it has a certificate issued by one of the certifiers
- trusted by the client. If it does not have a suitable certificate,
- the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
- to the client.
-
- If a trust relationship exists, the KDC then verifies the client's
- signature on PKAuthenticator. If that fails, the KDC returns an
- error message of type KDC_ERROR_INVALID_SIG. Otherwise, the KDC
- uses the timestamp in the PKAuthenticator to assure that the request
- is not a replay. The KDC also verifies that its name is specified
- in PKAuthenticator.
-
- Assuming no errors, the KDC replies as per RFC 1510, except that it
- encrypts the reply not with the user's key, but with a random key
- generated only for this particular response. This random key
- is sealed in the preauthentication field:
-
- PA-PK-AS-REP ::= SEQUENCE {
- -- PA TYPE 18
- kdcCert [0] SEQUENCE OF Certificate OPTIONAL,
- -- the KDC's certificate
- -- optionally followed by that
- -- certificate's certifier chain
- encPaReply [1] EncryptedData,
- -- of type PaReply
- -- using either the client public
- -- key or the Diffie-Hellman key
- -- specified by SignedDHPublicValue
- signedDHPublicValue [2] SignedDHPublicValue OPTIONAL
- }
-
-
- PaReply ::= SEQUENCE {
- replyEncKeyPack [0] ReplyEncKeyPack,
- replyEncKeyPackSig [1] Signature,
- -- of replyEncKeyPack
- -- using KDC's signature key
- }
-
- ReplyEncKeyPack ::= SEQUENCE {
- replyEncKey [0] EncryptionKey,
- -- used to encrypt main reply
- nonce [1] INTEGER
- -- binds response to the request
- -- passed in the PKAuthenticator
- }
-
- SignedDHPublicValue ::= SEQUENCE {
- dhPublicValue [0] SubjectPublicKeyInfo,
- dhPublicValueSig [1] Signature
- -- of dhPublicValue
- -- using KDC's signature key
- }
-
- The kdcCert field is a sequence of certificates, the first of which
- must have as its root certifier one of the certifiers sent to the
- KDC in the PA-PK-AS-REQ. Any subsequent certificates will be
- certificates of the certifiers of the KDC's certificate. These
- cerificates may be used by the client to verify the KDC's public
- key. This field is empty if the client did not send to the KDC a
- list of trusted certifiers (the trustedCertifiers field was empty).
-
- Since each certifier in the certification path of a user's
- certificate is essentially a separate realm, the name of each
- certifier shall be added to the transited field of the ticket. The
- format of these realm names shall follow the naming constraints set
- forth in RFC 1510 (sections 7.1 and 3.3.3.1). Note that this will
- require new nametypes to be defined for PGP certifiers and other
- types of realms as they arise.
-
- The KDC's certificate must bind the public key to a name derivable
- from the name of the realm for that KDC. 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.
-
-
-3.3. Digital Signature
-
- Implementation of the changes in this section are OPTIONAL for
- compliance with pk-init.
-
- We offer this option with the warning that it requires the client to
- generate a random key; the client may not be able to guarantee the
- same level of randomness as the KDC.
-
- If the user registered a digital signature key with the KDC instead
- of an encryption key, then a separate exchange must be used. The
- client sends a request for a TGT as usual, except that it (rather
- than the KDC) generates the random key that will be used to encrypt
- the KDC response. This key is sent to the KDC along with the
- request in a preauthentication field:
-
- PA-PK-AS-SIGN ::= SEQUENCE {
- -- PA TYPE 19
- encSignedKeyPack [0] EncryptedData
- -- of SignedKeyPack
- -- using the KDC's public key
- }
-
- SignedKeyPack ::= SEQUENCE {
- signedKey [0] KeyPack,
- signedKeyAuth [1] PKAuthenticator,
- signedKeySig [2] Signature
- -- of signedKey.signedKeyAuth
- -- using user's signature key
- }
-
- KeyPack ::= SEQUENCE {
- randomKey [0] EncryptionKey,
- -- will be used to encrypt reply
- nonce [1] INTEGER
- }
-
- where the nonce is copied from the request.
-
- Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
- the randomKey. It then replies as per RFC 1510, except that the
- reply is encrypted not with a password-derived user key, but with
- the randomKey sent in the request. Since the client already knows
- this key, there is no need to accompany the reply with an extra
- preauthentication field. The transited field of the ticket should
- specify the certification path as described in Section 3.2.
-
-
-3.4. Retrieving the Private Key From the KDC
-
- Implementation of the changes in this section is RECOMMENDED for
- compliance with pk-init.
-
- When the user's private key is not stored local to the user, he may
- choose to store the private key (normally encrypted using a
- password-derived key) on the KDC. We provide this option to present
- the user with an alternative to storing the private key on local
- disk at each machine where he expects to authenticate himself using
- pk-init. It should be noted that it replaces the added risk of
- long-term storage of the private key on possibly many workstations
- with the added risk of storing the private key on the KDC in a
- form vulnerable to brute-force attack.
-
- In order to obtain a private key, the client includes a
- preauthentication field with the AS-REQ message:
-
- PA-PK-KEY-REQ ::= SEQUENCE {
- -- PA TYPE 20
- patimestamp [0] KerberosTime OPTIONAL,
- -- used to address replay attacks.
- pausec [1] INTEGER OPTIONAL,
- -- used to address replay attacks.
- nonce [2] INTEGER,
- -- binds the reply to this request
- privkeyID [3] SEQUENCE OF KeyID OPTIONAL
- -- constructed as a hash of
- -- public key corresponding to
- -- desired private key
- }
-
- KeyID ::= SEQUENCE {
- KeyIdentifier [0] OCTET STRING
- }
-
- The client may request a specific private key by sending the
- corresponding ID. If this field is left empty, then all
- private keys are returned.
-
- If all checks out, the KDC responds as described in the above
- sections, except that an additional preauthentication field,
- containing the user's private key, accompanies the reply:
-
- PA-PK-KEY-REP ::= SEQUENCE {
- -- PA TYPE 21
- nonce [0] INTEGER,
- -- binds the reply to the request
- KeyData [1] SEQUENCE OF KeyPair
- }
-
- KeyPair ::= SEQUENCE {
- privKeyID [0] OCTET STRING,
- -- corresponding to encPrivKey
- encPrivKey [1] OCTET STRING
- }
-
-
-3.4.1. Additional Protection of Retrieved Private Keys
-
- We solicit discussion on the following proposal: that the client may
- optionally include in its request additional data to encrypt the
- private key, which is currently only protected by the user's
- password. One possibility is that the client might generate a
- random string of bits, encrypt it with the public key of the KDC (as
- in the SignedKeyPack, but with an ordinary OCTET STRING in place of
- an EncryptionKey), and include this with the request. The KDC then
- XORs each returned key with this random bit string. (If the bit
- string is too short, the KDC could either return an error, or XOR
- the returned key with a repetition of the bit string.)
-
- In order to make this work, additional means of preauthentication
- need to be devised in order to prevent attackers from simply
- inserting their own bit string. One way to do this is to store
- a hash of the password-derived key (the one used to encrypt the
- private key). This hash is then used in turn to derive a second
- key (called the hash-key); the hash-key is used to encrypt an ASN.1
- structure containing the generated bit string and a nonce value
- that binds it to the request.
-
- Since the KDC possesses the hash, it can generate the hash-key and
- verify this (weaker) preauthentication, and yet cannot reproduce
- the private key itself, since the hash is a one-way function.
-
-
-4. Logistics and Policy Issues
-
- We solicit discussion on how clients and KDCs should be configured
- in order to determine which of the options described above (if any)
- should be used. One possibility is to set the user's database
- record to indicate that authentication is to use public key
- cryptography; this will not work, however, in the event that the
- client needs to know before making the initial request.
-
-5. Compatibility with One-Time Passcodes
-
- We solicit discussion on how the protocol changes proposed in this
- draft will interact with the proposed use of one-time passcodes
- discussed in draft-ietf-cat-kerberos-passwords-00.txt.
-
-
-6. Strength of Cryptographic Schemes
-
- In light of recent findings on the strength of MD5 and DES,
- we solicit discussion on which encryption types to incorporate
- into the protocol changes.
-
-
-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] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
- Transport Layer Security (TLS).
- draft-ietf-tls-kerb-cipher-suites-00.txt
-
- [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
- Tickets for Application Servers (PKTAPP).
- draft-ietf-cat-pktapp-00.txt
-
- [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using
- Public Key Cryptography. Symposium On Network and Distributed System
- Security, 1997.
-
- [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
- Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce,
- July 1995.
-
- [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
- The SSL Protocol, Version 3.0 - IETF Draft.
-
- [8] B.C. Neuman, Proxy-Based Authorization and Accounting for
- Distributed Systems. In Proceedings of the 13th International
- Conference on Distributed Computing Systems, May 1993
-
- [9] ITU-T (formerly CCITT)
- Information technology - Open Systems Interconnection -
- The Directory: Authentication Framework Recommendation X.509
- ISO/IEC 9594-8
-
-
-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 30, 1997.
-
-
-10. Authors
-
- Clifford Neuman
- Brian Tung
- USC Information Sciences Institute
- 4676 Admiralty Way Suite 1001
- Marina del Rey CA 90292-6695
- Phone: +1 310 822 1511
- E-mail: {bcn, brian}@isi.edu
-
- John Wray
- Digital Equipment Corporation
- 550 King Street, LKG2-2/Z7
- Littleton, MA 01460
- Phone: +1 508 486 5210
- E-mail: wray@tuxedo.enet.dec.com
-
- Ari Medvinsky
- Matthew Hur
- CyberSafe Corporation
- 1605 NW Sammamish Road Suite 310
- Issaquah WA 98027-5378
- Phone: +1 206 391 6000
- E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
-
- Jonathan Trostle
- Novell
- E-mail: jonathan.trostle@novell.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt b/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
deleted file mode 100644
index 2284c3c6b57b8af22ba7c01c0fb2b22cd353f1e2..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
+++ /dev/null
@@ -1,8277 +0,0 @@
-
-INTERNET-DRAFT Clifford Neuman
- John Kohl
- Theodore Ts'o
- 11 July 1997
-
-
-
- The Kerberos Network Authentication Service (V5)
-
-
-STATUS OF THIS MEMO
-
- This document is an Internet-Draft. 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."
-
- To learn the current status of any Internet-Draft,
-please check the "1id-abstracts.txt" listing contained in
-the Internet-Drafts Shadow Directories on ds.internic.net
-(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-00.txt, and expires
-11 January 1998. 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 pro-
-vided in RFC1510. This document is intended to provide a
-detailed description of the protocol, suitable for implemen-
-tation, together with descriptions of the appropriate use of
-protocol messages and fields within those messages.
-
- This document is not intended to describe Kerberos to
-__________________________
-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.
-
-
-
-Overview - 1 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-the end user, system administrator, or application
-developer. Higher level papers describing Version 5 of the
-Kerberos system [1] and documenting version 4 [23], 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 proto-
-col.
-
- The motivations, goals, assumptions, and rationale
-behind most design decisions are treated cursorily; they are
-more fully described in a paper available in IEEE communica-
-tions [1] and earlier in the Kerberos portion of the Athena
-Technical Plan [2]. 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 [4]
-and on modifications suggested by Denning and Sacco [5].
-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 Ker-
-beros.
-
- Version 5 of the Kerberos protocol (described in this
-document) has evolved from Version 4 based on new require-
-ments 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 com-
-munity. 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. Reference implementa-
-tions of both version 4 and version 5 of Kerberos are pub-
-licly available and commercial implementations have been
-
-Overview - 2 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-developed and are widely used.
-
- Details on the differences between Kerberos Versions 4
-and 5 can be found in [6].
-
-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 per-
-forms 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 certifi-
-cation 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 con-
-tains the client's identity and a copy of the session key,
-all encrypted in the server's key) to the server. The ses-
-sion key (now shared by the client and server) is used to
-authenticate the client, and may optionally be used to
-__________________________
-[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.
-
-
-
-Section 1. - 3 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 transac-
-tions, 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 authenti-
-cation.
-
- 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 pro-
-tocol specification describes the AS and the TGS as separate
-servers, they are implemented in practice as different pro-
-tocol 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 tran-
-saction, 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, addi-
-tional information is sent to prove that the message ori-
-ginated 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 ses-
-sion key. Since no one except the requesting principal and
-
-
-Section 1. - 4 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 princi-
-pals 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 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, how-
-ever, 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
-__________________________
-[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.
-
-
-Section 1.1. - 5 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 tran-
-sited 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 authen-
-tication 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, intermedi-
-ate realms may be bypassed to achieve cross-realm authenti-
-cation 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.
-
-1.2. Authorization
-
-As an authentication service, Kerberos provides a means of
-verifying the identity of principals on a network. Authen-
-tication 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 con-
-sidered 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 [7] , or on other authorization services.
-
- Applications should not be modified to accept the
-issuance of a service ticket by the Kerberos server (even by
-
-Section 1.2. - 6 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-an 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
-where they interoperate with other KDCs or where other
-options for application authentication (e.g. the PKTAPP pro-
-posal) 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 Ker-
- beros. 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 not-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 suc-
- cessive 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 detec-
- tion. 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 net-
- work, 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.
-
-
-
-Section 1.3. - 7 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-1.4. Glossary of terms
-
-Below is a list of terms used throughout this document.
-
-
-Authentication Verifying the claimed identity of a
- principal.
-
-
-Authentication headerA 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 tran-
- sited 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 permis-
- sion 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).
-
-
-
-Section 1.4. - 8 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-Credentials A ticket plus the secret session key
- necessary to successfully use that
- ticket in an authentication exchange.
-
-
-KDC Key Distribution Center, a network ser-
- vice 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 ser-
- vice).
-
-
-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 authentica-
- tion service.
-
-
-Plaintext 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 identifierThe 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 life-
- time. In the case of a human user's
- principal, the secret key is derived
-
-
-Section 1.4. - 9 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- from a password.
-
-
-Server A particular Principal which provides a
- resource to network clients. The server
- is sometimes refered to as the Applica-
- tion 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 "ses-
- sion".
-
-
-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 dura-
- tion of a single association.
-
-
-Ticket A record that helps a client authenti-
- cate 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
-
-
-Section 2.1. - 10 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 tick-
-ets 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 inter-
-preted by the ticket-granting service (discussed below in
-section 3.3). It can usually be ignored by application
-servers. However, some particularly careful application
-
-
-Section 2.3. - 11 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 ser-
-viced. 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; post-
-dated 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
-
-
-Section 2.5. - 12 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 sec-
-tion to forward a ticket granting ticket.
-
- The PROXIABLE flag in a ticket is normally only inter-
-preted 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 grant-
-ing 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 ser-
-vice 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 authen-
-tication 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
-__________________________
-[4] Though it is permissible to request or issue tick-
-ets with no network addresses specified.
-
-
-Section 2.6. - 13 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 pro-
-cess FORWARDED tickets differently than non-FORWARDED tick-
-ets.
-
-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 indi-
-cates 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 pro-
-vided with the request. See section 3.3.3 for specific
-details.
-
-__________________________
-[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 sys-
-tem, the credentials obtained in the AS exchange may
-first be used in a TGS exchange to obtain credentials
-
-
-Section 3.1. - 14 - Expires 11 January 1998
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-
-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 creden-
-tials for a given server but currently holds no credentials.
-In its basic form, the client's secret key is used for en-
-cryption 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 ser-
-vices 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 sec-
-tions 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 ses-
-sion 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
-__________________________
-for a local server. Those credentials must then be
-verified by a local server through successful comple-
-tion of the Client/Server exchange.
-
-
-
-Section 3.1. - 15 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-message is not encrypted. The KRB_ERROR message contains
-information which can be used to associate it with the mes-
-sage 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 know-
-ing 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 ini-
-tial 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 pre-
-authentication as described in section <<sec preauth>>.
-
-3.1.1. Generation of KRB_AS_REQ message
-
- The client may specify a number of options in the ini-
-tial 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 sec-
-tion 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 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].
-__________________________
-
-
-Section 3.1.3. - 16 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
- 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 infor-
-mation 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 speci-
-fied, 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 cer-
-tain types or ranges of postdated tickets), and if accept-
-able, 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.
-
-
-
-
-
-
-
-
-
-__________________________
-[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 desir-
-able to use a truly random number generator, such as
-one based on measurements of random physical phenomena.
-
-
-
-Section 3.1.3. - 17 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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.
-
- The flags field of the new ticket will have the follow-
-ing options set if they have been requested and if the pol-
-icy 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
-
-
-Section 3.1.3. - 18 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 suf-
-ficient 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.
-
-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
-
-
-
-Section 3.2. - 19 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 authenti-
-cated 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 insuf-
-ficient to authenticate a client, since tickets are passed
-across the network in cleartext[8], 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 mes-
-sage 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 con-
-structs 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[9]. 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 col-
-lide with other sequence numbers in use.
-
- The client may indicate a requirement of mutual
-__________________________
-[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 un-
-reliable 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.
-
-
-
-Section 3.2.2. - 20 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 addi-
-tional 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 authentica-
-tor, 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 accept-
-able 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 indi-
-cates to the server that the ticket is encrypted in the ses-
-sion 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 encryp-
-tion 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
-__________________________
-[10] This is used for user-to-user authentication as
-described in [8].
-
-
-Section 3.2.3. - 21 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 authen-
-ticators 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 authentica-
-tor 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. Oth-
-erwise, 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
-__________________________
-[11] Note that the rejection here is restricted to au-
-thenticators from the same principal to the same
-server. Other client principals communicating with the
-same server principal should not be have their authen-
-ticators rejected if the time and microsecond fields
-happen to match some other client's authenticator.
-
-
-Section 3.2.3. - 22 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 ser-
-vice.
-
-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 ran-
-domly 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
-__________________________
-[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 mes-
-sages are formatted in such a way that it is not possi-
-ble to create the reply by judicious message surgery
-(even in encrypted form) without knowledge of the ap-
-propriate 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.
-
-
-Section 3.2.5. - 23 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-timestamp and microsecond fields match those in the Authen-
-ticator 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 check-
-sum type) to the application programmer; the Kerberos proto-
-col 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 protec-
-tion 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
-__________________________
-[14] Implementations of the protocol may wish to pro-
-vide 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.
-
-
-Section 3.2.6. - 24 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 authenti-
-cates to the system, such as when a user logs in). The mes-
-sage format for the TGS exchange is almost identical to that
-for the AS exchange. The primary difference is that encryp-
-tion 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 authentica-
-tion 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 col-
-lection 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 creden-
-tials, 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 authentica-
-tion header). The KRB_ERROR message contains an error code
-
-
-Section 3.3. - 25 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-and text explaining what went wrong. The KRB_ERROR message
-is not encrypted. The KRB_TGS_REP message contains informa-
-tion which can be used to detect replays, and to associate
-it with the message to which it replies. The KRB_ERROR mes-
-sage also contains information which can be used to associ-
-ate 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 ser-
-vice, the client must determine in which realm the applica-
-tion 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 mes-
-sage recursively). The Kerberos server may return a TGT for
-the desired realm in which case one can proceed. Alterna-
-tively, 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.
-__________________________
-[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 appli-
-cation server to the client.
-
-
-
-Section 3.3.1. - 26 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 appli-
-cation 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 authentica-
-tion 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 simi-
-lar 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 ser-
-vice, 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 grant-
-ing 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
-__________________________
-[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 ran-
-dom number and XOR it with the session key from the
-ticket-granting ticket.
-
-
-Section 3.3.2. - 27 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 sup-
-ported, 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
-
-
-Section 3.3.3. - 28 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 speci-
-fied, 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 dif-
-ferent, 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
-__________________________
-[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.
-
-
-Section 3.3.3. - 29 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 Authen-
-ticator, 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).
-
-
-
-Section 3.3.3.2. - 30 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 mali-
-cious 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 arrange-
-ment 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".
-__________________________
-[18] For the purpose of appending, the realm preceding
-the first listed realm is considered to be the null
-realm ("").
-
-
-Section 3.3.3.2. - 31 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 hierar-
-chy) 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 hierar-
-chy 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 pro-
-cessed in the same manner as the KRB_AS_REP processing
-described above. The primary difference is that the cipher-
-text part of the response must be decrypted using the ses-
-sion 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 informa-
-tion. 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
-__________________________
-[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 con-
-sidered to follow them.
-
-
-Section 3.4.1. - 32 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 prob-
-lem.
-
- 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 pro-
-tocol 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. 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
-__________________________
-[20] This means that a client and server running on the
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 check-
-sum 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 mes-
-sages 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 pro-
-tocol 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 gen-
-erated. The recipient verifies that the operating system's
-report of the sender's address matches the sender's address
-__________________________
-same host and communicating with one another using the
-KRB_SAFE messages should not share a common replay
-cache to detect KRB_SAFE replays.
-
-
-
-Section 3.5.2. - 34 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 mes-
-sage 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
-
-
-Section 3.6.2. - 35 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 gen-
-erated.
-
- 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 contain-
-ing 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 identif-
-ier
-key Principal's secret key
-p_kvno Principal's key version
-max_life Maximum lifetime for Tickets
-__________________________
-[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.
-
-
-Section 4.1. - 36 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 mas-
-ter 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 (end-
-time - 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 prin-
-cipal, 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
-
-
-Section 4.2. - 37 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 tick-
-ets as or for the principal. (A database may want to main-
-tain 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 con-
-trolled by the system-wide database service, Moira [9]), 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 authentica-
-tion, 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 modifica-
-tion 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
-__________________________
-[22] See the discussion of the padata field in section
-5.4.2 for details on why this can be useful.
-
-
-Section 4.3. - 38 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-section 5.2).
-
- Other frequently changing information that can be main-
-tained 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 confi-
-gurable 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 tick-
- ets 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 encryp-
-tion and checksum techniques, and the fields related to
-them, appear in section 6.
-
-5.1. ASN.1 Distinguished Encoding Representation
-
- All uses of ASN.1 in Kerberos shall use the Dis-
-tinguished Encoding Representation of the data elements as
-described in the X.509 specification, section 8.7 [10].
-
-
-
-
-
-Section 5.1. - 39 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 char-
-acter (_) 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 com-
-ponents consisting of the following sub-fields:
-
-name-type This field specifies the type of name that fol-
- lows. 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-stringThis field encodes a sequence of components that
- form a name, each component encoded as a General-
- String. Taken together, a PrincipalName and a
- Realm form a principal identifier. Most Princi-
- palNames will have only a few components (typi-
- cally one or two).
-
-
-
- KerberosTime ::= GeneralizedTime
- -- Specifying UTC time zone (Z)
-
-
- The timestamps used in Kerberos are encoded as General-
-izedTimes. 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
-
-
-Section 5.2. - 40 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- }
-
- HostAddresses ::= SEQUENCE OF SEQUENCE {
- addr-type[0] INTEGER,
- address[1] OCTET STRING
- }
-
-
- 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.
-
-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.
-
- 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),
-
-
-Section 5.2. - 41 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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),
- 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 multiple
- of 32 bits needed to include the highest order bit
- that is set (1), but in no case less than 32 bits.
- Implementations should accept values of bit
- strings of any length and treat the value of flags
- cooresponding to bits beyond the end of the bit
- string as if the bit were reset (0). Comparisonof
- 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].
-
-__________________________
-[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.
-
-
-
-Section 5.2. - 42 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 indi-
- cate 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 informa-
- tion 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).
-
-
-lr-value This field contains the time of the last request.
- The time must be interpreted according to the con-
- tents of the accompanying lr-type subfield.
-
- See section 6 for the definitions of Checksum, Check-
-sumType, EncryptedData, EncryptionKey, EncryptionType, and
-KeyType.
-
-
-5.3. Tickets and Authenticators
-
- This section describes the format and encryption param-
-eters for tickets and authenticators. When a ticket or
-authenticator is included in a protocol message it is
-treated as an opaque object.
-
-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
-}
-
-
-Section 5.3.1. - 43 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
--- 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 identi-
- cal.
-
-
-sname This field specifies the name part of the server's
- identity.
-
-
-enc-part This field holds the encrypted encoding of the
- EncTicketPart sequence.
-
-
-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:
-
-
-Section 5.3.1. - 44 - Expires 11 January 1998
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
- 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.
-
-
-
-
-
-
-
-
-Section 5.3.1. - 45 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
-
-
-
-Section 5.3.1. - 46 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
-Section 5.3.1. - 47 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
-
-
-
-Section 5.3.1. - 48 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
-
-authtime This field indicates the time of initial authenti-
- cation 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 implementa-
- tion of a `hot list' service at the KDC. An end
- service that is particularly paranoid could refuse
- to accept tickets for which the initial authenti-
- cation 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
-
-
-Section 5.3.1. - 49 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- (KRB_AS_REP), this is the current time on the Ker-
- beros 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-tillThis 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 abso-
- lute 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 sug-
- gested and default policy, however, is that such
- tickets will only be issued or accepted when addi-
- tional 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
-__________________________
-[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 actu-
-ally came from the proper KDC in a timely manner.
-
-
-Section 5.3.1. - 50 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 worksta-
- tion 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 ser-
- vice. 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 bases 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 addi-
- tional entries when a new ticket is obtained dur-
- ing 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, 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 ser-
- vice specific objects, and the rights to those
- objects. The format for this field is described
- in section 5.2. Although Kerberos is not con-
- cerned with the format of the contents of the sub-
- fields, it does carry type information (ad-type).
-
-
-
-Section 5.3.1. - 51 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 providing authoriza-
- tion or certifying group membership may be built
- using the authorization-data field. In this case,
- the entity granting authorization (not the author-
- ized entity), obtains a ticket in its own name
- (e.g. the ticket is issued in the name of a
- privelege server), and this entity adds restric-
- tions on its own authority and delegates the res-
- tricted authority through a proxy to the client.
- The client would then present this authorization
- credential to the application server separately
- from the authentication exchange.
-
- 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 [7] for some sug-
- gested 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
-}
-
-
-
-Section 5.3.2. - 52 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-authenticator-vno
- This field specifies the version number for the
- format of the authenticator. This document speci-
- fies 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 applica-
- tion specifies otherwise, if this field is left
- out the session key from the ticket will be used.
-
-seq-numberThis optional field includes the initial sequence
- number to be used by the KRB_PRIV or KRB_SAFE mes-
- sages when sequence numbers are used to detect
- replays (It may also be used by application
- specific messages). When included in the authen-
- ticator 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.
-
- 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.
-
-
-
-Section 5.3.2. - 53 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 car-
- ried 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
-
-
-Section 5.4.1. - 54 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 speci-
- fies the protocol version number. This document
- specifies protocol version 5.
-
-
-msg-type This field indicates the type of a protocol mes-
- sage. 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 con-
- tains 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 authenti-
- cation (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
-
-
-Section 5.4.1. - 55 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
- 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 [11] for
- additional uses of this field.
-
-padata-type
- The padata-type element of the padata field indi-
- cates 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:
-
-
-
-
-Section 5.4.1. - 56 - Expires 11 January 1998
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
-
-
-
-
-
-
-Section 5.4.1. - 57 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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.
-
-
-
-Section 5.4.1. - 58 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
-cname and sname
- These fields are the same as those described for
- the ticket in section 5.3.1. sname may only be
-
-
-Section 5.4.1. - 59 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- absent when the ENC-TKT-IN-SKEY option is speci-
- fied. 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 encod-
- ing 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.
-
-
-
-till This field contains the expiration date requested
- by the client in a ticket request. It is option
- 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 gen-
- erated randomly, but if the correct time is known,
- it may suffice[25].
-__________________________
-[25] Note, however, that if the time is used as the
-
-Section 5.4.1. - 60 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-etype This field specifies the desired encryption algo-
- rithm 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 per-
-form 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 subse-
-quent (TGS) request. There is no message type for
-__________________________
-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.
-
-
-
-Section 5.4.2. - 61 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 cipher-
-text is encrypted in the sub-session key from the Authenti-
-cator, or if absent, the session key from the ticket-
-granting ticket used in the request. In that case, no ver-
-sion 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.
-__________________________
-[27] An application code in the encrypted part of a
-message provides an additional check that the message
-was decrypted properly.
-
-
-Section 5.4.2. - 62 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 use-
- ful 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 appear-
- ance 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
-
-
-Section 5.4.2. - 63 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- client's secret key is due to expire. The expira-
- tion 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 expira-
- tion 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 sec-
- tion 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)
-
-
-Section 5.5.1. - 64 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-}
-
-
-pvno and msg-type
- These fields are described above in section 5.4.1.
- msg-type is KRB_AP_REQ.
-
-
-ap-optionsThis 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.
-
-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
-
-
-Section 5.5.2. - 65 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 associa-
-tion 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 ses-
- sion. 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 authentica-
- tor, or if also left out, the session key from the
- ticket will be used.
-
-
-
-__________________________
-[29] An application code in the encrypted part of a
-message provides an additional check that the message
-was decrypted properly.
-
-
-
-Section 5.5.2. - 66 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 exam-
-ple, 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. It is to be encoded separately
- and then have the checksum computed over it, for
- use in the cksum field.
-
-
-
-Section 5.6.1. - 67 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-cksum This field contains the checksum of the applica-
- tion data. Checksum details are described in sec-
- tion 6.4. The checksum is computed over the
- encoding of the KRB-SAFE-BODY sequence.
-
-
-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 reci-
- pient.
-
-
-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.
-
-
-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:
-
-__________________________
-[31] An application code in the encrypted part of a
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-
-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
-__________________________
-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 mes-
-sage, 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 algo-
-rithm will be used.
-
-
-Section 5.8. - 69 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-another. It is presented here to encourage a common mechan-
-ism 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 KRB_CRED.
-
-
-
-
-Section 5.8.1. - 70 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-tickets
- These are the tickets obtained from the KDC
- specifically for use by the intended recipient.
- Successive tickets are paired with the correspond-
- ing 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 mes-
- sage 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 pro-
- vide 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 mes-
- sage.
-
-
-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
-
-
-Section 5.8.1. - 71 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 not protected
-by any encryption, it is quite possible for an intruder to
-synthesize or modify such a message. In particular, this
-means that the client should not use any fields in this mes-
-sage for security-critical purposes, such as setting a sys-
-tem 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
-}
-
-
-
-
-
-Section 5.9.1. - 72 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 rea-
- sonably accurate timestamp.
-
-
-error-codeThis 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 sup-
- port 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 the error-
- code is KDC_ERR_PREAUTH_REQUIRED, then the e-data
- field will contain an encoding of a sequence of
- padata fields, each corresponding to an acceptable
- pre-authentication method and optionally contain-
- ing data for the method:
-
-
-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
-
-
-Section 5.9.1. - 73 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- message with the checksum absent. The checksum is
- then added to the KRB-ERROR structure and the mes-
- sage is re-encoded. The Checksum should be calcu-
- lated using the session key from the ticket grant-
- ing 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 preau-
- thentication to prove knowledge of the secret key
- by the client[33]. If a checksum can not be com-
- puted because the key to be used is not available,
- no checksum will be included.
-
- METHOD-DATA ::= SEQUENCE of PA-DATA
-
-
- If the error-code is KRB_AP_ERR_METHOD, then the
- e-data field will contain an encoding of the fol-
- lowing sequence:
-
- METHOD-DATA ::= SEQUENCE {
- method-type[0] INTEGER,
- method-data[1] OCTET STRING OPTIONAL
- }
-
- method-type will indicate the required alternate
- method; method-data will contain any required
- additional information.
-
-
-
-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, [12] in conjunction
-with block chaining and checksum methods [13]. Encryption
-is used to prove the identities of the network entities par-
-ticipating 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 confi-
-dence. 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
-__________________________
-[33] This prevents an attacker who generates an in-
-correct AS request from obtaining verifiable plaintext
-for use in an off-line password guessing attack.
-
-
-Section 6. - 74 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 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 dif-
-ficult. 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 con-
-founder 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 map-
-ping 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.
-
-
-
-Section 6. - 75 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- For an discussion of the integrity characteristics of
-the candidate encryption and checksum methods considered for
-Kerberos, the the reader is referred to [14].
-
-6.1. Encryption Specifications
-
- The following ASN.1 definition describes all encrypted
-messages. The enc-part field which appears in the unen-
-crypted part of messages in section 5 is a sequence consist-
-ing 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 specif-
- ications for selected encryption types appear
- later in this section.
-
-
-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 dic-
-tionary 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 suffi-
-cient to hold the appropriate item. The type and length is
-implicit and specified by the particular encryption type
-
-
-Section 6.1. - 76 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-being used (etype). The format for the data to be encrypted
-is described in the following diagram:
-
- +-----------+----------+-------------+-----+
- |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; calcu-
-lates 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 encryp-
-tion 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
-__________________________
-[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 be-
-cause they are specified by the encryption type.
-[36] The ordering of the fields in the CipherText is
-important. Additionally, messages encoded in this for-
-mat 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 mes-
-sage which could be truncated, while leaving the check-
-sum 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.
-
-
-
-Section 6.1. - 77 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 encryp-
-tion 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 addi-
-tional 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 key
- that follows in the keyvalue field. It will
- almost always correspond to the encryption algo-
- rithm used to generate the EncryptedData, though
- more than one algorithm may use the same type of
- key (the mapping is many to one). This might hap-
- pen, for example, if the encryption algorithm uses
- an alternate checksum algorithm for an integrity
- check, or a different chaining mechanism.
-
-
-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 encryp-
-tion 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).
-
-
-
-Section 6.3.1. - 78 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 [12] using the cipher
-block chaining mode [13]. A CRC-32 checksum (described in
-ISO 3309 [15]) 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 con-
-founder is used [14]. 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 Specifi-
-cation 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 [12] using the cipher
-block chaining mode [13]. An MD4 checksum (described in
-[16]) 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 concate-
-nation 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 [12] using the cipher
-block chaining mode [13]. An MD5 checksum (described in
-[17].) 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 concate-
-nation of confounder, checksum, and message) must be padded
-to an 8 byte boundary before encryption.
-
- Plaintext and DES ciphtertext are encoded as 8-octet
-blocks 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
-
-
-Section 6.3.4. - 79 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-bits, ..., and the eighth octet supplies the 8 least signi-
-ficant bits.
-
- Encryption under DES using cipher block chaining
-requires an additional input in the form of an initializa-
-tion 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 mes-
-sages 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 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.]
-
- To generate a DES key from a text string (password),
-the text string normally must have the realm and each com-
-ponent of the principal's name appended[37], then padded
-with ASCII nulls to an 8 byte boundary. This string is then
-fan-folded and eXclusive-ORed with itself to form an 8 byte
-DES key. The parity is corrected on the key, and it is used
-to generate a DES CBC checksum on the initial string (with
-the realm and name appended). Next, parity is corrected on
-the CBC checksum. If the result matches a "weak" or "semi-
-weak" key as described in the DES specification, it is
-eXclusive-ORed with the constant 00000000000000F0. Finally,
-the result is returned as the key. Pseudocode follows:
-
- string_to_key(string,realm,name) {
- odd = 1;
- s = string + realm;
- for(each component in name) {
- s = s + component;
- }
- tempkey = NULL;
- pad(s); /* with nulls to 8 byte boundary */
- for(8byteblock in s) {
-__________________________
-[37] In some cases, it may be necessary to use a dif-
-ferent "mix-in" string for compatibility reasons; see
-the discussion of padata in section 5.4.2.
-
-
-Section 6.3.4. - 80 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- if(odd == 0) {
- odd = 1;
- reverse(8byteblock)
- }
- else odd = 0;
- tempkey = tempkey XOR 8byteblock;
- }
- fixparity(tempkey);
- key = DES-CBC-check(s,tempkey);
- fixparity(key);
- if(is_weak_key_key(key))
- key = key XOR 0xF0;
- return(key);
- }
-
-6.3.5. Triple DES EDE in outer CBC mode with an SHA1 check-
-sum (des3-cbc-sha1)
-
- The des3-cbc-sha1 encryption encodes information using
-three Data Encryption Standard transformations with three
-DES keys. The first key is used to perform a DES ECB
-encryption on an eight-octet data block using the first DES
-key, followed by a DES ECB decryption of the result using
-the second DES key, and a DES ECB encryption of the result
-using the third DES key. Because DES blocks are 8 bytes,
-the data to be encrypted (the concatenation of confounder,
-checksum, and message) must first be padded to an 8 byte
-boundary before encryption. To support the outer CBC mode,
-the input is padded an eight-octet boundary. The first 8
-octets of the data to be encrypted (the confounder) is
-exclusive-ored with an initialization vector of zero and
-then ECB encrypted using triple DES as described above.
-Subsequent blocks of 8 octets are exclusive-ored with the
-ciphertext produced by the encryption on the previous block
-before ECB encryption.
-
- An HMAC-SHA1 checksum (described in [18].) is applied
-to the confounder and message sequence (msg-seq) and placed
-in the cksum field.
-
- Plaintext are encoded as 8-octet blocks which are con-
-catenated 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 Triple DES using cipher block chaining
-requires an additional input in the form of an initializa-
-tion 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-
-
-
-Section 6.3.5. - 81 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-weak" keys; those keys shall not be used for encrypting mes-
-sages 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 constant F0F0F0F0F0F0F0F0.
-
- A Triple DES key is 24 octets of data, with keytype
-seven (7). This consists of 168 bits of key, and 24 parity
-bits (one per octet). The key is encoded as a series of 24
-octets written in MSB-first order, with the first 8 octets
-treated as the first DES key, the second 8 octets as the
-second key, and the third 8 octets the third DES key. The
-bits within each 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.]
-
- To generate a DES key from a text string (password),
-the text string normally must have the realm and each com-
-ponent of the principal's name appended[38],
-
- The input string (with any salt data appended to it) is
-n-folded into a 24 octet (192 bit) string. 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 X is rotated to the right by 13 bit
-positions. The successive n-bit chunks are added together
-using 1's-complement addition (addition with end-around
-carry) to yield a n-bit result. (This transformation was
-proposed by Richard Basch)
-
- Each successive set of 8 octets is taken as a DES key,
-and its parity is adjusted in the same manner as previously
-described. If any of the three sets of 8 octets match a
-"weak" or "semi-weak" key as described in the DES specifica-
-tion, that chunk is eXclusive-ORed with the constant
-00000000000000F0. The resulting DES keys are then used in
-sequence to perform a Triple-DES CBC encryption of the n-
-folded input string (appended with any salt data), using a
-zero initial vector. Parity, weak, and semi-weak keys are
-once again corrected and the result is returned as the 24
-octet key.
-
- Pseudocode follows:
-
- string_to_key(string,realm,name) {
-__________________________
-[38] In some cases, it may be necessary to use a dif-
-ferent "mix-in" string for compatibility reasons; see
-the discussion of padata in section 5.4.2.
-
-
-Section 6.3.5. - 82 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- s = string + realm;
- for(each component in name) {
- s = s + component;
- }
- tkey[24] = fold(s);
- fixparity(tkey);
- if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0;
- if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0;
- if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0;
- key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0);
- fixparity(key);
- if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0;
- if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0;
- if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0;
- return(key);
- }
-
-6.4. Checksums
-
- The following is the ASN.1 definition used for a check-
-sum:
-
- Checksum ::= SEQUENCE {
- cksumtype[0] INTEGER,
- checksum[1] OCTET STRING
- }
-
-
-cksumtype This field indicates the algorithm used to gen-
- erate 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 subse-
-quently 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 mes-
-sage. In such cases, the composition of the checksum and
-
-
-Section 6.4. - 83 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 [15]. 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 proba-
-bilistic chosen-plaintext attack as described in [14] 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 [16]. 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
-__________________________
-[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 per-
-formed 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 pur-
-pose in the Message Integrity Check in the Privacy
-Enhanced Mail standard.
-
-
-Section 6.4.3. - 84 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-"semi-weak keys"; those keys shall not be used for generat-
-ing 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. [17]. 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 constant F0F0F0F0F0F0F0F0. The initialization vec-
-tor 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 encrypt-
-ing RSA-MD5 checksums for use in Kerberos.
-
- The format for the checksum is described in the follow-
-ing 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
-
-
-Section 6.4.5. - 85 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 constant F0F0F0F0F0F0F0F0. The initializa-
-tion 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 follow-
-ing 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
-
-
-Section 6.4.7. - 86 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 vec-
-tor 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 generat-
-ing 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 (/). Domain names must be converted
-to upper case when used as realm names.
-
- X.500 names contain an equal (=) and cannot contain a
-
-
-Section 7.1. - 87 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 organiza-
-tion 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 adminis-
-trator 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 dif-
-ferent). This constraint may be eliminated in the future.
-The following name types are defined:
-
- name-type value meaning
-
-
-Section 7.2. - 88 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
-
-
-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 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 UNK-
-NOWN.
-
- 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
-
-
-Section 7.2.1. - 89 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 interpreta-
-tions.
-
- 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 <sys/socket.h> with symbolic names AF_xxx (where xxx is
-an abbreviation of the address family name).
-
-
-Internet addresses
-
- Internet addresses are 32-bit (4-octet) quantities,
-encoded in MSB order. The type of internet addresses is two
-(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).
-
-
-Section 8.1. - 90 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 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 net-
-work 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).
-
-8.2. KDC messages
-
-8.2.1. 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). Servers may also accept
-TCP requests on port 88 (decimal). When the KRB_KDC_REQ
-message is sent to the KDC by TCP, a new connection will be
-established for each authentication exchange and the
-KRB_KDC_REP or KRB_ERROR message will be returned to the
-client on the TCP stream that was established for the
-request. The connection will be broken after the reply has
-been received (or upon time-out). 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.
-
-8.2.2. 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 mechan-
-ism 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
-
-
-Section 8.2.2. - 91 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-(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.
-
-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
-<reserved> 6
-des3-cbc-sha1 7 8 0 8
-sign-dsa-generate 8 (pkinit)
-encrypt-rsa-priv 9 (pkinit)
-encrypt-rsa-pub 10 (pkinit)
-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
-rsa-md5 7 16
-rsa-md5-des 8 24
-rsa-md5-des3 9 24
-hmac-sha1-des3 10 20 (I had this as 10, is it 12)
-
-
-Section 8.3. - 92 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-padata type padata-type value
-
-PA-TGS-REQ 1
-PA-ENC-TIMESTAMP 2
-PA-PW-SALT 3
-<reserved> 4
-PA-ENC-UNIX-TIME 5
-PA-SANDIA-SECUREID 6
-PA-SESAME 7
-PA-OSF-DCE 8
-PA-CYBERSAFE-SECUREID 9
-PA-AFS3-SALT 10
-PA-ETYPE-INFO 11
-SAM-CHALLENGE 12 (sam/otp)
-SAM-RESPONSE 13 (sam/otp)
-PA-PK-AS-REQ 14 (pkinit)
-PA-PK-AS-REP 15 (pkinit)
-PA-PK-AS-SIGN 16 (pkinit)
-PA-PK-KEY-REQ 17 (pkinit)
-PA-PK-KEY-REP 18 (pkinit)
-
-authorization data type ad-type value
-reserved values 0-63
-OSF-DCE 64
-SESAME 65
-
-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
-
-
-Section 8.3. - 93 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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
-
-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-
-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
-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
-
-
-
-Section 8.3. - 94 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message
-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)
-
-
-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 authentica-
-tion, user to user authentication, support for proxies, for-
-warding, 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 configura-
-tion 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 1
-
- This section defines the first specification of these
-options. Implementations which are configured in this way
-can be said to support Kerberos Version 5 Specification 1
-(5.1).
-
-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
-Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
-
-
-__________________________
-- 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.
-
-
-
-Section 9.1. - 95 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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.
-
-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 pre-
-authentication 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 deriva-
-tive 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. Indi-
-vidual realms and application servers can set their own pol-
-icy on when such tickets will be accepted.
-
- All implementations must recognize renewable and post-
-dated 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 imple-
-mentations shall make the presence of the postdated flag
-
-
-Section 9.1. - 96 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 defin-
-ition 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 authori-
-zation 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.
-
-9.2. Recommended KDC values
-
-Following is a list of recommended values for a KDC imple-
-mentation, based on the list of suggested configuration con-
-stants (see section 4.4).
-
-minimum lifetime 5 minutes
-
-maximum renewable lifetime1 week
-
-maximum ticket lifetime1 day
-
-empty addresses only when suitable restrictions appear
- in authorization data
-
-proxiable, etc. Allowed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Section 9.2. - 97 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-10. REFERENCES
-
-
-
-1. 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).
-
-2. 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).
-
-3. 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).
-
-4. 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).
-
-5. 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).
-
-6. 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).
-
-7. 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).
-
-8. Don Davis and Ralph Swick, "Workstation Services and
- Kerberos Authentication at Project Athena," Technical
- Memorandum TM-424, MIT Laboratory for Computer Science
- (February 1990).
-
-9. 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).
-
-10. CCITT, Recommendation X.509: The Directory Authentica-
- tion Framework, December 1988.
-
-11. J. Pato, Using Pre-Authentication to Avoid Password
- Guessing Attacks, Open Software Foundation DCE Request
- for Comments 26 (December 1992).
-
-
-
-Section 10. - 98 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-12. National Bureau of Standards, U.S. Department of Com-
- merce, "Data Encryption Standard," Federal Information
- Processing Standards Publication 46, Washington, DC
- (1977).
-
-13. National Bureau of Standards, U.S. Department of Com-
- merce, "DES Modes of Operation," Federal Information
- Processing Standards Publication 81, Springfield, VA
- (December 1980).
-
-14. 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).
-
-15. 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.
-
-16. R. Rivest, "The MD4 Message Digest Algorithm," RFC
- 1320, MIT Laboratory for Computer Science (April
- 1992).
-
-17. R. Rivest, "The MD5 Message Digest Algorithm," RFC
- 1321, MIT Laboratory for Computer Science (April
- 1992).
-
-18. H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication," Working Draft
- draft-ietf-ipsec-hmac-md5-01.txt, (August 1996).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Section 10. - 99 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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;
-
- client := lookup(req.cname,req.realm);
- server := lookup(req.sname,req.realm);
-
-
-Section A.2. - 100 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-
- 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
-
-
-Section A.2. - 101 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
- 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;
-
-
-Section A.2. - 102 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
- 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);
-
-
-
-Section A.2. - 103 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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
- 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;
-
-
-Section A.4. - 104 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
-
-
-Section A.5. - 105 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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);
-
- 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
-
-
-Section A.6. - 106 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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(server)) then
- server := best_intermediate_tgs(server);
- 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;
-
-
-Section A.6. - 107 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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);
- 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
-
-
-Section A.6. - 108 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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);
-
- 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,
-
-
-Section A.6. - 109 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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)
- 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;
-
-
-
-Section A.6. - 110 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- destroy resp.key;
- return error;
- endif
-
- check authorization_data as necessary;
- save_for_later(ticket,session,client,server,times,flags);
-
-
-
-Section A.7. - 111 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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};
-
-
-Section A.10. - 112 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 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
- /* 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 */
-
-
-Section A.11. - 113 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
- 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;
-
-
-Section A.13. - 114 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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
-
-
-Section A.15. - 115 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 */
-
- 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
-
-
-Section A.17. - 116 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
- 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
-
-
-Section A.18. - 117 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- (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
-
-
-Section A.20. - 118 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 119 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - cxx - Expires 11 January 1998
-
-
-
-
-
-
-
-
-
-
- Table of Contents
-
-
-
-
-Overview .............................................. 2
-
-Background ............................................ 2
-
-1. Introduction ....................................... 3
-
-1.1. Cross-Realm Operation ............................ 5
-
-1.2. Authorization .................................... 6
-
-1.3. Environmental assumptions ........................ 7
-
-1.4. Glossary of terms ................................ 8
-
-2. Ticket flag uses and requests ...................... 10
-
-2.1. Initial and pre-authenticated tickets ............ 10
-
-2.2. Invalid tickets .................................. 11
-
-2.3. Renewable tickets ................................ 11
-
-2.4. Postdated tickets ................................ 12
-
-2.5. Proxiable and proxy tickets ...................... 12
-
-2.6. Forwardable tickets .............................. 13
-
-2.7. Other KDC options ................................ 14
-
-3. Message Exchanges .................................. 14
-
-3.1. The Authentication Service Exchange .............. 14
-
-3.1.1. Generation of KRB_AS_REQ message ............... 16
-
-3.1.2. Receipt of KRB_AS_REQ message .................. 16
-
-3.1.3. Generation of KRB_AS_REP message ............... 16
-
-3.1.4. Generation of KRB_ERROR message ................ 19
-
-3.1.5. Receipt of KRB_AS_REP message .................. 19
-
-3.1.6. Receipt of KRB_ERROR message ................... 19
-
-3.2. The Client/Server Authentication Exchange ........ 19
-
-3.2.1. The KRB_AP_REQ message ......................... 20
-
-
- - i - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-3.2.2. Generation of a KRB_AP_REQ message ............. 20
-
-3.2.3. Receipt of KRB_AP_REQ message .................. 21
-
-3.2.4. Generation of a KRB_AP_REP message ............. 23
-
-3.2.5. Receipt of KRB_AP_REP message .................. 23
-
-3.2.6. Using the encryption key ....................... 24
-
-3.3. The Ticket-Granting Service (TGS) Exchange ....... 25
-
-3.3.1. Generation of KRB_TGS_REQ message .............. 26
-
-3.3.2. Receipt of KRB_TGS_REQ message ................. 27
-
-3.3.3. Generation of KRB_TGS_REP message .............. 28
-
-3.3.3.1. Checking for revoked tickets ................. 30
-
-3.3.3.2. Encoding the transited field ................. 30
-
-3.3.4. Receipt of KRB_TGS_REP message ................. 32
-
-3.4. The KRB_SAFE Exchange ............................ 32
-
-3.4.1. Generation of a KRB_SAFE message ............... 32
-
-3.4.2. Receipt of KRB_SAFE message .................... 33
-
-3.5. The KRB_PRIV Exchange ............................ 34
-
-3.5.1. Generation of a KRB_PRIV message ............... 34
-
-3.5.2. Receipt of KRB_PRIV message .................... 34
-
-3.6. The KRB_CRED Exchange ............................ 35
-
-3.6.1. Generation of a KRB_CRED message ............... 35
-
-3.6.2. Receipt of KRB_CRED message .................... 35
-
-4. The Kerberos Database .............................. 36
-
-4.1. Database contents ................................ 36
-
-4.2. Additional fields ................................ 37
-
-4.3. Frequently Changing Fields ....................... 38
-
-4.4. Site Constants ................................... 39
-
-5. Message Specifications ............................. 39
-
-
-
- - ii - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-5.1. ASN.1 Distinguished Encoding Representation ...... 39
-
-5.2. ASN.1 Base Definitions ........................... 40
-
-5.3. Tickets and Authenticators ....................... 43
-
-5.3.1. Tickets ........................................ 43
-
-5.3.2. Authenticators ................................. 52
-
-5.4. Specifications for the AS and TGS exchanges ...... 54
-
-5.4.1. KRB_KDC_REQ definition ......................... 54
-
-5.4.2. KRB_KDC_REP definition ......................... 61
-
-5.5. Client/Server (CS) message specifications ........ 64
-
-5.5.1. KRB_AP_REQ definition .......................... 64
-
-5.5.2. KRB_AP_REP definition .......................... 65
-
-5.5.3. Error message reply ............................ 67
-
-5.6. KRB_SAFE message specification ................... 67
-
-5.6.1. KRB_SAFE definition ............................ 67
-
-5.7. KRB_PRIV message specification ................... 68
-
-5.7.1. KRB_PRIV definition ............................ 68
-
-5.8. KRB_CRED message specification ................... 69
-
-5.8.1. KRB_CRED definition ............................ 70
-
-5.9. Error message specification ...................... 72
-
-5.9.1. KRB_ERROR definition ........................... 72
-
-6. Encryption and Checksum Specifications ............. 74
-
-6.1. Encryption Specifications ........................ 76
-
-6.2. Encryption Keys .................................. 78
-
-6.3. Encryption Systems ............................... 78
-
-6.3.1. The NULL Encryption System (null) .............. 78
-
-6.3.2. DES in CBC mode with a CRC-32 checksum (des-
-cbc-crc) .............................................. 79
-
-6.3.3. DES in CBC mode with an MD4 checksum (des-
-
-
- - iii - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-cbc-md4) .............................................. 79
-
-6.3.4. DES in CBC mode with an MD5 checksum (des-
-cbc-md5) .............................................. 79
-
-6.3.5. Triple DES EDE in outer CBC mode with an SHA1
-checksum (des3-cbc-sha1) .............................. 81
-
-6.4. Checksums ........................................ 83
-
-6.4.1. The CRC-32 Checksum (crc32) .................... 84
-
-6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 84
-
-6.4.3. RSA MD4 Cryptographic Checksum Using DES
-(rsa-md4-des) ......................................... 84
-
-6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 85
-
-6.4.5. RSA MD5 Cryptographic Checksum Using DES
-(rsa-md5-des) ......................................... 85
-
-6.4.6. DES cipher-block chained checksum (des-mac)
-
-6.4.7. RSA MD4 Cryptographic Checksum Using DES
-alternative (rsa-md4-des-k) ........................... 86
-
-6.4.8. DES cipher-block chained checksum alternative
-(des-mac-k) ........................................... 87
-
-7. Naming Constraints ................................. 87
-
-7.1. Realm Names ...................................... 87
-
-7.2. Principal Names .................................. 88
-
-7.2.1. Name of server principals ...................... 89
-
-8. Constants and other defined values ................. 90
-
-8.1. Host address types ............................... 90
-
-8.2. KDC messages ..................................... 91
-
-8.2.1. IP transport ................................... 91
-
-8.2.2. OSI transport .................................. 91
-
-8.2.3. Name of the TGS ................................ 92
-
-8.3. Protocol constants and associated values ......... 92
-
-9. Interoperability requirements ...................... 95
-
-
-
- - iv - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-9.1. Specification 1 .................................. 95
-
-9.2. Recommended KDC values ........................... 97
-
-10. REFERENCES ........................................ 98
-
-A. Pseudo-code for protocol processing ................ 100
-
-A.1. KRB_AS_REQ generation ............................ 100
-
-A.2. KRB_AS_REQ verification and KRB_AS_REP genera-
-tion .................................................. 100
-
-A.3. KRB_AS_REP verification .......................... 104
-
-A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 104
-
-A.5. KRB_TGS_REQ generation ........................... 105
-
-A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen-
-eration ............................................... 106
-
-A.7. KRB_TGS_REP verification ......................... 111
-
-A.8. Authenticator generation ......................... 112
-
-A.9. KRB_AP_REQ generation ............................ 112
-
-A.10. KRB_AP_REQ verification ......................... 112
-
-A.11. KRB_AP_REP generation ........................... 113
-
-A.12. KRB_AP_REP verification ......................... 114
-
-A.13. KRB_SAFE generation ............................. 114
-
-A.14. KRB_SAFE verification ........................... 115
-
-A.15. KRB_SAFE and KRB_PRIV common checks ............. 115
-
-A.16. KRB_PRIV generation ............................. 116
-
-A.17. KRB_PRIV verification ........................... 116
-
-A.18. KRB_CRED generation ............................. 117
-
-A.19. KRB_CRED verification ........................... 118
-
-A.20. KRB_ERROR generation ............................ 118
-
-
-
-
-
-
-
- - v - Expires 11 January 1998
-
-
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt b/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt
deleted file mode 100644
index 78db9d78f3cb2c45f0d6f73be748ef0f763cf98c..0000000000000000000000000000000000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt
+++ /dev/null
@@ -1,6214 +0,0 @@
-
-INTERNET-DRAFT Clifford Neuman
- John Kohl
- Theodore Ts'o
- 21 November 1997
-
-The Kerberos Network Authentication Service (V5)
-
-STATUS OF THIS MEMO
-
-This document is an Internet-Draft. 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.'
-
-To learn the current status of any Internet-Draft, please check the
-'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
-Directories on ds.internic.net (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-r-01.txt, and expires 21 May 1998. 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
-available in IEEE communications [NT94] and earlier in the Kerberos portion
-of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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.
-
-Applications should not be modified to accept the issuance of a service
-ticket by the Kerberos server (even by an 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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- * 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
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- (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.
-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
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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).
-
-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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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
-
-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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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).
-
-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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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 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,
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-"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
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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:
-
- "/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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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. 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.
-
-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. The recipient verifies that the
-operating system's report of the sender's address matches the sender's
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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
-generated.
-
-If present or required, the recipient verifies that the operating system's
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 contain- ing 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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.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
-}
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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)
-}
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-KDCOptions ::= BIT STRING {
- reserved(0),
- forwardable(1),
- forwarded(2),
- proxiable(3),
- proxy(4),
- allow-postdate(5),
- postdated(6),
- 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 multiple of 32 bits needed to
-include the highest order bit that is set (1), but in no case less than 32
-bits. Implementations should accept values of bit strings of any length and
-treat the value of flags cooresponding to bits beyond the end of the bit
-string as if the bit were reset (0). Comparisonof 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).
-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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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.
-
-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,
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- the two will always be identical.
-sname
- This field specifies the name part of the server's identity.
-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.
-
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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.
-
- 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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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.
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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.
-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 Ker- beros 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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 worksta- tion 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, 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).
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
- 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),
- obtains 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.
-
- 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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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:
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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.
-
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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
- session key, and not to identify the
- user. The ANONYMOUS flag on the ticket
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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.
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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. 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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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.
-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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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.
-
-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
-}
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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.
-
-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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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).
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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. It is
- to be encoded separately and then have the checksum computed over it,
- for use in the cksum field.
-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-BODY sequence.
-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.
-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
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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:
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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
- 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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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 not protected by any encryption, it
-is quite possible for an intruder to synthesize or modify such a message. In
-particular, this means that 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,
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- e-data[12] OCTET STRING OPTIONAL,
- e-cksum[13] Checksum OPTIONAL,
- e-typed-data[14] SEQUENCE of ETypedData OPTIONAL
-}
-
-ETypedData ::= SEQUENCE {
- e-data-type [1] INTEGER,
- e-data-value [2] OCTET STRING,
-}
-
-
-
-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 the
- errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
- contain an encoding of a sequence of padata fields, each corresponding
- to an acceptable pre-authentication method and optionally containing
- data for the method:
-
- METHOD-DATA ::= SEQUENCE of PA-DATA
-
- If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
- contain an encoding of the following sequence:
-
- METHOD-DATA ::= SEQUENCE {
- method-type[0] INTEGER,
- method-data[1] OCTET STRING OPTIONAL
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- }
-
- method-type will indicate the required alternate method; method-data
- will contain any required additional information.
-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.
-e-typed-data
- [This field for discussion, may be deleted from final spec] This field
- contains optional data that may be used to help the client recover from
- the indicated error. [This could contain the METHOD-DATA specified
- since I don't think anyone actually uses it yet. It could also contain
- the PA-DATA sequence for the preauth required error if we had a clear
- way to transition to the use of this field from the use of the untype
- e-data field.] For example, this field may specify the key version of
- the key used to verify preauthentication:
-
- e-data-type := 20 -- Key version number
- e-data-value := Integer -- Key version number used to verify
- preauthentication
-
-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] 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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 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
-}
-
-
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 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
-is described in the following diagram:
-
- +-----------+----------+-------------+-----+
- |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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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
-
-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 key that follows in the
- keyvalue field. It will almost always correspond to the encryption
- algorithm used to generate the EncryptedData, though more than one
- algorithm may use the same type of key (the mapping is many to one).
- This might happen, for example, if the encryption algorithm uses an
- alternate checksum algorithm for an integrity check, or a different
- chaining mechanism.
-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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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.]
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-String to key transformation
-
-To generate a DES key from a text string (password), the text string
-normally must have the realm and each component of the principal's name
-appended[37], then padded with ASCII nulls to an 8 byte boundary. This
-string is then fan-folded and eXclusive-ORed with itself to form an 8 byte
-DES key. The parity is corrected on the key, and it is used to generate a
-DES CBC checksum on the initial string (with the realm and name appended).
-Next, parity is corrected on the CBC checksum. If the result matches a
-'weak' or 'semi-weak' key as described in the DES specification, it is
-eXclusive-ORed with the constant 00000000000000F0. Finally, the result is
-returned as the key. Pseudocode follows:
-
- string_to_key(string,realm,name) {
- odd = 1;
- s = string + realm;
- for(each component in name) {
- s = s + component;
- }
- tempkey = NULL;
- pad(s); /* with nulls to 8 byte boundary */
- for(8byteblock in s) {
- if(odd == 0) {
- odd = 1;
- reverse(8byteblock)
- }
- else odd = 0;
- tempkey = tempkey XOR 8byteblock;
- }
- fixparity(tempkey);
- key = DES-CBC-check(s,tempkey);
- fixparity(key);
- if(is_weak_key_key(key))
- key = key XOR 0xF0;
- return(key);
- }
-
-6.3.5. Triple DES EDE in outer CBC mode with an SHA1 check-sum
-(des3-cbc-sha1)
-
-The des3-cbc-sha1 encryption encodes information using three Data Encryption
-Standard transformations with three DES keys. The first key is used to
-perform a DES ECB encryption on an eight-octet data block using the first
-DES key, followed by a DES ECB decryption of the result using the second DES
-key, and a DES ECB encryption of the result using the third DES key. Because
-DES blocks are 8 bytes, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must first be padded to an 8 byte
-boundary before encryption. To support the outer CBC mode, the input is
-padded to an eight-octet boundary. The first 8 octets of the data to be
-encrypted (the confounder) is exclusive-ored with an initialization vector
-of zero and then ECB encrypted using triple DES as described above.
-Subsequent blocks of 8 octets are exclusive-ored with the ciphertext
-produced by the encryption on the previous block before ECB encryption.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-An HMAC-SHA1 checksum (described in [KBC96].) is applied to the confounder
-and message sequence (msg-seq) and placed in the cksum field.
-
-Plaintext 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 Triple 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 Triple DES key is 24 octets of data, with keytype seven (7). This consists
-of 168 bits of key, and 24 parity bits (one per octet). The key is encoded
-as a series of 24 octets written in MSB-first order, with the first 8 octets
-treated as the first DES key, the second 8 octets as the second key, and the
-third 8 octets the third DES key. The bits within each 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.]
-
-Key derivation for specified operations (Horowitz)
-
-[Discussion is needed for this section, especially since it does not simply
-derive key generation, but also specifies encryption using triple DES in a
-manner that is different than the basic template that was specified for
-single DES and similar systems]
-
-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 in each of these places. Key derivation [Horowitz96] can
-be used to construct different keys for each operation from the keys
-transported on the network or derived from the password specified by the
-user.
-
-For each place where a key is used in Kerberos, a ``key usage'' is specified
-for that purpose. The key, key usage, and encryption/checksum type together
-describe the transformation from plaintext to ciphertext. For backwards
-compatibility, this key derivation is only specified here for encryption
-methods based on triple DES. Encryption methods specified for use by
-Kerberos in the future should specify the key derivation function to be
-used.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 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 | length | plaintext | padding) |
- H(Ki, confounder | length | 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, length | 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 recommended for use as H.
-
-The key usage value will be taken from the following list of places where
-keys are used in the Kerberos protocol, with key usage values and Kerberos
-specification 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)
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
- 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-SAFE cksum, keyed with a key chosen by the application
- (section 5.8.1)
-
- 16. Data which is defined in some specification outside of
- Kerberos to be encrypted using Kerberos encryption type.
- 17. Data which is defined in some specification outside of
- Kerberos to be checksummed using Kerberos checksum type.
-
- 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)
-
-String to key transformation
-
-To generate a DES key from a text string (password), the text string
-normally must have the realm and each component of the principal's name
-appended[38].
-
-The input string (with any salt data appended to it) is n-folded into a 24
-octet (192 bit) string. 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 X is rotated to the right by 13 bit positions.
-The successive n-bit chunks are added together using 1's-complement addition
-(addition with end-around carry) to yield a n-bit result. (This
-transformation was proposed by Richard Basch)
-
-Each successive set of 8 octets is taken as a DES key, and its parity is
-adjusted in the same manner as previously described. If any of the three
-sets of 8 octets match a 'weak' or 'semi-weak key as described in the DES
-specification, that chunk is eXclusive-ORed with the hexadecimal constant
-00000000000000F0. The resulting DES keys are then used in sequence to
-perform a Triple-DES CBC encryption of the n-folded input string (appended
-with any salt data), using a zero initial vector. Parity, weak, and
-semi-weak keys are once again corrected and the result is returned as the 24
-octet key.
-
-Pseudocode follows:
-
- string_to_key(string,realm,name) {
- s = string + realm;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- for(each component in name) {
- s = s + component;
- }
- tkey[24] = fold(s);
- fixparity(tkey);
- if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0;
- if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0;
- if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0;
- key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0);
- fixparity(key);
- if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0;
- if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0;
- if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0;
- return(key);
- }
-
-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.
-
-6.4.1. The CRC-32 Checksum (crc32)
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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)
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 1779.
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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
-
-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:
-
- * the Unspecified Address
- * the Loopback Address
- * 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).
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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
-
-Kerberos servers (KDC's) must accept 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
-connection will be broken after the reply has been received (or upon
-time-out). 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 will be
-required. The response to a request made through TCP/IP transport must also
-use TCP/IP transport.
-
-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.
-
-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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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
- 4
-des3-cbc-md5 5 8 0 8
- 6
-des3-cbc-sha1 7 8 0 8
-sign-dsa-generate 8 (pkinit)
-encrypt-rsa-priv 9 (pkinit)
-encrypt-rsa-pub 10 (pkinit)
-rsa-pub-md5 11 (pkinit)
-rsa-pub-sha1 12 (pkinit)
-ENCTYPE_PK_CROSS 48 (reserved for pkcross)
- 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
-rsa-md5 7 16
-rsa-md5-des 8 24
-rsa-md5-des3 9 24
-hmac-sha1-des3 10 20 (I had this as 10, is it 12)
-
-padata type padata-type value
-
-PA-TGS-REQ 1
-PA-ENC-TIMESTAMP 2
-PA-PW-SALT 3
- 4
-PA-ENC-UNIX-TIME 5
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-PA-SANDIA-SECUREID 6
-PA-SESAME 7
-PA-OSF-DCE 8
-PA-CYBERSAFE-SECUREID 9
-PA-AFS3-SALT 10
-PA-ETYPE-INFO 11
-SAM-CHALLENGE 12 (sam/otp)
-SAM-RESPONSE 13 (sam/otp)
-PA-PK-AS-REQ 14 (pkinit)
-PA-PK-AS-REP 15 (pkinit)
-PA-PK-AS-SIGN 16 (pkinit)
-PA-PK-KEY-REQ 17 (pkinit)
-PA-PK-KEY-REP 18 (pkinit)
-PA-USE-SPECIFIED-KVNO 20
-
-authorization data type ad-type value
-AD-KDC-ISSUED 1
-AD-INTENDED-FOR-SERVER 2
-AD-INTENDED-FOR-APPLICATION-CLASS 3
-AD-IF-RELEVANT 4
-AD-OR 5
-AD-MANDATORY-TICKET-EXTENSIONS 6
-AD-IN-TICKET-EXTENSIONS 7
-reserved values 8-63
-OSF-DCE 64
-SESAME 65
-
-Ticket Extension Types
-
-TE-TYPE-NULL 0 Null ticket extension
-TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data
- 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
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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 1779]
-
-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
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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_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)
-KDC_ERR_CERTIFICATE_MISMATCH 66 (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 may support
-TCP/IP transport.
-
-Encryption and checksum methods
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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
-Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
-
-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.
-
-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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.
-
-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-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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).
-
-[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).
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-[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).
-
-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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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
- 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 */
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- /* 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;
- 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;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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;
- 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;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
- 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
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- /* 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
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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);
-
- 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. */
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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 */
- 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 */
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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);
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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);
-
- 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);
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
- 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,
- 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;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
- 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 */
-
- 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;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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 decr_ticket.caddr) then
- error_out(KRB_AP_ERR_BADADDR);
- endif
- elseif (application requires addresses) then
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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;
- checksum.checksum := checksum value; /* checksum.checksum */
- packet.cksum := checksum;
- packet.safe-body := body;
-
-A.14. KRB_SAFE verification
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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 */
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
- /* 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;
- 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);
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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
- (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;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
- 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 ebcause 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. 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.
-
-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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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.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. If relevant
-
-AD-IF-RELEVANT AuthorizationData
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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.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
-
-An authorization data element of type mandatory-ticket-extensions specifies
-a collision-proof checksum using the same has angorithm used to protect the
-integrity of the ticket itself. This checksum will be calculated over the
-entire extensions field. If there are more than one extension, all will be
-covered by the checksum. This restriction indicates that the ticket should
-not be accepted if the checksum does not match that calculated over the
-ticket extensions. 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 has angorithm 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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-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.
-----------------------------------------------------------------------------
-[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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-[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.
-
-[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.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-
-[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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-[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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998
-
-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/doc/standardisation/rfc1508.txt b/doc/standardisation/rfc1508.txt
deleted file mode 100644
index 132b855e05e6db846cd0d097bf1ad11bbd6cac08..0000000000000000000000000000000000000000
--- a/doc/standardisation/rfc1508.txt
+++ /dev/null
@@ -1,2747 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Linn
-Request for Comments: 1508 Geer Zolot Associates
- September 1993
-
-
- Generic Security Service Application Program Interface
-
-Status of this Memo
-
- This RFC specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" for the standardization state and status
- of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This Generic Security Service Application Program Interface (GSS-API)
- definition provides security services to callers in a generic
- fashion, supportable with a range of underlying mechanisms and
- technologies and hence allowing source-level portability of
- applications to different environments. This specification defines
- GSS-API services and primitives at a level independent of underlying
- mechanism and programming language environment, and is to be
- complemented by other, related specifications:
-
- documents defining specific parameter bindings for particular
- language environments
-
- documents defining token formats, protocols, and procedures to
- be implemented in order to realize GSS-API services atop
- particular security mechanisms
-
-Table of Contents
-
- 1. GSS-API Characteristics and Concepts ....................... 2
- 1.1. GSS-API Constructs ....................................... 5
- 1.1.1. Credentials ........................................... 5
- 1.1.2. Tokens ................................................ 6
- 1.1.3. Security Contexts ..................................... 7
- 1.1.4. Mechanism Types ....................................... 8
- 1.1.5. Naming ................................................ 9
- 1.1.6. Channel Bindings ...................................... 10
- 1.2. GSS-API Features and Issues ............................. 11
- 1.2.1. Status Reporting ...................................... 11
- 1.2.2. Per-Message Security Service Availability ............. 12
- 1.2.3. Per-Message Replay Detection and Sequencing ........... 13
- 1.2.4. Quality of Protection ................................. 15
-
-
-
-Linn [Page 1]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- 2. Interface Descriptions ..................................... 15
- 2.1. Credential management calls ............................. 17
- 2.1.1. GSS_Acquire_cred call ................................. 17
- 2.1.2. GSS_Release_cred call ................................. 19
- 2.1.3. GSS_Inquire_cred call ................................. 20
- 2.2. Context-level calls ..................................... 21
- 2.2.1. GSS_Init_sec_context call ............................. 21
- 2.2.2. GSS_Accept_sec_context call ........................... 26
- 2.2.3. GSS_Delete_sec_context call ........................... 29
- 2.2.4. GSS_Process_context_token call ........................ 30
- 2.2.5. GSS_Context_time call ................................. 31
- 2.3. Per-message calls ....................................... 32
- 2.3.1. GSS_Sign call ......................................... 32
- 2.3.2. GSS_Verify call ....................................... 33
- 2.3.3. GSS_Seal call ......................................... 35
- 2.3.4. GSS_Unseal call ....................................... 36
- 2.4. Support calls ........................................... 37
- 2.4.1. GSS_Display_status call ............................... 37
- 2.4.2. GSS_Indicate_mechs call ............................... 38
- 2.4.3. GSS_Compare_name call ................................. 38
- 2.4.4. GSS_Display_name call ................................. 39
- 2.4.5. GSS_Import_name call .................................. 40
- 2.4.6. GSS_Release_name call ................................. 41
- 2.4.7. GSS_Release_buffer call ............................... 41
- 2.4.8. GSS_Release_oid_set call .............................. 42
- 3. Mechanism-Specific Example Scenarios ....................... 42
- 3.1. Kerberos V5, single-TGT ................................. 43
- 3.2. Kerberos V5, double-TGT ................................. 43
- 3.3. X.509 Authentication Framework .......................... 44
- 4. Related Activities ......................................... 45
- 5. Acknowledgments ............................................ 46
- 6. Security Considerations .................................... 46
- 7. Author's Address ........................................... 46
- Appendix A .................................................... 47
- Appendix B .................................................... 48
- Appendix C .................................................... 49
-
-1. GSS-API Characteristics and Concepts
-
- The operational paradigm in which GSS-API operates is as follows. A
- typical GSS-API caller is itself a communications protocol, calling
- on GSS-API in order to protect its communications with
- authentication, integrity, and/or confidentiality security services.
- A GSS-API caller accepts tokens provided to it by its local GSS-API
- implementation and transfers the tokens to a peer on a remote system;
- that peer passes the received tokens to its local GSS-API
- implementation for processing. The security services available
- through GSS-API in this fashion are implementable (and have been
-
-
-
-Linn [Page 2]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- implemented) over a range of underlying mechanisms based on secret-
- key and public-key cryptographic technologies.
-
- The GSS-API separates the operations of initializing a security
- context between peers, achieving peer entity authentication (This
- security service definition, and other definitions used in this
- document, corresponds to that provided in International Standard ISO
- 7498-2-1988(E), Security Architecture.) (GSS_Init_sec_context() and
- GSS_Accept_sec_context() calls), from the operations of providing
- per-message data origin authentication and data integrity protection
- (GSS_Sign() and GSS_Verify() calls) for messages subsequently
- transferred in conjunction with that context. Per-message GSS_Seal()
- and GSS_Unseal() calls provide the data origin authentication and
- data integrity services which GSS_Sign() and GSS_Verify() offer, and
- also support selection of confidentiality services as a caller
- option. Additional calls provide supportive functions to the GSS-
- API's users.
-
- The following paragraphs provide an example illustrating the
- dataflows involved in use of the GSS-API by a client and server in a
- mechanism-independent fashion, establishing a security context and
- transferring a protected message. The example assumes that credential
- acquisition has already been completed. The example assumes that the
- underlying authentication technology is capable of authenticating a
- client to a server using elements carried within a single token, and
- of authenticating the server to the client (mutual authentication)
- with a single returned token; this assumption holds for presently-
- documented CAT mechanisms but is not necessarily true for other
- cryptographic technologies and associated protocols.
-
- The client calls GSS_Init_sec_context() to establish a security
- context to the server identified by targ_name, and elects to set the
- mutual_req_flag so that mutual authentication is performed in the
- course of context establishment. GSS_Init_sec_context() returns an
- output_token to be passed to the server, and indicates
- GSS_CONTINUE_NEEDED status pending completion of the mutual
- authentication sequence. Had mutual_req_flag not been set, the
- initial call to GSS_Init_sec_context() would have returned
- GSS_COMPLETE status. The client sends the output_token to the server.
-
- The server passes the received token as the input_token parameter to
- GSS_Accept_sec_context(). GSS_Accept_sec_context indicates
- GSS_COMPLETE status, provides the client's authenticated identity in
- the src_name result, and provides an output_token to be passed to the
- client. The server sends the output_token to the client.
-
- The client passes the received token as the input_token parameter to
- a successor call to GSS_Init_sec_context(), which processes data
-
-
-
-Linn [Page 3]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- included in the token in order to achieve mutual authentication from
- the client's viewpoint. This call to GSS_Init_sec_context() returns
- GSS_COMPLETE status, indicating successful mutual authentication and
- the completion of context establishment for this example.
-
- The client generates a data message and passes it to GSS_Seal().
- GSS_Seal() performs data origin authentication, data integrity, and
- (optionally) confidentiality processing on the message and
- encapsulates the result into output_message, indicating GSS_COMPLETE
- status. The client sends the output_message to the server.
-
- The server passes the received message to GSS_Unseal(). GSS_Unseal
- inverts the encapsulation performed by GSS_Seal(), deciphers the
- message if the optional confidentiality feature was applied, and
- validates the data origin authentication and data integrity checking
- quantities. GSS_Unseal() indicates successful validation by
- returning GSS_COMPLETE status along with the resultant
- output_message.
-
- For purposes of this example, we assume that the server knows by
- out-of-band means that this context will have no further use after
- one protected message is transferred from client to server. Given
- this premise, the server now calls GSS_Delete_sec_context() to flush
- context-level information. GSS_Delete_sec_context() returns a
- context_token for the server to pass to the client.
-
- The client passes the returned context_token to
- GSS_Process_context_token(), which returns GSS_COMPLETE status after
- deleting context-level information at the client system.
-
- The GSS-API design assumes and addresses several basic goals,
- including:
-
- Mechanism independence: The GSS-API defines an interface to
- cryptographically implemented strong authentication and other
- security services at a generic level which is independent of
- particular underlying mechanisms. For example, GSS-API-provided
- services can be implemented by secret-key technologies (e.g.,
- Kerberos) or public-key approaches (e.g., X.509).
-
- Protocol environment independence: The GSS-API is independent of
- the communications protocol suites with which it is employed,
- permitting use in a broad range of protocol environments. In
- appropriate environments, an intermediate implementation "veneer"
- which is oriented to a particular communication protocol (e.g.,
- Remote Procedure Call (RPC)) may be interposed between
- applications which call that protocol and the GSS-API, thereby
- invoking GSS-API facilities in conjunction with that protocol's
-
-
-
-Linn [Page 4]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- communications invocations.
-
- Protocol association independence: The GSS-API's security context
- construct is independent of communications protocol association
- constructs. This characteristic allows a single GSS-API
- implementation to be utilized by a variety of invoking protocol
- modules on behalf of those modules' calling applications. GSS-API
- services can also be invoked directly by applications, wholly
- independent of protocol associations.
-
- Suitability to a range of implementation placements: GSS-API
- clients are not constrained to reside within any Trusted Computing
- Base (TCB) perimeter defined on a system where the GSS-API is
- implemented; security services are specified in a manner suitable
- to both intra-TCB and extra-TCB callers.
-
-1.1. GSS-API Constructs
-
- This section describes the basic elements comprising the GSS-API.
-
-1.1.1. Credentials
-
- Credentials structures provide the prerequisites enabling peers to
- establish security contexts with each other. A caller may designate
- that its default credential be used for context establishment calls
- without presenting an explicit handle to that credential.
- Alternately, those GSS-API callers which need to make explicit
- selection of particular credentials structures may make references to
- those credentials through GSS-API-provided credential handles
- ("cred_handles").
-
- A single credential structure may be used for initiation of outbound
- contexts and acceptance of inbound contexts. Callers needing to
- operate in only one of these modes may designate this fact when
- credentials are acquired for use, allowing underlying mechanisms to
- optimize their processing and storage requirements. The credential
- elements defined by a particular mechanism may contain multiple
- cryptographic keys, e.g., to enable authentication and message
- encryption to be performed with different algorithms.
-
- A single credential structure may accommodate credential information
- associated with multiple underlying mechanisms (mech_types); a
- credential structure's contents will vary depending on the set of
- mech_types supported by a particular GSS-API implementation.
- Commonly, a single mech_type will be used for all security contexts
- established by a particular initiator to a particular target; the
- primary motivation for supporting credential sets representing
- multiple mech_types is to allow initiators on systems which are
-
-
-
-Linn [Page 5]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- equipped to handle multiple types to initiate contexts to targets on
- other systems which can accommodate only a subset of the set
- supported at the initiator's system.
-
- It is the responsibility of underlying system-specific mechanisms and
- OS functions below the GSS-API to ensure that the ability to acquire
- and use credentials associated with a given identity is constrained
- to appropriate processes within a system. This responsibility should
- be taken seriously by implementors, as the ability for an entity to
- utilize a principal's credentials is equivalent to the entity's
- ability to successfully assert that principal's identity.
-
- Once a set of GSS-API credentials is established, the transferability
- of that credentials set to other processes or analogous constructs
- within a system is a local matter, not defined by the GSS-API. An
- example local policy would be one in which any credentials received
- as a result of login to a given user account, or of delegation of
- rights to that account, are accessible by, or transferable to,
- processes running under that account.
-
- The credential establishment process (particularly when performed on
- behalf of users rather than server processes) is likely to require
- access to passwords or other quantities which should be protected
- locally and exposed for the shortest time possible. As a result, it
- will often be appropriate for preliminary credential establishment to
- be performed through local means at user login time, with the
- result(s) cached for subsequent reference. These preliminary
- credentials would be set aside (in a system-specific fashion) for
- subsequent use, either:
-
- to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
- call, returning an explicit handle to reference that credential
-
- as the default credentials installed on behalf of a process
-
-1.1.2. Tokens
-
- Tokens are data elements transferred between GSS-API callers, and are
- divided into two classes. Context-level tokens are exchanged in order
- to establish and manage a security context between peers. Per-message
- tokens are exchanged in conjunction with an established context to
- provide protective security services for corresponding data messages.
- The internal contents of both classes of tokens are specific to the
- particular underlying mechanism used to support the GSS-API; Appendix
- B of this document provides a uniform recommendation for designers of
- GSS-API support mechanisms, encapsulating mechanism-specific
- information along with a globally-interpretable mechanism identifier.
-
-
-
-
-Linn [Page 6]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- Tokens are opaque from the viewpoint of GSS-API callers. They are
- generated within the GSS-API implementation at an end system,
- provided to a GSS-API caller to be transferred to the peer GSS-API
- caller at a remote end system, and processed by the GSS-API
- implementation at that remote end system. Tokens may be output by
- GSS-API primitives (and are to be transferred to GSS-API peers)
- independent of the status indications which those primitives
- indicate. Token transfer may take place in an in-band manner,
- integrated into the same protocol stream used by the GSS-API callers
- for other data transfers, or in an out-of-band manner across a
- logically separate channel.
-
- Development of GSS-API support primitives based on a particular
- underlying cryptographic technique and protocol does not necessarily
- imply that GSS-API callers invoking that GSS-API mechanism type will
- be able to interoperate with peers invoking the same technique and
- protocol outside the GSS-API paradigm. For example, the format of
- GSS-API tokens defined in conjunction with a particular mechanism,
- and the techniques used to integrate those tokens into callers'
- protocols, may not be the same as those used by non-GSS-API callers
- of the same underlying technique.
-
-1.1.3. Security Contexts
-
- Security contexts are established between peers, using credentials
- established locally in conjunction with each peer or received by
- peers via delegation. Multiple contexts may exist simultaneously
- between a pair of peers, using the same or different sets of
- credentials. Coexistence of multiple contexts using different
- credentials allows graceful rollover when credentials expire.
- Distinction among multiple contexts based on the same credentials
- serves applications by distinguishing different message streams in a
- security sense.
-
- The GSS-API is independent of underlying protocols and addressing
- structure, and depends on its callers to transport GSS-API-provided
- data elements. As a result of these factors, it is a caller
- responsibility to parse communicated messages, separating GSS-API-
- related data elements from caller-provided data. The GSS-API is
- independent of connection vs. connectionless orientation of the
- underlying communications service.
-
- No correlation between security context and communications protocol
- association is dictated. (The optional channel binding facility,
- discussed in Section 1.1.6 of this document, represents an
- intentional exception to this rule, supporting additional protection
- features within GSS-API supporting mechanisms.) This separation
- allows the GSS-API to be used in a wide range of communications
-
-
-
-Linn [Page 7]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- environments, and also simplifies the calling sequences of the
- individual calls. In many cases (depending on underlying security
- protocol, associated mechanism, and availability of cached
- information), the state information required for context setup can be
- sent concurrently with initial signed user data, without interposing
- additional message exchanges.
-
-1.1.4. Mechanism Types
-
- In order to successfully establish a security context with a target
- peer, it is necessary to identify an appropriate underlying mechanism
- type (mech_type) which both initiator and target peers support. The
- definition of a mechanism embodies not only the use of a particular
- cryptographic technology (or a hybrid or choice among alternative
- cryptographic technologies), but also definition of the syntax and
- semantics of data element exchanges which that mechanism will employ
- in order to support security services.
-
- It is recommended that callers initiating contexts specify the
- "default" mech_type value, allowing system-specific functions within
- or invoked by the GSS-API implementation to select the appropriate
- mech_type, but callers may direct that a particular mech_type be
- employed when necessary.
-
- The means for identifying a shared mech_type to establish a security
- context with a peer will vary in different environments and
- circumstances; examples include (but are not limited to):
-
- use of a fixed mech_type, defined by configuration, within an
- environment
-
- syntactic convention on a target-specific basis, through
- examination of a target's name
-
- lookup of a target's name in a naming service or other database in
- order to identify mech_types supported by that target
-
- explicit negotiation between GSS-API callers in advance of
- security context setup
-
- When transferred between GSS-API peers, mech_type specifiers (per
- Appendix B, represented as Object Identifiers (OIDs)) serve to
- qualify the interpretation of associated tokens. (The structure and
- encoding of Object Identifiers is defined in ISO/IEC 8824,
- "Specification of Abstract Syntax Notation One (ASN.1)" and in
- ISO/IEC 8825, "Specification of Basic Encoding Rules for Abstract
- Syntax Notation One (ASN.1)".) Use of hierarchically structured OIDs
- serves to preclude ambiguous interpretation of mech_type specifiers.
-
-
-
-Linn [Page 8]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- The OID representing the DASS MechType, for example, is
- 1.3.12.2.1011.7.5.
-
-1.1.5. Naming
-
- The GSS-API avoids prescription of naming structures, treating the
- names transferred across the interface in order to initiate and
- accept security contexts as opaque octet string quantities. This
- approach supports the GSS-API's goal of implementability atop a range
- of underlying security mechanisms, recognizing the fact that
- different mechanisms process and authenticate names which are
- presented in different forms. Generalized services offering
- translation functions among arbitrary sets of naming environments are
- outside the scope of the GSS-API; availability and use of local
- conversion functions to translate among the naming formats supported
- within a given end system is anticipated.
-
- Two distinct classes of name representations are used in conjunction
- with different GSS-API parameters:
-
- a printable form (denoted by OCTET STRING), for acceptance from
- and presentation to users; printable name forms are accompanied by
- OID tags identifying the namespace to which they correspond
-
- an internal form (denoted by INTERNAL NAME), opaque to callers and
- defined by individual GSS-API implementations; GSS-API
- implementations supporting multiple namespace types are
- responsible for maintaining internal tags to disambiguate the
- interpretation of particular names
-
- Tagging of printable names allows GSS-API callers and underlying
- GSS-API mechanisms to disambiguate name types and to determine
- whether an associated name's type is one which they are capable of
- processing, avoiding aliasing problems which could result from
- misinterpreting a name of one type as a name of another type.
-
- In addition to providing means for names to be tagged with types,
- this specification defines primitives to support a level of naming
- environment independence for certain calling applications. To provide
- basic services oriented towards the requirements of callers which
- need not themselves interpret the internal syntax and semantics of
- names, GSS-API calls for name comparison (GSS_Compare_name()),
- human-readable display (GSS_Display_name()), input conversion
- (GSS_Import_name()), and internal name deallocation
- (GSS_Release_name()) functions are defined. (It is anticipated that
- these proposed GSS-API calls will be implemented in many end systems
- based on system-specific name manipulation primitives already extant
- within those end systems; inclusion within the GSS-API is intended to
-
-
-
-Linn [Page 9]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- offer GSS-API callers a portable means to perform specific
- operations, supportive of authorization and audit requirements, on
- authenticated names.)
-
- GSS_Import_name() implementations can, where appropriate, support
- more than one printable syntax corresponding to a given namespace
- (e.g., alternative printable representations for X.500 Distinguished
- Names), allowing flexibility for their callers to select among
- alternative representations. GSS_Display_name() implementations
- output a printable syntax selected as appropriate to their
- operational environments; this selection is a local matter. Callers
- desiring portability across alternative printable syntaxes should
- refrain from implementing comparisons based on printable name forms
- and should instead use the GSS_Compare_name() call to determine
- whether or not one internal-format name matches another.
-
-1.1.6. Channel Bindings
-
- The GSS-API accommodates the concept of caller-provided channel
- binding ("chan_binding") information, used by GSS-API callers to bind
- the establishment of a security context to relevant characteristics
- (e.g., addresses, transformed representations of encryption keys) of
- the underlying communications channel and of protection mechanisms
- applied to that communications channel. Verification by one peer of
- chan_binding information provided by the other peer to a context
- serves to protect against various active attacks. The caller
- initiating a security context must determine the chan_binding values
- before making the GSS_Init_sec_context() call, and consistent values
- must be provided by both peers to a context. Callers should not
- assume that underlying mechanisms provide confidentiality protection
- for channel binding information.
-
- Use or non-use of the GSS-API channel binding facility is a caller
- option, and GSS-API supporting mechanisms can support operation in an
- environment where NULL channel bindings are presented. When non-NULL
- channel bindings are used, certain mechanisms will offer enhanced
- security value by interpreting the bindings' content (rather than
- simply representing those bindings, or signatures computed on them,
- within tokens) and will therefore depend on presentation of specific
- data in a defined format. To this end, agreements among mechanism
- implementors are defining conventional interpretations for the
- contents of channel binding arguments, including address specifiers
- (with content dependent on communications protocol environment) for
- context initiators and acceptors. (These conventions are being
- incorporated into related documents.) In order for GSS-API callers to
- be portable across multiple mechanisms and achieve the full security
- functionality available from each mechanism, it is strongly
- recommended that GSS-API callers provide channel bindings consistent
-
-
-
-Linn [Page 10]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- with these conventions and those of the networking environment in
- which they operate.
-
-1.2. GSS-API Features and Issues
-
- This section describes aspects of GSS-API operations, of the security
- services which the GSS-API provides, and provides commentary on
- design issues.
-
-1.2.1. Status Reporting
-
- Each GSS-API call provides two status return values. Major_status
- values provide a mechanism-independent indication of call status
- (e.g., GSS_COMPLETE, GSS_FAILURE, GSS_CONTINUE_NEEDED), sufficient to
- drive normal control flow within the caller in a generic fashion.
- Table 1 summarizes the defined major_status return codes in tabular
- fashion.
-
- Table 1: GSS-API Major Status Codes
-
- FATAL ERROR CODES
-
- GSS_BAD_BINDINGS channel binding mismatch
- GSS_BAD_MECH unsupported mechanism requested
- GSS_BAD_NAME invalid name provided
- GSS_BAD_NAMETYPE name of unsupported type provided
- GSS_BAD_STATUS invalid input status selector
- GSS_BAD_SIG token had invalid signature
- GSS_CONTEXT_EXPIRED specified security context expired
- GSS_CREDENTIALS_EXPIRED expired credentials detected
- GSS_DEFECTIVE_CREDENTIAL defective credential detected
- GSS_DEFECTIVE_TOKEN defective token detected
- GSS_FAILURE failure, unspecified at GSS-API
- level
- GSS_NO_CONTEXT no valid security context specified
- GSS_NO_CRED no valid credentials provided
-
- INFORMATORY STATUS CODES
-
- GSS_COMPLETE normal completion
- GSS_CONTINUE_NEEDED continuation call to routine
- required
- GSS_DUPLICATE_TOKEN duplicate per-message token
- detected
- GSS_OLD_TOKEN timed-out per-message token
- detected
- GSS_UNSEQ_TOKEN out-of-order per-message token
- detected
-
-
-
-Linn [Page 11]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- Minor_status provides more detailed status information which may
- include status codes specific to the underlying security mechanism.
- Minor_status values are not specified in this document.
-
- GSS_CONTINUE_NEEDED major_status returns, and optional message
- outputs, are provided in GSS_Init_sec_context() and
- GSS_Accept_sec_context() calls so that different mechanisms'
- employment of different numbers of messages within their
- authentication sequences need not be reflected in separate code paths
- within calling applications. Instead, such cases are accomodated with
- sequences of continuation calls to GSS_Init_sec_context() and
- GSS_Accept_sec_context(). The same mechanism is used to encapsulate
- mutual authentication within the GSS-API's context initiation calls.
-
- For mech_types which require interactions with third-party servers in
- order to establish a security context, GSS-API context establishment
- calls may block pending completion of such third-party interactions.
- On the other hand, no GSS-API calls pend on serialized interactions
- with GSS-API peer entities. As a result, local GSS-API status
- returns cannot reflect unpredictable or asynchronous exceptions
- occurring at remote peers, and reflection of such status information
- is a caller responsibility outside the GSS-API.
-
-1.2.2. Per-Message Security Service Availability
-
- When a context is established, two flags are returned to indicate the
- set of per-message protection security services which will be
- available on the context:
-
- the integ_avail flag indicates whether per-message integrity and
- data origin authentication services are available
-
- the conf_avail flag indicates whether per-message confidentiality
- services are available, and will never be returned TRUE unless the
- integ_avail flag is also returned TRUE
-
- GSS-API callers desiring per-message security services should
- check the values of these flags at context establishment time, and
- must be aware that a returned FALSE value for integ_avail means
- that invocation of GSS_Sign() or GSS_Seal() primitives on the
- associated context will apply no cryptographic protection to user
- data messages.
-
- The GSS-API per-message protection service primitives, as the
- category name implies, are oriented to operation at the granularity
- of protocol data units. They perform cryptographic operations on the
- data units, transfer cryptographic control information in tokens,
- and, in the case of GSS_Seal(), encapsulate the protected data unit.
-
-
-
-Linn [Page 12]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- As such, these primitives are not oriented to efficient data
- protection for stream-paradigm protocols (e.g., Telnet) if
- cryptography must be applied on an octet-by-octet basis.
-
-1.2.3. Per-Message Replay Detection and Sequencing
-
- Certain underlying mech_types are expected to offer support for
- replay detection and/or sequencing of messages transferred on the
- contexts they support. These optionally-selectable protection
- features are distinct from replay detection and sequencing features
- applied to the context establishment operation itself; the presence
- or absence of context-level replay or sequencing features is wholly a
- function of the underlying mech_type's capabilities, and is not
- selected or omitted as a caller option.
-
- The caller initiating a context provides flags (replay_det_req_flag
- and sequence_req_flag) to specify whether the use of per-message
- replay detection and sequencing features is desired on the context
- being established. The GSS-API implementation at the initiator system
- can determine whether these features are supported (and whether they
- are optionally selectable) as a function of mech_type, without need
- for bilateral negotiation with the target. When enabled, these
- features provide recipients with indicators as a result of GSS-API
- processing of incoming messages, identifying whether those messages
- were detected as duplicates or out-of-sequence. Detection of such
- events does not prevent a suspect message from being provided to a
- recipient; the appropriate course of action on a suspect message is a
- matter of caller policy.
-
- The semantics of the replay detection and sequencing services applied
- to received messages, as visible across the interface which the GSS-
- API provides to its clients, are as follows:
-
- When replay_det_state is TRUE, the possible major_status returns for
- well-formed and correctly signed messages are as follows:
-
- 1. GSS_COMPLETE indicates that the message was within the window
- (of time or sequence space) allowing replay events to be detected,
- and that the message was not a replay of a previously-processed
- message within that window.
-
- 2. GSS_DUPLICATE_TOKEN indicates that the signature on the
- received message was correct, but that the message was recognized
- as a duplicate of a previously-processed message.
-
- 3. GSS_OLD_TOKEN indicates that the signature on the received
- message was correct, but that the message is too old to be checked
- for duplication.
-
-
-
-Linn [Page 13]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- When sequence_state is TRUE, the possible major_status returns for
- well-formed and correctly signed messages are as follows:
-
- 1. GSS_COMPLETE indicates that the message was within the window
- (of time or sequence space) allowing replay events to be detected,
- and that the message was not a replay of a previously-processed
- message within that window.
-
- 2. GSS_DUPLICATE_TOKEN indicates that the signature on the
- received message was correct, but that the message was recognized
- as a duplicate of a previously-processed message.
-
- 3. GSS_OLD_TOKEN indicates that the signature on the received
- message was correct, but that the token is too old to be checked
- for duplication.
-
- 4. GSS_UNSEQ_TOKEN indicates that the signature on the received
- message was correct, but that it is earlier in a sequenced stream
- than a message already processed on the context. [Note:
- Mechanisms can be architected to provide a stricter form of
- sequencing service, delivering particular messages to recipients
- only after all predecessor messages in an ordered stream have been
- delivered. This type of support is incompatible with the GSS-API
- paradigm in which recipients receive all messages, whether in
- order or not, and provide them (one at a time, without intra-GSS-
- API message buffering) to GSS-API routines for validation. GSS-
- API facilities provide supportive functions, aiding clients to
- achieve strict message stream integrity in an efficient manner in
- conjunction with sequencing provisions in communications
- protocols, but the GSS-API does not offer this level of message
- stream integrity service by itself.]
-
- As the message stream integrity features (especially sequencing) may
- interfere with certain applications' intended communications
- paradigms, and since support for such features is likely to be
- resource intensive, it is highly recommended that mech_types
- supporting these features allow them to be activated selectively on
- initiator request when a context is established. A context initiator
- and target are provided with corresponding indicators
- (replay_det_state and sequence_state), signifying whether these
- features are active on a given context.
-
- An example mech_type supporting per-message replay detection could
- (when replay_det_state is TRUE) implement the feature as follows: The
- underlying mechanism would insert timestamps in data elements output
- by GSS_Sign() and GSS_Seal(), and would maintain (within a time-
- limited window) a cache (qualified by originator-recipient pair)
- identifying received data elements processed by GSS_Verify() and
-
-
-
-Linn [Page 14]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- GSS_Unseal(). When this feature is active, exception status returns
- (GSS_DUPLICATE_TOKEN, GSS_ OLD_TOKEN) will be provided when
- GSS_Verify() or GSS_Unseal() is presented with a message which is
- either a detected duplicate of a prior message or which is too old to
- validate against a cache of recently received messages.
-
-1.2.4. Quality of Protection
-
- Some mech_types will provide their users with fine granularity
- control over the means used to provide per-message protection,
- allowing callers to trade off security processing overhead
- dynamically against the protection requirements of particular
- messages. A per-message quality-of-protection parameter (analogous to
- quality-of-service, or QOS) selects among different QOP options
- supported by that mechanism. On context establishment for a multi-QOP
- mech_type, context-level data provides the prerequisite data for a
- range of protection qualities.
-
- It is expected that the majority of callers will not wish to exert
- explicit mechanism-specific QOP control and will therefore request
- selection of a default QOP. Definitions of, and choices among, non-
- default QOP values are mechanism-specific, and no ordered sequences
- of QOP values can be assumed equivalent across different mechanisms.
- Meaningful use of non-default QOP values demands that callers be
- familiar with the QOP definitions of an underlying mechanism or
- mechanisms, and is therefore a non-portable construct.
-
-2. Interface Descriptions
-
- This section describes the GSS-API's service interface, dividing the
- set of calls offered into four groups. Credential management calls
- are related to the acquisition and release of credentials by
- principals. Context-level calls are related to the management of
- security contexts between principals. Per-message calls are related
- to the protection of individual messages on established security
- contexts. Support calls provide ancillary functions useful to GSS-API
- callers. Table 2 groups and summarizes the calls in tabular fashion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn [Page 15]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- Table 2: GSS-API Calls
-
- CREDENTIAL MANAGEMENT
-
- GSS_Acquire_cred acquire credentials for use
- GSS_Release_cred release credentials after use
- GSS_Inquire_cred display information about
- credentials
-
- CONTEXT-LEVEL CALLS
-
- GSS_Init_sec_context initiate outbound security context
- GSS_Accept_sec_context accept inbound security context
- GSS_Delete_sec_context flush context when no longer needed
- GSS_Process_context_token process received control token on
- context
- GSS_Context_time indicate validity time remaining on
- context
-
- PER-MESSAGE CALLS
-
- GSS_Sign apply signature, receive as token
- separate from message
- GSS_Verify validate signature token along with
- message
- GSS_Seal sign, optionally encrypt,
- encapsulate
- GSS_Unseal decapsulate, decrypt if needed,
- validate signature
-
- SUPPORT CALLS
-
- GSS_Display_status translate status codes to printable
- form
- GSS_Indicate_mechs indicate mech_types supported on
- local system
- GSS_Compare_name compare two names for equality
- GSS_Display_name translate name to printable form
- GSS_Import_name convert printable name to
- normalized form
- GSS_Release_name free storage of normalized-form
- name
- GSS_Release_buffer free storage of printable name
- GSS_Release_oid_set free storage of OID set object
-
-
-
-
-
-
-
-Linn [Page 16]
-
-RFC 1508 Generic Security Interface September 1993
-
-
-2.1. Credential management calls
-
- These GSS-API calls provide functions related to the management of
- credentials. Their characterization with regard to whether or not
- they may block pending exchanges with other network entities (e.g.,
- directories or authentication servers) depends in part on OS-specific
- (extra-GSS-API) issues, so is not specified in this document.
-
- The GSS_Acquire_cred() call is defined within the GSS-API in support
- of application portability, with a particular orientation towards
- support of portable server applications. It is recognized that (for
- certain systems and mechanisms) credentials for interactive users may
- be managed differently from credentials for server processes; in such
- environments, it is the GSS-API implementation's responsibility to
- distinguish these cases and the procedures for making this
- distinction are a local matter. The GSS_Release_cred() call provides
- a means for callers to indicate to the GSS-API that use of a
- credentials structure is no longer required. The GSS_Inquire_cred()
- call allows callers to determine information about a credentials
- structure.
-
-2.1.1. GSS_Acquire_cred call
-
- Inputs:
-
- o desired_name INTERNAL NAME, -NULL requests locally-determined
- default
-
- o lifetime_req INTEGER,-in seconds; 0 requests default
-
- o desired_mechs SET OF OBJECT IDENTIFIER,-empty set requests
- system-selected default
-
- o cred_usage INTEGER-0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
- 2=ACCEPT-ONLY
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_cred_handle OCTET STRING,
-
- o actual_mechs SET OF OBJECT IDENTIFIER,
-
- o lifetime_rec INTEGER -in seconds, or reserved value for
- INDEFINITE
-
-
-
-Linn [Page 17]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that requested credentials were
- successfully established, for the duration indicated in
- lifetime_rec, suitable for the usage requested in cred_usage, for
- the set of mech_types indicated in actual_mechs, and that those
- credentials can be referenced for subsequent use with the handle
- returned in output_cred_handle.
-
- o GSS_BAD_MECH indicates that a mech_type unsupported by the GSS-API
- implementation type was requested, causing the credential
- establishment operation to fail.
-
- o GSS_BAD_NAMETYPE indicates that the provided desired_name is
- uninterpretable or of a type unsupported by the supporting GSS-API
- implementation, so no credentials could be established for the
- accompanying desired_name.
-
- o GSS_BAD_NAME indicates that the provided desired_name is
- inconsistent in terms of internally-incorporated type specifier
- information, so no credentials could be established for the
- accompanying desired_name.
-
- o GSS_FAILURE indicates that credential establishment failed for
- reasons unspecified at the GSS-API level, including lack of
- authorization to establish and use credentials associated with the
- identity named in the input desired_name argument.
-
- GSS_Acquire_cred() is used to acquire credentials so that a
- principal can (as a function of the input cred_usage parameter)
- initiate and/or accept security contexts under the identity
- represented by the desired_name input argument. On successful
- completion, the returned output_cred_handle result provides a handle
- for subsequent references to the acquired credentials. Typically,
- single-user client processes using only default credentials for
- context establishment purposes will have no need to invoke this call.
-
- A caller may provide the value NULL for desired_name, signifying a
- request for credentials corresponding to a default principal
- identity. The procedures used by GSS-API implementations to select
- the appropriate principal identity in response to this form of
- request are local matters. It is possible that multiple pre-
- established credentials may exist for the same principal identity
- (for example, as a result of multiple user login sessions) when
- GSS_Acquire_cred() is called; the means used in such cases to select
- a specific credential are local matters. The input lifetime_req
- argument to GSS_Acquire_cred() may provide useful information for
- local GSS-API implementations to employ in making this disambiguation
-
-
-
-Linn [Page 18]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- in a manner which will best satisfy a caller's intent.
-
- The lifetime_rec result indicates the length of time for which the
- acquired credentials will be valid, as an offset from the present. A
- mechanism may return a reserved value indicating INDEFINITE if no
- constraints on credential lifetime are imposed. A caller of
- GSS_Acquire_cred() can request a length of time for which acquired
- credentials are to be valid (lifetime_req argument), beginning at the
- present, or can request credentials with a default validity interval.
- (Requests for postdated credentials are not supported within the
- GSS-API.) Certain mechanisms and implementations may bind in
- credential validity period specifiers at a point preliminary to
- invocation of the GSS_Acquire_cred() call (e.g., in conjunction with
- user login procedures). As a result, callers requesting non-default
- values for lifetime_req must recognize that such requests cannot
- always be honored and must be prepared to accommodate the use of
- returned credentials with different lifetimes as indicated in
- lifetime_rec.
-
- The caller of GSS_Acquire_cred() can explicitly specify a set of
- mech_types which are to be accommodated in the returned credentials
- (desired_mechs argument), or can request credentials for a system-
- defined default set of mech_types. Selection of the system-specified
- default set is recommended in the interests of application
- portability. The actual_mechs return value may be interrogated by the
- caller to determine the set of mechanisms with which the returned
- credentials may be used.
-
-2.1.2. GSS_Release_cred call
-
- Input:
-
- o cred_handle OCTET STRING-NULL specifies default credentials
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the credentials referenced by the
- input cred_handle were released for purposes of subsequent access
- by the caller. The effect on other processes which may be
- authorized shared access to such credentials is a local matter.
-
-
-
-
-
-Linn [Page 19]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o GSS_NO_CRED indicates that no release operation was performed,
- either because the input cred_handle was invalid or because the
- caller lacks authorization to access the referenced credentials.
-
- o GSS_FAILURE indicates that the release operation failed for
- reasons unspecified at the GSS-API level.
-
- Provides a means for a caller to explicitly request that credentials
- be released when their use is no longer required. Note that system-
- specific credential management functions are also likely to exist,
- for example to assure that credentials shared among processes are
- properly deleted when all affected processes terminate, even if no
- explicit release requests are issued by those processes. Given the
- fact that multiple callers are not precluded from gaining authorized
- access to the same credentials, invocation of GSS_Release_cred()
- cannot be assumed to delete a particular set of credentials on a
- system-wide basis.
-
-2.1.3. GSS_Inquire_cred call
-
- Input:
-
- o cred_handle OCTET STRING -NULL specifies default credentials
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o cred_name INTERNAL NAME,
-
- o lifetime_rec INTEGER -in seconds, or reserved value for
- INDEFINITE
-
- o cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
- 2=ACCEPT-ONLY
-
- o mech_set SET OF OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the credentials referenced by the
- input cred_handle argument were valid, and that the output
- cred_name, lifetime_rec, and cred_usage values represent,
- respectively, the credentials' associated principal name,
- remaining lifetime, suitable usage modes, and supported
- mechanism types.
-
-
-
-Linn [Page 20]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o GSS_NO_CRED indicates that no information could be returned
- about the referenced credentials, either because the input
- cred_handle was invalid or because the caller lacks
- authorization to access the referenced credentials.
-
- o GSS_FAILURE indicates that the release operation failed for
- reasons unspecified at the GSS-API level.
-
- The GSS_Inquire_cred() call is defined primarily for the use of
- those callers which make use of default credentials rather than
- acquiring credentials explicitly with GSS_Acquire_cred(). It enables
- callers to determine a credential structure's associated principal
- name, remaining validity period, usability for security context
- initiation and/or acceptance, and supported mechanisms.
-
-2.2. Context-level calls
-
- This group of calls is devoted to the establishment and management of
- security contexts between peers. A context's initiator calls
- GSS_Init_sec_context(), resulting in generation of a token which the
- caller passes to the target. At the target, that token is passed to
- GSS_Accept_sec_context(). Depending on the underlying mech_type and
- specified options, additional token exchanges may be performed in the
- course of context establishment; such exchanges are accommodated by
- GSS_CONTINUE_NEEDED status returns from GSS_Init_sec_context() and
- GSS_Accept_sec_context(). Either party to an established context may
- invoke GSS_Delete_sec_context() to flush context information when a
- context is no longer required. GSS_Process_context_token() is used
- to process received tokens carrying context-level control
- information. GSS_Context_time() allows a caller to determine the
- length of time for which an established context will remain valid.
-
-2.2.1. GSS_Init_sec_context call
-
- Inputs:
-
- o claimant_cred_handle OCTET STRING, -NULL specifies "use
- default"
-
- o input_context_handle INTEGER, -0 specifies "none assigned
- yet"
-
- o targ_name INTERNAL NAME,
-
- o mech_type OBJECT IDENTIFIER, -NULL parameter specifies "use
- default"
-
- o deleg_req_flag BOOLEAN,
-
-
-
-Linn [Page 21]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o mutual_req_flag BOOLEAN,
-
- o replay_det_req_flag BOOLEAN,
-
- o sequence_req_flag BOOLEAN,
-
- o lifetime_req INTEGER,-0 specifies default lifetime
-
- o chan_bindings OCTET STRING,
-
- o input_token OCTET STRING-NULL or token received from target
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_context_handle INTEGER,
-
- o mech_type OBJECT IDENTIFIER, -actual mechanism always
- indicated, never NULL
-
- o output_token OCTET STRING, -NULL or token to pass to context
- target
-
- o deleg_state BOOLEAN,
-
- o mutual_state BOOLEAN,
-
- o replay_det_state BOOLEAN,
-
- o sequence_state BOOLEAN,
-
- o conf_avail BOOLEAN,
-
- o integ_avail BOOLEAN,
-
- o lifetime_rec INTEGER - in seconds, or reserved value for
- INDEFINITE
-
- This call may block pending network interactions for those mech_types
- in which an authentication server or other network entity must be
- consulted on behalf of a context initiator in order to generate an
- output_token suitable for presentation to a specified target.
-
- Return major_status codes:
-
-
-
-
-Linn [Page 22]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o GSS_COMPLETE indicates that context-level information was
- successfully initialized, and that the returned output_token will
- provide sufficient information for the target to perform per-
- message processing on the newly-established context.
-
- o GSS_CONTINUE_NEEDED indicates that control information in the
- returned output_token must be sent to the target, and that a reply
- must be received and passed as the input_token argument to a
- continuation call to GSS_Init_sec_context(), before per-message
- processing can be performed in conjunction with this context.
-
- o GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
- the input_token failed, preventing further processing from being
- performed based on that token.
-
- o GSS_DEFECTIVE_CREDENTIAL indicates that consistency checks
- performed on the credential structure referenced by
- claimant_cred_handle failed, preventing further processing from
- being performed using that credential structure.
-
- o GSS_BAD_SIG indicates that the received input_token contains an
- incorrect signature, so context setup cannot be accomplished.
-
- o GSS_NO_CRED indicates that no context was established, either
- because the input cred_handle was invalid, because the referenced
- credentials are valid for context acceptor use only, or because
- the caller lacks authorization to access the referenced
- credentials.
-
- o GSS_CREDENTIALS_EXPIRED indicates that the credentials provided
- through the input claimant_cred_handle argument are no longer
- valid, so context establishment cannot be completed.
-
- o GSS_BAD_BINDINGS indicates that a mismatch between the caller-
- provided chan_bindings and those extracted from the input_token
- was detected, signifying a security-relevant event and preventing
- context establishment. (This result will be returned by
- GSS_Init_sec_context only for contexts where mutual_state is
- TRUE.)
-
- o GSS_NO_CONTEXT indicates that no valid context was recognized for
- the input context_handle provided; this major status will be
- returned only for successor calls following GSS_CONTINUE_NEEDED
- status returns.
-
- o GSS_BAD_NAMETYPE indicates that the provided targ_name is of a
- type uninterpretable or unsupported by the supporting GSS-API
- implementation, so context establishment cannot be completed.
-
-
-
-Linn [Page 23]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o GSS_BAD_NAME indicates that the provided targ_name is inconsistent
- in terms of internally-incorporated type specifier information, so
- context establishment cannot be accomplished.
-
- o GSS_FAILURE indicates that context setup could not be accomplished
- for reasons unspecified at the GSS-API level, and that no
- interface-defined recovery action is available.
-
- This routine is used by a context initiator, and ordinarily emits one
- (or, for the case of a multi-step exchange, more than one)
- output_token suitable for use by the target within the selected
- mech_type's protocol. Using information in the credentials structure
- referenced by claimant_cred_handle, GSS_Init_sec_context()
- initializes the data structures required to establish a security
- context with target targ_name. The claimant_cred_handle must
- correspond to the same valid credentials structure on the initial
- call to GSS_Init_sec_context() and on any successor calls resulting
- from GSS_CONTINUE_NEEDED status returns; different protocol sequences
- modeled by the GSS_CONTINUE_NEEDED mechanism will require access to
- credentials at different points in the context establishment
- sequence.
-
- The input_context_handle argument is 0, specifying "not yet
- assigned", on the first GSS_Init_sec_context() call relating to a
- given context. That call returns an output_context_handle for future
- references to this context. When continuation attempts to
- GSS_Init_sec_context() are needed to perform context establishment,
- the previously-returned non-zero handle value is entered into the
- input_context_handle argument and will be echoed in the returned
- output_context_handle argument. On such continuation attempts (and
- only on continuation attempts) the input_token value is used, to
- provide the token returned from the context's target.
-
- The chan_bindings argument is used by the caller to provide
- information binding the security context to security-related
- characteristics (e.g., addresses, cryptographic keys) of the
- underlying communications channel. See Section 1.1.6 of this document
- for more discussion of this argument's usage.
-
- The input_token argument contains a message received from the target,
- and is significant only on a call to GSS_Init_sec_context() which
- follows a previous return indicating GSS_CONTINUE_NEEDED
- major_status.
-
- It is the caller's responsibility to establish a communications path
- to the target, and to transmit any returned output_token (independent
- of the accompanying returned major_status value) to the target over
- that path. The output_token can, however, be transmitted along with
-
-
-
-Linn [Page 24]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- the first application-provided input message to be processed by
- GSS_Sign() or GSS_Seal() in conjunction with a successfully-
- established context.
-
- The initiator may request various context-level functions through
- input flags: the deleg_req_flag requests delegation of access rights,
- the mutual_req_flag requests mutual authentication, the
- replay_det_req_flag requests that replay detection features be
- applied to messages transferred on the established context, and the
- sequence_req_flag requests that sequencing be enforced. (See Section
- 1.2.3 for more information on replay detection and sequencing
- features.)
-
- Not all of the optionally-requestable features will be available in
- all underlying mech_types; the corresponding return state values
- (deleg_state, mutual_state, replay_det_state, sequence_state)
- indicate, as a function of mech_type processing capabilities and
- initiator-provided input flags, the set of features which will be
- active on the context. These state indicators' values are undefined
- unless the routine's major_status indicates COMPLETE. Failure to
- provide the precise set of features requested by the caller does not
- cause context establishment to fail; it is the caller's prerogative
- to delete the context if the feature set provided is unsuitable for
- the caller's use. The returned mech_type value indicates the
- specific mechanism employed on the context, and will never indicate
- the value for "default".
-
- The conf_avail return value indicates whether the context supports
- per-message confidentiality services, and so informs the caller
- whether or not a request for encryption through the conf_req_flag
- input to GSS_Seal() can be honored. In similar fashion, the
- integ_avail return value indicates whether per-message integrity
- services are available (through either GSS_Sign() or GSS_Seal()) on
- the established context.
-
- The lifetime_req input specifies a desired upper bound for the
- lifetime of the context to be established, with a value of 0 used to
- request a default lifetime. The lifetime_rec return value indicates
- the length of time for which the context will be valid, expressed as
- an offset from the present; depending on mechanism capabilities,
- credential lifetimes, and local policy, it may not correspond to the
- value requested in lifetime_req. If no constraints on context
- lifetime are imposed, this may be indicated by returning a reserved
- value representing INDEFINITE lifetime_req. The values of conf_avail,
- integ_avail, and lifetime_rec are undefined unless the routine's
- major_status indicates COMPLETE.
-
- If the mutual_state is TRUE, this fact will be reflected within the
-
-
-
-Linn [Page 25]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- output_token. A call to GSS_Accept_sec_context() at the target in
- conjunction with such a context will return a token, to be processed
- by a continuation call to GSS_Init_sec_context(), in order to achieve
- mutual authentication.
-
-2.2.2. GSS_Accept_sec_context call
-
- Inputs:
-
- o acceptor_cred_handle OCTET STRING,-NULL specifies "use
- default"
-
- o input_context_handle INTEGER, -0 specifies "not yet assigned"
-
- o chan_bindings OCTET STRING,
-
- o input_token OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o src_name INTERNAL NAME,
-
- o mech_type OBJECT IDENTIFIER,
-
- o output_context_handle INTEGER,
-
- o deleg_state BOOLEAN,
-
- o mutual_state BOOLEAN,
-
- o replay_det_state BOOLEAN,
-
- o sequence_state BOOLEAN,
-
- o conf_avail BOOLEAN,
-
- o integ_avail BOOLEAN,
-
- o lifetime_rec INTEGER, - in seconds, or reserved value for
- INDEFINITE
-
- o delegated_cred_handle OCTET STRING,
-
- o output_token OCTET STRING -NULL or token to pass to context
-
-
-
-Linn [Page 26]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- initiator
-
- This call may block pending network interactions for those mech_types
- in which a directory service or other network entity must be
- consulted on behalf of a context acceptor in order to validate a
- received input_token.
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that context-level data structures were
- successfully initialized, and that per-message processing can now
- be performed in conjunction with this context.
-
- o GSS_CONTINUE_NEEDED indicates that control information in the
- returned output_token must be sent to the initiator, and that a
- response must be received and passed as the input_token argument
- to a continuation call to GSS_Accept_sec_context(), before per-
- message processing can be performed in conjunction with this
- context.
-
- o GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
- the input_token failed, preventing further processing from being
- performed based on that token.
-
- o GSS_DEFECTIVE_CREDENTIAL indicates that consistency checks
- performed on the credential structure referenced by
- acceptor_cred_handle failed, preventing further processing from
- being performed using that credential structure.
-
- o GSS_BAD_SIG indicates that the received input_token contains an
- incorrect signature, so context setup cannot be accomplished.
-
- o GSS_DUPLICATE_TOKEN indicates that the signature on the received
- input_token was correct, but that the input_token was recognized
- as a duplicate of an input_token already processed. No new context
- is established.
-
- o GSS_OLD_TOKEN indicates that the signature on the received
- input_token was correct, but that the input_token is too old to be
- checked for duplication against previously-processed input_tokens.
- No new context is established.
-
- o GSS_NO_CRED indicates that no context was established, either
- because the input cred_handle was invalid, because the referenced
- credentials are valid for context initiator use only, or because
- the caller lacks authorization to access the referenced
- credentials.
-
-
-
-
-Linn [Page 27]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o GSS_CREDENTIALS_EXPIRED indicates that the credentials provided
- through the input acceptor_cred_handle argument are no longer
- valid, so context establishment cannot be completed.
-
- o GSS_BAD_BINDINGS indicates that a mismatch between the caller-
- provided chan_bindings and those extracted from the input_token
- was detected, signifying a security-relevant event and preventing
- context establishment.
-
- o GSS_NO_CONTEXT indicates that no valid context was recognized for
- the input context_handle provided; this major status will be
- returned only for successor calls following GSS_CONTINUE_NEEDED
- status returns.
-
- o GSS_FAILURE indicates that context setup could not be accomplished
- for reasons unspecified at the GSS-API level, and that no
- interface-defined recovery action is available.
-
- The GSS_Accept_sec_context() routine is used by a context target.
- Using information in the credentials structure referenced by the
- input acceptor_cred_handle, it verifies the incoming input_token and
- (following the successful completion of a context establishment
- sequence) returns the authenticated src_name and the mech_type used.
- The acceptor_cred_handle must correspond to the same valid
- credentials structure on the initial call to GSS_Accept_sec_context()
- and on any successor calls resulting from GSS_CONTINUE_NEEDED status
- returns; different protocol sequences modeled by the
- GSS_CONTINUE_NEEDED mechanism will require access to credentials at
- different points in the context establishment sequence.
-
- The input_context_handle argument is 0, specifying "not yet
- assigned", on the first GSS_Accept_sec_context() call relating to a
- given context. That call returns an output_context_handle for future
- references to this context; when continuation attempts to
- GSS_Accept_sec_context() are needed to perform context
- establishment, that handle value will be entered into the
- input_context_handle argument.
-
- The chan_bindings argument is used by the caller to provide
- information binding the security context to security-related
- characteristics (e.g., addresses, cryptographic keys) of the
- underlying communications channel. See Section 1.1.6 of this document
- for more discussion of this argument's usage.
-
- The returned state results (deleg_state, mutual_state,
- replay_det_state, and sequence_state) reflect the same context state
- values as returned to GSS_Init_sec_context()'s caller at the
- initiator system.
-
-
-
-Linn [Page 28]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- The conf_avail return value indicates whether the context supports
- per-message confidentiality services, and so informs the caller
- whether or not a request for encryption through the conf_req_flag
- input to GSS_Seal() can be honored. In similar fashion, the
- integ_avail return value indicates whether per-message integrity
- services are available (through either GSS_Sign() or GSS_Seal()) on
- the established context.
-
- The lifetime_rec return value indicates the length of time for which
- the context will be valid, expressed as an offset from the present.
- The values of deleg_state, mutual_state, replay_det_state,
- sequence_state, conf_avail, integ_avail, and lifetime_rec are
- undefined unless the accompanying major_status indicates COMPLETE.
-
- The delegated_cred_handle result is significant only when deleg_state
- is TRUE, and provides a means for the target to reference the
- delegated credentials. The output_token result, when non-NULL,
- provides a context-level token to be returned to the context
- initiator to continue a multi-step context establishment sequence. As
- noted with GSS_Init_sec_context(), any returned token should be
- transferred to the context's peer (in this case, the context
- initiator), independent of the value of the accompanying returned
- major_status.
-
- Note: A target must be able to distinguish a context-level
- input_token, which is passed to GSS_Accept_sec_context(), from the
- per-message data elements passed to GSS_Verify() or GSS_Unseal().
- These data elements may arrive in a single application message, and
- GSS_Accept_sec_context() must be performed before per-message
- processing can be performed successfully.
-
-2.2.3. GSS_Delete_sec_context call
-
- Input:
-
- o context_handle INTEGER
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_context_token OCTET STRING
-
- Return major_status codes:
-
-
-
-
-
-Linn [Page 29]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o GSS_COMPLETE indicates that the context was recognized, that
- relevant context-specific information was flushed, and that the
- returned output_context_token is ready for transfer to the
- context's peer.
-
- o GSS_NO_CONTEXT indicates that no valid context was recognized for
- the input context_handle provide, so no deletion was performed.
-
- o GSS_FAILURE indicates that the context is recognized, but that the
- GSS_Delete_sec_context() operation could not be performed for
- reasons unspecified at the GSS-API level.
-
- This call may block pending network interactions for mech_types in
- which active notification must be made to a central server when a
- security context is to be deleted.
-
- This call can be made by either peer in a security context, to flush
- context-specific information and to return an output_context_token
- which can be passed to the context's peer informing it that the
- peer's corresponding context information can also be flushed. (Once a
- context is established, the peers involved are expected to retain
- cached credential and context-related information until the
- information's expiration time is reached or until a
- GSS_Delete_sec_context() call is made.) Attempts to perform per-
- message processing on a deleted context will result in error returns.
-
-2.2.4. GSS_Process_context_token call
-
- Inputs:
-
- o context_handle INTEGER,
-
- o input_context_token OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the input_context_token was
- successfully processed in conjunction with the context referenced
- by context_handle.
-
- o GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
- the received context_token failed, preventing further processing
-
-
-
-Linn [Page 30]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- from being performed with that token.
-
- o GSS_NO_CONTEXT indicates that no valid context was recognized for
- the input context_handle provided.
-
- o GSS_FAILURE indicates that the context is recognized, but that the
- GSS_Process_context_token() operation could not be performed for
- reasons unspecified at the GSS-API level.
-
- This call is used to process context_tokens received from a peer once
- a context has been established, with corresponding impact on
- context-level state information. One use for this facility is
- processing of the context_tokens generated by
- GSS_Delete_sec_context(); GSS_Process_context_token() will not block
- pending network interactions for that purpose. Another use is to
- process tokens indicating remote-peer context establishment failures
- after the point where the local GSS-API implementation has already
- indicated GSS_COMPLETE status.
-
-2.2.5. GSS_Context_time call
-
- Input:
-
- o context_handle INTEGER,
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o lifetime_rec INTEGER - in seconds, or reserved value for
- INDEFINITE
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the referenced context is valid, and
- will remain valid for the amount of time indicated in
- lifetime_rec.
-
- o GSS_CONTEXT_EXPIRED indicates that data items related to the
- referenced context have expired.
-
- o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
- but that its associated credentials have expired.
-
- o GSS_NO_CONTEXT indicates that no valid context was recognized for
- the input context_handle provided.
-
-
-
-Linn [Page 31]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o GSS_FAILURE indicates that the requested operation failed for
- reasons unspecified at the GSS-API level.
-
- This call is used to determine the amount of time for which a
- currently established context will remain valid.
-
-2.3. Per-message calls
-
- This group of calls is used to perform per-message protection
- processing on an established security context. None of these calls
- block pending network interactions. These calls may be invoked by a
- context's initiator or by the context's target. The four members of
- this group should be considered as two pairs; the output from
- GSS_Sign() is properly input to GSS_Verify(), and the output from
- GSS_Seal() is properly input to GSS_Unseal().
-
- GSS_Sign() and GSS_Verify() support data origin authentication and
- data integrity services. When GSS_Sign() is invoked on an input
- message, it yields a per-message token containing data items which
- allow underlying mechanisms to provide the specified security
- services. The original message, along with the generated per-message
- token, is passed to the remote peer; these two data elements are
- processed by GSS_Verify(), which validates the message in
- conjunction with the separate token.
-
- GSS_Seal() and GSS_Unseal() support caller-requested confidentiality
- in addition to the data origin authentication and data integrity
- services offered by GSS_Sign() and GSS_Verify(). GSS_Seal() outputs
- a single data element, encapsulating optionally enciphered user data
- as well as associated token data items. The data element output from
- GSS_Seal() is passed to the remote peer and processed by
- GSS_Unseal() at that system. GSS_Unseal() combines decipherment (as
- required) with validation of data items related to authentication and
- integrity.
-
-2.3.1. GSS_Sign call
-
- Inputs:
-
- o context_handle INTEGER,
-
- o qop_req INTEGER,-0 specifies default QOP
-
- o message OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
-
-
-Linn [Page 32]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o minor_status INTEGER,
-
- o per_msg_token OCTET STRING
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that a signature, suitable for an
- established security context, was successfully applied and that
- the message and corresponding per_msg_token are ready for
- transmission.
-
- o GSS_CONTEXT_EXPIRED indicates that context-related data items have
- expired, so that the requested operation cannot be performed.
-
- o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
- but that its associated credentials have expired, so that the
- requested operation cannot be performed.
-
- o GSS_NO_CONTEXT indicates that no valid context was recognized for
- the input context_handle provided.
-
- o GSS_FAILURE indicates that the context is recognized, but that the
- requested operation could not be performed for reasons unspecified
- at the GSS-API level.
-
- Using the security context referenced by context_handle, apply a
- signature to the input message (along with timestamps and/or other
- data included in support of mech_type-specific mechanisms) and return
- the result in per_msg_token. The qop_req parameter allows quality-
- of-protection control. The caller passes the message and the
- per_msg_token to the target.
-
- The GSS_Sign() function completes before the message and
- per_msg_token is sent to the peer; successful application of
- GSS_Sign() does not guarantee that a corresponding GSS_Verify() has
- been (or can necessarily be) performed successfully when the message
- arrives at the destination.
-
-2.3.2. GSS_Verify call
-
- Inputs:
-
- o context_handle INTEGER,
-
- o message OCTET STRING,
-
- o per_msg_token OCTET STRING
-
-
-
-
-Linn [Page 33]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- Outputs:
-
- o qop_state INTEGER,
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the message was successfully verified.
-
- o GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
- the received per_msg_token failed, preventing further processing
- from being performed with that token.
-
- o GSS_BAD_SIG indicates that the received per_msg_token contains an
- incorrect signature for the message.
-
- o GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN values
- appear in conjunction with the optional per-message replay
- detection features described in Section 1.2.3; their semantics are
- described in that section.
-
- o GSS_CONTEXT_EXPIRED indicates that context-related data items have
- expired, so that the requested operation cannot be performed.
-
- o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
- but that its associated credentials have expired, so that the
- requested operation cannot be performed.
-
- o GSS_NO_CONTEXT indicates that no valid context was recognized for
- the input context_handle provided.
-
- o GSS_FAILURE indicates that the context is recognized, but that the
- GSS_Verify() operation could not be performed for reasons
- unspecified at the GSS-API level.
-
- Using the security context referenced by context_handle, verify that
- the input per_msg_token contains an appropriate signature for the
- input message, and apply any active replay detection or sequencing
- features. Return an indication of the quality-of-protection applied
- to the processed message in the qop_state result.
-
-
-
-
-
-
-
-
-Linn [Page 34]
-
-RFC 1508 Generic Security Interface September 1993
-
-
-2.3.3. GSS_Seal call
-
- Inputs:
-
- o context_handle INTEGER,
-
- o conf_req_flag BOOLEAN,
-
- o qop_req INTEGER,-0 specifies default QOP
-
- o input_message OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o conf_state BOOLEAN,
-
- o output_message OCTET STRING
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the input_message was successfully
- processed and that the output_message is ready for transmission.
-
- o GSS_CONTEXT_EXPIRED indicates that context-related data items have
- expired, so that the requested operation cannot be performed.
-
- o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
- but that its associated credentials have expired, so that the
- requested operation cannot be performed.
-
- o GSS_NO_CONTEXT indicates that no valid context was recognized for
- the input context_handle provided.
-
- o GSS_FAILURE indicates that the context is recognized, but that the
- GSS_Seal() operation could not be performed for reasons
- unspecified at the GSS-API level.
-
- Performs the data origin authentication and data integrity functions
- of GSS_Sign(). If the input conf_req_flag is TRUE, requests that
- confidentiality be applied to the input_message. Confidentiality may
- not be supported in all mech_types or by all implementations; the
- returned conf_state flag indicates whether confidentiality was
- provided for the input_message. The qop_req parameter allows
- quality-of-protection control.
-
-
-
-Linn [Page 35]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- In all cases, the GSS_Seal() call yields a single output_message
- data element containing (optionally enciphered) user data as well as
- control information.
-
-2.3.4. GSS_Unseal call
-
- Inputs:
-
- o context_handle INTEGER,
-
- o input_message OCTET STRING
-
- Outputs:
-
- o conf_state BOOLEAN,
-
- o qop_state INTEGER,
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_message OCTET STRING
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the input_message was successfully
- processed and that the resulting output_message is available.
-
- o GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
- the per_msg_token extracted from the input_message failed,
- preventing further processing from being performed.
-
- o GSS_BAD_SIG indicates that an incorrect signature was detected for
- the message.
-
- o GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN values
- appear in conjunction with the optional per-message replay
- detection features described in Section 1.2.3; their semantics are
- described in that section.
-
- o GSS_CONTEXT_EXPIRED indicates that context-related data items have
- expired, so that the requested operation cannot be performed.
-
- o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
- but that its associated credentials have expired, so that the
- requested operation cannot be performed.
-
-
-
-
-Linn [Page 36]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o GSS_NO_CONTEXT indicates that no valid context was recognized for
- the input context_handle provided.
-
- o GSS_FAILURE indicates that the context is recognized, but that the
- GSS_Unseal() operation could not be performed for reasons
- unspecified at the GSS-API level.
-
- Processes a data element generated (and optionally enciphered) by
- GSS_Seal(), provided as input_message. The returned conf_state value
- indicates whether confidentiality was applied to the input_message.
- If conf_state is TRUE, GSS_Unseal() deciphers the input_message.
- Returns an indication of the quality-of-protection applied to the
- processed message in the qop_state result. GSS_Seal() performs the
- data integrity and data origin authentication checking functions of
- GSS_Verify() on the plaintext data. Plaintext data is returned in
- output_message.
-
-2.4. Support calls
-
- This group of calls provides support functions useful to GSS-API
- callers, independent of the state of established contexts. Their
- characterization with regard to blocking or non-blocking status in
- terms of network interactions is unspecified.
-
-2.4.1. GSS_Display_status call
-
- Inputs:
-
- o status_value INTEGER,-GSS-API major_status or minor_status
- return value
-
- o status_type INTEGER,-1 if major_status, 2 if minor_status
-
- o mech_type OBJECT IDENTIFIER-mech_type to be used for minor_
- status translation
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o status_string_set SET OF OCTET STRING
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that a valid printable status
- representation (possibly representing more than one status event
-
-
-
-Linn [Page 37]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- encoded within the status_value) is available in the returned
- status_string_set.
-
- o GSS_BAD_MECH indicates that translation in accordance with an
- unsupported mech_type was requested, so translation could not be
- performed.
-
- o GSS_BAD_STATUS indicates that the input status_value was invalid,
- or that the input status_type carried a value other than 1 or 2,
- so translation could not be performed.
-
- o GSS_FAILURE indicates that the requested operation could not be
- performed for reasons unspecified at the GSS-API level.
-
- Provides a means for callers to translate GSS-API-returned major and
- minor status codes into printable string representations.
-
-2.4.2. GSS_Indicate_mechs call
-
- Input:
-
- o (none)
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o mech_set SET OF OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that a set of available mechanisms has
- been returned in mech_set.
-
- o GSS_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- Allows callers to determine the set of mechanism types available on
- the local system. This call is intended for support of specialized
- callers who need to request non-default mech_type sets from
- GSS_Acquire_cred(), and should not be needed by other callers.
-
-2.4.3. GSS_Compare_name call
-
- Inputs:
-
-
-
-
-Linn [Page 38]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o name1 INTERNAL NAME,
-
- o name2 INTERNAL NAME
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o name_equal BOOLEAN
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that name1 and name2 were comparable, and
- that the name_equal result indicates whether name1 and name2 were
- equal or unequal.
-
- o GSS_BAD_NAMETYPE indicates that one or both of name1 and name2
- contained internal type specifiers uninterpretable by the
- supporting GSS-API implementation, or that the two names' types
- are different and incomparable, so the equality comparison could
- not be completed.
-
- o GSS_BAD_NAME indicates that one or both of the input names was
- ill-formed in terms of its internal type specifier, so the
- equality comparison could not be completed.
-
- o GSS_FAILURE indicates that the requested operation could not be
- performed for reasons unspecified at the GSS-API level.
-
- Allows callers to compare two internal name representations for
- equality.
-
-2.4.4. GSS_Display_name call
-
- Inputs:
-
- o name INTERNAL NAME
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o name_string OCTET STRING,
-
-
-
-
-Linn [Page 39]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o name_type OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that a valid printable name representation
- is available in the returned name_string.
-
- o GSS_BAD_NAMETYPE indicates that the provided name was of a type
- uninterpretable by the supporting GSS-API implementation, so no
- printable representation could be generated.
-
- o GSS_BAD_NAME indicates that the contents of the provided name were
- inconsistent with the internally-indicated name type, so no
- printable representation could be generated.
-
- o GSS_FAILURE indicates that the requested operation could not be
- performed for reasons unspecified at the GSS-API level.
-
- Allows callers to translate an internal name representation into a
- printable form with associated namespace type descriptor. The syntax
- of the printable form is a local matter.
-
-2.4.5. GSS_Import_name call
-
- Inputs:
-
- o input_name_string OCTET STRING,
-
- o input_name_type OBJECT IDENTIFIER
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_name INTERNAL NAME
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that a valid name representation is output
- in output_name and described by the type value in
- output_name_type.
-
- o GSS_BAD_NAMETYPE indicates that the input_name_type is unsupported
- by the GSS-API implementation, so the import operation could not
- be completed.
-
-
-
-
-Linn [Page 40]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o GSS_BAD_NAME indicates that the provided input_name_string is
- ill-formed in terms of the input_name_type, so the import
- operation could not be completed.
-
- o GSS_FAILURE indicates that the requested operation could not be
- performed for reasons unspecified at the GSS-API level.
-
- Allows callers to provide a printable name representation, designate
- the type of namespace in conjunction with which it should be parsed,
- and convert that printable representation to an internal form
- suitable for input to other GSS-API routines. The syntax of the
- input_name is a local matter.
-
-2.4.6. GSS_Release_name call
-
- Inputs:
-
- o name INTERNAL NAME
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the storage associated with the input
- name was successfully released.
-
- o GSS_BAD_NAME indicates that the input name argument did not
- contain a valid name.
-
- o GSS_FAILURE indicates that the requested operation could not be
- performed for reasons unspecified at the GSS-API level.
-
- Allows callers to release the storage associated with an internal
- name representation.
-
-2.4.7. GSS_Release_buffer call
-
- Inputs:
-
- o buffer OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
-
-
-Linn [Page 41]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- o minor_status INTEGER
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the storage associated with the input
- buffer was successfully released.
-
- o GSS_FAILURE indicates that the requested operation could not be
- performed for reasons unspecified at the GSS-API level.
-
- Allows callers to release the storage associated with an OCTET STRING
- buffer allocated by another GSS-API call.
-
-2.4.8. GSS_Release_oid_set call
-
- Inputs:
-
- o buffer SET OF OBJECT IDENTIFIER
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER
-
- Return major_status codes:
-
- o GSS_COMPLETE indicates that the storage associated with the input
- object identifier set was successfully released.
-
- o GSS_FAILURE indicates that the requested operation could not be
- performed for reasons unspecified at the GSS-API level.
-
- Allows callers to release the storage associated with an object
- identifier set object allocated by another GSS-API call.
-
-3. Mechanism-Specific Example Scenarios
-
- This section provides illustrative overviews of the use of various
- candidate mechanism types to support the GSS-API. These discussions
- are intended primarily for readers familiar with specific security
- technologies, demonstrating how GSS-API functions can be used and
- implemented by candidate underlying mechanisms. They should not be
- regarded as constrictive to implementations or as defining the only
- means through which GSS-API functions can be realized with a
- particular underlying technology, and do not demonstrate all GSS-API
- features with each technology.
-
-
-
-
-Linn [Page 42]
-
-RFC 1508 Generic Security Interface September 1993
-
-
-3.1. Kerberos V5, single-TGT
-
- OS-specific login functions yield a TGT to the local realm Kerberos
- server; TGT is placed in a credentials structure for the client.
- Client calls GSS_Acquire_cred() to acquire a cred_handle in order to
- reference the credentials for use in establishing security contexts.
-
- Client calls GSS_Init_sec_context(). If the requested service is
- located in a different realm, GSS_Init_sec_context() gets the
- necessary TGT/key pairs needed to traverse the path from local to
- target realm; these data are placed in the owner's TGT cache. After
- any needed remote realm resolution, GSS_Init_sec_context() yields a
- service ticket to the requested service with a corresponding session
- key; these data are stored in conjunction with the context. GSS-API
- code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP
- response(s) (in the successful case) or KRB_ERROR.
-
- Assuming success, GSS_Init_sec_context() builds a Kerberos-formatted
- KRB_AP_REQ message, and returns it in output_token. The client sends
- the output_token to the service.
-
- The service passes the received token as the input_token argument to
- GSS_Accept_sec_context(), which verifies the authenticator, provides
- the service with the client's authenticated name, and returns an
- output_context_handle.
-
- Both parties now hold the session key associated with the service
- ticket, and can use this key in subsequent GSS_Sign(), GSS_Verify(),
- GSS_Seal(), and GSS_Unseal() operations.
-
-3.2. Kerberos V5, double-TGT
-
- TGT acquisition as above.
-
- Note: To avoid unnecessary frequent invocations of error paths when
- implementing the GSS-API atop Kerberos V5, it seems appropriate to
- represent "single-TGT K-V5" and "double-TGT K-V5" with separate
- mech_types, and this discussion makes that assumption.
-
- Based on the (specified or defaulted) mech_type,
- GSS_Init_sec_context() determines that the double-TGT protocol
- should be employed for the specified target. GSS_Init_sec_context()
- returns GSS_CONTINUE_NEEDED major_status, and its returned
- output_token contains a request to the service for the service's TGT.
- (If a service TGT with suitably long remaining lifetime already
- exists in a cache, it may be usable, obviating the need for this
- step.) The client passes the output_token to the service. Note: this
- scenario illustrates a different use for the GSS_CONTINUE_NEEDED
-
-
-
-Linn [Page 43]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- status return facility than for support of mutual authentication;
- note that both uses can coexist as successive operations within a
- single context establishment operation.
-
- The service passes the received token as the input_token argument to
- GSS_Accept_sec_context(), which recognizes it as a request for TGT.
- (Note that current Kerberos V5 defines no intra-protocol mechanism to
- represent such a request.) GSS_Accept_sec_context() returns
- GSS_CONTINUE_NEEDED major_status and provides the service's TGT in
- its output_token. The service sends the output_token to the client.
-
- The client passes the received token as the input_token argument to a
- continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches
- the received service TGT and uses it as part of a service ticket
- request to the Kerberos authentication server, storing the returned
- service ticket and session key in conjunction with the context.
- GSS_Init_sec_context() builds a Kerberos-formatted authenticator,
- and returns it in output_token along with GSS_COMPLETE return
- major_status. The client sends the output_token to the service.
-
- Service passes the received token as the input_token argument to a
- continuation call to GSS_Accept_sec_context().
- GSS_Accept_sec_context() verifies the authenticator, provides the
- service with the client's authenticated name, and returns
- major_status GSS_COMPLETE.
-
- GSS_Sign(), GSS_Verify(), GSS_Seal(), and GSS_Unseal() as above.
-
-3.3. X.509 Authentication Framework
-
- This example illustrates use of the GSS-API in conjunction with
- public-key mechanisms, consistent with the X.509 Directory
- Authentication Framework.
-
- The GSS_Acquire_cred() call establishes a credentials structure,
- making the client's private key accessible for use on behalf of the
- client.
-
- The client calls GSS_Init_sec_context(), which interrogates the
- Directory to acquire (and validate) a chain of public-key
- certificates, thereby collecting the public key of the service. The
- certificate validation operation determines that suitable signatures
- were applied by trusted authorities and that those certificates have
- not expired. GSS_Init_sec_context() generates a secret key for use
- in per-message protection operations on the context, and enciphers
- that secret key under the service's public key.
-
- The enciphered secret key, along with an authenticator quantity
-
-
-
-Linn [Page 44]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- signed with the client's private key, is included in the output_token
- from GSS_Init_sec_context(). The output_token also carries a
- certification path, consisting of a certificate chain leading from
- the service to the client; a variant approach would defer this path
- resolution to be performed by the service instead of being asserted
- by the client. The client application sends the output_token to the
- service.
-
- The service passes the received token as the input_token argument to
- GSS_Accept_sec_context(). GSS_Accept_sec_context() validates the
- certification path, and as a result determines a certified binding
- between the client's distinguished name and the client's public key.
- Given that public key, GSS_Accept_sec_context() can process the
- input_token's authenticator quantity and verify that the client's
- private key was used to sign the input_token. At this point, the
- client is authenticated to the service. The service uses its private
- key to decipher the enciphered secret key provided to it for per-
- message protection operations on the context.
-
- The client calls GSS_Sign() or GSS_Seal() on a data message, which
- causes per-message authentication, integrity, and (optional)
- confidentiality facilities to be applied to that message. The service
- uses the context's shared secret key to perform corresponding
- GSS_Verify() and GSS_Unseal() calls.
-
-4. Related Activities
-
- In order to implement the GSS-API atop existing, emerging, and future
- security mechanisms:
-
- object identifiers must be assigned to candidate GSS-API
- mechanisms and the name types which they support
-
- concrete data element formats must be defined for candidate
- mechanisms
-
- Calling applications must implement formatting conventions which will
- enable them to distinguish GSS-API tokens from other data carried in
- their application protocols.
-
- Concrete language bindings are required for the programming
- environments in which the GSS-API is to be employed; such bindings
- for the C language are available in an associated RFC.
-
-
-
-
-
-
-
-
-Linn [Page 45]
-
-RFC 1508 Generic Security Interface September 1993
-
-
-5. Acknowledgments
-
- This proposal is the result of a collaborative effort.
- Acknowledgments are due to the many members of the IETF Security Area
- Advisory Group (SAAG) and the Common Authentication Technology (CAT)
- Working Group for their contributions at meetings and by electronic
- mail. Acknowledgments are also due to Kannan Alagappan, Doug Barlow,
- Bill Brown, Cliff Kahn, Charlie Kaufman, Butler Lampson, Richard
- Pitkin, Joe Tardo, and John Wray of Digital Equipment Corporation,
- and John Carr, John Kohl, Jon Rochlis, Jeff Schiller, and Ted T'so of
- MIT and Project Athena. Joe Pato and Bill Sommerfeld of HP/Apollo,
- Walt Tuvell of OSF, and Bill Griffith and Mike Merritt of AT&T,
- provided inputs which helped to focus and clarify directions.
- Precursor work by Richard Pitkin, presented to meetings of the
- Trusted Systems Interoperability Group (TSIG), helped to demonstrate
- the value of a generic, mechanism-independent security service API.
-
-6. Security Considerations
-
- Security issues are discussed throughout this memo.
-
-7. Author's Address
-
- John Linn
- Geer Zolot Associates
- One Main St.
- Cambridge, MA 02142 USA
-
- Phone: +1 617.374.3700
- Email: Linn@gza.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn [Page 46]
-
-RFC 1508 Generic Security Interface September 1993
-
-
-APPENDIX A
-
-PACS AND AUTHORIZATION SERVICES
-
- Consideration has been given to modifying the GSS-API service
- interface to recognize and manipulate Privilege Attribute
- Certificates (PACs) as in ECMA 138, carrying authorization data as a
- side effect of establishing a security context, but no such
- modifications have been incorporated at this time. This appendix
- provides rationale for this decision and discusses compatibility
- alternatives between PACs and the GSS-API which do not require that
- PACs be made visible to GSS-API callers.
-
- Existing candidate mechanism types such as Kerberos and X.509 do not
- incorporate PAC manipulation features, and exclusion of such
- mechanisms from the set of candidates equipped to fully support the
- GSS-API seems inappropriate. Inclusion (and GSS-API visibility) of a
- feature supported by only a limited number of mechanisms could
- encourage the development of ostensibly portable applications which
- would in fact have only limited portability.
-
- The status quo, in which PACs are not visible across the GSS-API
- interface, does not preclude implementations in which PACs are
- carried transparently, within the tokens defined and used for certain
- mech_types, and stored within peers' credentials and context-level
- data structures. While invisible to API callers, such PACs could be
- used by operating system or other local functions as inputs in the
- course of mediating access requests made by callers. This course of
- action allows dynamic selection of PAC contents, if such selection is
- administratively-directed rather than caller-directed.
-
- In a distributed computing environment, authentication must span
- different systems; the need for such authentication provides
- motivation for GSS-API definition and usage. Heterogeneous systems in
- a network can intercommunicate, with globally authenticated names
- comprising the common bond between locally defined access control
- policies. Access control policies to which authentication provides
- inputs are often local, or specific to particular operating systems
- or environments. If the GSS-API made particular authorization models
- visible across its service interface, its scope of application would
- become less general. The current GSS-API paradigm is consistent with
- the precedent set by Kerberos, neither defining the interpretation of
- authorization-related data nor enforcing access controls based on
- such data.
-
- The GSS-API is a general interface, whose callers may reside inside
- or outside any defined TCB or NTCB boundaries. Given this
- characteristic, it appears more realistic to provide facilities which
-
-
-
-Linn [Page 47]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- provide "value-added" security services to its callers than to offer
- facilities which enforce restrictions on those callers. Authorization
- decisions must often be mediated below the GSS-API level in a local
- manner against (or in spite of) applications, and cannot be
- selectively invoked or omitted at those applications' discretion.
- Given that the GSS-API's placement prevents it from providing a
- comprehensive solution to the authorization issue, the value of a
- partial contribution specific to particular authorization models is
- debatable.
-
-APPENDIX B
-
-MECHANISM-INDEPENDENT TOKEN FORMAT
-
- This appendix specifies a mechanism-independent level of
- encapsulating representation for the initial token of a GSS-API
- context establishment sequence, incorporating an identifier of the
- mechanism type to be used on that context. Use of this format (with
- ASN.1-encoded data elements represented in BER, constrained in the
- interests of parsing simplicity to the Distinguished Encoding Rule
- (DER) BER subset defined in X.509, clause 8.7) is recommended to the
- designers of GSS-API implementations based on various mechanisms, so
- that tokens can be interpreted unambiguously at GSS-API peers. There
- is no requirement that the mechanism-specific innerContextToken,
- innerMsgToken, and sealedUserData data elements be encoded in ASN.1
- BER.
-
- -- optional top-level token definitions to
- -- frame different mechanisms
-
- GSS-API DEFINITIONS ::=
-
- BEGIN
-
- MechType ::= OBJECT IDENTIFIER
- -- data structure definitions
-
- -- callers must be able to distinguish among
- -- InitialContextToken, SubsequentContextToken,
- -- PerMsgToken, and SealedMessage data elements
- -- based on the usage in which they occur
-
- InitialContextToken ::=
- -- option indication (delegation, etc.) indicated within
- -- mechanism-specific token
- [APPLICATION 0] IMPLICIT SEQUENCE {
- thisMech MechType,
- innerContextToken ANY DEFINED BY thisMech
-
-
-
-Linn [Page 48]
-
-RFC 1508 Generic Security Interface September 1993
-
-
- -- contents mechanism-specific
- }
-
- SubsequentContextToken ::= innerContextToken ANY
- -- interpretation based on predecessor InitialContextToken
-
- PerMsgToken ::=
- -- as emitted by GSS_Sign and processed by GSS_Verify
- innerMsgToken ANY
-
- SealedMessage ::=
- -- as emitted by GSS_Seal and processed by GSS_Unseal
- -- includes internal, mechanism-defined indicator
- -- of whether or not encrypted
- sealedUserData ANY
-
- END
-
-APPENDIX C
-
-MECHANISM DESIGN CONSTRAINTS
-
- The following constraints on GSS-API mechanism designs are adopted in
- response to observed caller protocol requirements, and adherence
- thereto is anticipated in subsequent descriptions of GSS-API
- mechanisms to be documented in standards-track Internet
- specifications.
-
- Use of the approach defined in Appendix B of this specification,
- applying a mechanism type tag to the InitialContextToken, is
- required.
-
- It is strongly recommended that mechanisms offering per-message
- protection services also offer at least one of the replay detection
- and sequencing services, as mechanisms offering neither of the latter
- will fail to satisfy recognized requirements of certain candidate
- caller protocols.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn [Page 49]
-
\ No newline at end of file
diff --git a/doc/standardisation/rfc1509.txt b/doc/standardisation/rfc1509.txt
deleted file mode 100644
index f36cd80e6dcdaa52c8215b6b0c28013e1c513130..0000000000000000000000000000000000000000
--- a/doc/standardisation/rfc1509.txt
+++ /dev/null
@@ -1,2691 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Wray
-Request for Comments: 1509 Digital Equipment Corporation
- September 1993
-
-
- Generic Security Service API : C-bindings
-
-Status of this Memo
-
- This RFC specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" for the standardization state and status
- of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This document specifies C language bindings for the Generic Security
- Service Application Program Interface (GSS-API), which is described
- at a language-independent conceptual level in other documents.
-
- The Generic Security Service Application Programming Interface (GSS-
- API) provides security services to its callers, and is intended for
- implementation atop alternative underlying cryptographic mechanisms.
- Typically, GSS-API callers will be application protocols into which
- security enhancements are integrated through invocation of services
- provided by the GSS-API. The GSS-API allows a caller application to
- authenticate a principal identity associated with a peer application,
- to delegate rights to a peer, and to apply security services such as
- confidentiality and integrity on a per-message basis.
-
-1. INTRODUCTION
-
- The Generic Security Service Application Programming Interface [1]
- provides security services to calling applications. It allows a
- communicating application to authenticate the user associated with
- another application, to delegate rights to another application, and
- to apply security services such as confidentiality and integrity on a
- per-message basis.
-
- There are four stages to using the GSSAPI:
-
- (a) The application acquires a set of credentials with which it may
- prove its identity to other processes. The application's
- credentials vouch for its global identity, which may or may not
- be related to the local username under which it is running.
-
-
-
-
-
-Wray [Page 1]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- (b) A pair of communicating applications establish a joint security
- context using their credentials. The security context is a
- pair of GSSAPI data structures that contain shared state
- information, which is required in order that per-message
- security services may be provided. As part of the
- establishment of a security context, the context initiator is
- authenticated to the responder, and may require that the
- responder is authenticated in turn. The initiator may
- optionally give the responder the right to initiate further
- security contexts. This transfer of rights is termed
- delegation, and is achieved by creating a set of credentials,
- similar to those used by the originating application, but which
- may be used by the responder. To establish and maintain the
- shared information that makes up the security context, certain
- GSSAPI calls will return a token data structure, which is a
- cryptographically protected opaque data type. The caller of
- such a GSSAPI routine is responsible for transferring the token
- to the peer application, which should then pass it to a
- corresponding GSSAPI routine which will decode it and extract
- the information.
-
- (c) Per-message services are invoked to apply either:
-
- (i) integrity and data origin authentication, or
-
- (ii) confidentiality, integrity and data origin authentication
- to application data, which are treated by GSSAPI as
- arbitrary octet-strings. The application transmitting a
- message that it wishes to protect will call the appropriate
- GSSAPI routine (sign or seal) to apply protection, specifying
- the appropriate security context, and send the result to the
- receiving application. The receiver will pass the received
- data to the corresponding decoding routine (verify or unseal)
- to remove the protection and validate the data.
-
- (d) At the completion of a communications session (which may extend
- across several connections), the peer applications call GSSAPI
- routines to delete the security context. Multiple contexts may
- also be used (either successively or simultaneously) within a
- single communications association.
-
-2. GSSAPI Routines
-
- This section lists the functions performed by each of the GSSAPI
- routines and discusses their major parameters, describing how they
- are to be passed to the routines. The routines are listed in figure
- 4-1.
-
-
-
-
-Wray [Page 2]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- Figure 4-1 GSSAPI Routines
-
-
- Routine Function
-
- gss_acquire_cred Assume a global identity
-
- gss_release_cred Discard credentials
-
- gss_init_sec_context Initiate a security context
- with a peer application
-
- gss_accept_sec_context Accept a security context
- initiated by a peer
- application
-
- gss_process_context_token Process a token on a security
- context from a peer
- application
-
- gss_delete_sec_context Discard a security context
-
- gss_context_time Determine for how long a
- context will remain valid
-
- gss_sign Sign a message; integrity
- service
-
- gss_verify Check signature on a message
-
- gss_seal Sign (optionally encrypt) a
- message; confidentiality
- service
-
- gss_unseal Verify (optionally decrypt)
- message
-
- gss_display_status Convert an API status code
- to text
-
- gss_indicate_mechs Determine underlying
- authentication mechanism
-
- gss_compare_name Compare two internal-form
- names
-
- gss_display_name Convert opaque name to text
-
-
-
-
-Wray [Page 3]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- gss_import_name Convert a textual name to
- internal-form
-
- gss_release_name Discard an internal-form
- name
-
- gss_release_buffer Discard a buffer
-
- gss_release_oid_set Discard a set of object
- identifiers
-
- gss_inquire_cred Determine information about
- a credential
-
- Individual GSSAPI implementations may augment these routines by
- providing additional mechanism-specific routines if required
- functionality is not available from the generic forms. Applications
- are encouraged to use the generic routines wherever possible on
- portability grounds.
-
-2.1. Data Types and Calling Conventions
-
- The following conventions are used by the GSSAPI:
-
-2.1.1. Structured data types
-
- Wherever these GSSAPI C-bindings describe structured data, only
- fields that must be provided by all GSSAPI implementation are
- documented. Individual implementations may provide additional
- fields, either for internal use within GSSAPI routines, or for use by
- non-portable applications.
-
-2.1.2. Integer types
-
- GSSAPI defines the following integer data type:
-
- OM_uint32 32-bit unsigned integer
-
- Where guaranteed minimum bit-count is important, this portable data
- type is used by the GSSAPI routine definitions. Individual GSSAPI
- implementations will include appropriate typedef definitions to map
- this type onto a built-in data type.
-
-2.1.3. String and similar data
-
- Many of the GSSAPI routines take arguments and return values that
- describe contiguous multiple-byte data. All such data is passed
- between the GSSAPI and the caller using the gss_buffer_t data type.
-
-
-
-Wray [Page 4]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- This data type is a pointer to a buffer descriptor, which consists of
- a length field that contains the total number of bytes in the datum,
- and a value field which contains a pointer to the actual datum:
-
- typedef struct gss_buffer_desc_struct {
- size_t length;
- void *value;
- } gss_buffer_desc, *gss_buffer_t;
-
- Storage for data passed to the application by a GSSAPI routine using
- the gss_buffer_t conventions is allocated by the GSSAPI routine. The
- application may free this storage by invoking the gss_release_buffer
- routine. Allocation of the gss_buffer_desc object is always the
- responsibility of the application; Unused gss_buffer_desc objects
- may be initialized to the value GSS_C_EMPTY_BUFFER.
-
-2.1.3.1. Opaque data types
-
- Certain multiple-word data items are considered opaque data types at
- the GSSAPI, because their internal structure has no significance
- either to the GSSAPI or to the caller. Examples of such opaque data
- types are the input_token parameter to gss_init_sec_context (which is
- opaque to the caller), and the input_message parameter to gss_seal
- (which is opaque to the GSSAPI). Opaque data is passed between the
- GSSAPI and the application using the gss_buffer_t datatype.
-
-2.1.3.2. Character strings
-
- Certain multiple-word data items may be regarded as simple ISO
- Latin-1 character strings. An example of this is the
- input_name_buffer parameter to gss_import_name. Some GSSAPI routines
- also return character strings. Character strings are passed between
- the application and the GSSAPI using the gss_buffer_t datatype,
- defined earlier.
-
-2.1.4. Object Identifiers
-
- Certain GSSAPI procedures take parameters of the type gss_OID, or
- Object identifier. This is a type containing ISO-defined tree-
- structured values, and is used by the GSSAPI caller to select an
- underlying security mechanism. A value of type gss_OID has the
- following structure:
-
- typedef struct gss_OID_desc_struct {
- OM_uint32 length;
- void *elements;
- } gss_OID_desc, *gss_OID;
-
-
-
-
-Wray [Page 5]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- The elements field of this structure points to the first byte of an
- octet string containing the ASN.1 BER encoding of the value of the
- gss_OID. The length field contains the number of bytes in this
- value. For example, the gss_OID value corresponding to {iso(1)
- identified- oganization(3) icd-ecma(12) member-company(2) dec(1011)
- cryptoAlgorithms(7) SPX(5)} meaning SPX (Digital's X.509
- authentication mechanism) has a length field of 7 and an elements
- field pointing to seven octets containing the following octal values:
- 53,14,2,207,163,7,5. GSSAPI implementations should provide constant
- gss_OID values to allow callers to request any supported mechanism,
- although applications are encouraged on portability grounds to accept
- the default mechanism. gss_OID values should also be provided to
- allow applications to specify particular name types (see section
- 2.1.10). Applications should treat gss_OID_desc values returned by
- GSSAPI routines as read-only. In particular, the application should
- not attempt to deallocate them. The gss_OID_desc datatype is
- equivalent to the X/Open OM_object_identifier datatype [2].
-
-2.1.5. Object Identifier Sets
-
- Certain GSSAPI procedures take parameters of the type gss_OID_set.
- This type represents one or more object identifiers (section 2.1.4).
- A gss_OID_set object has the following structure:
-
- typedef struct gss_OID_set_desc_struct {
- int count;
- gss_OID elements;
- } gss_OID_set_desc, *gss_OID_set;
-
- The count field contains the number of OIDs within the set. The
- elements field is a pointer to an array of gss_OID_desc objects, each
- of which describes a single OID. gss_OID_set values are used to name
- the available mechanisms supported by the GSSAPI, to request the use
- of specific mechanisms, and to indicate which mechanisms a given
- credential supports. Storage associated with gss_OID_set values
- returned to the application by the GSSAPI may be deallocated by the
- gss_release_oid_set routine.
-
-2.1.6. Credentials
-
- A credential handle is a caller-opaque atomic datum that identifies a
- GSSAPI credential data structure. It is represented by the caller-
- opaque type gss_cred_id_t, which may be implemented as either an
- arithmetic or a pointer type. Credentials describe a principal, and
- they give their holder the ability to act as that principal. The
- GSSAPI does not make the actual credentials available to
- applications; instead the credential handle is used to identify a
- particular credential, held internally by GSSAPI or underlying
-
-
-
-Wray [Page 6]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- mechanism. Thus the credential handle contains no security-relavent
- information, and requires no special protection by the application.
- Depending on the implementation, a given credential handle may refer
- to different credentials when presented to the GSSAPI by different
- callers. Individual GSSAPI implementations should define both the
- scope of a credential handle and the scope of a credential itself
- (which must be at least as wide as that of a handle). Possibilities
- for credential handle scope include the process that acquired the
- handle, the acquiring process and its children, or all processes
- sharing some local identification information (e.g., UID). If no
- handles exist by which a given credential may be reached, the GSSAPI
- may delete the credential.
-
- Certain routines allow credential handle parameters to be omitted to
- indicate the use of a default credential. The mechanism by which a
- default credential is established and its scope should be defined by
- the individual GSSAPI implementation.
-
-2.1.7. Contexts
-
- The gss_ctx_id_t data type contains a caller-opaque atomic value that
- identifies one end of a GSSAPI security context. It may be
- implemented as either an arithmetic or a pointer type. Depending on
- the implementation, a given gss_ctx_id_t value may refer to different
- GSSAPI security contexts when presented to the GSSAPI by different
- callers. The security context holds state information about each end
- of a peer communication, including cryptographic state information.
- Individual GSSAPI implementations should define the scope of a
- context. Since no way is provided by which a new gss_ctx_id_t value
- may be obtained for an existing context, the scope of a context
- should be the same as the scope of a gss_ctx_id_t.
-
-2.1.8. Authentication tokens
-
- A token is a caller-opaque type that GSSAPI uses to maintain
- synchronization between the context data structures at each end of a
- GSSAPI security context. The token is a cryptographically protected
- bit-string, generated by the underlying mechanism at one end of a
- GSSAPI security context for use by the peer mechanism at the other
- end. Encapsulation (if required) and transfer of the token are the
- responsibility of the peer applications. A token is passed between
- the GSSAPI and the application using the gss_buffer_t conventions.
-
-2.1.9. Status values
-
- One or more status codes are returned by each GSSAPI routine. Two
- distinct sorts of status codes are returned. These are termed GSS
- status codes and Mechanism status codes.
-
-
-
-Wray [Page 7]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
-2.1.9.1. GSS status codes
-
- GSSAPI routines return GSS status codes as their OM_uint32 function
- value. These codes indicate errors that are independent of the
- underlying mechanism used to provide the security service. The
- errors that can be indicated via a GSS status code are either generic
- API routine errors (errors that are defined in the GSSAPI
- specification) or calling errors (errors that are specific to these
- bindings).
-
- A GSS status code can indicate a single fatal generic API error from
- the routine and a single calling error. In addition, supplementary
- status information may be indicated via the setting of bits in the
- supplementary info field of a GSS status code.
-
- These errors are encoded into the 32-bit GSS status code as follows:
-
- MSB LSB
- |------------------------------------------------------------|
- | Calling Error | Routine Error | Supplementary Info |
- |------------------------------------------------------------|
- Bit 31 24 23 16 15 0
-
- Hence if a GSSAPI routine returns a GSS status code whose upper 16
- bits contain a non-zero value, the call failed. If the calling error
- field is non-zero, the invoking application's call of the routine was
- erroneous. Calling errors are defined in table 5-1. If the routine
- error field is non-zero, the routine failed for one of the routine-
- specific reasons listed below in table 5-2. Whether or not the upper
- 16 bits indicate a failure or a success, the routine may indicate
- additional information by setting bits in the supplementary info
- field of the status code. The meaning of individual bits is listed
- below in table 5-3.
-
- Table 5-1 Calling Errors
-
- Name Value in Meaning
- Field
- GSS_S_CALL_INACCESSIBLE_READ 1 A required input
- parameter could
- not be read.
- GSS_S_CALL_INACCESSIBLE_WRITE 2 A required output
- parameter could
- not be written.
- GSS_S_CALL_BAD_STRUCTURE 3 A parameter was
- malformed
-
-
-
-
-
-Wray [Page 8]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- Table 5-2 Routine Errors
-
- Name Value in Meaning
- Field
-
- GSS_S_BAD_MECH 1 An unsupported mechanism was
- requested
- GSS_S_BAD_NAME 2 An invalid name was supplied
- GSS_S_BAD_NAMETYPE 3 A supplied name was of an
- unsupported type
- GSS_S_BAD_BINDINGS 4 Incorrect channel bindings
- were supplied
- GSS_S_BAD_STATUS 5 An invalid status code was
- supplied
-
- GSS_S_BAD_SIG 6 A token had an invalid
- signature
- GSS_S_NO_CRED 7 No credentials were supplied
- GSS_S_NO_CONTEXT 8 No context has been
- established
- GSS_S_DEFECTIVE_TOKEN 9 A token was invalid
- GSS_S_DEFECTIVE_CREDENTIAL 10 A credential was invalid
- GSS_S_CREDENTIALS_EXPIRED 11 The referenced credentials
- have expired
- GSS_S_CONTEXT_EXPIRED 12 The context has expired
- GSS_S_FAILURE 13 Miscellaneous failure
- (see text)
-
- Table 5-3 Supplementary Status Bits
-
- Name Bit Number Meaning
- GSS_S_CONTINUE_NEEDED 0 (LSB) The routine must be called
- again to complete its
- function.
- See routine documentation for
- detailed description.
- GSS_S_DUPLICATE_TOKEN 1 The token was a duplicate of
- an earlier token
- GSS_S_OLD_TOKEN 2 The token's validity period
- has expired
- GSS_S_UNSEQ_TOKEN 3 A later token has already been
- processed
-
- The routine documentation also uses the name GSS_S_COMPLETE, which is
- a zero value, to indicate an absence of any API errors or
- supplementary information bits.
-
-
-
-
-
-Wray [Page 9]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- All GSS_S_xxx symbols equate to complete OM_uint32 status codes,
- rather than to bitfield values. For example, the actual value of the
- symbol GSS_S_BAD_NAMETYPE (value 3 in the routine error field) is 3
- << 16.
-
- The macros GSS_CALLING_ERROR(), GSS_ROUTINE_ERROR() and
- GSS_SUPPLEMENTARY_INFO() are provided, each of which takes a GSS
- status code and removes all but the relevant field. For example, the
- value obtained by applying GSS_ROUTINE_ERROR to a status code removes
- the calling errors and supplementary info fields, leaving only the
- routine errors field. The values delivered by these macros may be
- directly compared with a GSS_S_xxx symbol of the appropriate type.
- The macro GSS_ERROR() is also provided, which when applied to a GSS
- status code returns a non-zero value if the status code indicated a
- calling or routine error, and a zero value otherwise.
-
- A GSSAPI implementation may choose to signal calling errors in a
- platform-specific manner instead of, or in addition to the routine
- value; routine errors and supplementary info should be returned via
- routine status values only.
-
-2.1.9.2. Mechanism-specific status codes
-
- GSSAPI routines return a minor_status parameter, which is used to
- indicate specialized errors from the underlying security mechanism.
- This parameter may contain a single mechanism-specific error,
- indicated by a OM_uint32 value.
-
- The minor_status parameter will always be set by a GSSAPI routine,
- even if it returns a calling error or one of the generic API errors
- indicated above as fatal, although other output parameters may remain
- unset in such cases. However, output parameters that are expected to
- return pointers to storage allocated by a routine must always set set
- by the routine, even in the event of an error, although in such cases
- the GSSAPI routine may elect to set the returned parameter value to
- NULL to indicate that no storage was actually allocated. Any length
- field associated with such pointers (as in a gss_buffer_desc
- structure) should also be set to zero in such cases.
-
- The GSS status code GSS_S_FAILURE is used to indicate that the
- underlying mechanism detected an error for which no specific GSS
- status code is defined. The mechanism status code will provide more
- details about the error.
-
-2.1.10. Names
-
- A name is used to identify a person or entity. GSSAPI authenticates
- the relationship between a name and the entity claiming the name.
-
-
-
-Wray [Page 10]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- Two distinct representations are defined for names:
-
- (a) A printable form, for presentation to a user
-
- (b) An internal form, for presentation at the API
-
- The syntax of a printable name is defined by the GSSAPI
- implementation, and may be dependent on local system configuration,
- or on individual user preference. The internal form provides a
- canonical representation of the name that is independent of
- configuration.
-
- A given GSSAPI implementation may support names drawn from multiple
- namespaces. In such an implementation, the internal form of the name
- must include fields that identify the namespace from which the name
- is drawn. The namespace from which a printable name is drawn is
- specified by an accompanying object identifier.
-
- Routines (gss_import_name and gss_display_name) are provided to
- convert names between their printable representations and the
- gss_name_t type. gss_import_name may support multiple syntaxes for
- each supported namespace, allowing users the freedom to choose a
- preferred name representation. gss_display_name should use an
- implementation-chosen preferred syntax for each supported name-type.
-
- Comparison of internal-form names is accomplished via the
- gss_compare_names routine. This removes the need for the application
- program to understand the syntaxes of the various printable names
- that a given GSSAPI implementation may support.
-
- Storage is allocated by routines that return gss_name_t values. A
- procedure, gss_release_name, is provided to free storage associated
- with a name.
-
-2.1.11. Channel Bindings
-
- GSSAPI supports the use of user-specified tags to identify a given
- context to the peer application. These tags are used to identify the
- particular communications channel that carries the context. Channel
- bindings are communicated to the GSSAPI using the following
- structure:
-
-
-
-
-
-
-
-
-
-
-Wray [Page 11]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- typedef struct gss_channel_bindings_struct {
- OM_uint32 initiator_addrtype;
- gss_buffer_desc initiator_address;
- OM_uint32 acceptor_addrtype;
- gss_buffer_desc acceptor_address;
- gss_buffer_desc application_data;
- } *gss_channel_bindings_t;
-
- The initiator_addrtype and acceptor_addrtype fields denote the type
- of addresses contained in the initiator_address and acceptor_address
- buffers. The address type should be one of the following:
-
- GSS_C_AF_UNSPEC Unspecified address type
- GSS_C_AF_LOCAL Host-local address type
- GSS_C_AF_INET DARPA Internet address type
- GSS_C_AF_IMPLINK ARPAnet IMP address type (eg IP)
- GSS_C_AF_PUP pup protocols (eg BSP) address type
- GSS_C_AF_CHAOS MIT CHAOS protocol address type
- GSS_C_AF_NS XEROX NS address type
- GSS_C_AF_NBS nbs address type
- GSS_C_AF_ECMA ECMA address type
- GSS_C_AF_DATAKIT datakit protocols address type
- GSS_C_AF_CCITT CCITT protocols (eg X.25)
- GSS_C_AF_SNA IBM SNA address type
- GSS_C_AF_DECnet DECnet address type
- GSS_C_AF_DLI Direct data link interface address type
- GSS_C_AF_LAT LAT address type
- GSS_C_AF_HYLINK NSC Hyperchannel address type
- GSS_C_AF_APPLETALK AppleTalk address type
- GSS_C_AF_BSC BISYNC 2780/3780 address type
- GSS_C_AF_DSS Distributed system services address type
- GSS_C_AF_OSI OSI TP4 address type
- GSS_C_AF_X25 X25
- GSS_C_AF_NULLADDR No address specified
-
- Note that these name address families rather than specific addressing
- formats. For address families that contain several alternative
- address forms, the initiator_address and acceptor_address fields must
- contain sufficient information to determine which address form is
- used. When not otherwise specified, addresses should be specified in
- network byte-order.
-
- Conceptually, the GSSAPI concatenates the initiator_addrtype,
- initiator_address, acceptor_addrtype, acceptor_address and
- application_data to form an octet string. The mechanism signs this
- octet string, and binds the signature to the context establishment
- token emitted by gss_init_sec_context. The same bindings are
- presented by the context acceptor to gss_accept_sec_context, and a
-
-
-
-Wray [Page 12]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- signature is calculated in the same way. The calculated signature is
- compared with that found in the token, and if the signatures differ,
- gss_accept_sec_context will return a GSS_S_BAD_BINDINGS error, and
- the context will not be established. Some mechanisms may include the
- actual channel binding data in the token (rather than just a
- signature); applications should therefore not use confidential data
- as channel-binding components. Individual mechanisms may impose
- additional constraints on addresses and address types that may appear
- in channel bindings. For example, a mechanism may verify that the
- initiator_address field of the channel bindings presented to
- gss_init_sec_context contains the correct network address of the host
- system.
-
-2.1.12. Optional parameters
-
- Various parameters are described as optional. This means that they
- follow a convention whereby a default value may be requested. The
- following conventions are used for omitted parameters. These
- conventions apply only to those parameters that are explicitly
- documented as optional.
-
-2.1.12.1. gss_buffer_t types
-
- Specify GSS_C_NO_BUFFER as a value. For an input parameter this
- signifies that default behavior is requested, while for an output
- parameter it indicates that the information that would be returned
- via the parameter is not required by the application.
-
-2.1.12.2. Integer types (input)
-
- Individual parameter documentation lists values to be used to
- indicate default actions.
-
-2.1.12.3. Integer types (output)
-
- Specify NULL as the value for the pointer.
-
-2.1.12.4. Pointer types
-
- Specify NULL as the value.
-
-2.1.12.5. Object IDs
-
- Specify GSS_C_NULL_OID as the value.
-
-2.1.12.6. Object ID Sets
-
- Specify GSS_C_NULL_OID_SET as the value.
-
-
-
-Wray [Page 13]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
-2.1.12.7. Credentials
-
- Specify GSS_C_NO_CREDENTIAL to use the default credential handle.
-
-2.1.12.8. Channel Bindings
-
- Specify GSS_C_NO_CHANNEL_BINDINGS to indicate that channel bindings
- are not to be used.
-
-3. GSSAPI routine descriptions
-
-2.1. gss_acquire_cred
-
- OM_uint32 gss_acquire_cred (
- OM_uint32 * minor_status,
- gss_name_t desired_name,
- OM_uint32 time_req,
- gss_OID_set desired_mechs,
- int cred_usage,
- gss_cred_id_t * output_cred_handle,
- gss_OID_set * actual_mechs,
- OM_int32 * time_rec)
- Purpose:
-
- Allows an application to acquire a handle for a pre-existing
- credential by name. GSSAPI implementations must impose a local
- access-control policy on callers of this routine to prevent
- unauthorized callers from acquiring credentials to which they are not
- entitled. This routine is not intended to provide a "login to the
- network" function, as such a function would result in the creation of
- new credentials rather than merely acquiring a handle to existing
- credentials. Such functions, if required, should be defined in
- implementation-specific extensions to the API.
-
- If credential acquisition is time-consuming for a mechanism, the
- mechanism may chooses to delay the actual acquisition until the
- credential is required (e.g., by gss_init_sec_context or
- gss_accept_sec_context). Such mechanism-specific implementation
- decisions should be invisible to the calling application; thus a call
- of gss_inquire_cred immediately following the call of
- gss_acquire_cred must return valid credential data, and may therefore
- incur the overhead of a deferred credential acquisition.
-
- Parameters:
-
- desired_name gss_name_t, read
- Name of principal whose credential
- should be acquired
-
-
-
-Wray [Page 14]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- time_req integer, read
- number of seconds that credentials
- should remain valid
-
- desired_mechs Set of Object IDs, read
- set of underlying security mechanisms that
- may be used. GSS_C_NULL_OID_SET may be used
- to obtain an implementation-specific default.
-
- cred_usage integer, read
- GSS_C_BOTH - Credentials may be used
- either to initiate or accept
- security contexts.
- GSS_C_INITIATE - Credentials will only be
- used to initiate security
- contexts.
- GSS_C_ACCEPT - Credentials will only be used to
- accept security contexts.
-
- output_cred_handle gss_cred_id_t, modify
- The returned credential handle.
-
- actual_mechs Set of Object IDs, modify, optional
- The set of mechanisms for which the
- credential is valid. Specify NULL
- if not required.
-
- time_rec Integer, modify, optional
- Actual number of seconds for which the
- returned credentials will remain valid. If the
- implementation does not support expiration of
- credentials, the value GSS_C_INDEFINITE will
- be returned. Specify NULL if not required
-
- minor_status Integer, modify
- Mechanism specific status code.
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_MECH Unavailable mechanism requested
-
- GSS_S_BAD_NAMETYPE Type contained within desired_name parameter is
- not supported
-
- GSS_S_BAD_NAME Value supplied for desired_name parameter is
-
-
-
-Wray [Page 15]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- ill-formed.
-
- GSS_S_FAILURE Unspecified failure. The minor_status parameter
- contains more detailed information
-
-3.2. gss_release_cred
-
- OM_uint32 gss_release_cred (
- OM_uint32 * minor_status,
- gss_cred_id_t * cred_handle)
-
- Purpose:
-
- Informs GSSAPI that the specified credential handle is no longer
- required by the process. When all processes have released a
- credential, it will be deleted.
-
- Parameters:
-
- cred_handle gss_cred_id_t, modify, optional
- buffer containing opaque credential
- handle. If GSS_C_NO_CREDENTIAL is supplied,
- the default credential will be released
-
- minor_status integer, modify
- Mechanism specific status code.
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_NO_CRED Credentials could not be accessed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wray [Page 16]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
-3.3. gss_init_sec_context
-
- OM_uint32 gss_init_sec_context (
- OM_uint32 * minor_status,
- gss_cred_id_t claimant_cred_handle,
- gss_ctx_id_t * context_handle,
- gss_name_t target_name,
- gss_OID mech_type,
- int req_flags,
- int time_req,
- gss_channel_bindings_t
- input_chan_bindings,
- gss_buffer_t input_token
- gss_OID * actual_mech_type,
- gss_buffer_t output_token,
- int * ret_flags,
- OM_uint32 * time_rec )
-
- Purpose:
-
- Initiates the establishment of a security context between the
- application and a remote peer. Initially, the input_token parameter
- should be specified as GSS_C_NO_BUFFER. The routine may return a
- output_token which should be transferred to the peer application,
- where the peer application will present it to gss_accept_sec_context.
- If no token need be sent, gss_init_sec_context will indicate this by
- setting the length field of the output_token argument to zero. To
- complete the context establishment, one or more reply tokens may be
- required from the peer application; if so, gss_init_sec_context will
- return a status indicating GSS_S_CONTINUE_NEEDED in which case it
- should be called again when the reply token is received from the peer
- application, passing the token to gss_init_sec_context via the
- input_token parameters.
-
- The values returned via the ret_flags and time_rec parameters are not
- defined unless the routine returns GSS_S_COMPLETE.
-
- Parameters:
-
- claimant_cred_handle gss_cred_id_t, read, optional
- handle for credentials claimed. Supply
- GSS_C_NO_CREDENTIAL to use default
- credentials.
-
- context_handle gss_ctx_id_t, read/modify
- context handle for new context. Supply
- GSS_C_NO_CONTEXT for first call; use value
- returned by first call in continuation calls.
-
-
-
-Wray [Page 17]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- target_name gss_name_t, read
- Name of target
-
- mech_type OID, read, optional
- Object ID of desired mechanism. Supply
- GSS_C_NULL_OID to obtain an implementation
- specific default
-
- req_flags bit-mask, read
- Contains four independent flags, each of
- which requests that the context support a
- specific service option. Symbolic
- names are provided for each flag, and the
- symbolic names corresponding to the required
- flags should be logically-ORed
- together to form the bit-mask value. The
- flags are:
-
- GSS_C_DELEG_FLAG
- True - Delegate credentials to remote peer
- False - Don't delegate
- GSS_C_MUTUAL_FLAG
- True - Request that remote peer
- authenticate itself
- False - Authenticate self to remote peer
- only
- GSS_C_REPLAY_FLAG
- True - Enable replay detection for signed
- or sealed messages
- False - Don't attempt to detect
- replayed messages
- GSS_C_SEQUENCE_FLAG
- True - Enable detection of out-of-sequence
- signed or sealed messages
- False - Don't attempt to detect
- out-of-sequence messages
-
- time_req integer, read
- Desired number of seconds for which context
- should remain valid. Supply 0 to request a
- default validity period.
-
- input_chan_bindings channel bindings, read
- Application-specified bindings. Allows
- application to securely bind channel
- identification information to the security
- context.
-
-
-
-
-Wray [Page 18]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- input_token buffer, opaque, read, optional (see text)
- Token received from peer application.
- Supply GSS_C_NO_BUFFER on initial call.
-
- actual_mech_type OID, modify
- actual mechanism used.
-
- output_token buffer, opaque, modify
- token to be sent to peer application. If
- the length field of the returned buffer is
- zero, no token need be sent to the peer
- application.
-
- ret_flags bit-mask, modify
- Contains six independent flags, each of which
- indicates that the context supports a specific
- service option. Symbolic names are provided
- for each flag, and the symbolic names
- corresponding to the required flags should be
- logically-ANDed with the ret_flags value to test
- whether a given option is supported by the
- context. The flags are:
-
- GSS_C_DELEG_FLAG
- True - Credentials were delegated to
- the remote peer
- False - No credentials were delegated
- GSS_C_MUTUAL_FLAG
- True - Remote peer has been asked to
- authenticated itself
- False - Remote peer has not been asked to
- authenticate itself
- GSS_C_REPLAY_FLAG
- True - replay of signed or sealed messages
- will be detected
- False - replayed messages will not be
- detected
- GSS_C_SEQUENCE_FLAG
- True - out-of-sequence signed or sealed
- messages will be detected
- False - out-of-sequence messages will not
- be detected
- GSS_C_CONF_FLAG
- True - Confidentiality service may be
- invoked by calling seal routine
- False - No confidentiality service (via
- seal) available. seal will provide
- message encapsulation, data-origin
-
-
-
-Wray [Page 19]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- authentication and integrity
- services only.
- GSS_C_INTEG_FLAG
- True - Integrity service may be invoked by
- calling either gss_sign or gss_seal
- routines.
- False - Per-message integrity service
- unavailable.
-
- time_rec integer, modify, optional
- number of seconds for which the context
- will remain valid. If the implementation does
- not support credential expiration, the value
- GSS_C_INDEFINITE will be returned. Specify
- NULL if not required.
-
- minor_status integer, modify
- Mechanism specific status code.
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
- application is required to complete thecontext, and
- that gss_init_sec_context must be called again with
- that token.
-
- GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed on
- the input_token failed
-
- GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
- performed on the credential failed.
-
- GSS_S_NO_CRED The supplied credentials were not valid for context
- initiation, or the credential handle did not
- reference any credentials.
-
- GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired
-
- GSS_S_BAD_BINDINGS The input_token contains different channel
- bindings to those specified via the
- input_chan_bindings parameter
-
- GSS_S_BAD_SIG The input_token contains an invalid signature, or a
- signature that could not be verified
-
-
-
-Wray [Page 20]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- GSS_S_OLD_TOKEN The input_token was too old. This is a fatal error
- during context establishment
-
- GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate of
- a token already processed. This is a fatal error
- during context establishment.
-
- GSS_S_NO_CONTEXT Indicates that the supplied context handle did not
- refer to a valid context
-
- GSS_S_BAD_NAMETYPE The provided target_name parameter contained an
- invalid or unsupported type of name
-
- GSS_S_BAD_NAME The provided target_name parameter was ill-formed.
-
- GSS_S_FAILURE Failure. See minor_status for more information
-
-3.4. gss_accept_sec_context
-
- OM_uint32 gss_accept_sec_context (
- OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- gss_cred_id_t verifier_cred_handle,
- gss_buffer_t input_token_buffer
- gss_channel_bindings_t
- input_chan_bindings,
- gss_name_t * src_name,
- gss_OID * mech_type,
- gss_buffer_t output_token,
- int * ret_flags,
- OM_uint32 * time_rec,
- gss_cred_id_t * delegated_cred_handle)
-
- Purpose:
-
- Allows a remotely initiated security context between the application
- and a remote peer to be established. The routine may return a
- output_token which should be transferred to the peer application,
- where the peer application will present it to gss_init_sec_context.
- If no token need be sent, gss_accept_sec_context will indicate this
- by setting the length field of the output_token argument to zero. To
- complete the context establishment, one or more reply tokens may be
- required from the peer application; if so, gss_accept_sec_context
- will return a status flag of GSS_S_CONTINUE_NEEDED, in which case it
- should be called again when the reply token is received from the peer
- application, passing the token to gss_accept_sec_context via the
- input_token parameters.
-
-
-
-
-Wray [Page 21]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- The values returned via the src_name, ret_flags, time_rec, and
- delegated_cred_handle parameters are not defined unless the routine
- returns GSS_S_COMPLETE.
-
- Parameters:
-
- context_handle gss_ctx_id_t, read/modify
- context handle for new context. Supply
- GSS_C_NO_CONTEXT for first call; use value
- returned in subsequent calls.
-
- verifier_cred_handle gss_cred_id_t, read, optional
- Credential handle claimed by context
- acceptor.
- Specify GSS_C_NO_CREDENTIAL to use default
- credentials. If GSS_C_NO_CREDENTIAL is
- specified, but the caller has no default
- credentials established, an
- implementation-defined default credential
- may be used.
-
- input_token_buffer buffer, opaque, read
- token obtained from remote application
-
- input_chan_bindings channel bindings, read
- Application-specified bindings. Allows
- application to securely bind channel
- identification information to the security
- context.
-
- src_name gss_name_t, modify, optional
- Authenticated name of context initiator.
- After use, this name should be deallocated by
- passing it to gss_release_name. If not required,
- specify NULL.
-
- mech_type Object ID, modify
- Security mechanism used. The returned
- OID value will be a pointer into static
- storage, and should be treated as read-only
- by the caller.
-
- output_token buffer, opaque, modify
- Token to be passed to peer application. If the
- length field of the returned token buffer is 0,
- then no token need be passed to the peer
- application.
-
-
-
-
-Wray [Page 22]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- ret_flags bit-mask, modify
- Contains six independent flags, each of
- which indicates that the context supports a
- specific service option. Symbolic names are
- provided for each flag, and the symbolic names
- corresponding to the required flags
- should be logically-ANDed with the ret_flags
- value to test whether a given option is
- supported by the context. The flags are:
- GSS_C_DELEG_FLAG
- True - Delegated credentials are available
- via the delegated_cred_handle
- parameter
- False - No credentials were delegated
- GSS_C_MUTUAL_FLAG
- True - Remote peer asked for mutual
- authentication
- False - Remote peer did not ask for mutual
- authentication
- GSS_C_REPLAY_FLAG
- True - replay of signed or sealed messages
- will be detected
- False - replayed messages will not be
- detected
- GSS_C_SEQUENCE_FLAG
- True - out-of-sequence signed or sealed
- messages will be detected
- False - out-of-sequence messages will not
- be detected
- GSS_C_CONF_FLAG
- True - Confidentiality service may be
- invoked by calling seal routine
- False - No confidentiality service (via
- seal) available. seal will
- provide message encapsulation,
- data-origin authentication and
- integrity services only.
- GSS_C_INTEG_FLAG
- True - Integrity service may be invoked
- by calling either gss_sign or
- gss_seal routines.
- False - Per-message integrity service
- unavailable.
-
- time_rec integer, modify, optional
- number of seconds for which the context
- will remain valid. Specify NULL if not required.
-
-
-
-
-Wray [Page 23]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- delegated_cred_handle
- gss_cred_id_t, modify
- credential handle for credentials received from
- context initiator. Only valid if deleg_flag in
- ret_flags is true.
-
- minor_status integer, modify
- Mechanism specific status code.
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
- application is required to complete the context,
- and that gss_accept_sec_context must be called
- again with that token.
-
- GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks
- performed on the input_token failed.
-
- GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
- performed on the credential failed.
-
- GSS_S_NO_CRED The supplied credentials were not valid for
- context acceptance, or the credential handle
- did not reference any credentials.
-
- GSS_S_CREDENTIALS_EXPIRED The referenced credentials have
- expired.
-
- GSS_S_BAD_BINDINGS The input_token contains different channel
- bindings to those specified via the
- input_chan_bindings parameter.
-
- GSS_S_NO_CONTEXT Indicates that the supplied context handle did
- not refer to a valid context.
-
- GSS_S_BAD_SIG The input_token contains an invalid signature.
-
- GSS_S_OLD_TOKEN The input_token was too old. This is a fatal
- error during context establishment.
-
- GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a
- duplicate of a token already processed. This
- is a fatal error during context establishment.
-
-
-
-Wray [Page 24]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- GSS_S_FAILURE Failure. See minor_status for more information.
-
-3.5. gss_process_context_token
-
- OM_uint32 gss_process_context_token (
- OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- gss_buffer_t token_buffer)
-
- Purpose:
-
- Provides a way to pass a token to the security service. Usually,
- tokens are associated either with context establishment (when they
- would be passed to gss_init_sec_context or gss_accept_sec_context) or
- with per-message security service (when they would be passed to
- gss_verify or gss_unseal). Occasionally, tokens may be received at
- other times, and gss_process_context_token allows such tokens to be
- passed to the underlying security service for processing. At
- present, such additional tokens may only be generated by
- gss_delete_sec_context. GSSAPI implementation may use this service
- to implement deletion of the security context.
-
- Parameters:
-
- context_handle gss_ctx_id_t, read
- context handle of context on which token is to
- be processed
-
- token_buffer buffer, opaque, read
- pointer to first byte of token to process
-
- minor_status integer, modify
- Implementation specific status code.
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks
- performed on the token failed
-
- GSS_S_FAILURE Failure. See minor_status for more information
-
- GSS_S_NO_CONTEXT The context_handle did not refer to a valid
- context
-
-
-
-
-Wray [Page 25]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
-3.6. gss_delete_sec_context
-
- OM_uint32 gss_delete_sec_context (
- OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- gss_buffer_t output_token)
-
- Purpose:
-
- Delete a security context. gss_delete_sec_context will delete the
- local data structures associated with the specified security context,
- and generate an output_token, which when passed to the peer
- gss_process_context_token will instruct it to do likewise. No
- further security services may be obtained using the context specified
- by context_handle.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code.
-
- context_handle gss_ctx_id_t, modify
- context handle identifying context to delete.
-
- output_token buffer, opaque, modify
- token to be sent to remote application to
- instruct it to also delete the context
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_FAILURE Failure, see minor_status for more information
-
- GSS_S_NO_CONTEXT No valid context was supplied
-
-3.7. gss_context_time
-
- OM_uint32 gss_context_time (
- OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- OM_uint32 * time_rec)
- Purpose:
-
- Determines the number of seconds for which the specified context will
- remain valid.
-
-
-
-Wray [Page 26]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- Parameters:
-
- minor_status integer, modify
- Implementation specific status code.
-
- context_handle gss_ctx_id_t, read
- Identifies the context to be interrogated.
-
- time_rec integer, modify
- Number of seconds that the context will remain
- valid. If the context has already expired,
- zero will be returned.
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
- associated credentials have expired
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a
- valid context
-
-3.8. gss_sign
-
- OM_uint32 gss_sign (
- OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- int qop_req,
- gss_buffer_t message_buffer,
- gss_buffer_t msg_token)
- Purpose:
-
- Generates a cryptographic signature for the supplied message, and
- places the signature in a token for transfer to the peer application.
- The qop_req parameter allows a choice between several cryptographic
- algorithms, if supported by the chosen mechanism.
-
- Parameters:
-
- minor_status integer, modify
- Implementation specific status code.
-
- context_handle gss_ctx_id_t, read
- identifies the context on which the message
-
-
-
-Wray [Page 27]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- will be sent
-
- qop_req integer, read, optional
- Specifies requested quality of protection.
- Callers are encouraged, on portability grounds,
- to accept the default quality of protection
- offered by the chosen mechanism, which may be
- requested by specifying GSS_C_QOP_DEFAULT for
- this parameter. If an unsupported protection
- strength is requested, gss_sign will return a
- major_status of GSS_S_FAILURE.
-
- message_buffer buffer, opaque, read
- message to be signed
-
- msg_token buffer, opaque, modify
- buffer to receive token
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
- associated credentials have expired
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a
- valid context
-
- GSS_S_FAILURE Failure. See minor_status for more information.
-
-3.9. gss_verify
-
- OM_uint32 gss_verify (
- OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- gss_buffer_t message_buffer,
- gss_buffer_t token_buffer,
- int * qop_state)
- Purpose:
-
- Verifies that a cryptographic signature, contained in the token
- parameter, fits the supplied message. The qop_state parameter allows
- a message recipient to determine the strength of protection that was
- applied to the message.
-
-
-
-Wray [Page 28]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code.
-
- context_handle gss_ctx_id_t, read
- identifies the context on which the message
- arrived
-
- message_buffer buffer, opaque, read
- message to be verified
-
- token_buffer buffer, opaque, read
- token associated with message
-
- qop_state integer, modify
- quality of protection gained from signature
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
-
- GSS_S_BAD_SIG The signature was incorrect
-
- GSS_S_DUPLICATE_TOKEN The token was valid, and contained a correct
- signature for the message, but it had already
- been processed
-
- GSS_S_OLD_TOKEN The token was valid, and contained a correct
- signature for the message, but it is too old
-
- GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct
- signature for the message, but has been
- verified out of sequence; an earlier token has
- been signed or sealed by the remote
- application, but not yet been processed
- locally.
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
- associated credentials have expired
-
-
-
-
-
-Wray [Page 29]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a
- valid context
-
- GSS_S_FAILURE Failure. See minor_status for more information.
-
-3.10. gss_seal
-
- OM_uint32 gss_seal (
- OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- int conf_req_flag,
- int qop_req
- gss_buffer_t input_message_buffer,
- int * conf_state,
- gss_buffer_t output_message_buffer)
-
- Purpose:
-
- Cryptographically signs and optionally encrypts the specified
- input_message. The output_message contains both the signature and
- the message. The qop_req parameter allows a choice between several
- cryptographic algorithms, if supported by the chosen mechanism.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code.
-
- context_handle gss_ctx_id_t, read
- identifies the context on which the message
- will be sent
-
- conf_req_flag boolean, read
- True - Both confidentiality and integrity
- services are requested
- False - Only integrity service is requested
-
- qop_req integer, read, optional
- Specifies required quality of protection. A
- mechanism-specific default may be requested by
- setting qop_req to GSS_C_QOP_DEFAULT. If an
- unsupported protection strength is requested,
- gss_seal will return a major_status of
- GSS_S_FAILURE.
-
- input_message_buffer buffer, opaque, read
- message to be sealed
-
-
-
-
-Wray [Page 30]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- conf_state boolean, modify
- True - Confidentiality, data origin
- authentication and integrity services
- have been applied
- False - Integrity and data origin services only
- has been applied.
-
- output_message_buffer buffer, opaque, modify
- buffer to receive sealed message
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
- associated credentials have expired
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a
- valid context
-
- GSS_S_FAILURE Failure. See minor_status for more information.
-
-3.11. gss_unseal
-
- OM_uint32 gss_unseal (
- OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- gss_buffer_t input_message_buffer,
- gss_buffer_t output_message_buffer,
- int * conf_state,
- int * qop_state)
-
- Purpose:
-
- Converts a previously sealed message back to a usable form, verifying
- the embedded signature. The conf_state parameter indicates whether
- the message was encrypted; the qop_state parameter indicates the
- strength of protection that was used to provide the confidentiality
- and integrity services.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code.
-
-
-
-Wray [Page 31]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- context_handle gss_ctx_id_t, read
- identifies the context on which the message
- arrived
-
- input_message_buffer buffer, opaque, read
- sealed message
-
- output_message_buffer buffer, opaque, modify
- buffer to receive unsealed message
-
- conf_state boolean, modify
- True - Confidentiality and integrity protection
- were used
- False - Inteegrity service only was used
-
- qop_state integer, modify
- quality of protection gained from signature
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
-
- GSS_S_BAD_SIG The signature was incorrect
-
- GSS_S_DUPLICATE_TOKEN The token was valid, and contained a
- correct signature for the message, but it had
- already been processed
-
- GSS_S_OLD_TOKEN The token was valid, and contained a correct
- signature for the message, but it is too old
-
- GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct
- signature for the message, but has been
- verified out of sequence; an earlier token has
- been signed or sealed by the remote
- application, but not yet been processed
- locally.
-
- GSS_S_CONTEXT_EXPIRED The context has already expired
-
- GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
- associated credentials have expired
-
-
-
-
-
-Wray [Page 32]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- GSS_S_NO_CONTEXT The context_handle parameter did not identify a
- valid context
-
- GSS_S_FAILURE Failure. See minor_status for more information.
-
-3.12. gss_display_status
-
- OM_uint32 gss_display_status (
- OM_uint32 * minor_status,
- int status_value,
- int status_type,
- gss_OID mech_type,
- int * message_context,
- gss_buffer_t status_string)
-
- Purpose:
-
- Allows an application to obtain a textual representation of a GSSAPI
- status code, for display to the user or for logging purposes. Since
- some status values may indicate multiple errors, applications may
- need to call gss_display_status multiple times, each call generating
- a single text string. The message_context parameter is used to
- indicate which error message should be extracted from a given
- status_value; message_context should be initialized to 0, and
- gss_display_status will return a non-zero value if there are further
- messages to extract.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code.
-
- status_value integer, read
- Status value to be converted
-
- status_type integer, read
- GSS_C_GSS_CODE - status_value is a GSS status
- code
- GSS_C_MECH_CODE - status_value is a mechanism
- status code
-
- mech_type Object ID, read, optional
- Underlying mechanism (used to interpret a
- minor status value) Supply GSS_C_NULL_OID to
- obtain the system default.
-
- message_context integer, read/modify
- Should be initialized to zero by caller
-
-
-
-Wray [Page 33]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- on first call. If further messages are
- contained in the status_value parameter,
- message_context will be non-zero on return,
- and this value should be passed back to
- subsequent calls, along with the same
- status_value, status_type and mech_type
- parameters.
-
- status_string buffer, character string, modify
- textual interpretation of the status_value
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_MECH Indicates that translation in accordance with
- an unsupported mechanism type was requested
-
- GSS_S_BAD_STATUS The status value was not recognized, or the
- status type was neither GSS_C_GSS_CODE nor
- GSS_C_MECH_CODE.
-
-
-3.13. gss_indicate_mechs
-
- OM_uint32 gss_indicate_mechs (
- OM_uint32 * minor_status,
- gss_OID_set * mech_set)
-
- Purpose:
-
- Allows an application to determine which underlying security
- mechanisms are available.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code.
-
- mech_set set of Object IDs, modify
- set of implementation-supported mechanisms.
- The returned gss_OID_set value will be a
- pointer into static storage, and should be
- treated as read-only by the caller.
-
-
-
-
-
-Wray [Page 34]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
-3.14. gss_compare_name
-
- OM_uint32 gss_compare_name (
- OM_uint32 * minor_status,
- gss_name_t name1,
- gss_name_t name2,
- int * name_equal)
-
- Purpose:
-
- Allows an application to compare two internal-form names to determine
- whether they refer to the same entity.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code.
-
- name1 gss_name_t, read
- internal-form name
-
- name2 gss_name_t, read
- internal-form name
-
- name_equal boolean, modify
- True - names refer to same entity
- False - names refer to different entities
- (strictly, the names are not known to
- refer to the same identity).
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAMETYPE The type contained within either name1 or
- name2 was unrecognized, or the names were of
- incomparable types.
-
- GSS_S_BAD_NAME One or both of name1 or name2 was ill-formed
-
-
-
-
-
-Wray [Page 35]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
-3.15. gss_display_name
-
- OM_uint32 gss_display_name (
- OM_uint32 * minor_status,
- gss_name_t input_name,
- gss_buffer_t output_name_buffer,
- gss_OID * output_name_type)
-
- Purpose:
-
- Allows an application to obtain a textual representation of an opaque
- internal-form name for display purposes. The syntax of a printable
- name is defined by the GSSAPI implementation.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code.
-
- input_name gss_name_t, read
- name to be displayed
-
- output_name_buffer buffer, character-string, modify
- buffer to receive textual name string
-
- output_name_type Object ID, modify
- The type of the returned name. The returned
- gss_OID will be a pointer into static storage,
- and should be treated as read-only by the caller
-
- Function value:
-
- GSS status code:
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAMETYPE The type of input_name was not recognized
-
- GSS_S_BAD_NAME input_name was ill-formed
-
-3.16. gss_import_name
-
- OM_uint32 gss_import_name (
- OM_uint32 * minor_status,
- gss_buffer_t input_name_buffer,
- gss_OID input_name_type,
- gss_name_t * output_name)
-
-
-
-
-Wray [Page 36]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- Purpose:
-
- Convert a printable name to internal form.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code
-
- input_name_buffer buffer, character-string, read
- buffer containing printable name to convert
-
- input_name_type Object ID, read, optional
- Object Id specifying type of printable
- name. Applications may specify either
- GSS_C_NULL_OID to use a local system-specific
- printable syntax, or an OID registered by the
- GSSAPI implementation to name a particular
- namespace.
-
- output_name gss_name_t, modify
- returned name in internal form
-
- Function value:
-
- GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAMETYPE The input_name_type was unrecognized
-
- GSS_S_BAD_NAME The input_name parameter could not be
- interpreted as a name of the specified type
-
-3.17. gss_release_name
-
- OM_uint32 gss_release_name (
- OM_uint32 * minor_status,
- gss_name_t * name)
-
- Purpose:
-
- Free GSSAPI-allocated storage associated with an internal form name.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code
-
-
-
-Wray [Page 37]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- name gss_name_t, modify
- The name to be deleted
-
- Function value:
-
- GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_BAD_NAME The name parameter did not contain a valid name
-
-3.18. gss_release_buffer
-
- OM_uint32 gss_release_buffer (
- OM_uint32 * minor_status,
- gss_buffer_t buffer)
-
- Purpose:
-
- Free storage associated with a buffer format name. The storage must
- have been allocated by a GSSAPI routine. In addition to freeing the
- associated storage, the routine will zero the length field in the
- buffer parameter.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code
-
- buffer buffer, modify
- The storage associated with the buffer will be
- deleted. The gss_buffer_desc object will not
- be freed, but its length field will be zeroed.
-
- Function value:
-
- GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-3.19. gss_release_oid_set
-
- OM_uint32 gss_release_oid_set (
- OM_uint32 * minor_status,
- gss_OID_set * set)
-
- Purpose:
-
-
-
-
-Wray [Page 38]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- Free storage associated with a gss_OID_set object. The storage must
- have been allocated by a GSSAPI routine.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code
-
- set Set of Object IDs, modify
- The storage associated with the gss_OID_set
- will be deleted.
-
- Function value:
-
- GSS status code
-
- GSS_S_COMPLETE Successful completion
-
-3.20. gss_inquire_cred
-
- OM_uint32 gss_inquire_cred (
- OM_uint32 * minor_status,
- gss_cred_id_t cred_handle,
- gss_name_t * name,
- OM_uint32 * lifetime,
- int * cred_usage,
- gss_OID_set * mechanisms )
-
- Purpose:
-
- Obtains information about a credential. The caller must already have
- obtained a handle that refers to the credential.
-
- Parameters:
-
- minor_status integer, modify
- Mechanism specific status code
-
- cred_handle gss_cred_id_t, read
- A handle that refers to the target credential.
- Specify GSS_C_NO_CREDENTIAL to inquire about
- the default credential.
-
- name gss_name_t, modify
- The name whose identity the credential asserts.
- Specify NULL if not required.
-
- lifetime Integer, modify
-
-
-
-Wray [Page 39]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- The number of seconds for which the credential
- will remain valid. If the credential has
- expired, this parameter will be set to zero.
- If the implementation does not support
- credential expiration, the value
- GSS_C_INDEFINITE will be returned. Specify
- NULL if not required.
-
- cred_usage Integer, modify
- How the credential may be used. One of the
- following:
- GSS_C_INITIATE
- GSS_C_ACCEPT
- GSS_C_BOTH
- Specify NULL if not required.
-
- mechanisms gss_OID_set, modify
- Set of mechanisms supported by the credential.
- Specify NULL if not required.
-
- Function value:
-
- GSS status code
-
- GSS_S_COMPLETE Successful completion
-
- GSS_S_NO_CRED The referenced credentials could not be
- accessed.
-
- GSS_S_DEFECTIVE_CREDENTIAL The referenced credentials were
- invalid.
-
- GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
- If the lifetime parameter was not passed as
- NULL, it will be set to 0.
-
-
- #ifndef GSSAPI_H_
- #define GSSAPI_H_
-
- /*
- * First, define the platform-dependent types.
- */
- typedef <platform-specific> OM_uint32;
- typedef <platform-specific> gss_ctx_id_t;
- typedef <platform-specific> gss_cred_id_t;
- typedef <platform-specific> gss_name_t;
-
-
-
-
-Wray [Page 40]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- /*
- * Note that a platform supporting the xom.h X/Open header file
- * may make use of that header for the definitions of OM_uint32
- * and the structure to which gss_OID_desc equates.
- */
-
- typedef struct gss_OID_desc_struct {
- OM_uint32 length;
- void *elements;
- } gss_OID_desc, *gss_OID;
-
- typedef struct gss_OID_set_desc_struct {
- int count;
- gss_OID elements;
- } gss_OID_set_desc, *gss_OID_set;
-
- typedef struct gss_buffer_desc_struct {
- size_t length;
- void *value;
- } gss_buffer_desc, *gss_buffer_t;
-
- typedef struct gss_channel_bindings_struct {
- OM_uint32 initiator_addrtype;
- gss_buffer_desc initiator_address;
- OM_uint32 acceptor_addrtype;
- gss_buffer_desc acceptor_address;
- gss_buffer_desc application_data;
- } *gss_channel_bindings_t;
-
-
- /*
- * Six independent flags each of which indicates that a context
- * supports a specific service option.
- */
- #define GSS_C_DELEG_FLAG 1
- #define GSS_C_MUTUAL_FLAG 2
- #define GSS_C_REPLAY_FLAG 4
- #define GSS_C_SEQUENCE_FLAG 8
- #define GSS_C_CONF_FLAG 16
- #define GSS_C_INTEG_FLAG 32
-
-
- /*
- * Credential usage options
- */
- #define GSS_C_BOTH 0
- #define GSS_C_INITIATE 1
- #define GSS_C_ACCEPT 2
-
-
-
-Wray [Page 41]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- /*
- * Status code types for gss_display_status
- */
- #define GSS_C_GSS_CODE 1
- #define GSS_C_MECH_CODE 2
-
- /*
- * The constant definitions for channel-bindings address families
- */
- #define GSS_C_AF_UNSPEC 0;
- #define GSS_C_AF_LOCAL 1;
- #define GSS_C_AF_INET 2;
- #define GSS_C_AF_IMPLINK 3;
- #define GSS_C_AF_PUP 4;
- #define GSS_C_AF_CHAOS 5;
- #define GSS_C_AF_NS 6;
- #define GSS_C_AF_NBS 7;
- #define GSS_C_AF_ECMA 8;
- #define GSS_C_AF_DATAKIT 9;
- #define GSS_C_AF_CCITT 10;
- #define GSS_C_AF_SNA 11;
- #define GSS_C_AF_DECnet 12;
- #define GSS_C_AF_DLI 13;
- #define GSS_C_AF_LAT 14;
- #define GSS_C_AF_HYLINK 15;
- #define GSS_C_AF_APPLETALK 16;
- #define GSS_C_AF_BSC 17;
- #define GSS_C_AF_DSS 18;
- #define GSS_C_AF_OSI 19;
- #define GSS_C_AF_X25 21;
-
- #define GSS_C_AF_NULLADDR 255;
-
- #define GSS_C_NO_BUFFER ((gss_buffer_t) 0)
- #define GSS_C_NULL_OID ((gss_OID) 0)
- #define GSS_C_NULL_OID_SET ((gss_OID_set) 0)
- #define GSS_C_NO_CONTEXT ((gss_ctx_id_t) 0)
- #define GSS_C_NO_CREDENTIAL ((gss_cred_id_t) 0)
- #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
- #define GSS_C_EMPTY_BUFFER {0, NULL}
-
- /*
- * Define the default Quality of Protection for per-message
- * services. Note that an implementation that offers multiple
- * levels of QOP may either reserve a value (for example zero,
- * as assumed here) to mean "default protection", or alternatively
- * may simply equate GSS_C_QOP_DEFAULT to a specific explicit QOP
- * value.
-
-
-
-Wray [Page 42]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- */
- #define GSS_C_QOP_DEFAULT 0
-
- /*
- * Expiration time of 2^32-1 seconds means infinite lifetime for a
- * credential or security context
- */
- #define GSS_C_INDEFINITE 0xfffffffful
-
-
- /* Major status codes */
-
- #define GSS_S_COMPLETE 0
-
- /*
- * Some "helper" definitions to make the status code macros obvious.
- */
- #define GSS_C_CALLING_ERROR_OFFSET 24
- #define GSS_C_ROUTINE_ERROR_OFFSET 16
- #define GSS_C_SUPPLEMENTARY_OFFSET 0
- #define GSS_C_CALLING_ERROR_MASK 0377ul
- #define GSS_C_ROUTINE_ERROR_MASK 0377ul
- #define GSS_C_SUPPLEMENTARY_MASK 0177777ul
-
- /*
- * The macros that test status codes for error conditions
- */
- #define GSS_CALLING_ERROR(x) \
- (x & (GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET))
- #define GSS_ROUTINE_ERROR(x) \
- (x & (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET))
- #define GSS_SUPPLEMENTARY_INFO(x) \
- (x & (GSS_C_SUPPLEMENTARY_MASK << GSS_C_SUPPLEMENTARY_OFFSET))
- #define GSS_ERROR(x) \
- ((GSS_CALLING_ERROR(x) != 0) || (GSS_ROUTINE_ERROR(x) != 0))
-
-
- /*
- * Now the actual status code definitions
- */
-
- /*
- * Calling errors:
- */
- #define GSS_S_CALL_INACCESSIBLE_READ \
- (1ul << GSS_C_CALLING_ERROR_OFFSET)
- #define GSS_S_CALL_INACCESSIBLE_WRITE \
- (2ul << GSS_C_CALLING_ERROR_OFFSET)
-
-
-
-Wray [Page 43]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- #define GSS_S_CALL_BAD_STRUCTURE \
- (3ul << GSS_C_CALLING_ERROR_OFFSET)
-
- /*
- * Routine errors:
- */
- #define GSS_S_BAD_MECH (1ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_NAME (2ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_NAMETYPE (3ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_BINDINGS (4ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_STATUS (5ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_BAD_SIG (6ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_NO_CRED (7ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_NO_CONTEXT (8ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_DEFECTIVE_CREDENTIAL (10ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_CREDENTIALS_EXPIRED (11ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_CONTEXT_EXPIRED (12ul << GSS_C_ROUTINE_ERROR_OFFSET)
- #define GSS_S_FAILURE (13ul << GSS_C_ROUTINE_ERROR_OFFSET)
-
- /*
- * Supplementary info bits:
- */
- #define GSS_S_CONTINUE_NEEDED (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 0))
- #define GSS_S_DUPLICATE_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 1))
- #define GSS_S_OLD_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 2))
- #define GSS_S_UNSEQ_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 3))
-
-
- /*
- * Finally, function prototypes for the GSSAPI routines.
- */
-
- OM_uint32 gss_acquire_cred
- (OM_uint32*, /* minor_status */
- gss_name_t, /* desired_name */
- OM_uint32, /* time_req */
- gss_OID_set, /* desired_mechs */
- int, /* cred_usage */
- gss_cred_id_t*, /* output_cred_handle */
- gss_OID_set*, /* actual_mechs */
- OM_uint32* /* time_rec */
- );
-
- OM_uint32 gss_release_cred,
- (OM_uint32*, /* minor_status */
- gss_cred_id_t* /* cred_handle */
- );
-
-
-
-Wray [Page 44]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- OM_uint32 gss_init_sec_context
- (OM_uint32*, /* minor_status */
- gss_cred_id_t, /* claimant_cred_handle */
- gss_ctx_id_t*, /* context_handle */
- gss_name_t, /* target_name */
- gss_OID, /* mech_type */
- int, /* req_flags */
- OM_uint32, /* time_req */
- gss_channel_bindings_t,
- /* input_chan_bindings */
- gss_buffer_t, /* input_token */
- gss_OID*, /* actual_mech_type */
- gss_buffer_t, /* output_token */
- int*, /* ret_flags */
- OM_uint32* /* time_rec */
- );
-
- OM_uint32 gss_accept_sec_context
- (OM_uint32*, /* minor_status */
- gss_ctx_id_t*, /* context_handle */
- gss_cred_id_t, /* verifier_cred_handle */
- gss_buffer_t, /* input_token_buffer */
- gss_channel_bindings_t,
- /* input_chan_bindings */
- gss_name_t*, /* src_name */
- gss_OID*, /* mech_type */
- gss_buffer_t, /* output_token */
- int*, /* ret_flags */
- OM_uint32*, /* time_rec */
- gss_cred_id_t* /* delegated_cred_handle */
- );
-
- OM_uint32 gss_process_context_token
- (OM_uint32*, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- gss_buffer_t /* token_buffer */
- );
-
- OM_uint32 gss_delete_sec_context
- (OM_uint32*, /* minor_status */
- gss_ctx_id_t*, /* context_handle */
- gss_buffer_t /* output_token */
- );
-
-
-
-
-
-
-
-
-Wray [Page 45]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- OM_uint32 gss_context_time
- (OM_uint32*, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- OM_uint32* /* time_rec */
- );
-
- OM_uint32 gss_sign
- (OM_uint32*, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- int, /* qop_req */
- gss_buffer_t, /* message_buffer */
- gss_buffer_t /* message_token */
- );
-
- OM_uitn32 gss_verify
- (OM_uint32*, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- gss_buffer_t, /* message_buffer */
- gss_buffer_t, /* token_buffer */
- int* /* qop_state */
- );
-
- OM_uint32 gss_seal
- (OM_uint32*, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- int, /* conf_req_flag */
- int, /* qop_req */
- gss_buffer_t, /* input_message_buffer */
- int*, /* conf_state */
- gss_buffer_t /* output_message_buffer */
- );
-
- OM_uint32 gss_unseal
- (OM_uint32*, /* minor_status */
- gss_ctx_id_t, /* context_handle */
- gss_buffer_t, /* input_message_buffer */
- gss_buffer_t, /* output_message_buffer */
- int*, /* conf_state */
- int* /* qop_state */
- );
-
-
-
-
-
-
-
-
-
-
-
-Wray [Page 46]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- OM_uint32 gss_display_status
- (OM_uint32*, /* minor_status */
- OM_uint32, /* status_value */
- int, /* status_type */
- gss_OID, /* mech_type */
- int*, /* message_context */
- gss_buffer_t /* status_string */
- );
-
- OM_uint32 gss_indicate_mechs
- (OM_uint32*, /* minor_status */
- gss_OID_set* /* mech_set */
- );
-
- OM_uint32 gss_compare_name
- (OM_uint32*, /* minor_status */
- gss_name_t, /* name1 */
- gss_name_t, /* name2 */
- int* /* name_equal */
- );
-
- OM_uint32 gss_display_name,
- (OM_uint32*, /* minor_status */
- gss_name_t, /* input_name */
- gss_buffer_t, /* output_name_buffer */
- gss_OID* /* output_name_type */
- );
-
- OM_uint32 gss_import_name
- (OM_uint32*, /* minor_status */
- gss_buffer_t, /* input_name_buffer */
- gss_OID, /* input_name_type */
- gss_name_t* /* output_name */
- );
-
- OM_uint32 gss_release_name
- (OM_uint32*, /* minor_status */
- gss_name_t* /* input_name */
- );
-
- OM_uint32 gss_release_buffer
- (OM_uint32*, /* minor_status */
- gss_buffer_t /* buffer */
- );
-
- OM_uint32 gss_release_oid_set
- (OM_uint32*, /* minor_status */
- gss_OID_set* /* set */
-
-
-
-Wray [Page 47]
-
-RFC 1509 GSSAPI - Overview and C bindings September 1993
-
-
- );
-
- OM_uint32 gss_inquire_cred
- (OM_uint32 *, /* minor_status */
- gss_cred_id_t, /* cred_handle */
- gss_name_t *, /* name */
- OM_uint32 *, /* lifetime */
- int *, /* cred_usage */
- gss_OID_set * /* mechanisms */
- );
-
-
-
- #endif /* GSSAPI_H_ */
-
-References
-
- [1] Linn, J., "Generic Security Service Application Program
- Interface", RFC 1508, Geer Zolot Associate, September 1993.
-
- [2] "OSI Object Management API Specification, Version 2.0 t", X.400
- API Association & X/Open Company Limited, August 24, 1990.
- Specification of datatypes and routines for manipulating
- information objects.
-
-Security Considerations
-
- Security issues are discussed throughout this memo.
-
-Author's Address
-
- John Wray
- Digital Equipment Corporation
- 550 King Street, LKG2-2/AA6
- Littleton, MA 01460
- USA
-
- Phone: +1-508-486-5210
- EMail: Wray@tuxedo.enet.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-Wray [Page 48]
-
\ No newline at end of file
diff --git a/doc/standardisation/rfc1510.txt b/doc/standardisation/rfc1510.txt
deleted file mode 100644
index bc810cc506fab750607044c38bbed6a178f02078..0000000000000000000000000000000000000000
--- a/doc/standardisation/rfc1510.txt
+++ /dev/null
@@ -1,6275 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Kohl
-Request for Comments: 1510 Digital Equipment Corporation
- C. Neuman
- ISI
- September 1993
-
-
- The Kerberos Network Authentication Service (V5)
-
-Status of this Memo
-
- This RFC specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" for the standardization state and status
- of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This document gives an overview and specification of Version 5 of the
- protocol for the Kerberos network authentication system. Version 4,
- described elsewhere [1,2], is presently in production use at MIT's
- Project Athena, and at other Internet sites.
-
-Overview
-
- Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos,
- Moira, and Zephyr are trademarks of the Massachusetts Institute of
- Technology (MIT). No commercial use of these trademarks may be made
- without prior written permission of MIT.
-
- This RFC 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; for Version 4 they are fully
- described in the Kerberos portion of the Athena Technical Plan [1].
- The protocols are under review, and are not being submitted for
- consideration as an Internet standard at this time. Comments are
- encouraged. 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.
-
-
-
-
-
-Kohl & Neuman [Page 1]
-
-RFC 1510 Kerberos September 1993
-
-
-Background
-
- The Kerberos model is based in part on Needham and Schroeder's
- trusted third-party authentication protocol [3] and on modifications
- suggested by Denning and Sacco [4]. 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 4 is publicly available, and has seen wide use across the
- Internet.
-
- Version 5 (described in this document) has evolved from Version 4
- based on new requirements and desires for features not available in
- Version 4. Details on the differences between Kerberos Versions 4
- and 5 can be found in [5].
-
-Table of Contents
-
- 1. Introduction ....................................... 5
- 1.1. Cross-Realm Operation ............................ 7
- 1.2. Environmental assumptions ........................ 8
- 1.3. Glossary of terms ................................ 9
- 2. Ticket flag uses and requests ...................... 12
- 2.1. Initial and pre-authenticated tickets ............ 12
- 2.2. Invalid tickets .................................. 12
- 2.3. Renewable tickets ................................ 12
- 2.4. Postdated tickets ................................ 13
- 2.5. Proxiable and proxy tickets ...................... 14
- 2.6. Forwardable tickets .............................. 15
- 2.7. Other KDC options ................................ 15
- 3. Message Exchanges .................................. 16
- 3.1. The Authentication Service Exchange .............. 16
- 3.1.1. Generation of KRB_AS_REQ message ............... 17
- 3.1.2. Receipt of KRB_AS_REQ message .................. 17
- 3.1.3. Generation of KRB_AS_REP message ............... 17
- 3.1.4. Generation of KRB_ERROR message ................ 19
- 3.1.5. Receipt of KRB_AS_REP message .................. 19
- 3.1.6. Receipt of KRB_ERROR message ................... 20
- 3.2. The Client/Server Authentication Exchange ........ 20
- 3.2.1. The KRB_AP_REQ message ......................... 20
- 3.2.2. Generation of a KRB_AP_REQ message ............. 20
- 3.2.3. Receipt of KRB_AP_REQ message .................. 21
- 3.2.4. Generation of a KRB_AP_REP message ............. 23
- 3.2.5. Receipt of KRB_AP_REP message .................. 23
-
-
-
-Kohl & Neuman [Page 2]
-
-RFC 1510 Kerberos September 1993
-
-
- 3.2.6. Using the encryption key ....................... 24
- 3.3. The Ticket-Granting Service (TGS) Exchange ....... 24
- 3.3.1. Generation of KRB_TGS_REQ message .............. 25
- 3.3.2. Receipt of KRB_TGS_REQ message ................. 26
- 3.3.3. Generation of KRB_TGS_REP message .............. 27
- 3.3.3.1. Encoding the transited field ................. 29
- 3.3.4. Receipt of KRB_TGS_REP message ................. 31
- 3.4. The KRB_SAFE Exchange ............................ 31
- 3.4.1. Generation of a KRB_SAFE message ............... 31
- 3.4.2. Receipt of KRB_SAFE message .................... 32
- 3.5. The KRB_PRIV Exchange ............................ 33
- 3.5.1. Generation of a KRB_PRIV message ............... 33
- 3.5.2. Receipt of KRB_PRIV message .................... 33
- 3.6. The KRB_CRED Exchange ............................ 34
- 3.6.1. Generation of a KRB_CRED message ............... 34
- 3.6.2. Receipt of KRB_CRED message .................... 34
- 4. The Kerberos Database .............................. 35
- 4.1. Database contents ................................ 35
- 4.2. Additional fields ................................ 36
- 4.3. Frequently Changing Fields ....................... 37
- 4.4. Site Constants ................................... 37
- 5. Message Specifications ............................. 38
- 5.1. ASN.1 Distinguished Encoding Representation ...... 38
- 5.2. ASN.1 Base Definitions ........................... 38
- 5.3. Tickets and Authenticators ....................... 42
- 5.3.1. Tickets ........................................ 42
- 5.3.2. Authenticators ................................. 47
- 5.4. Specifications for the AS and TGS exchanges ...... 49
- 5.4.1. KRB_KDC_REQ definition ......................... 49
- 5.4.2. KRB_KDC_REP definition ......................... 56
- 5.5. Client/Server (CS) message specifications ........ 58
- 5.5.1. KRB_AP_REQ definition .......................... 58
- 5.5.2. KRB_AP_REP definition .......................... 60
- 5.5.3. Error message reply ............................ 61
- 5.6. KRB_SAFE message specification ................... 61
- 5.6.1. KRB_SAFE definition ............................ 61
- 5.7. KRB_PRIV message specification ................... 62
- 5.7.1. KRB_PRIV definition ............................ 62
- 5.8. KRB_CRED message specification ................... 63
- 5.8.1. KRB_CRED definition ............................ 63
- 5.9. Error message specification ...................... 65
- 5.9.1. KRB_ERROR definition ........................... 66
- 6. Encryption and Checksum Specifications ............. 67
- 6.1. Encryption Specifications ........................ 68
- 6.2. Encryption Keys .................................. 71
- 6.3. Encryption Systems ............................... 71
- 6.3.1. The NULL Encryption System (null) .............. 71
- 6.3.2. DES in CBC mode with a CRC-32 checksum (descbc-crc)71
-
-
-
-Kohl & Neuman [Page 3]
-
-RFC 1510 Kerberos September 1993
-
-
- 6.3.3. DES in CBC mode with an MD4 checksum (descbc-md4) 72
- 6.3.4. DES in CBC mode with an MD5 checksum (descbc-md5) 72
- 6.4. Checksums ........................................ 74
- 6.4.1. The CRC-32 Checksum (crc32) .................... 74
- 6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 75
- 6.4.3. RSA MD4 Cryptographic Checksum Using DES
- (rsa-md4-des) ......................................... 75
- 6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 76
- 6.4.5. RSA MD5 Cryptographic Checksum Using DES
- (rsa-md5-des) ......................................... 76
- 6.4.6. DES cipher-block chained checksum (des-mac)
- 6.4.7. RSA MD4 Cryptographic Checksum Using DES
- alternative (rsa-md4-des-k) ........................... 77
- 6.4.8. DES cipher-block chained checksum alternative
- (des-mac-k) ........................................... 77
- 7. Naming Constraints ................................. 78
- 7.1. Realm Names ...................................... 77
- 7.2. Principal Names .................................. 79
- 7.2.1. Name of server principals ...................... 80
- 8. Constants and other defined values ................. 80
- 8.1. Host address types ............................... 80
- 8.2. KDC messages ..................................... 81
- 8.2.1. IP transport ................................... 81
- 8.2.2. OSI transport .................................. 82
- 8.2.3. Name of the TGS ................................ 82
- 8.3. Protocol constants and associated values ......... 82
- 9. Interoperability requirements ...................... 86
- 9.1. Specification 1 .................................. 86
- 9.2. Recommended KDC values ........................... 88
- 10. Acknowledgments ................................... 88
- 11. References ........................................ 89
- 12. Security Considerations ........................... 90
- 13. Authors' Addresses ................................ 90
- A. Pseudo-code for protocol processing ................ 91
- A.1. KRB_AS_REQ generation ............................ 91
- A.2. KRB_AS_REQ verification and KRB_AS_REP generation 92
- A.3. KRB_AS_REP verification .......................... 95
- A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 96
- A.5. KRB_TGS_REQ generation ........................... 97
- A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 98
- A.7. KRB_TGS_REP verification ......................... 104
- A.8. Authenticator generation ......................... 104
- A.9. KRB_AP_REQ generation ............................ 105
- A.10. KRB_AP_REQ verification ......................... 105
- A.11. KRB_AP_REP generation ........................... 106
- A.12. KRB_AP_REP verification ......................... 107
- A.13. KRB_SAFE generation ............................. 107
- A.14. KRB_SAFE verification ........................... 108
-
-
-
-Kohl & Neuman [Page 4]
-
-RFC 1510 Kerberos September 1993
-
-
- A.15. KRB_SAFE and KRB_PRIV common checks ............. 108
- A.16. KRB_PRIV generation ............................. 109
- A.17. KRB_PRIV verification ........................... 110
- A.18. KRB_CRED generation ............................. 110
- A.19. KRB_CRED verification ........................... 111
- A.20. KRB_ERROR generation ............................ 112
-
-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
- authentication 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. (Note,
- however, that many applications use Kerberos' functions only upon the
- initiation of a stream-based network connection, and assume the
- absence of any "hijackers" who might subvert such a connection. Such
- use implicitly trusts the host addresses involved.) Kerberos
- performs authentication under these conditions as a trusted third-
- party authentication service by using conventional cryptography,
- i.e., shared secret key. (shared secret key - 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.)
-
- The 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.
-
- The implementation 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
-
-
-
-Kohl & Neuman [Page 5]
-
-RFC 1510 Kerberos September 1993
-
-
- transactions, a typical network application adds one or two calls to
- the Kerberos library, which results in the transmission of the
- necessary messages to achieve authentication.
-
- The Kerberos protocol consists of several sub-protocols (or
- exchanges). There are two 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 sends the TGT to
- the TGS in the same manner as if it were contacting any other
- application server which requires Kerberos credentials. The reply is
- encrypted in the session key from the TGT.
-
- 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 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
- was originated by 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 integrity of the
- messages exchanged between principals can be secured by encrypting
- the data to be passed using the session key passed in the ticket, and
- contained in the credentials.
-
- The authentication exchanges mentioned above require read-only access
- to the Kerberos database. Sometimes, however, the entries in the
-
-
-
-Kohl & Neuman [Page 6]
-
-RFC 1510 Kerberos September 1993
-
-
- 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). The administration protocol is not described in this
- document. There is also a protocol for maintaining multiple copies of
- the Kerberos database, but this can be considered an implementation
- detail and may vary to support different database technologies.
-
-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 use its
- authentication remotely (Of course, with appropriate permission the
- client could arrange registration of a separately-named principal 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). 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 some database in order to construct an
-
-
-
-Kohl & Neuman [Page 7]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
-1.2. 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 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 not-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 per-server basis. 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
-
-
-
-Kohl & Neuman [Page 8]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.3. 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.
-
-
-
-
-
-
-Kohl & Neuman [Page 9]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
-
- Principal A uniquely named client or server
- instance that participates in a network
- communication.
-
-
-
-
-Kohl & Neuman [Page 10]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
-
- 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.
-
-
-
-Kohl & Neuman [Page 11]
-
-RFC 1510 Kerberos September 1993
-
-
-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 knowledge of a client's
- secret key (e.g., a passwordchanging 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).
-
-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 shortlived 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
-
-
-
-Kohl & Neuman [Page 12]
-
-RFC 1510 Kerberos September 1993
-
-
- 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-
-
-
-
-Kohl & Neuman [Page 13]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 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 by
- default.
-
- 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 (It is permissible to request or
- issue tickets with no network addresses specified, but we do not
- recommend it). For this reason, a client wishing to grant a proxy
- must request a new ticket valid for the network address of the
- service to be granted the proxy.
-
- The PROXY flag is set in a ticket by the TGS when it issues a
- proxy ticket. Application servers may check this flag and require
- additional authentication from the agent presenting the proxy in
- order to provide an audit trail.
-
-
-
-
-
-Kohl & Neuman [Page 14]
-
-RFC 1510 Kerberos September 1993
-
-
-2.6. Forwardable tickets
-
- Authentication forwarding is an instance of the proxy case 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 end result
- can still be achieved if the user engages in the AS exchange with 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 it be set 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 wish 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 to-be-issued ticket for the end
- server is to be encrypted in the session key from the additional
- ticket-granting ticket provided with the request. See section 3.3.3
- for specific details.
-
-
-
-
-
-Kohl & Neuman [Page 15]
-
-RFC 1510 Kerberos September 1993
-
-
-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 usually initiated by a client when
- it wishes to obtain authentication credentials for a given server but
- currently holds no credentials. 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. (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 session and
- change another user's password.) This exchange does not by itself
- provide any assurance of the the identity of the user. (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 the local server through successful completion of the
- Client/Server exchange.)
-
- 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
-
-
-
-Kohl & Neuman [Page 16]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 also 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 or fabrications of such messages.
-
- In the normal case 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 if desired, but the
- mechanism is not currently specified.
-
-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 preauthentication 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 nonrenewable 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 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
-
-
-
-Kohl & Neuman [Page 17]
-
-RFC 1510 Kerberos September 1993
-
-
- KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random"
- session key ("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 would be
- more desirable to use a truly random number generator, such as one
- based on measurements of random physical phenomena.).
-
- If the requested start time is absent or indicates a time in the
- past, then the start time of the ticket is set to the authentication
- server's current time. If it indicates a time in the future, 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:
-
-
-
-Kohl & Neuman [Page 18]
-
-RFC 1510 Kerberos September 1993
-
-
- +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 postdated (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, 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
-
-
-
-Kohl & Neuman [Page 19]
-
-RFC 1510 Kerberos September 1993
-
-
- 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. 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.
-
-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(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.), 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 it. 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
-
-
-
-Kohl & Neuman [Page 20]
-
-RFC 1510 Kerberos September 1993
-
-
- TGS exchange) a ticket and session key for the desired service. The
- client may re-use any tickets it holds until they expire. The client
- then 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 (Note that this can make
- applications based on unreliable transports difficult to code
- correctly, if the transport might deliver duplicated messages. In
- such cases, a new authenticator must be generated for each retry.).
- 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 (This is
- used for user-to-user authentication as described in [6]). 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
-
-
-
-Kohl & Neuman [Page 21]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 (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.). 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.
-
-
-
-
-Kohl & Neuman [Page 22]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
-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). [Note: 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.] 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 (Note that for
- encrypting the KRB_AP_REP message, the sub-session key is not used,
- even if present in the Authenticator.) 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
-
-
-
-Kohl & Neuman [Page 23]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
- (Implementations of the protocol may wish to provide routines to
- choose subkeys based on session keys and random numbers and to
- orchestrate a negotiated key to be returned in the KRB_AP_REP
- message.). 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 a 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.
-
- 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 or KRB_ERROR responses
- 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
-
-
-
-Kohl & Neuman [Page 24]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 subsession 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
- [Note: This can be accomplished in several ways. It might be known
- beforehand (since the realm is part of the principal identifier), or
- it might be stored in a nameserver. Presently, however, this
- information is obtained from a configuration 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
- authenticated. 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.]. 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 the local Kerberos server (using the
-
-
-
-Kohl & Neuman [Page 25]
-
-RFC 1510 Kerberos September 1993
-
-
- 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; as long as the secret keys exchanged by realms
- are kept secret, only denial of service results from 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 (If the client selects a sub-session key, care must be
- taken to ensure the randomness of the selected subsession key. One
- approach would be to generate a random number and XOR it with the
- session key from the ticket-granting ticket.). 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 in 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
-
-
-
-Kohl & Neuman [Page 26]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
-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.
-
-
-
-
-Kohl & Neuman [Page 27]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 (endtimestarttime) 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 or indicates a time in the
- past, then the start time of the ticket is set to the authentication
- server's current time. If it indicates a time in the future, 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
- MAYPOSTDATE 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 (This allows easy implementation of user-to-
- user authentication [6], which uses ticket-granting ticket session
- keys in lieu of secret server keys in situations where such secret
-
-
-
-Kohl & Neuman [Page 28]
-
-RFC 1510 Kerberos September 1993
-
-
- keys could be easily compromised.).
-
- 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, and the server is registered in the realm of
- the KDC, If the RENEW option is requested, then the KDC will verify
- that the RENEWABLE flag is 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,
- the KDC will issue the appropriate new ticket.
-
- 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 dates 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.1. 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,
-
-
-
-Kohl & Neuman [Page 29]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 preceding 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 endpoints,
- 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 (For the purpose of appending, the realm preceding
- the first listed realm is considered to be the null realm ("")). 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".
-
-
-
-Kohl & Neuman [Page 30]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 (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.). 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 collisionproof 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 some sort of
- 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
-
-
-
-Kohl & Neuman [Page 31]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
- collisionproof keyed checksum, and if it is not, a
- KRB_AP_ERR_INAPP_CKSUM error is generated. 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 timestamp and usec or a sequence
- number is present, a KRB_AP_ERR_MODIFIED error is generated.
-
-
-
-Kohl & Neuman [Page 32]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 modified 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. 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
-
-
-
-Kohl & Neuman [Page 33]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 timestamp 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 raddress 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.
-
-
-
-Kohl & Neuman [Page 34]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 (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.).
-
-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
-
-
-
-Kohl & Neuman [Page 35]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
-
-
-
-Kohl & Neuman [Page 36]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 [7]), or to identify the "string to key" conversion algorithm
- used for a principal's key. (See the discussion of the padata field
- in section 5.4.2 for details on why this can be useful.) 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 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
-
-
-
-Kohl & Neuman [Page 37]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
-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 [8].
-
-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
-
-
-
-Kohl & Neuman [Page 38]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 General
- String. 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 SEQUENCE {
- addr-type[0] INTEGER,
- address[1] OCTET STRING
- }
-
-
- 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
-
-
-
-Kohl & Neuman [Page 39]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
- 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.
-
- 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)
- }
-
- KDCOptions ::= BIT STRING {
- reserved(0),
- forwardable(1),
- forwarded(2),
- proxiable(3),
- proxy(4),
- allow-postdate(5),
- postdated(6),
-
-
-
-Kohl & Neuman [Page 40]
-
-RFC 1510 Kerberos September 1993
-
-
- unused7(7),
- renewable(8),
- unused9(9),
- unused10(10),
- unused11(11),
- renewable-ok(27),
- enc-tkt-in-skey(28),
- renew(30),
- validate(31)
- }
-
-
- 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).
-
- 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.
-
-
-
-
-
-
-
-
-Kohl & Neuman [Page 41]
-
-RFC 1510 Kerberos September 1993
-
-
-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.
-
-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
-}
--- 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
-
-
-
-Kohl & Neuman [Page 42]
-
-RFC 1510 Kerberos September 1993
-
-
- always be identical.
-
- sname This field specifies the name part of the server's
- identity.
-
- enc-part This field holds the encrypted encoding of the
- EncTicketPart sequence.
-
- 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.
-
-
-
-
-Kohl & Neuman [Page 43]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
- 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 particularly careful servers
- may wish to disallow renewable
- tickets). A renewable ticket can be
- used to obtain a replacement 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 authenticated by the KDC before a
- ticket was issued. The strength of
- the preauthentication 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
-
-
-
-Kohl & Neuman [Page 44]
-
-RFC 1510 Kerberos September 1993
-
-
- client. The hardware authentication
- method is selected by the KDC and the
- strength of the method is not
- indicated.
-
- 12-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.1 for details on how
- this field encodes the traversed realms.
-
- 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 (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.).
-
- 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
-
-
-
-Kohl & Neuman [Page 45]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
-
-
-
-
-
-Kohl & Neuman [Page 46]
-
-RFC 1510 Kerberos September 1993
-
-
- 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. The data in this field are specific to the end
- service. It is expected that 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 subfields, 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.
-
- It is interesting to note that 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 [9] 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,
-
-
-
-Kohl & Neuman [Page 47]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 application 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.
-
- 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.
-
-
-
-
-
-
-Kohl & Neuman [Page 48]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 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,
- rtime[6] KerberosTime OPTIONAL,
- nonce[7] INTEGER,
-
-
-
-Kohl & Neuman [Page 49]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 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 collisionproof) 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
- }
-
-
-
-
-Kohl & Neuman [Page 50]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
- 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
- "smartcards" with Kerberos. The details of such extensions
- are beyond the scope of this specification. See [10] 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:
-
-
-
-
-
-
-
-Kohl & Neuman [Page 51]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
- subsequent request if the ticket-
- granting ticket on which it is based
- is also forwardable.
-
- 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
- proxiable 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 subsequent request if
-
-
-
-Kohl & Neuman [Page 52]
-
-RFC 1510 Kerberos September 1993
-
-
- 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-26 RESERVED Reserved for future use.
-
- 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
-
-
-
-Kohl & Neuman [Page 53]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 validate 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 validated 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.
-
-
-
-
-Kohl & Neuman [Page 54]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
- till This field contains the expiration date requested by the
- client in a ticket request.
-
- 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 gen erated
- randomly, but if the correct time is known, it may suffice
- (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.).
-
- 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).
-
-
-
-Kohl & Neuman [Page 55]
-
-RFC 1510 Kerberos September 1993
-
-
- 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,
- enc-part[6] EncryptedData
- }
-
- EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart
- EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
-
- EncKDCRepPart ::= SEQUENCE {
- key[0] EncryptionKey,
- last-req[1] LastReq,
-
-
-
-Kohl & Neuman [Page 56]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
- }
-
- NOTE: In EncASRepPart, the application code in the encrypted
- part of a message provides an additional check that
- the message was decrypted properly.
-
- 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
-
-
-
-Kohl & Neuman [Page 57]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
- expira tion 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,
-
-
-
-Kohl & Neuman [Page 58]
-
-RFC 1510 Kerberos September 1993
-
-
- 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-KEYThe 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 specified, the ticket is
- encrypted in the server's secret key.
-
- 2 MUTUAL-REQUIREDThe 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.
-
-
-
-
-Kohl & Neuman [Page 59]
-
-RFC 1510 Kerberos September 1993
-
-
-5.5.2. KRB_AP_REP definition
-
- The KRB_AP_REP message contains the Kerberos protocol version number,
- the message type, and an encrypted timestamp. 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] SEQUENCE {
- ctime[0] KerberosTime,
- cusec[1] INTEGER,
- subkey[2] EncryptionKey OPTIONAL,
- seq-number[3] INTEGER OPTIONAL
- }
-
- NOTE: in EncAPRepPart, the application code in the encrypted part of
- a message provides an additional check that the message was decrypted
- properly.
-
- 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.
-
-
-
-
-
-Kohl & Neuman [Page 60]
-
-RFC 1510 Kerberos September 1993
-
-
-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 session key. 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,
- 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. It is to be encoded separately and then have the
- checksum computed over it, for use in the cksum field.
-
- cksum This field contains the checksum of the application data.
- Checksum details are described in section 6.4. The
-
-
-
-Kohl & Neuman [Page 61]
-
-RFC 1510 Kerberos September 1993
-
-
- checksum is computed over the encoding of the KRB-SAFE-BODY
- sequence.
-
- 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.
-
- 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
- }
-
-
-
-
-
-Kohl & Neuman [Page 62]
-
-RFC 1510 Kerberos September 1993
-
-
- EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
- user-data[0] OCTET STRING,
- timestamp[1] KerberosTime OPTIONAL,
- usec[2] INTEGER OPTIONAL,
- seq-number[3] INTEGER OPTIONAL,
- s-address[4] HostAddress, -- sender's addr
- r-address[5] HostAddress OPTIONAL
- -- recip's addr
- }
-
- NOTE: In EncKrbPrivPart, the application code in the encrypted part
- of a message provides an additional check that the message was
- decrypted properly.
-
- 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 (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.). 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
-
-
-
-Kohl & Neuman [Page 63]
-
-RFC 1510 Kerberos September 1993
-
-
- each. The information needed to use the tickets is encryped under an
- encryption key previously exchanged. 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 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.
-
-
-
-Kohl & Neuman [Page 64]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 mes sage 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
- corresponding 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 not protected by any
- encryption, it is quite possible for an intruder to synthesize or
-
-
-
-Kohl & Neuman [Page 65]
-
-RFC 1510 Kerberos September 1993
-
-
- modify such a message. In particular, this means that 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
- }
-
- 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 999. 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
-
-
-
-Kohl & Neuman [Page 66]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 the errorcode is KDC_ERR_PREAUTH_REQUIRED, then
- the e-data field will contain an encoding of a sequence of
- padata fields, each corresponding to an acceptable pre-
- authentication method and optionally containing data for
- the method:
-
- METHOD-DATA ::= SEQUENCE of PA-DATA
-
- If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
- contain an encoding of the following sequence:
-
- METHOD-DATA ::= SEQUENCE {
- method-type[0] INTEGER,
- method-data[1] OCTET STRING OPTIONAL
- }
-
- method-type will indicate the required alternate method; method-data
- will contain any required additional information.
-
-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 [11], in conjunction with block chaining and checksum
- methods [12]. 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
-
-
-
-Kohl & Neuman [Page 67]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 plaintext 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 a discussion of the integrity characteristics of the candidate
- encryption and checksum methods considered for Kerberos, the the
- reader is referred to [13].
-
-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
-
-
-
-Kohl & Neuman [Page 68]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 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 is
- described in the following diagram:
-
- +-----------+----------+-------------+-----+
- |confounder | check | msg-seq | pad |
- +-----------+----------+-------------+-----+
-
- The format cannot be described in ASN.1, but for those who prefer an
- ASN.1-like notation:
-
-
-
-
-
-Kohl & Neuman [Page 69]
-
-RFC 1510 Kerberos September 1993
-
-
-CipherText ::= ENCRYPTED SEQUENCE {
- confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL,
- check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
- msg-seq[2] MsgSequence,
- pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
-}
-
- 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.
-
- 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 (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.). 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.
-
-
-
-
-
-
-Kohl & Neuman [Page 70]
-
-RFC 1510 Kerberos September 1993
-
-
-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 key that
- follows in the keyvalue field. It will almost always
- correspond to the encryption algorithm used to generate the
- EncryptedData, though more than one algorithm may use the
- same type of key (the mapping is many to one). This might
- happen, for example, if the encryption algorithm uses an
- alternate checksum algorithm for an integrity check, or a
- different chaining mechanism.
-
- 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 interpretations.
-
-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 [11] using the cipher block chaining mode [12].
- A CRC-32 checksum (described in ISO 3309 [14]) 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 collisionproof, an
-
-
-
-Kohl & Neuman [Page 71]
-
-RFC 1510 Kerberos September 1993
-
-
- attacker could use a probabilistic chosenplaintext attack to generate
- a valid message even if a confounder is used [13]. 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 [11] using the cipher block chaining mode [12].
- An MD4 checksum (described in [15]) 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 descbc-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 [11] using the cipher block chaining mode [12].
- An MD5 checksum (described in [16]) 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 8-octet blocks 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 "semiweak" 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 constant
- F0F0F0F0F0F0F0F0.
-
-
-
-Kohl & Neuman [Page 72]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.]
-
- To generate a DES key from a text string (password), the text string
- normally must have the realm and each component of the principal's
- name appended(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.), then padded with ASCII nulls to an 8 byte
- boundary. This string is then fan-folded and eXclusive-ORed with
- itself to form an 8 byte DES key. The parity is corrected on the
- key, and it is used to generate a DES CBC checksum on the initial
- string (with the realm and name appended). Next, parity is corrected
- on the CBC checksum. If the result matches a "weak" or "semiweak"
- key as described in the DES specification, it is eXclusive-ORed with
- the constant 00000000000000F0. Finally, the result is returned as
- the key. Pseudocode follows:
-
- string_to_key(string,realm,name) {
- odd = 1;
- s = string + realm;
- for(each component in name) {
- s = s + component;
- }
- tempkey = NULL;
- pad(s); /* with nulls to 8 byte boundary */
- for(8byteblock in s) {
- if(odd == 0) {
- odd = 1;
- reverse(8byteblock)
- }
- else odd = 0;
- tempkey = tempkey XOR 8byteblock;
- }
- fixparity(tempkey);
- key = DES-CBC-check(s,tempkey);
- fixparity(key);
- if(is_weak_key_key(key))
- key = key XOR 0xF0;
- return(key);
- }
-
-
-
-Kohl & Neuman [Page 73]
-
-RFC 1510 Kerberos September 1993
-
-
-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 as well 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 collisionproof
- 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 [14]. 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 [13] 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
-
-
-
-Kohl & Neuman [Page 74]
-
-RFC 1510 Kerberos September 1993
-
-
- significant threat.
-
-6.4.2. The RSA MD4 Checksum (rsa-md4)
-
- The RSA-MD4 checksum calculates a checksum using the RSA MD4
- algorithm [15]. 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-md4des)
-
- The RSA-MD4-DES checksum calculates a keyed collisionproof 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 (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.). 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"; those keys shall
- not be used for generating RSA-MD4 checksums for use in Kerberos.
-
- The format for the checksum is described in the following 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)
- }
-
-
-
-Kohl & Neuman [Page 75]
-
-RFC 1510 Kerberos September 1993
-
-
-6.4.4. The RSA MD5 Checksum (rsa-md5)
-
- The RSA-MD5 checksum calculates a checksum using the RSA MD5
- algorithm [16]. 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-md5des)
-
- The RSA-MD5-DES checksum calculates a keyed collisionproof 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 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"; 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
-
-
-
-Kohl & Neuman [Page 76]
-
-RFC 1510 Kerberos September 1993
-
-
- eXclusive-ORing the key with the 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 "semiweak" keys;
- those keys shall not be used for generating DES-MAC checksums for use
- in Kerberos, nor shall a key be used whose veriant 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 cipherblock-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 (desmac-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
-
-
-
-Kohl & Neuman [Page 77]
-
-RFC 1510 Kerberos September 1993
-
-
- this checksum type is the old method for encoding the DESMAC checksum
- and it is no longer recommended.
-
- The DES specifications identify some "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.
-
- There are presently four styles of realm names: domain, X500, other,
- and reserved. Examples of each style follow:
-
- domain: host.subdomain.domain (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 (/).
-
- 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
-
-
-
-Kohl & Neuman [Page 78]
-
-RFC 1510 Kerberos September 1993
-
-
- 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). This constraint may be eliminated in the future. The
- following name types are defined:
-
- name-type value meaning
- NT-UNKNOWN 0 Name type not known
- NT-PRINCIPAL 1 Just the name of the principal as in
- DCE, or for users
- 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 host as remaining components
- NT-UID 5 Unique ID
-
- 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).
-
-
-
-Kohl & Neuman [Page 79]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 ticket
- which 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 SRVXHST 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 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. For services such as telnet and the
- Berkeley R commands which run with system privileges, the first
- component will be the string "host" instead of a service specific
- identifier.
-
-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
-
-
-
-Kohl & Neuman [Page 80]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 <sys/socket.h> with
- symbolic names AF_xxx (where xxx is an abbreviation of the address
- family name).
-
-
- Internet addresses
-
- Internet addresses are 32-bit (4-octet) quantities, encoded in MSB
- order. The type of internet addresses is two (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).
-
-8.2. KDC messages
-
-8.2.1. IP transport
-
- When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
- using 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
-
-
-
-Kohl & Neuman [Page 81]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
-8.2.2. OSI transport
-
- During authentication of an OSI client to and 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(5),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-SRVINST, 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.
-
-
-
-
-
-
-
-
-
-Kohl & Neuman [Page 82]
-
-RFC 1510 Kerberos September 1993
-
-
----------------+-----------+----------+----------------+---------------
-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
-
--------------------------------+-------------------+-------------
-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
-rsa-md5 7 16
-rsa-md5-des 8 24
-
--------------------------------+-----------------
-padata type |padata-type value
--------------------------------+-----------------
-PA-TGS-REQ 1
-PA-ENC-TIMESTAMP 2
-PA-PW-SALT 3
-
--------------------------------+-------------
-authorization data type |ad-type value
--------------------------------+-------------
-reserved values 0-63
-OSF-DCE 64
-SESAME 65
-
--------------------------------+-----------------
-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
-
-
-
-
-
-
-Kohl & Neuman [Page 83]
-
-RFC 1510 Kerberos September 1993
-
-
---------------+-------+-----------------------------------------
-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
-
-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
-
-
-
-Kohl & Neuman [Page 84]
-
-RFC 1510 Kerberos September 1993
-
-
-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-authentication
- required*
-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
-
-
-
-Kohl & Neuman [Page 85]
-
-RFC 1510 Kerberos September 1993
-
-
- message
-KRB_ERR_GENERIC 60 Generic error (description in e-text)
-KRB_ERR_FIELD_TOOLONG 61 Field is too long for this
- implementation
-
- *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.
-
-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 1
-
- This section defines the first specification of these options.
- Implementations which are configured in this way can be said to
- support Kerberos Version 5 Specification 1 (5.1).
-
- 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: Encryption: DES-CBC-MD5
- Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
-
- 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.
-
-
-
-
-Kohl & Neuman [Page 86]
-
-RFC 1510 Kerberos September 1993
-
-
- Transited field encoding
-
- DOMAIN-X500-COMPRESS (described in section 3.3.3.1) 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-ENCTIMESTAMP
- as an acceptable method, the client should retry the initial request
- using the PA-ENC-TIMESTAMP preauthentication method. Servers need not
- support the PAENC-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. By default, servers should not accept 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-TKTIN-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.
-
-
-
-Kohl & Neuman [Page 87]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.
-
-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. Acknowledgments
-
- Early versions of this document, describing version 4 of the
- protocol, were written by Jennifer Steiner (formerly at Project
- Athena); these drafts provided an excellent starting point for this
- current version 5 specification. Many people in the Internet
- community have contributed ideas and suggested protocol changes for
- version 5. Notable contributions came from Ted Anderson, Steve
- Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows,
- Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill
- Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon,
- Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted
- T'so, and Stanley Zanarotti. Many others commented and helped shape
- this specification into its current form.
-
-
-
-
-
-
-
-Kohl & Neuman [Page 88]
-
-RFC 1510 Kerberos September 1993
-
-
-11. References
-
- [1] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section
- E.2.1: Kerberos Authentication and Authorization System",
- M.I.T. Project Athena, Cambridge, Massachusetts, December 21,
- 1987.
-
- [2] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An
- Authentication Service for Open Network Systems", pp. 191-202 in
- Usenix Conference Proceedings, Dallas, Texas, February, 1988.
-
- [3] Needham, R., and M. Schroeder, "Using Encryption for
- Authentication in Large Networks of Computers", Communications
- of the ACM, Vol. 21 (12), pp. 993-999, December 1978.
-
- [4] Denning, D., and G. Sacco, "Time stamps in Key Distribution
- Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536,
- August 1981.
-
- [5] Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the
- Kerberos Authentication Service", in an IEEE Computer Society
- Text soon to be published, June 1992.
-
- [6] Davis, D., and R. Swick, "Workstation Services and Kerberos
- Authentication at Project Athena", Technical Memorandum TM-424,
- MIT Laboratory for Computer Science, February 1990.
-
- [7] Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K.
- Raeburn, "Section E.1: Service Management System, M.I.T.
- Project Athena, Cambridge, Mas sachusetts (1987).
-
- [8] CCITT, Recommendation X.509: The Directory Authentication
- Framework, December 1988.
-
- [9] Neuman, C., "Proxy-Based Authorization and Accounting for
- Distributed Systems," in Proceedings of the 13th International
- Conference on Distributed Computing Systems", Pittsburgh, PA,
- May 1993.
-
- [10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
- Attacks", Open Software Foundation DCE Request for Comments 26,
- December 1992.
-
- [11] National Bureau of Standards, U.S. Department of Commerce, "Data
- Encryption Standard", Federal Information Processing Standards
- Publication 46, Washington, DC (1977).
-
-
-
-
-
-Kohl & Neuman [Page 89]
-
-RFC 1510 Kerberos September 1993
-
-
- [12] National Bureau of Standards, U.S. Department of Commerce, "DES
- Modes of Operation", Federal Information Processing Standards
- Publication 81, Springfield, VA, December 1980.
-
- [13] Stubblebine S., and V. Gligor, "On Message Integrity in
- Cryptographic Protocols", in Proceedings of the IEEE Symposium
- on Research in Security and Privacy, Oakland, California, May
- 1992.
-
- [14] International Organization for Standardization, "ISO Information
- Processing Systems - Data Communication High-Level Data Link
- Control Procedure - Frame Structure", IS 3309, October 1984, 3rd
- Edition.
-
- [15] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT
- Laboratory for Computer Science, April 1992.
-
- [16] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT
- Laboratory for Computer Science, April 1992.
-
- [17] Bellovin S., and M. Merritt, "Limitations of the Kerberos
- Authentication System", Computer Communications Review, Vol.
- 20(5), pp. 119-132, October 1990.
-
-12. Security Considerations
-
- Security issues are discussed throughout this memo.
-
-13. Authors' Addresses
-
- John Kohl
- Digital Equipment Corporation
- 110 Spit Brook Road, M/S ZKO3-3/U14
- Nashua, NH 03062
-
- Phone: 603-881-2481
- EMail: jtkohl@zk3.dec.com
-
-
- B. Clifford Neuman
- USC/Information Sciences Institute
- 4676 Admiralty Way #1001
- Marina del Rey, CA 90292-6695
-
- Phone: 310-822-1511
- EMail: bcn@isi.edu
-
-
-
-
-
-Kohl & Neuman [Page 90]
-
-RFC 1510 Kerberos September 1993
-
-
-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
-
-
-
-Kohl & Neuman [Page 91]
-
-RFC 1510 Kerberos September 1993
-
-
-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
- 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;
-
-
-
-
-Kohl & Neuman [Page 92]
-
-RFC 1510 Kerberos September 1993
-
-
- /* 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.ALLOW-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.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);
-
-
-
-Kohl & Neuman [Page 93]
-
-RFC 1510 Kerberos September 1993
-
-
- 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;
-
-
-
-Kohl & Neuman [Page 94]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
-
- /* 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
-
-
-
-Kohl & Neuman [Page 95]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
- 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;
-
-
-
-Kohl & Neuman [Page 96]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
-
-
-
-
-Kohl & Neuman [Page 97]
-
-RFC 1510 Kerberos September 1993
-
-
- /* 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
-
-
-
-Kohl & Neuman [Page 98]
-
-RFC 1510 Kerberos September 1993
-
-
- 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(server)) then
- server := best_intermediate_tgs(server);
- 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;
-
-
-
-Kohl & Neuman [Page 99]
-
-RFC 1510 Kerberos September 1993
-
-
- 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.POSTDATE is set) then
- if (tgt.flags.POSTDATE is reset)
- error_out(KDC_ERR_BADOPTION);
- endif
- set new_tkt.flags.POSTDATE;
- endif
- if (req.kdc-options.POSTDATED is set) then
- if (tgt.flags.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
-
-
-
-Kohl & Neuman [Page 100]
-
-RFC 1510 Kerberos September 1993
-
-
- 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);
-
- 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);
-
-
-
-Kohl & Neuman [Page 101]
-
-RFC 1510 Kerberos September 1993
-
-
- 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)
- endif
-
-
-
-Kohl & Neuman [Page 102]
-
-RFC 1510 Kerberos September 1993
-
-
- 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,
-
-
-
-Kohl & Neuman [Page 103]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
-
-
-
-Kohl & Neuman [Page 104]
-
-RFC 1510 Kerberos September 1993
-
-
-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
- 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
-
-
-
-Kohl & Neuman [Page 105]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
- /* 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;
-
-
-
-Kohl & Neuman [Page 106]
-
-RFC 1510 Kerberos September 1993
-
-
- 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 */
-
-
-
-Kohl & Neuman [Page 107]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
- 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
-
-
-
-Kohl & Neuman [Page 108]
-
-RFC 1510 Kerberos September 1993
-
-
- /* 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 */
-
- 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
-
-
-
-
-Kohl & Neuman [Page 109]
-
-RFC 1510 Kerberos September 1993
-
-
- 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;
- 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;
-
-
-
-Kohl & Neuman [Page 110]
-
-RFC 1510 Kerberos September 1993
-
-
- 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);
-
-
-
-Kohl & Neuman [Page 111]
-
-RFC 1510 Kerberos September 1993
-
-
- 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
- (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
-
-
-
-
-
-
-
-
-
-
-
-Kohl & Neuman [Page 112]
-
\ No newline at end of file
diff --git a/doc/standardisation/rfc1750.txt b/doc/standardisation/rfc1750.txt
deleted file mode 100644
index 56d478c7eef421b425efcc4f548f2e16355b616a..0000000000000000000000000000000000000000
--- a/doc/standardisation/rfc1750.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake, 3rd
-Request for Comments: 1750 DEC
-Category: Informational S. Crocker
- Cybercash
- J. Schiller
- MIT
- December 1994
-
-
- Randomness Recommendations for Security
-
-Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
-Abstract
-
- Security systems today are built on increasingly strong cryptographic
- algorithms that foil pattern analysis attempts. However, the security
- of these systems is dependent on generating secret quantities for
- passwords, cryptographic keys, and similar quantities. The use of
- pseudo-random processes to generate secret quantities can result in
- pseudo-security. The sophisticated attacker of these security
- systems may find it easier to reproduce the environment that produced
- the secret quantities, searching the resulting small set of
- possibilities, than to locate the quantities in the whole of the
- number space.
-
- Choosing random quantities to foil a resourceful and motivated
- adversary is surprisingly difficult. This paper points out many
- pitfalls in using traditional pseudo-random number generation
- techniques for choosing such quantities. It recommends the use of
- truly random hardware techniques and shows that the existing hardware
- on many systems can be used for this purpose. It provides
- suggestions to ameliorate the problem when a hardware solution is not
- available. And it gives examples of how large such quantities need
- to be for some particular applications.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 1]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-Acknowledgements
-
- Comments on this document that have been incorporated were received
- from (in alphabetic order) the following:
-
- David M. Balenson (TIS)
- Don Coppersmith (IBM)
- Don T. Davis (consultant)
- Carl Ellison (Stratus)
- Marc Horowitz (MIT)
- Christian Huitema (INRIA)
- Charlie Kaufman (IRIS)
- Steve Kent (BBN)
- Hal Murray (DEC)
- Neil Haller (Bellcore)
- Richard Pitkin (DEC)
- Tim Redmond (TIS)
- Doug Tygar (CMU)
-
-Table of Contents
-
- 1. Introduction........................................... 3
- 2. Requirements........................................... 4
- 3. Traditional Pseudo-Random Sequences.................... 5
- 4. Unpredictability....................................... 7
- 4.1 Problems with Clocks and Serial Numbers............... 7
- 4.2 Timing and Content of External Events................ 8
- 4.3 The Fallacy of Complex Manipulation.................. 8
- 4.4 The Fallacy of Selection from a Large Database....... 9
- 5. Hardware for Randomness............................... 10
- 5.1 Volume Required...................................... 10
- 5.2 Sensitivity to Skew.................................. 10
- 5.2.1 Using Stream Parity to De-Skew..................... 11
- 5.2.2 Using Transition Mappings to De-Skew............... 12
- 5.2.3 Using FFT to De-Skew............................... 13
- 5.2.4 Using Compression to De-Skew....................... 13
- 5.3 Existing Hardware Can Be Used For Randomness......... 14
- 5.3.1 Using Existing Sound/Video Input................... 14
- 5.3.2 Using Existing Disk Drives......................... 14
- 6. Recommended Non-Hardware Strategy..................... 14
- 6.1 Mixing Functions..................................... 15
- 6.1.1 A Trivial Mixing Function.......................... 15
- 6.1.2 Stronger Mixing Functions.......................... 16
- 6.1.3 Diff-Hellman as a Mixing Function.................. 17
- 6.1.4 Using a Mixing Function to Stretch Random Bits..... 17
- 6.1.5 Other Factors in Choosing a Mixing Function........ 18
- 6.2 Non-Hardware Sources of Randomness................... 19
- 6.3 Cryptographically Strong Sequences................... 19
-
-
-
-Eastlake, Crocker & Schiller [Page 2]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- 6.3.1 Traditional Strong Sequences....................... 20
- 6.3.2 The Blum Blum Shub Sequence Generator.............. 21
- 7. Key Generation Standards.............................. 22
- 7.1 US DoD Recommendations for Password Generation....... 23
- 7.2 X9.17 Key Generation................................. 23
- 8. Examples of Randomness Required....................... 24
- 8.1 Password Generation................................. 24
- 8.2 A Very High Security Cryptographic Key............... 25
- 8.2.1 Effort per Key Trial............................... 25
- 8.2.2 Meet in the Middle Attacks......................... 26
- 8.2.3 Other Considerations............................... 26
- 9. Conclusion............................................ 27
- 10. Security Considerations.............................. 27
- References............................................... 28
- Authors' Addresses....................................... 30
-
-1. Introduction
-
- Software cryptography is coming into wider use. Systems like
- Kerberos, PEM, PGP, etc. are maturing and becoming a part of the
- network landscape [PEM]. These systems provide substantial
- protection against snooping and spoofing. However, there is a
- potential flaw. At the heart of all cryptographic systems is the
- generation of secret, unguessable (i.e., random) numbers.
-
- For the present, the lack of generally available facilities for
- generating such unpredictable numbers is an open wound in the design
- of cryptographic software. For the software developer who wants to
- build a key or password generation procedure that runs on a wide
- range of hardware, the only safe strategy so far has been to force
- the local installation to supply a suitable routine to generate
- random numbers. To say the least, this is an awkward, error-prone
- and unpalatable solution.
-
- It is important to keep in mind that the requirement is for data that
- an adversary has a very low probability of guessing or determining.
- This will fail if pseudo-random data is used which only meets
- traditional statistical tests for randomness or which is based on
- limited range sources, such as clocks. Frequently such random
- quantities are determinable by an adversary searching through an
- embarrassingly small space of possibilities.
-
- This informational document suggests techniques for producing random
- quantities that will be resistant to such attack. It recommends that
- future systems include hardware random number generation or provide
- access to existing hardware that can be used for this purpose. It
- suggests methods for use if such hardware is not available. And it
- gives some estimates of the number of random bits required for sample
-
-
-
-Eastlake, Crocker & Schiller [Page 3]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- applications.
-
-2. Requirements
-
- Probably the most commonly encountered randomness requirement today
- is the user password. This is usually a simple character string.
- Obviously, if a password can be guessed, it does not provide
- security. (For re-usable passwords, it is desirable that users be
- able to remember the password. This may make it advisable to use
- pronounceable character strings or phrases composed on ordinary
- words. But this only affects the format of the password information,
- not the requirement that the password be very hard to guess.)
-
- Many other requirements come from the cryptographic arena.
- Cryptographic techniques can be used to provide a variety of services
- including confidentiality and authentication. Such services are
- based on quantities, traditionally called "keys", that are unknown to
- and unguessable by an adversary.
-
- In some cases, such as the use of symmetric encryption with the one
- time pads [CRYPTO*] or the US Data Encryption Standard [DES], the
- parties who wish to communicate confidentially and/or with
- authentication must all know the same secret key. In other cases,
- using what are called asymmetric or "public key" cryptographic
- techniques, keys come in pairs. One key of the pair is private and
- must be kept secret by one party, the other is public and can be
- published to the world. It is computationally infeasible to
- determine the private key from the public key [ASYMMETRIC, CRYPTO*].
-
- The frequency and volume of the requirement for random quantities
- differs greatly for different cryptographic systems. Using pure RSA
- [CRYPTO*], random quantities are required when the key pair is
- generated, but thereafter any number of messages can be signed
- without any further need for randomness. The public key Digital
- Signature Algorithm that has been proposed by the US National
- Institute of Standards and Technology (NIST) requires good random
- numbers for each signature. And encrypting with a one time pad, in
- principle the strongest possible encryption technique, requires a
- volume of randomness equal to all the messages to be processed.
-
- In most of these cases, an adversary can try to determine the
- "secret" key by trial and error. (This is possible as long as the
- key is enough smaller than the message that the correct key can be
- uniquely identified.) The probability of an adversary succeeding at
- this must be made acceptably low, depending on the particular
- application. The size of the space the adversary must search is
- related to the amount of key "information" present in the information
- theoretic sense [SHANNON]. This depends on the number of different
-
-
-
-Eastlake, Crocker & Schiller [Page 4]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- secret values possible and the probability of each value as follows:
-
- -----
- \
- Bits-of-info = \ - p * log ( p )
- / i 2 i
- /
- -----
-
- where i varies from 1 to the number of possible secret values and p
- sub i is the probability of the value numbered i. (Since p sub i is
- less than one, the log will be negative so each term in the sum will
- be non-negative.)
-
- If there are 2^n different values of equal probability, then n bits
- of information are present and an adversary would, on the average,
- have to try half of the values, or 2^(n-1) , before guessing the
- secret quantity. If the probability of different values is unequal,
- then there is less information present and fewer guesses will, on
- average, be required by an adversary. In particular, any values that
- the adversary can know are impossible, or are of low probability, can
- be initially ignored by an adversary, who will search through the
- more probable values first.
-
- For example, consider a cryptographic system that uses 56 bit keys.
- If these 56 bit keys are derived by using a fixed pseudo-random
- number generator that is seeded with an 8 bit seed, then an adversary
- needs to search through only 256 keys (by running the pseudo-random
- number generator with every possible seed), not the 2^56 keys that
- may at first appear to be the case. Only 8 bits of "information" are
- in these 56 bit keys.
-
-3. Traditional Pseudo-Random Sequences
-
- Most traditional sources of random numbers use deterministic sources
- of "pseudo-random" numbers. These typically start with a "seed"
- quantity and use numeric or logical operations to produce a sequence
- of values.
-
- [KNUTH] has a classic exposition on pseudo-random numbers.
- Applications he mentions are simulation of natural phenomena,
- sampling, numerical analysis, testing computer programs, decision
- making, and games. None of these have the same characteristics as
- the sort of security uses we are talking about. Only in the last two
- could there be an adversary trying to find the random quantity.
- However, in these cases, the adversary normally has only a single
- chance to use a guessed value. In guessing passwords or attempting
- to break an encryption scheme, the adversary normally has many,
-
-
-
-Eastlake, Crocker & Schiller [Page 5]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- perhaps unlimited, chances at guessing the correct value and should
- be assumed to be aided by a computer.
-
- For testing the "randomness" of numbers, Knuth suggests a variety of
- measures including statistical and spectral. These tests check
- things like autocorrelation between different parts of a "random"
- sequence or distribution of its values. They could be met by a
- constant stored random sequence, such as the "random" sequence
- printed in the CRC Standard Mathematical Tables [CRC].
-
- A typical pseudo-random number generation technique, known as a
- linear congruence pseudo-random number generator, is modular
- arithmetic where the N+1th value is calculated from the Nth value by
-
- V = ( V * a + b )(Mod c)
- N+1 N
-
- The above technique has a strong relationship to linear shift
- register pseudo-random number generators, which are well understood
- cryptographically [SHIFT*]. In such generators bits are introduced
- at one end of a shift register as the Exclusive Or (binary sum
- without carry) of bits from selected fixed taps into the register.
-
- For example:
-
- +----+ +----+ +----+ +----+
- | B | <-- | B | <-- | B | <-- . . . . . . <-- | B | <-+
- | 0 | | 1 | | 2 | | n | |
- +----+ +----+ +----+ +----+ |
- | | | |
- | | V +-----+
- | V +----------------> | |
- V +-----------------------------> | XOR |
- +---------------------------------------------------> | |
- +-----+
-
-
- V = ( ( V * 2 ) + B .xor. B ... )(Mod 2^n)
- N+1 N 0 2
-
- The goodness of traditional pseudo-random number generator algorithms
- is measured by statistical tests on such sequences. Carefully chosen
- values of the initial V and a, b, and c or the placement of shift
- register tap in the above simple processes can produce excellent
- statistics.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 6]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- These sequences may be adequate in simulations (Monte Carlo
- experiments) as long as the sequence is orthogonal to the structure
- of the space being explored. Even there, subtle patterns may cause
- problems. However, such sequences are clearly bad for use in
- security applications. They are fully predictable if the initial
- state is known. Depending on the form of the pseudo-random number
- generator, the sequence may be determinable from observation of a
- short portion of the sequence [CRYPTO*, STERN]. For example, with
- the generators above, one can determine V(n+1) given knowledge of
- V(n). In fact, it has been shown that with these techniques, even if
- only one bit of the pseudo-random values is released, the seed can be
- determined from short sequences.
-
- Not only have linear congruent generators been broken, but techniques
- are now known for breaking all polynomial congruent generators
- [KRAWCZYK].
-
-4. Unpredictability
-
- Randomness in the traditional sense described in section 3 is NOT the
- same as the unpredictability required for security use.
-
- For example, use of a widely available constant sequence, such as
- that from the CRC tables, is very weak against an adversary. Once
- they learn of or guess it, they can easily break all security, future
- and past, based on the sequence [CRC]. Yet the statistical
- properties of these tables are good.
-
- The following sections describe the limitations of some randomness
- generation techniques and sources.
-
-4.1 Problems with Clocks and Serial Numbers
-
- Computer clocks, or similar operating system or hardware values,
- provide significantly fewer real bits of unpredictability than might
- appear from their specifications.
-
- Tests have been done on clocks on numerous systems and it was found
- that their behavior can vary widely and in unexpected ways. One
- version of an operating system running on one set of hardware may
- actually provide, say, microsecond resolution in a clock while a
- different configuration of the "same" system may always provide the
- same lower bits and only count in the upper bits at much lower
- resolution. This means that successive reads on the clock may
- produce identical values even if enough time has passed that the
- value "should" change based on the nominal clock resolution. There
- are also cases where frequently reading a clock can produce
- artificial sequential values because of extra code that checks for
-
-
-
-Eastlake, Crocker & Schiller [Page 7]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- the clock being unchanged between two reads and increases it by one!
- Designing portable application code to generate unpredictable numbers
- based on such system clocks is particularly challenging because the
- system designer does not always know the properties of the system
- clocks that the code will execute on.
-
- Use of a hardware serial number such as an Ethernet address may also
- provide fewer bits of uniqueness than one would guess. Such
- quantities are usually heavily structured and subfields may have only
- a limited range of possible values or values easily guessable based
- on approximate date of manufacture or other data. For example, it is
- likely that most of the Ethernet cards installed on Digital Equipment
- Corporation (DEC) hardware within DEC were manufactured by DEC
- itself, which significantly limits the range of built in addresses.
-
- Problems such as those described above related to clocks and serial
- numbers make code to produce unpredictable quantities difficult if
- the code is to be ported across a variety of computer platforms and
- systems.
-
-4.2 Timing and Content of External Events
-
- It is possible to measure the timing and content of mouse movement,
- key strokes, and similar user events. This is a reasonable source of
- unguessable data with some qualifications. On some machines, inputs
- such as key strokes are buffered. Even though the user's inter-
- keystroke timing may have sufficient variation and unpredictability,
- there might not be an easy way to access that variation. Another
- problem is that no standard method exists to sample timing details.
- This makes it hard to build standard software intended for
- distribution to a large range of machines based on this technique.
-
- The amount of mouse movement or the keys actually hit are usually
- easier to access than timings but may yield less unpredictability as
- the user may provide highly repetitive input.
-
- Other external events, such as network packet arrival times, can also
- be used with care. In particular, the possibility of manipulation of
- such times by an adversary must be considered.
-
-4.3 The Fallacy of Complex Manipulation
-
- One strategy which may give a misleading appearance of
- unpredictability is to take a very complex algorithm (or an excellent
- traditional pseudo-random number generator with good statistical
- properties) and calculate a cryptographic key by starting with the
- current value of a computer system clock as the seed. An adversary
- who knew roughly when the generator was started would have a
-
-
-
-Eastlake, Crocker & Schiller [Page 8]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- relatively small number of seed values to test as they would know
- likely values of the system clock. Large numbers of pseudo-random
- bits could be generated but the search space an adversary would need
- to check could be quite small.
-
- Thus very strong and/or complex manipulation of data will not help if
- the adversary can learn what the manipulation is and there is not
- enough unpredictability in the starting seed value. Even if they can
- not learn what the manipulation is, they may be able to use the
- limited number of results stemming from a limited number of seed
- values to defeat security.
-
- Another serious strategy error is to assume that a very complex
- pseudo-random number generation algorithm will produce strong random
- numbers when there has been no theory behind or analysis of the
- algorithm. There is a excellent example of this fallacy right near
- the beginning of chapter 3 in [KNUTH] where the author describes a
- complex algorithm. It was intended that the machine language program
- corresponding to the algorithm would be so complicated that a person
- trying to read the code without comments wouldn't know what the
- program was doing. Unfortunately, actual use of this algorithm
- showed that it almost immediately converged to a single repeated
- value in one case and a small cycle of values in another case.
-
- Not only does complex manipulation not help you if you have a limited
- range of seeds but blindly chosen complex manipulation can destroy
- the randomness in a good seed!
-
-4.4 The Fallacy of Selection from a Large Database
-
- Another strategy that can give a misleading appearance of
- unpredictability is selection of a quantity randomly from a database
- and assume that its strength is related to the total number of bits
- in the database. For example, typical USENET servers as of this date
- process over 35 megabytes of information per day. Assume a random
- quantity was selected by fetching 32 bytes of data from a random
- starting point in this data. This does not yield 32*8 = 256 bits
- worth of unguessability. Even after allowing that much of the data
- is human language and probably has more like 2 or 3 bits of
- information per byte, it doesn't yield 32*2.5 = 80 bits of
- unguessability. For an adversary with access to the same 35
- megabytes the unguessability rests only on the starting point of the
- selection. That is, at best, about 25 bits of unguessability in this
- case.
-
- The same argument applies to selecting sequences from the data on a
- CD ROM or Audio CD recording or any other large public database. If
- the adversary has access to the same database, this "selection from a
-
-
-
-Eastlake, Crocker & Schiller [Page 9]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- large volume of data" step buys very little. However, if a selection
- can be made from data to which the adversary has no access, such as
- system buffers on an active multi-user system, it may be of some
- help.
-
-5. Hardware for Randomness
-
- Is there any hope for strong portable randomness in the future?
- There might be. All that's needed is a physical source of
- unpredictable numbers.
-
- A thermal noise or radioactive decay source and a fast, free-running
- oscillator would do the trick directly [GIFFORD]. This is a trivial
- amount of hardware, and could easily be included as a standard part
- of a computer system's architecture. Furthermore, any system with a
- spinning disk or the like has an adequate source of randomness
- [DAVIS]. All that's needed is the common perception among computer
- vendors that this small additional hardware and the software to
- access it is necessary and useful.
-
-5.1 Volume Required
-
- How much unpredictability is needed? Is it possible to quantify the
- requirement in, say, number of random bits per second?
-
- The answer is not very much is needed. For DES, the key is 56 bits
- and, as we show in an example in Section 8, even the highest security
- system is unlikely to require a keying material of over 200 bits. If
- a series of keys are needed, it can be generated from a strong random
- seed using a cryptographically strong sequence as explained in
- Section 6.3. A few hundred random bits generated once a day would be
- enough using such techniques. Even if the random bits are generated
- as slowly as one per second and it is not possible to overlap the
- generation process, it should be tolerable in high security
- applications to wait 200 seconds occasionally.
-
- These numbers are trivial to achieve. It could be done by a person
- repeatedly tossing a coin. Almost any hardware process is likely to
- be much faster.
-
-5.2 Sensitivity to Skew
-
- Is there any specific requirement on the shape of the distribution of
- the random numbers? The good news is the distribution need not be
- uniform. All that is needed is a conservative estimate of how non-
- uniform it is to bound performance. Two simple techniques to de-skew
- the bit stream are given below and stronger techniques are mentioned
- in Section 6.1.2 below.
-
-
-
-Eastlake, Crocker & Schiller [Page 10]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-5.2.1 Using Stream Parity to De-Skew
-
- Consider taking a sufficiently long string of bits and map the string
- to "zero" or "one". The mapping will not yield a perfectly uniform
- distribution, but it can be as close as desired. One mapping that
- serves the purpose is to take the parity of the string. This has the
- advantages that it is robust across all degrees of skew up to the
- estimated maximum skew and is absolutely trivial to implement in
- hardware.
-
- The following analysis gives the number of bits that must be sampled:
-
- Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is
- between 0 and 0.5 and is a measure of the "eccentricity" of the
- distribution. Consider the distribution of the parity function of N
- bit samples. The probabilities that the parity will be one or zero
- will be the sum of the odd or even terms in the binomial expansion of
- (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 -
- e, the probability of a zero.
-
- These sums can be computed easily as
-
- N N
- 1/2 * ( ( p + q ) + ( p - q ) )
- and
- N N
- 1/2 * ( ( p + q ) - ( p - q ) ).
-
- (Which one corresponds to the probability the parity will be 1
- depends on whether N is odd or even.)
-
- Since p + q = 1 and p - q = 2e, these expressions reduce to
-
- N
- 1/2 * [1 + (2e) ]
- and
- N
- 1/2 * [1 - (2e) ].
-
- Neither of these will ever be exactly 0.5 unless e is zero, but we
- can bring them arbitrarily close to 0.5. If we want the
- probabilities to be within some delta d of 0.5, i.e. then
-
- N
- ( 0.5 + ( 0.5 * (2e) ) ) < 0.5 + d.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 11]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- Solving for N yields N > log(2d)/log(2e). (Note that 2e is less than
- 1, so its log is negative. Division by a negative number reverses
- the sense of an inequality.)
-
- The following table gives the length of the string which must be
- sampled for various degrees of skew in order to come within 0.001 of
- a 50/50 distribution.
-
- +---------+--------+-------+
- | Prob(1) | e | N |
- +---------+--------+-------+
- | 0.5 | 0.00 | 1 |
- | 0.6 | 0.10 | 4 |
- | 0.7 | 0.20 | 7 |
- | 0.8 | 0.30 | 13 |
- | 0.9 | 0.40 | 28 |
- | 0.95 | 0.45 | 59 |
- | 0.99 | 0.49 | 308 |
- +---------+--------+-------+
-
- The last entry shows that even if the distribution is skewed 99% in
- favor of ones, the parity of a string of 308 samples will be within
- 0.001 of a 50/50 distribution.
-
-5.2.2 Using Transition Mappings to De-Skew
-
- Another technique, originally due to von Neumann [VON NEUMANN], is to
- examine a bit stream as a sequence of non-overlapping pairs. You
- could then discard any 00 or 11 pairs found, interpret 01 as a 0 and
- 10 as a 1. Assume the probability of a 1 is 0.5+e and the
- probability of a 0 is 0.5-e where e is the eccentricity of the source
- and described in the previous section. Then the probability of each
- pair is as follows:
-
- +------+-----------------------------------------+
- | pair | probability |
- +------+-----------------------------------------+
- | 00 | (0.5 - e)^2 = 0.25 - e + e^2 |
- | 01 | (0.5 - e)*(0.5 + e) = 0.25 - e^2 |
- | 10 | (0.5 + e)*(0.5 - e) = 0.25 - e^2 |
- | 11 | (0.5 + e)^2 = 0.25 + e + e^2 |
- +------+-----------------------------------------+
-
- This technique will completely eliminate any bias but at the expense
- of taking an indeterminate number of input bits for any particular
- desired number of output bits. The probability of any particular
- pair being discarded is 0.5 + 2e^2 so the expected number of input
- bits to produce X output bits is X/(0.25 - e^2).
-
-
-
-Eastlake, Crocker & Schiller [Page 12]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- This technique assumes that the bits are from a stream where each bit
- has the same probability of being a 0 or 1 as any other bit in the
- stream and that bits are not correlated, i.e., that the bits are
- identical independent distributions. If alternate bits were from two
- correlated sources, for example, the above analysis breaks down.
-
- The above technique also provides another illustration of how a
- simple statistical analysis can mislead if one is not always on the
- lookout for patterns that could be exploited by an adversary. If the
- algorithm were mis-read slightly so that overlapping successive bits
- pairs were used instead of non-overlapping pairs, the statistical
- analysis given is the same; however, instead of provided an unbiased
- uncorrelated series of random 1's and 0's, it instead produces a
- totally predictable sequence of exactly alternating 1's and 0's.
-
-5.2.3 Using FFT to De-Skew
-
- When real world data consists of strongly biased or correlated bits,
- it may still contain useful amounts of randomness. This randomness
- can be extracted through use of the discrete Fourier transform or its
- optimized variant, the FFT.
-
- Using the Fourier transform of the data, strong correlations can be
- discarded. If adequate data is processed and remaining correlations
- decay, spectral lines approaching statistical independence and
- normally distributed randomness can be produced [BRILLINGER].
-
-5.2.4 Using Compression to De-Skew
-
- Reversible compression techniques also provide a crude method of de-
- skewing a skewed bit stream. This follows directly from the
- definition of reversible compression and the formula in Section 2
- above for the amount of information in a sequence. Since the
- compression is reversible, the same amount of information must be
- present in the shorter output than was present in the longer input.
- By the Shannon information equation, this is only possible if, on
- average, the probabilities of the different shorter sequences are
- more uniformly distributed than were the probabilities of the longer
- sequences. Thus the shorter sequences are de-skewed relative to the
- input.
-
- However, many compression techniques add a somewhat predicatable
- preface to their output stream and may insert such a sequence again
- periodically in their output or otherwise introduce subtle patterns
- of their own. They should be considered only a rough technique
- compared with those described above or in Section 6.1.2. At a
- minimum, the beginning of the compressed sequence should be skipped
- and only later bits used for applications requiring random bits.
-
-
-
-Eastlake, Crocker & Schiller [Page 13]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-5.3 Existing Hardware Can Be Used For Randomness
-
- As described below, many computers come with hardware that can, with
- care, be used to generate truly random quantities.
-
-5.3.1 Using Existing Sound/Video Input
-
- Increasingly computers are being built with inputs that digitize some
- real world analog source, such as sound from a microphone or video
- input from a camera. Under appropriate circumstances, such input can
- provide reasonably high quality random bits. The "input" from a
- sound digitizer with no source plugged in or a camera with the lens
- cap on, if the system has enough gain to detect anything, is
- essentially thermal noise.
-
- For example, on a SPARCstation, one can read from the /dev/audio
- device with nothing plugged into the microphone jack. Such data is
- essentially random noise although it should not be trusted without
- some checking in case of hardware failure. It will, in any case,
- need to be de-skewed as described elsewhere.
-
- Combining this with compression to de-skew one can, in UNIXese,
- generate a huge amount of medium quality random data by doing
-
- cat /dev/audio | compress - >random-bits-file
-
-5.3.2 Using Existing Disk Drives
-
- Disk drives have small random fluctuations in their rotational speed
- due to chaotic air turbulence [DAVIS]. By adding low level disk seek
- time instrumentation to a system, a series of measurements can be
- obtained that include this randomness. Such data is usually highly
- correlated so that significant processing is needed, including FFT
- (see section 5.2.3). Nevertheless experimentation has shown that,
- with such processing, disk drives easily produce 100 bits a minute or
- more of excellent random data.
-
- Partly offsetting this need for processing is the fact that disk
- drive failure will normally be rapidly noticed. Thus, problems with
- this method of random number generation due to hardware failure are
- very unlikely.
-
-6. Recommended Non-Hardware Strategy
-
- What is the best overall strategy for meeting the requirement for
- unguessable random numbers in the absence of a reliable hardware
- source? It is to obtain random input from a large number of
- uncorrelated sources and to mix them with a strong mixing function.
-
-
-
-Eastlake, Crocker & Schiller [Page 14]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- Such a function will preserve the randomness present in any of the
- sources even if other quantities being combined are fixed or easily
- guessable. This may be advisable even with a good hardware source as
- hardware can also fail, though this should be weighed against any
- increase in the chance of overall failure due to added software
- complexity.
-
-6.1 Mixing Functions
-
- A strong mixing function is one which combines two or more inputs and
- produces an output where each output bit is a different complex non-
- linear function of all the input bits. On average, changing any
- input bit will change about half the output bits. But because the
- relationship is complex and non-linear, no particular output bit is
- guaranteed to change when any particular input bit is changed.
-
- Consider the problem of converting a stream of bits that is skewed
- towards 0 or 1 to a shorter stream which is more random, as discussed
- in Section 5.2 above. This is simply another case where a strong
- mixing function is desired, mixing the input bits to produce a
- smaller number of output bits. The technique given in Section 5.2.1
- of using the parity of a number of bits is simply the result of
- successively Exclusive Or'ing them which is examined as a trivial
- mixing function immediately below. Use of stronger mixing functions
- to extract more of the randomness in a stream of skewed bits is
- examined in Section 6.1.2.
-
-6.1.1 A Trivial Mixing Function
-
- A trivial example for single bit inputs is the Exclusive Or function,
- which is equivalent to addition without carry, as show in the table
- below. This is a degenerate case in which the one output bit always
- changes for a change in either input bit. But, despite its
- simplicity, it will still provide a useful illustration.
-
- +-----------+-----------+----------+
- | input 1 | input 2 | output |
- +-----------+-----------+----------+
- | 0 | 0 | 0 |
- | 0 | 1 | 1 |
- | 1 | 0 | 1 |
- | 1 | 1 | 0 |
- +-----------+-----------+----------+
-
- If inputs 1 and 2 are uncorrelated and combined in this fashion then
- the output will be an even better (less skewed) random bit than the
- inputs. If we assume an "eccentricity" e as defined in Section 5.2
- above, then the output eccentricity relates to the input eccentricity
-
-
-
-Eastlake, Crocker & Schiller [Page 15]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- as follows:
-
- e = 2 * e * e
- output input 1 input 2
-
- Since e is never greater than 1/2, the eccentricity is always
- improved except in the case where at least one input is a totally
- skewed constant. This is illustrated in the following table where
- the top and left side values are the two input eccentricities and the
- entries are the output eccentricity:
-
- +--------+--------+--------+--------+--------+--------+--------+
- | e | 0.00 | 0.10 | 0.20 | 0.30 | 0.40 | 0.50 |
- +--------+--------+--------+--------+--------+--------+--------+
- | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
- | 0.10 | 0.00 | 0.02 | 0.04 | 0.06 | 0.08 | 0.10 |
- | 0.20 | 0.00 | 0.04 | 0.08 | 0.12 | 0.16 | 0.20 |
- | 0.30 | 0.00 | 0.06 | 0.12 | 0.18 | 0.24 | 0.30 |
- | 0.40 | 0.00 | 0.08 | 0.16 | 0.24 | 0.32 | 0.40 |
- | 0.50 | 0.00 | 0.10 | 0.20 | 0.30 | 0.40 | 0.50 |
- +--------+--------+--------+--------+--------+--------+--------+
-
- However, keep in mind that the above calculations assume that the
- inputs are not correlated. If the inputs were, say, the parity of
- the number of minutes from midnight on two clocks accurate to a few
- seconds, then each might appear random if sampled at random intervals
- much longer than a minute. Yet if they were both sampled and
- combined with xor, the result would be zero most of the time.
-
-6.1.2 Stronger Mixing Functions
-
- The US Government Data Encryption Standard [DES] is an example of a
- strong mixing function for multiple bit quantities. It takes up to
- 120 bits of input (64 bits of "data" and 56 bits of "key") and
- produces 64 bits of output each of which is dependent on a complex
- non-linear function of all input bits. Other strong encryption
- functions with this characteristic can also be used by considering
- them to mix all of their key and data input bits.
-
- Another good family of mixing functions are the "message digest" or
- hashing functions such as The US Government Secure Hash Standard
- [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series. These functions
- all take an arbitrary amount of input and produce an output mixing
- all the input bits. The MD* series produce 128 bits of output and SHS
- produces 160 bits.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 16]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- Although the message digest functions are designed for variable
- amounts of input, DES and other encryption functions can also be used
- to combine any number of inputs. If 64 bits of output is adequate,
- the inputs can be packed into a 64 bit data quantity and successive
- 56 bit keys, padding with zeros if needed, which are then used to
- successively encrypt using DES in Electronic Codebook Mode [DES
- MODES]. If more than 64 bits of output are needed, use more complex
- mixing. For example, if inputs are packed into three quantities, A,
- B, and C, use DES to encrypt A with B as a key and then with C as a
- key to produce the 1st part of the output, then encrypt B with C and
- then A for more output and, if necessary, encrypt C with A and then B
- for yet more output. Still more output can be produced by reversing
- the order of the keys given above to stretch things. The same can be
- done with the hash functions by hashing various subsets of the input
- data to produce multiple outputs. But keep in mind that it is
- impossible to get more bits of "randomness" out than are put in.
-
- An example of using a strong mixing function would be to reconsider
- the case of a string of 308 bits each of which is biased 99% towards
- zero. The parity technique given in Section 5.2.1 above reduced this
- to one bit with only a 1/1000 deviance from being equally likely a
- zero or one. But, applying the equation for information given in
- Section 2, this 308 bit sequence has 5 bits of information in it.
- Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the
- result would yield 5 unbiased random bits as opposed to the single
- bit given by calculating the parity of the string.
-
-6.1.3 Diffie-Hellman as a Mixing Function
-
- Diffie-Hellman exponential key exchange is a technique that yields a
- shared secret between two parties that can be made computationally
- infeasible for a third party to determine even if they can observe
- all the messages between the two communicating parties. This shared
- secret is a mixture of initial quantities generated by each of them
- [D-H]. If these initial quantities are random, then the shared
- secret contains the combined randomness of them both, assuming they
- are uncorrelated.
-
-6.1.4 Using a Mixing Function to Stretch Random Bits
-
- While it is not necessary for a mixing function to produce the same
- or fewer bits than its inputs, mixing bits cannot "stretch" the
- amount of random unpredictability present in the inputs. Thus four
- inputs of 32 bits each where there is 12 bits worth of
- unpredicatability (such as 4,096 equally probable values) in each
- input cannot produce more than 48 bits worth of unpredictable output.
- The output can be expanded to hundreds or thousands of bits by, for
- example, mixing with successive integers, but the clever adversary's
-
-
-
-Eastlake, Crocker & Schiller [Page 17]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- search space is still 2^48 possibilities. Furthermore, mixing to
- fewer bits than are input will tend to strengthen the randomness of
- the output the way using Exclusive Or to produce one bit from two did
- above.
-
- The last table in Section 6.1.1 shows that mixing a random bit with a
- constant bit with Exclusive Or will produce a random bit. While this
- is true, it does not provide a way to "stretch" one random bit into
- more than one. If, for example, a random bit is mixed with a 0 and
- then with a 1, this produces a two bit sequence but it will always be
- either 01 or 10. Since there are only two possible values, there is
- still only the one bit of original randomness.
-
-6.1.5 Other Factors in Choosing a Mixing Function
-
- For local use, DES has the advantages that it has been widely tested
- for flaws, is widely documented, and is widely implemented with
- hardware and software implementations available all over the world
- including source code available by anonymous FTP. The SHS and MD*
- family are younger algorithms which have been less tested but there
- is no particular reason to believe they are flawed. Both MD5 and SHS
- were derived from the earlier MD4 algorithm. They all have source
- code available by anonymous FTP [SHS, MD2, MD4, MD5].
-
- DES and SHS have been vouched for the the US National Security Agency
- (NSA) on the basis of criteria that primarily remain secret. While
- this is the cause of much speculation and doubt, investigation of DES
- over the years has indicated that NSA involvement in modifications to
- its design, which originated with IBM, was primarily to strengthen
- it. No concealed or special weakness has been found in DES. It is
- almost certain that the NSA modification to MD4 to produce the SHS
- similarly strengthened the algorithm, possibly against threats not
- yet known in the public cryptographic community.
-
- DES, SHS, MD4, and MD5 are royalty free for all purposes. MD2 has
- been freely licensed only for non-profit use in connection with
- Privacy Enhanced Mail [PEM]. Between the MD* algorithms, some people
- believe that, as with "Goldilocks and the Three Bears", MD2 is strong
- but too slow, MD4 is fast but too weak, and MD5 is just right.
-
- Another advantage of the MD* or similar hashing algorithms over
- encryption algorithms is that they are not subject to the same
- regulations imposed by the US Government prohibiting the unlicensed
- export or import of encryption/decryption software and hardware. The
- same should be true of DES rigged to produce an irreversible hash
- code but most DES packages are oriented to reversible encryption.
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 18]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-6.2 Non-Hardware Sources of Randomness
-
- The best source of input for mixing would be a hardware randomness
- such as disk drive timing affected by air turbulence, audio input
- with thermal noise, or radioactive decay. However, if that is not
- available there are other possibilities. These include system
- clocks, system or input/output buffers, user/system/hardware/network
- serial numbers and/or addresses and timing, and user input.
- Unfortunately, any of these sources can produce limited or
- predicatable values under some circumstances.
-
- Some of the sources listed above would be quite strong on multi-user
- systems where, in essence, each user of the system is a source of
- randomness. However, on a small single user system, such as a
- typical IBM PC or Apple Macintosh, it might be possible for an
- adversary to assemble a similar configuration. This could give the
- adversary inputs to the mixing process that were sufficiently
- correlated to those used originally as to make exhaustive search
- practical.
-
- The use of multiple random inputs with a strong mixing function is
- recommended and can overcome weakness in any particular input. For
- example, the timing and content of requested "random" user keystrokes
- can yield hundreds of random bits but conservative assumptions need
- to be made. For example, assuming a few bits of randomness if the
- inter-keystroke interval is unique in the sequence up to that point
- and a similar assumption if the key hit is unique but assuming that
- no bits of randomness are present in the initial key value or if the
- timing or key value duplicate previous values. The results of mixing
- these timings and characters typed could be further combined with
- clock values and other inputs.
-
- This strategy may make practical portable code to produce good random
- numbers for security even if some of the inputs are very weak on some
- of the target systems. However, it may still fail against a high
- grade attack on small single user systems, especially if the
- adversary has ever been able to observe the generation process in the
- past. A hardware based random source is still preferable.
-
-6.3 Cryptographically Strong Sequences
-
- In cases where a series of random quantities must be generated, an
- adversary may learn some values in the sequence. In general, they
- should not be able to predict other values from the ones that they
- know.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 19]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- The correct technique is to start with a strong random seed, take
- cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and
- do not reveal the complete state of the generator in the sequence
- elements. If each value in the sequence can be calculated in a fixed
- way from the previous value, then when any value is compromised, all
- future values can be determined. This would be the case, for
- example, if each value were a constant function of the previously
- used values, even if the function were a very strong, non-invertible
- message digest function.
-
- It should be noted that if your technique for generating a sequence
- of key values is fast enough, it can trivially be used as the basis
- for a confidentiality system. If two parties use the same sequence
- generating technique and start with the same seed material, they will
- generate identical sequences. These could, for example, be xor'ed at
- one end with data being send, encrypting it, and xor'ed with this
- data as received, decrypting it due to the reversible properties of
- the xor operation.
-
-6.3.1 Traditional Strong Sequences
-
- A traditional way to achieve a strong sequence has been to have the
- values be produced by hashing the quantities produced by
- concatenating the seed with successive integers or the like and then
- mask the values obtained so as to limit the amount of generator state
- available to the adversary.
-
- It may also be possible to use an "encryption" algorithm with a
- random key and seed value to encrypt and feedback some or all of the
- output encrypted value into the value to be encrypted for the next
- iteration. Appropriate feedback techniques will usually be
- recommended with the encryption algorithm. An example is shown below
- where shifting and masking are used to combine the cypher output
- feedback. This type of feedback is recommended by the US Government
- in connection with DES [DES MODES].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 20]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- +---------------+
- | V |
- | | n |
- +--+------------+
- | | +---------+
- | +---------> | | +-----+
- +--+ | Encrypt | <--- | Key |
- | +-------- | | +-----+
- | | +---------+
- V V
- +------------+--+
- | V | |
- | n+1 |
- +---------------+
-
- Note that if a shift of one is used, this is the same as the shift
- register technique described in Section 3 above but with the all
- important difference that the feedback is determined by a complex
- non-linear function of all bits rather than a simple linear or
- polynomial combination of output from a few bit position taps.
-
- It has been shown by Donald W. Davies that this sort of shifted
- partial output feedback significantly weakens an algorithm compared
- will feeding all of the output bits back as input. In particular,
- for DES, repeated encrypting a full 64 bit quantity will give an
- expected repeat in about 2^63 iterations. Feeding back anything less
- than 64 (and more than 0) bits will give an expected repeat in
- between 2**31 and 2**32 iterations!
-
- To predict values of a sequence from others when the sequence was
- generated by these techniques is equivalent to breaking the
- cryptosystem or inverting the "non-invertible" hashing involved with
- only partial information available. The less information revealed
- each iteration, the harder it will be for an adversary to predict the
- sequence. Thus it is best to use only one bit from each value. It
- has been shown that in some cases this makes it impossible to break a
- system even when the cryptographic system is invertible and can be
- broken if all of each generated value was revealed.
-
-6.3.2 The Blum Blum Shub Sequence Generator
-
- Currently the generator which has the strongest public proof of
- strength is called the Blum Blum Shub generator after its inventors
- [BBS]. It is also very simple and is based on quadratic residues.
- It's only disadvantage is that is is computationally intensive
- compared with the traditional techniques give in 6.3.1 above. This
- is not a serious draw back if it is used for moderately infrequent
- purposes, such as generating session keys.
-
-
-
-Eastlake, Crocker & Schiller [Page 21]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- Simply choose two large prime numbers, say p and q, which both have
- the property that you get a remainder of 3 if you divide them by 4.
- Let n = p * q. Then you choose a random number x relatively prime to
- n. The initial seed for the generator and the method for calculating
- subsequent values are then
-
- 2
- s = ( x )(Mod n)
- 0
-
- 2
- s = ( s )(Mod n)
- i+1 i
-
- You must be careful to use only a few bits from the bottom of each s.
- It is always safe to use only the lowest order bit. If you use no
- more than the
-
- log ( log ( s ) )
- 2 2 i
-
- low order bits, then predicting any additional bits from a sequence
- generated in this manner is provable as hard as factoring n. As long
- as the initial x is secret, you can even make n public if you want.
-
- An intersting characteristic of this generator is that you can
- directly calculate any of the s values. In particular
-
- i
- ( ( 2 )(Mod (( p - 1 ) * ( q - 1 )) ) )
- s = ( s )(Mod n)
- i 0
-
- This means that in applications where many keys are generated in this
- fashion, it is not necessary to save them all. Each key can be
- effectively indexed and recovered from that small index and the
- initial s and n.
-
-7. Key Generation Standards
-
- Several public standards are now in place for the generation of keys.
- Two of these are described below. Both use DES but any equally
- strong or stronger mixing function could be substituted.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 22]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-7.1 US DoD Recommendations for Password Generation
-
- The United States Department of Defense has specific recommendations
- for password generation [DoD]. They suggest using the US Data
- Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
- follows:
-
- use an initialization vector determined from
- the system clock,
- system ID,
- user ID, and
- date and time;
- use a key determined from
- system interrupt registers,
- system status registers, and
- system counters; and,
- as plain text, use an external randomly generated 64 bit
- quantity such as 8 characters typed in by a system
- administrator.
-
- The password can then be calculated from the 64 bit "cipher text"
- generated in 64-bit Output Feedback Mode. As many bits as are needed
- can be taken from these 64 bits and expanded into a pronounceable
- word, phrase, or other format if a human being needs to remember the
- password.
-
-7.2 X9.17 Key Generation
-
- The American National Standards Institute has specified a method for
- generating a sequence of keys as follows:
-
- s is the initial 64 bit seed
- 0
-
- g is the sequence of generated 64 bit key quantities
- n
-
- k is a random key reserved for generating this key sequence
-
- t is the time at which a key is generated to as fine a resolution
- as is available (up to 64 bits).
-
- DES ( K, Q ) is the DES encryption of quantity Q with key K
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 23]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- g = DES ( k, DES ( k, t ) .xor. s )
- n n
-
- s = DES ( k, DES ( k, t ) .xor. g )
- n+1 n
-
- If g sub n is to be used as a DES key, then every eighth bit should
- be adjusted for parity for that use but the entire 64 bit unmodified
- g should be used in calculating the next s.
-
-8. Examples of Randomness Required
-
- Below are two examples showing rough calculations of needed
- randomness for security. The first is for moderate security
- passwords while the second assumes a need for a very high security
- cryptographic key.
-
-8.1 Password Generation
-
- Assume that user passwords change once a year and it is desired that
- the probability that an adversary could guess the password for a
- particular account be less than one in a thousand. Further assume
- that sending a password to the system is the only way to try a
- password. Then the crucial question is how often an adversary can
- try possibilities. Assume that delays have been introduced into a
- system so that, at most, an adversary can make one password try every
- six seconds. That's 600 per hour or about 15,000 per day or about
- 5,000,000 tries in a year. Assuming any sort of monitoring, it is
- unlikely someone could actually try continuously for a year. In
- fact, even if log files are only checked monthly, 500,000 tries is
- more plausible before the attack is noticed and steps taken to change
- passwords and make it harder to try more passwords.
-
- To have a one in a thousand chance of guessing the password in
- 500,000 tries implies a universe of at least 500,000,000 passwords or
- about 2^29. Thus 29 bits of randomness are needed. This can probably
- be achieved using the US DoD recommended inputs for password
- generation as it has 8 inputs which probably average over 5 bits of
- randomness each (see section 7.1). Using a list of 1000 words, the
- password could be expressed as a three word phrase (1,000,000,000
- possibilities) or, using case insensitive letters and digits, six
- would suffice ((26+10)^6 = 2,176,782,336 possibilities).
-
- For a higher security password, the number of bits required goes up.
- To decrease the probability by 1,000 requires increasing the universe
- of passwords by the same factor which adds about 10 bits. Thus to
- have only a one in a million chance of a password being guessed under
- the above scenario would require 39 bits of randomness and a password
-
-
-
-Eastlake, Crocker & Schiller [Page 24]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- that was a four word phrase from a 1000 word list or eight
- letters/digits. To go to a one in 10^9 chance, 49 bits of randomness
- are needed implying a five word phrase or ten letter/digit password.
-
- In a real system, of course, there are also other factors. For
- example, the larger and harder to remember passwords are, the more
- likely users are to write them down resulting in an additional risk
- of compromise.
-
-8.2 A Very High Security Cryptographic Key
-
- Assume that a very high security key is needed for symmetric
- encryption / decryption between two parties. Assume an adversary can
- observe communications and knows the algorithm being used. Within
- the field of random possibilities, the adversary can try key values
- in hopes of finding the one in use. Assume further that brute force
- trial of keys is the best the adversary can do.
-
-8.2.1 Effort per Key Trial
-
- How much effort will it take to try each key? For very high security
- applications it is best to assume a low value of effort. Even if it
- would clearly take tens of thousands of computer cycles or more to
- try a single key, there may be some pattern that enables huge blocks
- of key values to be tested with much less effort per key. Thus it is
- probably best to assume no more than a couple hundred cycles per key.
- (There is no clear lower bound on this as computers operate in
- parallel on a number of bits and a poor encryption algorithm could
- allow many keys or even groups of keys to be tested in parallel.
- However, we need to assume some value and can hope that a reasonably
- strong algorithm has been chosen for our hypothetical high security
- task.)
-
- If the adversary can command a highly parallel processor or a large
- network of work stations, 2*10^10 cycles per second is probably a
- minimum assumption for availability today. Looking forward just a
- couple years, there should be at least an order of magnitude
- improvement. Thus assuming 10^9 keys could be checked per second or
- 3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
- reasonable. This implies a need for a minimum of 51 bits of
- randomness in keys to be sure they cannot be found in a month. Even
- then it is possible that, a few years from now, a highly determined
- and resourceful adversary could break the key in 2 weeks (on average
- they need try only half the keys).
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 25]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-8.2.2 Meet in the Middle Attacks
-
- If chosen or known plain text and the resulting encrypted text are
- available, a "meet in the middle" attack is possible if the structure
- of the encryption algorithm allows it. (In a known plain text
- attack, the adversary knows all or part of the messages being
- encrypted, possibly some standard header or trailer fields. In a
- chosen plain text attack, the adversary can force some chosen plain
- text to be encrypted, possibly by "leaking" an exciting text that
- would then be sent by the adversary over an encrypted channel.)
-
- An oversimplified explanation of the meet in the middle attack is as
- follows: the adversary can half-encrypt the known or chosen plain
- text with all possible first half-keys, sort the output, then half-
- decrypt the encoded text with all the second half-keys. If a match
- is found, the full key can be assembled from the halves and used to
- decrypt other parts of the message or other messages. At its best,
- this type of attack can halve the exponent of the work required by
- the adversary while adding a large but roughly constant factor of
- effort. To be assured of safety against this, a doubling of the
- amount of randomness in the key to a minimum of 102 bits is required.
-
- The meet in the middle attack assumes that the cryptographic
- algorithm can be decomposed in this way but we can not rule that out
- without a deep knowledge of the algorithm. Even if a basic algorithm
- is not subject to a meet in the middle attack, an attempt to produce
- a stronger algorithm by applying the basic algorithm twice (or two
- different algorithms sequentially) with different keys may gain less
- added security than would be expected. Such a composite algorithm
- would be subject to a meet in the middle attack.
-
- Enormous resources may be required to mount a meet in the middle
- attack but they are probably within the range of the national
- security services of a major nation. Essentially all nations spy on
- other nations government traffic and several nations are believed to
- spy on commercial traffic for economic advantage.
-
-8.2.3 Other Considerations
-
- Since we have not even considered the possibilities of special
- purpose code breaking hardware or just how much of a safety margin we
- want beyond our assumptions above, probably a good minimum for a very
- high security cryptographic key is 128 bits of randomness which
- implies a minimum key length of 128 bits. If the two parties agree
- on a key by Diffie-Hellman exchange [D-H], then in principle only
- half of this randomness would have to be supplied by each party.
- However, there is probably some correlation between their random
- inputs so it is probably best to assume that each party needs to
-
-
-
-Eastlake, Crocker & Schiller [Page 26]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- provide at least 96 bits worth of randomness for very high security
- if Diffie-Hellman is used.
-
- This amount of randomness is beyond the limit of that in the inputs
- recommended by the US DoD for password generation and could require
- user typing timing, hardware random number generation, or other
- sources.
-
- It should be noted that key length calculations such at those above
- are controversial and depend on various assumptions about the
- cryptographic algorithms in use. In some cases, a professional with
- a deep knowledge of code breaking techniques and of the strength of
- the algorithm in use could be satisfied with less than half of the
- key size derived above.
-
-9. Conclusion
-
- Generation of unguessable "random" secret quantities for security use
- is an essential but difficult task.
-
- We have shown that hardware techniques to produce such randomness
- would be relatively simple. In particular, the volume and quality
- would not need to be high and existing computer hardware, such as
- disk drives, can be used. Computational techniques are available to
- process low quality random quantities from multiple sources or a
- larger quantity of such low quality input from one source and produce
- a smaller quantity of higher quality, less predictable key material.
- In the absence of hardware sources of randomness, a variety of user
- and software sources can frequently be used instead with care;
- however, most modern systems already have hardware, such as disk
- drives or audio input, that could be used to produce high quality
- randomness.
-
- Once a sufficient quantity of high quality seed key material (a few
- hundred bits) is available, strong computational techniques are
- available to produce cryptographically strong sequences of
- unpredicatable quantities from this seed material.
-
-10. Security Considerations
-
- The entirety of this document concerns techniques and recommendations
- for generating unguessable "random" quantities for use as passwords,
- cryptographic keys, and similar security uses.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 27]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-References
-
- [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems,
- edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview
- Press, Inc.
-
- [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM
- Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub.
-
- [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day,
- 1981, David Brillinger.
-
- [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber
- Publishing Company.
-
- [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication,
- John Wiley & Sons, 1981, Alan G. Konheim.
-
- [CRYPTO2] - Cryptography: A New Dimension in Computer Data Security,
- A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H.
- Meyer & Stephen M. Matyas.
-
- [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source
- Code in C, John Wiley & Sons, 1994, Bruce Schneier.
-
- [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
- Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
- Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
- Philip Fenstermacher.
-
- [DES] - Data Encryption Standard, United States of America,
- Department of Commerce, National Institute of Standards and
- Technology, Federal Information Processing Standard (FIPS) 46-1.
- - Data Encryption Algorithm, American National Standards Institute,
- ANSI X3.92-1981.
- (See also FIPS 112, Password Usage, which includes FORTRAN code for
- performing DES.)
-
- [DES MODES] - DES Modes of Operation, United States of America,
- Department of Commerce, National Institute of Standards and
- Technology, Federal Information Processing Standard (FIPS) 81.
- - Data Encryption Algorithm - Modes of Operation, American National
- Standards Institute, ANSI X3.106-1983.
-
- [D-H] - New Directions in Cryptography, IEEE Transactions on
- Information Technology, November, 1976, Whitfield Diffie and Martin
- E. Hellman.
-
-
-
-
-Eastlake, Crocker & Schiller [Page 28]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- [DoD] - Password Management Guideline, United States of America,
- Department of Defense, Computer Security Center, CSC-STD-002-85.
- (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85
- as one of its appendices.)
-
- [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988,
- David K. Gifford
-
- [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical
- Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing
- Company, Second Edition 1982, Donald E. Knuth.
-
- [KRAWCZYK] - How to Predict Congruential Generators, Journal of
- Algorithms, V. 13, N. 4, December 1992, H. Krawczyk
-
- [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B.
- Kaliski
- [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R.
- Rivest
- [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R.
- Rivest
-
- [PEM] - RFCs 1421 through 1424:
- - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part
- IV: Key Certification and Related Services, 02/10/1993, B. Kaliski
- - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part
- III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson
- - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part
- II: Certificate-Based Key Management, 02/10/1993, S. Kent
- - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I:
- Message Encryption and Authentication Procedures, 02/10/1993, J. Linn
-
- [SHANNON] - The Mathematical Theory of Communication, University of
- Illinois Press, 1963, Claude E. Shannon. (originally from: Bell
- System Technical Journal, July and October 1948)
-
- [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised
- Edition 1982, Solomon W. Golomb.
-
- [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher
- Systems, Aegean Park Press, 1984, Wayne G. Barker.
-
- [SHS] - Secure Hash Standard, United States of American, National
- Institute of Science and Technology, Federal Information Processing
- Standard (FIPS) 180, April 1993.
-
- [STERN] - Secret Linear Congruential Generators are not
- Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern.
-
-
-
-Eastlake, Crocker & Schiller [Page 29]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- [VON NEUMANN] - Various techniques used in connection with random
- digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963,
- J. von Neumann.
-
-Authors' Addresses
-
- Donald E. Eastlake 3rd
- Digital Equipment Corporation
- 550 King Street, LKG2-1/BB3
- Littleton, MA 01460
-
- Phone: +1 508 486 6577(w) +1 508 287 4877(h)
- EMail: dee@lkg.dec.com
-
-
- Stephen D. Crocker
- CyberCash Inc.
- 2086 Hunters Crest Way
- Vienna, VA 22181
-
- Phone: +1 703-620-1222(w) +1 703-391-2651 (fax)
- EMail: crocker@cybercash.com
-
-
- Jeffrey I. Schiller
- Massachusetts Institute of Technology
- 77 Massachusetts Avenue
- Cambridge, MA 02139
-
- Phone: +1 617 253 0161(w)
- EMail: jis@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 30]
-
diff --git a/doc/standardisation/rfc1964.txt b/doc/standardisation/rfc1964.txt
deleted file mode 100644
index f2960b961dd698f4f001873187dbf69ffd1c95bd..0000000000000000000000000000000000000000
--- a/doc/standardisation/rfc1964.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Linn
-Request for Comments: 1964 OpenVision Technologies
-Category: Standards Track June 1996
-
-
- The Kerberos Version 5 GSS-API Mechanism
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-ABSTRACT
-
- This specification defines protocols, procedures, and conventions to
- be employed by peers implementing the Generic Security Service
- Application Program Interface (as specified in RFCs 1508 and 1509)
- when using Kerberos Version 5 technology (as specified in RFC 1510).
-
-ACKNOWLEDGMENTS
-
- Much of the material in this memo is based on working documents
- drafted by John Wray of Digital Equipment Corporation and on
- discussions, implementation activities, and interoperability testing
- involving Marc Horowitz, Ted Ts'o, and John Wray. Particular thanks
- are due to each of these individuals for their contributions towards
- development and availability of GSS-API support within the Kerberos
- Version 5 code base.
-
-1. Token Formats
-
- This section discusses protocol-visible characteristics of the GSS-
- API mechanism to be implemented atop Kerberos V5 security technology
- per RFC-1508 and RFC-1510; it defines elements of protocol for
- interoperability and is independent of language bindings per RFC-
- 1509.
-
- Tokens transferred between GSS-API peers (for security context
- management and per-message protection purposes) are defined. The
- data elements exchanged between a GSS-API endpoint implementation and
- the Kerberos KDC are not specific to GSS-API usage and are therefore
- defined within RFC-1510 rather than within this specification.
-
-
-
-
-
-
-Linn Standards Track [Page 1]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- To support ongoing experimentation, testing, and evolution of the
- specification, the Kerberos V5 GSS-API mechanism as defined in this
- and any successor memos will be identified with the following Object
- Identifier, as defined in RFC-1510, until the specification is
- advanced to the level of Proposed Standard RFC:
-
- {iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)}
-
- Upon advancement to the level of Proposed Standard RFC, the Kerberos
- V5 GSS-API mechanism will be identified by an Object Identifier
- having the value:
-
- {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
- gssapi(2) krb5(2)}
-
-1.1. Context Establishment Tokens
-
- Per RFC-1508, Appendix B, the initial context establishment token
- will be enclosed within framing as follows:
-
- 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 of the initial context token will consist of a
- Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id
- (TOK_ID) field, which shall contain the value 01 00.
-
- The above GSS-API framing shall be applied to all tokens emitted by
- the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
- context-deletion, and per-message tokens, not just to the initial
- token in a context establishment sequence. While not required by
- RFC-1508, this enables implementations to perform enhanced error-
- checking. The innerContextToken field of context establishment tokens
- for the Kerberos V5 GSS-API mechanism will contain a Kerberos message
- (KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID
- field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP
- messages and 03 00 for KRB_ERROR messages.
-
-
-
-
-
-
-Linn Standards Track [Page 2]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
-1.1.1. Initial Token
-
- Relevant KRB_AP_REQ syntax (from RFC-1510) is as follows:
-
- AP-REQ ::= [APPLICATION 14] SEQUENCE {
- pvno [0] INTEGER, -- indicates Version 5
- msg-type [1] INTEGER, -- indicates KRB_AP_REQ
- ap-options[2] APOptions,
- ticket[3] Ticket,
- authenticator[4] EncryptedData
- }
-
- APOptions ::= BIT STRING {
- reserved (0),
- use-session-key (1),
- mutual-required (2)
- }
-
- Ticket ::= [APPLICATION 1] SEQUENCE {
- tkt-vno [0] INTEGER, -- indicates Version 5
- realm [1] Realm,
- sname [2] PrincipalName,
- enc-part [3] EncryptedData
- }
-
- -- 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
- }
-
- -- 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,
-
-
-
-Linn Standards Track [Page 3]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- subkey[6] EncryptionKey OPTIONAL,
- seq-number[7] INTEGER OPTIONAL,
- authorization-data[8] AuthorizationData OPTIONAL
- }
-
- For purposes of this specification, the authenticator shall include
- the optional sequence number, and the checksum field shall be used to
- convey channel binding, service flags, and optional delegation
- information. The checksum will have a type of 0x8003 (a value being
- registered within the Kerberos protocol specification), and a value
- field of at least 24 bytes in length. The length of the value field
- is extended beyond 24 bytes if and only if an optional facility to
- carry a Kerberos-defined KRB_CRED message for delegation purposes is
- supported by an implementation and active on a context. When
- delegation is active, a TGT with its FORWARDABLE flag set will be
- transferred within the KRB_CRED message.
-
- The checksum value field's format is as follows:
-
- Byte Name Description
- 0..3 Lgth Number of bytes in Bnd field;
- Currently contains hex 10 00 00 00
- (16, represented in little-endian form)
- 4..19 Bnd MD5 hash of channel bindings, taken over all non-null
- components of bindings, in order of declaration.
- Integer fields within channel bindings are represented
- in little-endian order for the purposes of the MD5
- calculation.
- 20..23 Flags Bit vector of context-establishment flags,
- with values consistent with RFC-1509, p. 41:
- GSS_C_DELEG_FLAG: 1
- GSS_C_MUTUAL_FLAG: 2
- GSS_C_REPLAY_FLAG: 4
- GSS_C_SEQUENCE_FLAG: 8
- GSS_C_CONF_FLAG: 16
- GSS_C_INTEG_FLAG: 32
- The resulting bit vector is encoded into bytes 20..23
- in little-endian form.
- 24..25 DlgOpt The Delegation Option identifier (=1) [optional]
- 26..27 Dlgth The length of the Deleg field. [optional]
- 28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional]
-
- In computing the contents of the "Bnd" field, the following detailed
- points apply:
-
- (1) Each integer field shall be formatted into four bytes, using
- little-endian byte ordering, for purposes of MD5 hash
- computation.
-
-
-
-Linn Standards Track [Page 4]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- (2) All input length fields within gss_buffer_desc elements of a
- gss_channel_bindings_struct, even those which are zero-valued,
- shall be included in the hash calculation; the value elements of
- gss_buffer_desc elements shall be dereferenced, and the
- resulting data shall be included within the hash computation,
- only for the case of gss_buffer_desc elements having non-zero
- length specifiers.
-
- (3) If the caller passes the value GSS_C_NO_BINDINGS instead of
- a valid channel bindings structure, the Bnd field shall be set
- to 16 zero-valued bytes.
-
- In the initial Kerberos V5 GSS-API mechanism token (KRB_AP_REQ token)
- from initiator to target, the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG,
- GSS_C_REPLAY_FLAG, and GSS_C_SEQUENCE_FLAG values shall each be set
- as the logical AND of the initiator's corresponding request flag to
- GSS_Init_sec_context() and a Boolean indicator of whether that
- optional service is available to GSS_Init_sec_context()'s caller.
- GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG, for which no corresponding
- context-level input indicator flags to GSS_Init_sec_context() exist,
- shall each be set to indicate whether their respective per-message
- protection services are available for use on the context being
- established.
-
- When input source address channel binding values are provided by a
- caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or the
- source address specifier value within the input structure is
- GSS_C_NULL_ADDRTYPE), and the corresponding token received from the
- context's peer bears address restrictions, it is recommended that an
- implementation of the Kerberos V5 GSS-API mechanism should check that
- the source address as provided by the caller matches that in the
- received token, and should return the GSS_S_BAD_BINDINGS major_status
- value if a mismatch is detected. Note: discussion is ongoing about
- the strength of recommendation to be made in this area, and on the
- circumstances under which such a recommendation should be applicable;
- implementors are therefore advised that changes on this matter may be
- included in subsequent versions of this specification.
-
-1.1.2. Response Tokens
-
- A context establishment sequence based on the Kerberos V5 mechanism
- will perform one-way authentication (without confirmation or any
- return token from target to initiator in response to the initiator's
- KRB_AP_REQ) if the mutual_req bit is not set in the application's
- call to GSS_Init_sec_context(). Applications requiring confirmation
- that their authentication was successful should request mutual
- authentication, resulting in a "mutual-required" indication within
- KRB_AP_REQ APoptions and the setting of the mutual_req bit in the
-
-
-
-Linn Standards Track [Page 5]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- flags field of the authenticator checksum. In response to such a
- request, the context target will reply to the initiator with a token
- containing either a KRB_AP_REP or KRB_ERROR, completing the mutual
- context establishment exchange.
-
- Relevant KRB_AP_REP syntax is as follows:
-
- AP-REP ::= [APPLICATION 15] SEQUENCE {
- pvno [0] INTEGER, -- represents Kerberos V5
- msg-type [1] INTEGER, -- represents KRB_AP_REP
- enc-part [2] EncryptedData
- }
-
- EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
- ctime [0] KerberosTime,
- cusec [1] INTEGER,
- subkey [2] EncryptionKey OPTIONAL,
- seq-number [3] INTEGER OPTIONAL
- }
-
- The optional seq-number element within the AP-REP's EncAPRepPart
- shall be included.
-
- The syntax of KRB_ERROR is as follows:
-
- 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
- }
-
- Values to be transferred in the error-code field of a KRB-ERROR
- message are defined in [RFC-1510], not in this specification.
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 6]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
-1.2. Per-Message and Context Deletion Tokens
-
- Three classes of tokens are defined in this section: "MIC" tokens,
- emitted by calls to GSS_GetMIC() (formerly GSS_Sign()) and consumed
- by calls to GSS_VerifyMIC() (formerly GSS_Verify()), "Wrap" tokens,
- emitted by calls to GSS_Wrap() (formerly GSS_Seal()) and consumed by
- calls to GSS_Unwrap() (formerly GSS_Unseal()), and context deletion
- tokens, emitted by calls to GSS_Delete_sec_context() and consumed by
- calls to GSS_Process_context_token(). Note: References to GSS-API
- per-message routines in the remainder of this specification will be
- based on those routines' newer recommended names rather than those
- names' predecessors.
-
- Several variants of cryptographic keys are used in generation and
- processing of per-message tokens:
-
- (1) context key: uses Kerberos session key (or subkey, if
- present in authenticator emitted by context initiator) directly
-
- (2) confidentiality key: forms variant of context key by
- exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0.
-
- (3) MD2.5 seed key: forms variant of context key by reversing
- the bytes of the context key (i.e. if the original key is the
- 8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed key
- will be {hh, gg, ff, ee, dd, cc, bb, aa}).
-
-1.2.1. Per-message Tokens - MIC
-
-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 as received. The token has the following format:
-
- Byte no Name Description
- 0..1 TOK_ID Identification field.
- Tokens emitted by GSS_GetMIC() contain
- the hex value 01 01 in this field.
- 2..3 SGN_ALG Integrity algorithm indicator.
- 00 00 - DES MAC MD5
- 01 00 - MD2.5
- 02 00 - DES MAC
- 4..7 Filler Contains ff ff ff ff
- 8..15 SND_SEQ Sequence number field.
- 16..23 SGN_CKSUM Checksum of "to-be-signed data",
- calculated according to algorithm
- specified in SGN_ALG field.
-
-
-
-
-
-Linn Standards Track [Page 7]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- GSS-API tokens must be encapsulated within the higher-level protocol
- by the application; no embedded length field is necessary.
-
-1.2.1.1. Checksum
-
- Checksum calculation procedure (common to all algorithms): Checksums
- are calculated over the data field, logically prepended by the first
- 8 bytes of the plaintext packet header. The resulting value binds
- the data to the packet type and signature algorithm identifier
- fields.
-
- DES MAC MD5 algorithm: The checksum is formed by computing an MD5
- [RFC-1321] hash over the plaintext data, and then computing a DES-CBC
- MAC on the 16-byte MD5 result. A standard 64-bit DES-CBC MAC is
- computed per [FIPS-PUB-113], employing the context key and a zero IV.
- The 8-byte result is stored in the SGN_CKSUM field.
-
- MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
- 16-byte zero-block, using a zero IV and a key formed by reversing the
- bytes of the context key (i.e. if the original key is the 8-byte
- sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
- {hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
- logically prepended to the to-be-signed data. A standard MD5
- checksum is calculated over the combined data, and the first 8 bytes
- of the result are stored in the SGN_CKSUM field. Note 1: we refer to
- this algorithm informally as "MD2.5" to connote the fact that it uses
- half of the 128 bits generated by MD5; use of only a subset of the
- MD5 bits is intended to protect against the prospect that data could
- be postfixed to an existing message with corresponding modifications
- being made to the checksum. Note 2: This algorithm is fairly novel
- and has received more limited evaluation than that to which other
- integrity algorithms have been subjected. An initial, limited
- evaluation indicates that it may be significantly weaker than DES MAC
- MD5.
-
- DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
- plaintext data per [FIPS-PUB-113], employing the context key and a
- zero IV. Padding procedures to accomodate plaintext data lengths
- which may not be integral multiples of 8 bytes are defined in [FIPS-
- PUB-113]. The result is an 8-byte value, which is stored in the
- SGN_CKSUM field. Support for this algorithm may not be present in
- all implementations.
-
-1.2.1.2. Sequence Number
-
- Sequence number field: The 8 byte plaintext sequence number field is
- formed from the sender's four-byte sequence number as follows. If
- the four bytes of the sender's sequence number are named s0, s1, s2
-
-
-
-Linn Standards Track [Page 8]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- and s3 (from least to most significant), the plaintext sequence
- number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
- di), where 'di' is the direction-indicator (Hex 0 - sender is the
- context initiator, Hex FF - sender is the context acceptor). The
- field is then DES-CBC encrypted using the context key and an IV
- formed from the first 8 bytes of the previously calculated SGN_CKSUM
- field. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
- sequence number is incremented by one.
-
- The receiver of the token will first verify the SGN_CKSUM field. If
- valid, the sequence number field may be decrypted and compared to the
- expected sequence number. The repetition of the (effectively 1-bit)
- direction indicator within the sequence number field provides
- redundancy so that the receiver may verify that the decryption
- succeeded.
-
- Since the checksum computation is used as an IV to the sequence
- number decryption, attempts to splice a checksum and sequence number
- from different messages will be detected. The direction indicator
- will detect packets that have been maliciously reflected.
-
- The sequence number provides a basis for detection of replayed
- tokens. Replay detection can be performed using state information
- retained on received sequence numbers, interpreted in conjunction
- with the security context on which they arrive.
-
- Provision of per-message replay and out-of-sequence detection
- services is optional for implementations of the Kerberos V5 GSS-API
- mechanism. Further, it is recommended that implementations of the
- Kerberos V5 GSS-API mechanism which offer these services should honor
- a caller's request that the services be disabled on a context.
- Specifically, if replay_det_req_flag is input FALSE, replay_det_state
- should be returned FALSE and the GSS_DUPLICATE_TOKEN and
- GSS_OLD_TOKEN stati should not be indicated as a result of duplicate
- detection when tokens are processed; if sequence_req_flag is input
- FALSE, sequence_state should be returned FALSE and
- GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN stati should
- not be indicated as a result of out-of-sequence detection when tokens
- are processed.
-
-1.2.2. Per-message Tokens - Wrap
-
- Use of the GSS_Wrap() call yields a token which encapsulates the
- input user data (optionally encrypted) along with associated
- integrity check quantities. The token emitted by GSS_Wrap() consists
- of an integrity header whose format is identical to that emitted by
- GSS_GetMIC() (except that the TOK_ID field contains the value 02 01),
- followed by a body portion that contains either the plaintext data
-
-
-
-Linn Standards Track [Page 9]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- (if SEAL_ALG = ff ff) or encrypted data for any other supported value
- of SEAL_ALG. Currently, only SEAL_ALG = 00 00 is supported, and
- means that DES-CBC encryption is being used to protect the data.
-
- The GSS_Wrap() token has the following format:
-
- 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.
- 00 00 - DES MAC MD5
- 01 00 - MD2.5
- 02 00 - DES MAC
- 4..5 SEAL_ALG ff ff - none
- 00 00 - DES
- 6..7 Filler Contains ff ff
- 8..15 SND_SEQ Encrypted sequence number field.
- 16..23 SGN_CKSUM Checksum of plaintext padded data,
- calculated according to algorithm
- specified in SGN_ALG field.
- 24..last Data encrypted or plaintext padded data
-
- GSS-API tokens must be encapsulated within the higher-level protocol
- by the application; no embedded length field is necessary.
-
-1.2.2.1. Checksum
-
- Checksum calculation procedure (common to all algorithms): Checksums
- are calculated over the plaintext padded data field, logically
- prepended by the first 8 bytes of the plaintext packet header. The
- resulting signature binds the data to the packet type, protocol
- version, and signature algorithm identifier fields.
-
- DES MAC MD5 algorithm: The checksum is formed by computing an MD5
- hash over the plaintext padded data, and then computing a DES-CBC MAC
- on the 16-byte MD5 result. A standard 64-bit DES-CBC MAC is computed
- per [FIPS-PUB-113], employing the context key and a zero IV. The 8-
- byte result is stored in the SGN_CKSUM field.
-
- MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
- 16-byte zero-block, using a zero IV and a key formed by reversing the
- bytes of the context key (i.e., if the original key is the 8-byte
- sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
- {hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
- logically pre-pended to the "to-be-signed data". A standard MD5
- checksum is calculated over the combined data, and the first 8 bytes
- of the result are stored in the SGN_CKSUM field.
-
-
-
-Linn Standards Track [Page 10]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
- plaintext padded data per [FIPS-PUB-113], employing the context key
- and a zero IV. The plaintext padded data is already assured to be an
- integral multiple of 8 bytes; no additional padding is required or
- applied in order to accomplish MAC calculation. The result is an 8-
- byte value, which is stored in the SGN_CKSUM field. Support for this
- lgorithm may not be present in all implementations.
-
-1.2.2.2. Sequence Number
-
- Sequence number field: The 8 byte plaintext sequence number field is
- formed from the sender's four-byte sequence number as follows. If
- the four bytes of the sender's sequence number are named s0, s1, s2
- and s3 (from least to most significant), the plaintext sequence
- number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
- di), where 'di' is the direction-indicator (Hex 0 - sender is the
- context initiator, Hex FF - sender is the context acceptor).
-
- The field is then DES-CBC encrypted using the context key and an IV
- formed from the first 8 bytes of the SEAL_CKSUM field.
-
- After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
- sequence numbers are incremented by one.
-
-1.2.2.3. Padding
-
- Data padding: Before encryption and/or signature calculation,
- plaintext data is padded to the next highest multiple of 8 bytes, by
- appending between 1 and 8 bytes, the value of each such byte being
- the total number of pad bytes. For example, given data of length 20
- bytes, four pad bytes will be appended, and each byte will contain
- the hex value 04. An 8-byte random confounder is prepended to the
- data, and signatures are calculated over the resulting padded
- plaintext.
-
- After padding, the data is encrypted according to the algorithm
- specified in the SEAL_ALG field. For SEAL_ALG=DES (the only non-null
- algorithm currently supported), the data is encrypted using DES-CBC,
- with an IV of zero. The key used is derived from the established
- context key by XOR-ing the context key with the hexadecimal constant
- f0f0f0f0f0f0f0f0.
-
-1.2.3. Context deletion token
-
- The token emitted by GSS_Delete_sec_context() is based on the packet
- format for tokens emitted by GSS_GetMIC(). The context-deletion
- token has the following format:
-
-
-
-
-Linn Standards Track [Page 11]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- Byte no Name Description
- 0..1 TOK_ID Identification field.
- Tokens emitted by
- GSS_Delete_sec_context() contain
- the hex value 01 02 in this field.
- 2..3 SGN_ALG Integrity algorithm indicator.
- 00 00 - DES MAC MD5
- 01 00 - MD2.5
- 02 00 - DES MAC
- 4..7 Filler Contains ff ff ff ff
- 8..15 SND_SEQ Sequence number field.
- 16..23 SGN_CKSUM Checksum of "to-be-signed data",
- calculated according to algorithm
- specified in SGN_ALG field.
-
- SGN_ALG and SND_SEQ will be calculated as for tokens emitted by
- GSS_GetMIC(). The SGN_CKSUM will be calculated as for tokens emitted
- by GSS_GetMIC(), except that the user-data component of the "to-be-
- signed" data will be a zero-length string.
-
-2. Name Types and Object Identifiers
-
- This section discusses the name types which may be passed as input to
- the Kerberos V5 GSS-API 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-1509. In addition to specifying OID values for name type
- identifiers, symbolic names are included and recommended to GSS-API
- implementors in the interests of convenience to callers. It is
- understood that not all implementations of the Kerberos V5 GSS-API
- 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 V5 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 GSS-API 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
-
-
-
-Linn Standards Track [Page 12]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- portability, implementors of mechanisms are encouraged to support
- name forms as defined in this section, even if their mechanisms are
- independent of Kerberos V5.
-
-2.1. Mandatory Name Forms
-
- This section discusses name forms which are to be supported by all
- conformant implementations of the Kerberos V5 GSS-API mechanism.
-
-2.1.1. Kerberos Principal Name Form
-
- This name form shall be represented by the Object Identifier {iso(1)
- member-body(2) United States(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 V5 implementation, such
- names are parseable with the krb5_parse_name() function.) The
- elements included within this name representation are as follows,
- proceeding 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.
-
-
-
-
-
-
-Linn Standards Track [Page 13]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- (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.
-
-2.1.2. Host-Based Service Name Form
-
- This name form has been incorporated at the mechanism-independent
- GSS-API level as of GSS-API, Version 2. This subsection retains the
- Object Identifier and symbolic name assignments previously made at
- the Kerberos V5 GSS-API mechanism level, and adopts the definition as
- promoted to the mechanism-independent level.
-
- This name form shall be represented by the Object Identifier {iso(1)
- member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- generic(1) service_name(4)}. The previously recommended symbolic
- name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME". The
- currently preferred symbolic name for this type is
- "GSS_C_NT_HOSTBASED_SERVICE".
-
- This name type is used to represent services associated with host
- computers. This name form is constructed using two elements,
- "service" and "hostname", as follows:
-
- service@hostname
-
- When a reference to a name of this type is resolved, the "hostname"
- is canonicalized by attempting a DNS lookup and using the fully-
- qualified domain name which is returned, or by using the "hostname"
- as provided if the DNS lookup fails. The canonicalization operation
- also maps the host's name into lower-case characters.
-
- The "hostname" element may be omitted. If no "@" separator is
- included, the entire name is interpreted as the service specifier,
- with the "hostname" defaulted to the canonicalized name of the local
- host.
-
- Values for the "service" element will be registered with the IANA.
-
-2.1.3. Exported Name Object Form for Kerberos V5 Mechanism
-
- Support for this name form is not required for GSS-V1
- implementations, but will be required for use in conjunction with the
- GSS_Export_name() call planned for GSS-API Version 2. Use of this
- name form will be signified by a "GSS-API Exported Name Object" OID
- value which will be defined at the mechanism-independent level for
-
-
-
-Linn Standards Track [Page 14]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- GSS-API Version 2.
-
- This name type represents a self-describing object, whose framing
- structure will be defined at the mechanism-independent level for
- GSS-API Version 2. When generated by the Kerberos V5 mechanism, the
- Mechanism OID within the exportable name shall be that of the
- Kerberos V5 mechanism. 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
- 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).
-
-2.2. Optional Name Forms
-
- This section discusses additional name forms which may optionally be
- supported by implementations of the Kerberos V5 GSS-API mechanism.
- It is recognized that some of the name forms cited here are derived
- from UNIX(tm) operating system platforms; some listed forms may be
- irrelevant to non-UNIX platforms, and definition of additional forms
- corresponding to such platforms may also be appropriate. It is also
- recognized that OS-specific functions outside GSS-API are likely to
- exist in order to perform translations among these forms, and that
- GSS-API implementations supporting these forms may themselves be
- layered atop such OS-specific functions. Inclusion of this support
- within GSS-API implementations is intended as a convenience to
- applications.
-
-2.2.1. User Name Form
-
- This name form shall be represented by the Object Identifier {iso(1)
- member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- generic(1) user_name(1)}. The recommended symbolic name for this
- type is "GSS_KRB5_NT_USER_NAME".
-
- This name type is used to indicate a named user on a local system.
-
-
-
-Linn Standards Track [Page 15]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- Its interpretation is OS-specific. This name form is constructed as:
-
- username
-
- Assuming that users' principal names are the same as their local
- operating system names, an implementation of GSS_Import_name() based
- on Kerberos V5 technology can process names of this form by
- postfixing an "@" sign and the name of the local realm.
-
-2.2.2. Machine UID Form
-
- This name form shall be represented by the Object Identifier {iso(1)
- member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- generic(1) machine_uid_name(2)}. The recommended symbolic name for
- this type is "GSS_KRB5_NT_MACHINE_UID_NAME".
-
- This name type is used to indicate a numeric user identifier
- corresponding to a user on a local system. Its interpretation is
- OS-specific. The gss_buffer_desc representing a name of this type
- should contain a locally-significant uid_t, represented in host byte
- order. The GSS_Import_name() operation resolves this uid into a
- username, which is then treated as the User Name Form.
-
-2.2.3. String UID Form
-
- This name form shall be represented by the Object Identifier {iso(1)
- member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- generic(1) string_uid_name(3)}. The recommended symbolic name for
- this type is "GSS_KRB5_NT_STRING_UID_NAME".
-
- This name type is used to indicate a string of digits representing
- the numeric user identifier of a user on a local system. Its
- interpretation is OS-specific. This name type is similar to the
- Machine UID Form, except that the buffer contains a string
- representing the uid_t.
-
-3. Credentials Management
-
- The Kerberos V5 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 V5 credentials
- cache, sometimes known as a ticket file.
-
-
-
-
-Linn Standards Track [Page 16]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- 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 V5 key table, or srvtab file. 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 V5 mechanism's credential handle may contain references
- to either or both types of credentials. It is a local matter how the
- Kerberos V5 mechanism implementation finds the appropriate Kerberos
- V5 credentials cache or key table.
-
- However, when the Kerberos V5 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 V5 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.
-
-4. Parameter Definitions
-
- This section defines parameter values used by the Kerberos V5 GSS-API
- mechanism. It defines interface elements in support of portability,
- and assumes use of C language bindings per RFC-1509.
-
-4.1. Minor Status Codes
-
- This section recommends common symbolic names for minor_status values
- to be returned by the Kerberos V5 GSS-API mechanism. Use of these
- 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 GSS-API 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.
-
-
-
-Linn Standards Track [Page 17]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
-4.1.1. Non-Kerberos-specific codes
-
- 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" */
-
-4.1.2. Kerberos-specific-codes
-
- 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" */
-
-4.2. Quality of Protection Values
-
- This section defines Quality of Protection (QOP) values to be used
- with the Kerberos V5 GSS-API mechanism as input to GSS_Wrap() and
- GSS_GetMIC() routines in order to select among alternate integrity
- and confidentiality algorithms. Additional QOP values may be added in
- future versions of this specification. Non-overlapping bit positions
- are and will be employed in order that both integrity and
-
-
-
-Linn Standards Track [Page 18]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
- confidentiality QOP may be selected within a single parameter, via
- inclusive-OR of the specified integrity and confidentiality values.
-
-4.2.1. Integrity Algorithms
-
- The following Quality of Protection (QOP) values are currently
- defined for the Kerberos V5 GSS-API mechanism, and are used to select
- among alternate integrity checking algorithms.
-
- GSS_KRB5_INTEG_C_QOP_MD5 (numeric value: 1)
- /* Integrity using partial MD5 ("MD2.5") of plaintext */
-
- GSS_KRB5_INTEG_C_QOP_DES_MD5 (numeric value: 2)
- /* Integrity using DES MAC of MD5 of plaintext */
-
- GSS_KRB5_INTEG_C_QOP_DES_MAC (numeric value: 3)
- /* Integrity using DES MAC of plaintext */
-
-4.2.2. Confidentiality Algorithms
-
- Only one confidentiality QOP value is currently defined for the
- Kerberos V5 GSS-API mechanism:
-
- GSS_KRB5_CONF_C_QOP_DES (numeric value: 0)
- /* Confidentiality with DES */
-
- Note: confidentiality QOP should be indicated only by GSS-API calls
- capable of providing confidentiality services. If non-zero
- confidentiality QOP values are defined in future to represent
- different algorithms, therefore, the bit positions containing those
- values should be cleared before being returned by implementations of
- GSS_GetMIC() and GSS_VerifyMIC().
-
-4.3. Buffer Sizes
-
- All implementations of this specification shall be capable of
- accepting buffers of at least 16 Kbytes as input to GSS_GetMIC(),
- GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting
- the output_token generated by GSS_Wrap() for a 16 Kbyte input buffer
- as input to GSS_Unwrap(). Support for larger buffer sizes is optional
- but recommended.
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 19]
-
-RFC 1964 Kerberos Version 5 GSS-API June 1996
-
-
-5. Security Considerations
-
- Security issues are discussed throughout this memo.
-
-6. References
-
-
- [RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC
- 1321, April 1992.
-
- [RFC-1508]: Linn, J., "Generic Security Service Application Program
- Interface", RFC 1508, September 1993.
-
- [RFC-1509]: Wray, J., "Generic Security Service Application Program
- Interface: C-bindings", RFC 1509, September 1993.
-
- [RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network
- Authentication Service (V5)", RFC 1510, September 1993.
-
- [FIPS-PUB-113]: National Bureau of Standards, Federal Information
- Processing Standard 113, "Computer Data Authentication", May 1985.
-
-AUTHOR'S ADDRESS
-
- John Linn
- OpenVision Technologies
- One Main St.
- Cambridge, MA 02142 USA
-
- Phone: +1 617.374.2245
- EMail: John.Linn@ov.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 20]
-
diff --git a/doc/standardisation/rfc2078.txt b/doc/standardisation/rfc2078.txt
deleted file mode 100644
index 1dd1e4aebd2d7474691f027b540f54f331bb19fa..0000000000000000000000000000000000000000
--- a/doc/standardisation/rfc2078.txt
+++ /dev/null
@@ -1,4763 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Linn
-Request for Comments: 2078 OpenVision Technologies
-Category: Standards Track January 1997
-Obsoletes: 1508
-
-
- Generic Security Service Application Program Interface, Version 2
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- The Generic Security Service Application Program Interface (GSS-API),
- as defined in RFC-1508, provides security services to callers in a
- generic fashion, supportable with a range of underlying mechanisms
- and technologies and hence allowing source-level portability of
- applications to different environments. This specification defines
- GSS-API services and primitives at a level independent of underlying
- mechanism and programming language environment, and is to be
- complemented by other, related specifications:
-
- documents defining specific parameter bindings for particular
- language environments
-
- documents defining token formats, protocols, and procedures to be
- implemented in order to realize GSS-API services atop particular
- security mechanisms
-
- This memo revises RFC-1508, making specific, incremental changes in
- response to implementation experience and liaison requests. It is
- intended, therefore, that this memo or a successor version thereto
- will become the basis for subsequent progression of the GSS-API
- specification on the standards track.
-
-Table of Contents
-
- 1: GSS-API Characteristics and Concepts.......................... 3
- 1.1: GSS-API Constructs.......................................... 6
- 1.1.1: Credentials.............................................. 6
- 1.1.1.1: Credential Constructs and Concepts...................... 6
- 1.1.1.2: Credential Management................................... 7
- 1.1.1.3: Default Credential Resolution........................... 8
-
-
-
-Linn Standards Track [Page 1]
-
-RFC 2078 GSS-API January 1997
-
-
- 1.1.2: Tokens.................................................... 9
- 1.1.3: Security Contexts........................................ 10
- 1.1.4: Mechanism Types.......................................... 11
- 1.1.5: Naming................................................... 12
- 1.1.6: Channel Bindings......................................... 14
- 1.2: GSS-API Features and Issues................................ 15
- 1.2.1: Status Reporting......................................... 15
- 1.2.2: Per-Message Security Service Availability................. 17
- 1.2.3: Per-Message Replay Detection and Sequencing............... 18
- 1.2.4: Quality of Protection.................................... 20
- 1.2.5: Anonymity Support......................................... 21
- 1.2.6: Initialization............................................ 22
- 1.2.7: Per-Message Protection During Context Establishment....... 22
- 1.2.8: Implementation Robustness................................. 23
- 2: Interface Descriptions....................................... 23
- 2.1: Credential management calls................................ 25
- 2.1.1: GSS_Acquire_cred call.................................... 26
- 2.1.2: GSS_Release_cred call.................................... 28
- 2.1.3: GSS_Inquire_cred call.................................... 29
- 2.1.4: GSS_Add_cred call........................................ 31
- 2.1.5: GSS_Inquire_cred_by_mech call............................ 33
- 2.2: Context-level calls........................................ 34
- 2.2.1: GSS_Init_sec_context call................................ 34
- 2.2.2: GSS_Accept_sec_context call.............................. 40
- 2.2.3: GSS_Delete_sec_context call.............................. 44
- 2.2.4: GSS_Process_context_token call........................... 46
- 2.2.5: GSS_Context_time call.................................... 47
- 2.2.6: GSS_Inquire_context call................................. 47
- 2.2.7: GSS_Wrap_size_limit call................................. 49
- 2.2.8: GSS_Export_sec_context call.............................. 50
- 2.2.9: GSS_Import_sec_context call.............................. 52
- 2.3: Per-message calls.......................................... 53
- 2.3.1: GSS_GetMIC call.......................................... 54
- 2.3.2: GSS_VerifyMIC call....................................... 55
- 2.3.3: GSS_Wrap call............................................ 56
- 2.3.4: GSS_Unwrap call.......................................... 58
- 2.4: Support calls.............................................. 59
- 2.4.1: GSS_Display_status call.................................. 60
- 2.4.2: GSS_Indicate_mechs call.................................. 60
- 2.4.3: GSS_Compare_name call.................................... 61
- 2.4.4: GSS_Display_name call.................................... 62
- 2.4.5: GSS_Import_name call..................................... 63
- 2.4.6: GSS_Release_name call.................................... 64
- 2.4.7: GSS_Release_buffer call.................................. 65
- 2.4.8: GSS_Release_OID_set call................................. 65
- 2.4.9: GSS_Create_empty_OID_set call............................ 66
- 2.4.10: GSS_Add_OID_set_member call.............................. 67
- 2.4.11: GSS_Test_OID_set_member call............................. 67
-
-
-
-Linn Standards Track [Page 2]
-
-RFC 2078 GSS-API January 1997
-
-
- 2.4.12: GSS_Release_OID call..................................... 68
- 2.4.13: GSS_OID_to_str call...................................... 68
- 2.4.14: GSS_Str_to_OID call...................................... 69
- 2.4.15: GSS_Inquire_names_for_mech call.......................... 69
- 2.4.16: GSS_Inquire_mechs_for_name call.......................... 70
- 2.4.17: GSS_Canonicalize_name call............................... 71
- 2.4.18: GSS_Export_name call..................................... 72
- 2.4.19: GSS_Duplicate_name call.................................. 73
- 3: Data Structure Definitions for GSS-V2 Usage................... 73
- 3.1: Mechanism-Independent Token Format.......................... 74
- 3.2: Mechanism-Independent Exported Name Object Format........... 77
- 4: Name Type Definitions......................................... 77
- 4.1: Host-Based Service Name Form................................ 77
- 4.2: User Name Form.............................................. 78
- 4.3: Machine UID Form............................................ 78
- 4.4: String UID Form............................................. 79
- 5: Mechanism-Specific Example Scenarios......................... 79
- 5.1: Kerberos V5, single-TGT..................................... 79
- 5.2: Kerberos V5, double-TGT..................................... 80
- 5.3: X.509 Authentication Framework............................. 81
- 6: Security Considerations...................................... 82
- 7: Related Activities........................................... 82
- Appendix A: Mechanism Design Constraints......................... 83
- Appendix B: Compatibility with GSS-V1............................ 83
-
-1: GSS-API Characteristics and Concepts
-
- GSS-API operates in the following paradigm. A typical GSS-API caller
- is itself a communications protocol, calling on GSS-API in order to
- protect its communications with authentication, integrity, and/or
- confidentiality security services. A GSS-API caller accepts tokens
- provided to it by its local GSS-API implementation and transfers the
- tokens to a peer on a remote system; that peer passes the received
- tokens to its local GSS-API implementation for processing. The
- security services available through GSS-API in this fashion are
- implementable (and have been implemented) over a range of underlying
- mechanisms based on secret-key and public-key cryptographic
- technologies.
-
- The GSS-API separates the operations of initializing a security
- context between peers, achieving peer entity authentication (This
- security service definition, and other definitions used in this
- document, corresponds to that provided in International Standard ISO
- 7498-2-1988(E), Security Architecture.) (GSS_Init_sec_context() and
- GSS_Accept_sec_context() calls), from the operations of providing
- per-message data origin authentication and data integrity protection
- (GSS_GetMIC() and GSS_VerifyMIC() calls) for messages subsequently
- transferred in conjunction with that context. When establishing a
-
-
-
-Linn Standards Track [Page 3]
-
-RFC 2078 GSS-API January 1997
-
-
- security context, the GSS-API enables a context initiator to
- optionally permit its credentials to be delegated, meaning that the
- context acceptor may initiate further security contexts on behalf of
- the initiating caller. Per-message GSS_Wrap() and GSS_Unwrap() calls
- provide the data origin authentication and data integrity services
- which GSS_GetMIC() and GSS_VerifyMIC() offer, and also support
- selection of confidentiality services as a caller option. Additional
- calls provide supportive functions to the GSS-API's users.
-
- The following paragraphs provide an example illustrating the
- dataflows involved in use of the GSS-API by a client and server in a
- mechanism-independent fashion, establishing a security context and
- transferring a protected message. The example assumes that credential
- acquisition has already been completed. The example assumes that the
- underlying authentication technology is capable of authenticating a
- client to a server using elements carried within a single token, and
- of authenticating the server to the client (mutual authentication)
- with a single returned token; this assumption holds for presently-
- documented CAT mechanisms but is not necessarily true for other
- cryptographic technologies and associated protocols.
-
- The client calls GSS_Init_sec_context() to establish a security
- context to the server identified by targ_name, and elects to set the
- mutual_req_flag so that mutual authentication is performed in the
- course of context establishment. GSS_Init_sec_context() returns an
- output_token to be passed to the server, and indicates
- GSS_S_CONTINUE_NEEDED status pending completion of the mutual
- authentication sequence. Had mutual_req_flag not been set, the
- initial call to GSS_Init_sec_context() would have returned
- GSS_S_COMPLETE status. The client sends the output_token to the
- server.
-
- The server passes the received token as the input_token parameter to
- GSS_Accept_sec_context(). GSS_Accept_sec_context indicates
- GSS_S_COMPLETE status, provides the client's authenticated identity
- in the src_name result, and provides an output_token to be passed to
- the client. The server sends the output_token to the client.
-
- The client passes the received token as the input_token parameter to
- a successor call to GSS_Init_sec_context(), which processes data
- included in the token in order to achieve mutual authentication from
- the client's viewpoint. This call to GSS_Init_sec_context() returns
- GSS_S_COMPLETE status, indicating successful mutual authentication
- and the completion of context establishment for this example.
-
- The client generates a data message and passes it to GSS_Wrap().
- GSS_Wrap() performs data origin authentication, data integrity, and
- (optionally) confidentiality processing on the message and
-
-
-
-Linn Standards Track [Page 4]
-
-RFC 2078 GSS-API January 1997
-
-
- encapsulates the result into output_message, indicating
- GSS_S_COMPLETE status. The client sends the output_message to the
- server.
-
- The server passes the received message to GSS_Unwrap(). GSS_Unwrap()
- inverts the encapsulation performed by GSS_Wrap(), deciphers the
- message if the optional confidentiality feature was applied, and
- validates the data origin authentication and data integrity checking
- quantities. GSS_Unwrap() indicates successful validation by
- returning GSS_S_COMPLETE status along with the resultant
- output_message.
-
- For purposes of this example, we assume that the server knows by
- out-of-band means that this context will have no further use after
- one protected message is transferred from client to server. Given
- this premise, the server now calls GSS_Delete_sec_context() to flush
- context-level information. Optionally, the server-side application
- may provide a token buffer to GSS_Delete_sec_context(), to receive a
- context_token to be transferred to the client in order to request
- that client-side context-level information be deleted.
-
- If a context_token is transferred, the client passes the
- context_token to GSS_Process_context_token(), which returns
- GSS_S_COMPLETE status after deleting context-level information at the
- client system.
-
- The GSS-API design assumes and addresses several basic goals,
- including:
-
- Mechanism independence: The GSS-API defines an interface to
- cryptographically implemented strong authentication and other
- security services at a generic level which is independent of
- particular underlying mechanisms. For example, GSS-API-provided
- services can be implemented by secret-key technologies (e.g.,
- Kerberos) or public-key approaches (e.g., X.509).
-
- Protocol environment independence: The GSS-API is independent of
- the communications protocol suites with which it is employed,
- permitting use in a broad range of protocol environments. In
- appropriate environments, an intermediate implementation "veneer"
- which is oriented to a particular communication protocol (e.g.,
- Remote Procedure Call (RPC)) may be interposed between
- applications which call that protocol and the GSS-API, thereby
- invoking GSS-API facilities in conjunction with that protocol's
- communications invocations.
-
- Protocol association independence: The GSS-API's security context
- construct is independent of communications protocol association
-
-
-
-Linn Standards Track [Page 5]
-
-RFC 2078 GSS-API January 1997
-
-
- constructs. This characteristic allows a single GSS-API
- implementation to be utilized by a variety of invoking protocol
- modules on behalf of those modules' calling applications. GSS-API
- services can also be invoked directly by applications, wholly
- independent of protocol associations.
-
- Suitability to a range of implementation placements: GSS-API
- clients are not constrained to reside within any Trusted Computing
- Base (TCB) perimeter defined on a system where the GSS-API is
- implemented; security services are specified in a manner suitable
- to both intra-TCB and extra-TCB callers.
-
-1.1: GSS-API Constructs
-
- This section describes the basic elements comprising the GSS-API.
-
-1.1.1: Credentials
-
-1.1.1.1: Credential Constructs and Concepts
-
- Credentials provide the prerequisites which permit GSS-API peers to
- establish security contexts with each other. A caller may designate
- that the credential elements which are to be applied for context
- initiation or acceptance be selected by default. Alternately, those
- GSS-API callers which need to make explicit selection of particular
- credentials structures may make references to those credentials
- through GSS-API-provided credential handles ("cred_handles"). In all
- cases, callers' credential references are indirect, mediated by GSS-
- API implementations and not requiring callers to access the selected
- credential elements.
-
- A single credential structure may be used to initiate outbound
- contexts and to accept inbound contexts. Callers needing to operate
- in only one of these modes may designate this fact when credentials
- are acquired for use, allowing underlying mechanisms to optimize
- their processing and storage requirements. The credential elements
- defined by a particular mechanism may contain multiple cryptographic
- keys, e.g., to enable authentication and message encryption to be
- performed with different algorithms.
-
- A GSS-API credential structure may contain multiple credential
- elements, each containing mechanism-specific information for a
- particular underlying mechanism (mech_type), but the set of elements
- within a given credential structure represent a common entity. A
- credential structure's contents will vary depending on the set of
- mech_types supported by a particular GSS-API implementation. Each
- credential element identifies the data needed by its mechanism in
- order to establish contexts on behalf of a particular principal, and
-
-
-
-Linn Standards Track [Page 6]
-
-RFC 2078 GSS-API January 1997
-
-
- may contain separate credential references for use in context
- initiation and context acceptance. Multiple credential elements
- within a given credential having overlapping combinations of
- mechanism, usage mode, and validity period are not permitted.
-
- Commonly, a single mech_type will be used for all security contexts
- established by a particular initiator to a particular target. A major
- motivation for supporting credential sets representing multiple
- mech_types is to allow initiators on systems which are equipped to
- handle multiple types to initiate contexts to targets on other
- systems which can accommodate only a subset of the set supported at
- the initiator's system.
-
-1.1.1.2: Credential Management
-
- It is the responsibility of underlying system-specific mechanisms and
- OS functions below the GSS-API to ensure that the ability to acquire
- and use credentials associated with a given identity is constrained
- to appropriate processes within a system. This responsibility should
- be taken seriously by implementors, as the ability for an entity to
- utilize a principal's credentials is equivalent to the entity's
- ability to successfully assert that principal's identity.
-
- Once a set of GSS-API credentials is established, the transferability
- of that credentials set to other processes or analogous constructs
- within a system is a local matter, not defined by the GSS-API. An
- example local policy would be one in which any credentials received
- as a result of login to a given user account, or of delegation of
- rights to that account, are accessible by, or transferable to,
- processes running under that account.
-
- The credential establishment process (particularly when performed on
- behalf of users rather than server processes) is likely to require
- access to passwords or other quantities which should be protected
- locally and exposed for the shortest time possible. As a result, it
- will often be appropriate for preliminary credential establishment to
- be performed through local means at user login time, with the
- result(s) cached for subsequent reference. These preliminary
- credentials would be set aside (in a system-specific fashion) for
- subsequent use, either:
-
- to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
- call, returning an explicit handle to reference that credential
-
- to comprise default credential elements to be installed, and to be
- used when default credential behavior is requested on behalf of a
- process
-
-
-
-
-Linn Standards Track [Page 7]
-
-RFC 2078 GSS-API January 1997
-
-
-1.1.1.3: Default Credential Resolution
-
- The gss_init_sec_context and gss_accept_sec_context routines allow
- the value GSS_C_NO_CREDENTIAL to be specified as their credential
- handle parameter. This special credential-handle indicates a desire
- by the application to act as a default principal. While individual
- GSS-API implementations are free to determine such default behavior
- as appropriate to the mechanism, the following default behavior by
- these routines is recommended for portability:
-
- GSS_Init_sec_context:
-
- (i) If there is only a single principal capable of initiating
- security contexts that the application is authorized to act on
- behalf of, then that principal shall be used, otherwise
-
- (ii) If the platform maintains a concept of a default network-
- identity, and if the application is authorized to act on behalf of
- that identity for the purpose of initiating security contexts,
- then the principal corresponding to that identity shall be used,
- otherwise
-
- (iii) If the platform maintains a concept of a default local
- identity, and provides a means to map local identities into
- network-identities, and if the application is authorized to act on
- behalf of the network-identity image of the default local identity
- for the purpose of initiating security contexts, then the
- principal corresponding to that identity shall be used, otherwise
-
- (iv) A user-configurable default identity should be used.
-
- GSS_Accept_sec_context:
-
- (i) If there is only a single authorized principal identity
- capable of accepting security contexts, then that principal shall
- be used, otherwise
-
- (ii) If the mechanism can determine the identity of the target
- principal by examining the context-establishment token, and if the
- accepting application is authorized to act as that principal for
- the purpose of accepting security contexts, then that principal
- identity shall be used, otherwise
-
- (iii) If the mechanism supports context acceptance by any
- principal, and mutual authentication was not requested, any
- principal that the application is authorized to accept security
- contexts under may be used, otherwise
-
-
-
-
-Linn Standards Track [Page 8]
-
-RFC 2078 GSS-API January 1997
-
-
- (iv) A user-configurable default identity shall be used.
-
- The purpose of the above rules is to allow security contexts to be
- established by both initiator and acceptor using the default behavior
- wherever possible. Applications requesting default behavior are
- likely to be more portable across mechanisms and platforms than ones
- that use GSS_Acquire_cred to request a specific identity.
-
-1.1.2: Tokens
-
- Tokens are data elements transferred between GSS-API callers, and are
- divided into two classes. Context-level tokens are exchanged in order
- to establish and manage a security context between peers. Per-message
- tokens relate to an established context and are exchanged to provide
- protective security services (i.e., data origin authentication,
- integrity, and optional confidentiality) for corresponding data
- messages.
-
- The first context-level token obtained from GSS_Init_sec_context() is
- required to indicate at its very beginning a globally-interpretable
- mechanism identifier, i.e., an Object Identifier (OID) of the
- security mechanism. The remaining part of this token as well as the
- whole content of all other tokens are specific to the particular
- underlying mechanism used to support the GSS-API. Section 3 of this
- document provides, for designers of GSS-API support mechanisms, the
- description of the header of the first context-level token which is
- then followed by mechanism-specific information.
-
- Tokens' contents are opaque from the viewpoint of GSS-API callers.
- They are generated within the GSS-API implementation at an end
- system, provided to a GSS-API caller to be transferred to the peer
- GSS-API caller at a remote end system, and processed by the GSS-API
- implementation at that remote end system. Tokens may be output by
- GSS-API calls (and should be transferred to GSS-API peers) whether or
- not the calls' status indicators indicate successful completion.
- Token transfer may take place in an in-band manner, integrated into
- the same protocol stream used by the GSS-API callers for other data
- transfers, or in an out-of-band manner across a logically separate
- channel.
-
- Different GSS-API tokens are used for different purposes (e.g.,
- context initiation, context acceptance, protected message data on an
- established context), and it is the responsibility of a GSS-API
- caller receiving tokens to distinguish their types, associate them
- with corresponding security contexts, and pass them to appropriate
- GSS-API processing routines. Depending on the caller protocol
- environment, this distinction may be accomplished in several ways.
-
-
-
-
-Linn Standards Track [Page 9]
-
-RFC 2078 GSS-API January 1997
-
-
- The following examples illustrate means through which tokens' types
- may be distinguished:
-
- - implicit tagging based on state information (e.g., all tokens on
- a new association are considered to be context establishment
- tokens until context establishment is completed, at which point
- all tokens are considered to be wrapped data objects for that
- context),
-
- - explicit tagging at the caller protocol level,
-
- - a hybrid of these approaches.
-
- Commonly, the encapsulated data within a token includes internal
- mechanism-specific tagging information, enabling mechanism-level
- processing modules to distinguish tokens used within the mechanism
- for different purposes. Such internal mechanism-level tagging is
- recommended to mechanism designers, and enables mechanisms to
- determine whether a caller has passed a particular token for
- processing by an inappropriate GSS-API routine.
-
- Development of GSS-API support primitives based on a particular
- underlying cryptographic technique and protocol (i.e., conformant to
- a specific GSS-API mechanism definition) does not necessarily imply
- that GSS-API callers using that GSS-API mechanism will be able to
- interoperate with peers invoking the same technique and protocol
- outside the GSS-API paradigm, or with peers implementing a different
- GSS-API mechanism based on the same underlying technology. The
- format of GSS-API tokens defined in conjunction with a particular
- mechanism, and the techniques used to integrate those tokens into
- callers' protocols, may not be interoperable with the tokens used by
- non-GSS-API callers of the same underlying technique.
-
-1.1.3: Security Contexts
-
- Security contexts are established between peers, using credentials
- established locally in conjunction with each peer or received by
- peers via delegation. Multiple contexts may exist simultaneously
- between a pair of peers, using the same or different sets of
- credentials. Coexistence of multiple contexts using different
- credentials allows graceful rollover when credentials expire.
- Distinction among multiple contexts based on the same credentials
- serves applications by distinguishing different message streams in a
- security sense.
-
- The GSS-API is independent of underlying protocols and addressing
- structure, and depends on its callers to transport GSS-API-provided
- data elements. As a result of these factors, it is a caller
-
-
-
-Linn Standards Track [Page 10]
-
-RFC 2078 GSS-API January 1997
-
-
- responsibility to parse communicated messages, separating GSS-API-
- related data elements from caller-provided data. The GSS-API is
- independent of connection vs. connectionless orientation of the
- underlying communications service.
-
- No correlation between security context and communications protocol
- association is dictated. (The optional channel binding facility,
- discussed in Section 1.1.6 of this document, represents an
- intentional exception to this rule, supporting additional protection
- features within GSS-API supporting mechanisms.) This separation
- allows the GSS-API to be used in a wide range of communications
- environments, and also simplifies the calling sequences of the
- individual calls. In many cases (depending on underlying security
- protocol, associated mechanism, and availability of cached
- information), the state information required for context setup can be
- sent concurrently with initial signed user data, without interposing
- additional message exchanges.
-
-1.1.4: Mechanism Types
-
- In order to successfully establish a security context with a target
- peer, it is necessary to identify an appropriate underlying mechanism
- type (mech_type) which both initiator and target peers support. The
- definition of a mechanism embodies not only the use of a particular
- cryptographic technology (or a hybrid or choice among alternative
- cryptographic technologies), but also definition of the syntax and
- semantics of data element exchanges which that mechanism will employ
- in order to support security services.
-
- It is recommended that callers initiating contexts specify the
- "default" mech_type value, allowing system-specific functions within
- or invoked by the GSS-API implementation to select the appropriate
- mech_type, but callers may direct that a particular mech_type be
- employed when necessary.
-
- The means for identifying a shared mech_type to establish a security
- context with a peer will vary in different environments and
- circumstances; examples include (but are not limited to):
-
- use of a fixed mech_type, defined by configuration, within an
- environment
-
- syntactic convention on a target-specific basis, through
- examination of a target's name
-
- lookup of a target's name in a naming service or other database in
- order to identify mech_types supported by that target
-
-
-
-
-Linn Standards Track [Page 11]
-
-RFC 2078 GSS-API January 1997
-
-
- explicit negotiation between GSS-API callers in advance of
- security context setup
-
- When transferred between GSS-API peers, mech_type specifiers (per
- Section 3, represented as Object Identifiers (OIDs)) serve to qualify
- the interpretation of associated tokens. (The structure and encoding
- of Object Identifiers is defined in ISO/IEC 8824, "Specification of
- Abstract Syntax Notation One (ASN.1)" and in ISO/IEC 8825,
- "Specification of Basic Encoding Rules for Abstract Syntax Notation
- One (ASN.1)".) Use of hierarchically structured OIDs serves to
- preclude ambiguous interpretation of mech_type specifiers. The OID
- representing the DASS MechType, for example, is 1.3.12.2.1011.7.5,
- and that of the Kerberos V5 mechanism, once advanced to the level of
- Proposed Standard, will be 1.2.840.113554.1.2.2.
-
-1.1.5: Naming
-
- The GSS-API avoids prescribing naming structures, treating the names
- which are transferred across the interface in order to initiate and
- accept security contexts as opaque objects. This approach supports
- the GSS-API's goal of implementability atop a range of underlying
- security mechanisms, recognizing the fact that different mechanisms
- process and authenticate names which are presented in different
- forms. Generalized services offering translation functions among
- arbitrary sets of naming environments are outside the scope of the
- GSS-API; availability and use of local conversion functions to
- translate among the naming formats supported within a given end
- system is anticipated.
-
- Different classes of name representations are used in conjunction
- with different GSS-API parameters:
-
- - Internal form (denoted in this document by INTERNAL NAME),
- opaque to callers and defined by individual GSS-API
- implementations. GSS-API implementations supporting multiple
- namespace types must maintain internal tags to disambiguate the
- interpretation of particular names. A Mechanism Name (MN) is a
- special case of INTERNAL NAME, guaranteed to contain elements
- corresponding to one and only one mechanism; calls which are
- guaranteed to emit MNs or which require MNs as input are so
- identified within this specification.
-
- - Contiguous string ("flat") form (denoted in this document by
- OCTET STRING); accompanied by OID tags identifying the namespace
- to which they correspond. Depending on tag value, flat names may
- or may not be printable strings for direct acceptance from and
- presentation to users. Tagging of flat names allows GSS-API
- callers and underlying GSS-API mechanisms to disambiguate name
-
-
-
-Linn Standards Track [Page 12]
-
-RFC 2078 GSS-API January 1997
-
-
- types and to determine whether an associated name's type is one
- which they are capable of processing, avoiding aliasing problems
- which could result from misinterpreting a name of one type as a
- name of another type.
-
- - The GSS-API Exported Name Object, a special case of flat name
- designated by a reserved OID value, carries a canonicalized form
- of a name suitable for binary comparisons.
-
- In addition to providing means for names to be tagged with types,
- this specification defines primitives to support a level of naming
- environment independence for certain calling applications. To provide
- basic services oriented towards the requirements of callers which
- need not themselves interpret the internal syntax and semantics of
- names, GSS-API calls for name comparison (GSS_Compare_name()),
- human-readable display (GSS_Display_name()), input conversion
- (GSS_Import_name()), internal name deallocation (GSS_Release_name()),
- and internal name duplication (GSS_Duplicate_name()) functions are
- defined. (It is anticipated that these proposed GSS-API calls will be
- implemented in many end systems based on system-specific name
- manipulation primitives already extant within those end systems;
- inclusion within the GSS-API is intended to offer GSS-API callers a
- portable means to perform specific operations, supportive of
- authorization and audit requirements, on authenticated names.)
-
- GSS_Import_name() implementations can, where appropriate, support
- more than one printable syntax corresponding to a given namespace
- (e.g., alternative printable representations for X.500 Distinguished
- Names), allowing flexibility for their callers to select among
- alternative representations. GSS_Display_name() implementations
- output a printable syntax selected as appropriate to their
- operational environments; this selection is a local matter. Callers
- desiring portability across alternative printable syntaxes should
- refrain from implementing comparisons based on printable name forms
- and should instead use the GSS_Compare_name() call to determine
- whether or not one internal-format name matches another.
-
- The GSS_Canonicalize_name() and GSS_Export_name() calls enable
- callers to acquire and process Exported Name Objects, canonicalized
- and translated in accordance with the procedures of a particular
- GSS-API mechanism. Exported Name Objects can, in turn, be input to
- GSS_Import_name(), yielding equivalent MNs. These facilities are
- designed specifically to enable efficient storage and comparison of
- names (e.g., for use in access control lists).
-
-
-
-
-
-
-
-Linn Standards Track [Page 13]
-
-RFC 2078 GSS-API January 1997
-
-
- The following diagram illustrates the intended dataflow among name-
- related GSS-API processing routines.
-
- GSS-API library defaults
- |
- |
- V text, for
- text --------------> internal_name (IN) -----------> display only
- import_name() / display_name()
- /
- /
- /
- accept_sec_context() /
- | /
- | /
- | / canonicalize_name()
- | /
- | /
- | /
- | /
- | /
- | |
- V V <---------------------
- single mechanism import_name() exported name: flat
- internal_name (MN) binary "blob" usable
- ----------------------> for access control
- export_name()
-
-1.1.6: Channel Bindings
-
- The GSS-API accommodates the concept of caller-provided channel
- binding ("chan_binding") information. Channel bindings are used to
- strengthen the quality with which peer entity authentication is
- provided during context establishment, by limiting the scope within
- which an intercepted context establishment token can be reused by an
- attacker. Specifically, they enable GSS-API callers to bind the
- establishment of a security context to relevant characteristics
- (e.g., addresses, transformed representations of encryption keys) of
- the underlying communications channel, of protection mechanisms
- applied to that communications channel, and to application-specific
- data.
-
- The caller initiating a security context must determine the
- appropriate channel binding values to provide as input to the
- GSS_Init_sec_context() call, and consistent values must be provided
- to GSS_Accept_sec_context() by the context's target, in order for
- both peers' GSS-API mechanisms to validate that received tokens
- possess correct channel-related characteristics. Use or non-use of
-
-
-
-Linn Standards Track [Page 14]
-
-RFC 2078 GSS-API January 1997
-
-
- the GSS-API channel binding facility is a caller option. GSS-API
- mechanisms can operate in an environment where NULL channel bindings
- are presented; mechanism implementors are encouraged, but not
- required, to make use of caller-provided channel binding data within
- their mechanisms. Callers should not assume that underlying
- mechanisms provide confidentiality protection for channel binding
- information.
-
- When non-NULL channel bindings are provided by callers, certain
- mechanisms can offer enhanced security value by interpreting the
- bindings' content (rather than simply representing those bindings, or
- integrity check values computed on them, within tokens) and will
- therefore depend on presentation of specific data in a defined
- format. To this end, agreements among mechanism implementors are
- defining conventional interpretations for the contents of channel
- binding arguments, including address specifiers (with content
- dependent on communications protocol environment) for context
- initiators and acceptors. (These conventions are being incorporated
- in GSS-API mechanism specifications and into the GSS-API C language
- bindings specification.) In order for GSS-API callers to be portable
- across multiple mechanisms and achieve the full security
- functionality which each mechanism can provide, it is strongly
- recommended that GSS-API callers provide channel bindings consistent
- with these conventions and those of the networking environment in
- which they operate.
-
-1.2: GSS-API Features and Issues
-
- This section describes aspects of GSS-API operations, of the security
- services which the GSS-API provides, and provides commentary on
- design issues.
-
-1.2.1: Status Reporting
-
- Each GSS-API call provides two status return values. Major_status
- values provide a mechanism-independent indication of call status
- (e.g., GSS_S_COMPLETE, GSS_S_FAILURE, GSS_S_CONTINUE_NEEDED),
- sufficient to drive normal control flow within the caller in a
- generic fashion. Table 1 summarizes the defined major_status return
- codes in tabular fashion.
-
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 15]
-
-RFC 2078 GSS-API January 1997
-
-
-Table 1: GSS-API Major Status Codes
-
- FATAL ERROR CODES
-
- GSS_S_BAD_BINDINGS channel binding mismatch
- GSS_S_BAD_MECH unsupported mechanism requested
- GSS_S_BAD_NAME invalid name provided
- GSS_S_BAD_NAMETYPE name of unsupported type provided
- GSS_S_BAD_STATUS invalid input status selector
- GSS_S_BAD_SIG token had invalid integrity check
- GSS_S_CONTEXT_EXPIRED specified security context expired
- GSS_S_CREDENTIALS_EXPIRED expired credentials detected
- GSS_S_DEFECTIVE_CREDENTIAL defective credential detected
- GSS_S_DEFECTIVE_TOKEN defective token detected
- GSS_S_FAILURE failure, unspecified at GSS-API
- level
- GSS_S_NO_CONTEXT no valid security context specified
- GSS_S_NO_CRED no valid credentials provided
- GSS_S_BAD_QOP unsupported QOP value
- GSS_S_UNAUTHORIZED operation unauthorized
- GSS_S_UNAVAILABLE operation unavailable
- GSS_S_DUPLICATE_ELEMENT duplicate credential element requested
- GSS_S_NAME_NOT_MN name contains multi-mechanism elements
-
- INFORMATORY STATUS CODES
-
- GSS_S_COMPLETE normal completion
- GSS_S_CONTINUE_NEEDED continuation call to routine
- required
- GSS_S_DUPLICATE_TOKEN duplicate per-message token
- detected
- GSS_S_OLD_TOKEN timed-out per-message token
- detected
- GSS_S_UNSEQ_TOKEN reordered (early) per-message token
- detected
- GSS_S_GAP_TOKEN skipped predecessor token(s)
- detected
-
- Minor_status provides more detailed status information which may
- include status codes specific to the underlying security mechanism.
- Minor_status values are not specified in this document.
-
- GSS_S_CONTINUE_NEEDED major_status returns, and optional message
- outputs, are provided in GSS_Init_sec_context() and
- GSS_Accept_sec_context() calls so that different mechanisms'
- employment of different numbers of messages within their
- authentication sequences need not be reflected in separate code paths
- within calling applications. Instead, such cases are accommodated
-
-
-
-Linn Standards Track [Page 16]
-
-RFC 2078 GSS-API January 1997
-
-
- with sequences of continuation calls to GSS_Init_sec_context() and
- GSS_Accept_sec_context(). The same mechanism is used to encapsulate
- mutual authentication within the GSS-API's context initiation calls.
-
- For mech_types which require interactions with third-party servers in
- order to establish a security context, GSS-API context establishment
- calls may block pending completion of such third-party interactions.
-
- On the other hand, no GSS-API calls pend on serialized interactions
- with GSS-API peer entities. As a result, local GSS-API status
- returns cannot reflect unpredictable or asynchronous exceptions
- occurring at remote peers, and reflection of such status information
- is a caller responsibility outside the GSS-API.
-
-1.2.2: Per-Message Security Service Availability
-
- When a context is established, two flags are returned to indicate the
- set of per-message protection security services which will be
- available on the context:
-
- the integ_avail flag indicates whether per-message integrity and
- data origin authentication services are available
-
- the conf_avail flag indicates whether per-message confidentiality
- services are available, and will never be returned TRUE unless the
- integ_avail flag is also returned TRUE
-
- GSS-API callers desiring per-message security services should
- check the values of these flags at context establishment time, and
- must be aware that a returned FALSE value for integ_avail means
- that invocation of GSS_GetMIC() or GSS_Wrap() primitives on the
- associated context will apply no cryptographic protection to user
- data messages.
-
- The GSS-API per-message integrity and data origin authentication
- services provide assurance to a receiving caller that protection was
- applied to a message by the caller's peer on the security context,
- corresponding to the entity named at context initiation. The GSS-API
- per-message confidentiality service provides assurance to a sending
- caller that the message's content is protected from access by
- entities other than the context's named peer.
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 17]
-
-RFC 2078 GSS-API January 1997
-
-
- The GSS-API per-message protection service primitives, as the
- category name implies, are oriented to operation at the granularity
- of protocol data units. They perform cryptographic operations on the
- data units, transfer cryptographic control information in tokens,
- and, in the case of GSS_Wrap(), encapsulate the protected data unit.
- As such, these primitives are not oriented to efficient data
- protection for stream-paradigm protocols (e.g., Telnet) if
- cryptography must be applied on an octet-by-octet basis.
-
-1.2.3: Per-Message Replay Detection and Sequencing
-
- Certain underlying mech_types offer support for replay detection
- and/or sequencing of messages transferred on the contexts they
- support. These optionally-selectable protection features are distinct
- from replay detection and sequencing features applied to the context
- establishment operation itself; the presence or absence of context-
- level replay or sequencing features is wholly a function of the
- underlying mech_type's capabilities, and is not selected or omitted
- as a caller option.
-
- The caller initiating a context provides flags (replay_det_req_flag
- and sequence_req_flag) to specify whether the use of per-message
- replay detection and sequencing features is desired on the context
- being established. The GSS-API implementation at the initiator system
- can determine whether these features are supported (and whether they
- are optionally selectable) as a function of mech_type, without need
- for bilateral negotiation with the target. When enabled, these
- features provide recipients with indicators as a result of GSS-API
- processing of incoming messages, identifying whether those messages
- were detected as duplicates or out-of-sequence. Detection of such
- events does not prevent a suspect message from being provided to a
- recipient; the appropriate course of action on a suspect message is a
- matter of caller policy.
-
- The semantics of the replay detection and sequencing services applied
- to received messages, as visible across the interface which the GSS-
- API provides to its clients, are as follows:
-
- When replay_det_state is TRUE, the possible major_status returns for
- well-formed and correctly signed messages are as follows:
-
- 1. GSS_S_COMPLETE indicates that the message was within the window
- (of time or sequence space) allowing replay events to be detected,
- and that the message was not a replay of a previously-processed
- message within that window.
-
-
-
-
-
-
-Linn Standards Track [Page 18]
-
-RFC 2078 GSS-API January 1997
-
-
- 2. GSS_S_DUPLICATE_TOKEN indicates that the cryptographic
- checkvalue on the received message was correct, but that the
- message was recognized as a duplicate of a previously-processed
- message.
-
- 3. GSS_S_OLD_TOKEN indicates that the cryptographic checkvalue on
- the received message was correct, but that the message is too old
- to be checked for duplication.
-
- When sequence_state is TRUE, the possible major_status returns for
- well-formed and correctly signed messages are as follows:
-
- 1. GSS_S_COMPLETE indicates that the message was within the window
- (of time or sequence space) allowing replay events to be detected,
- that the message was not a replay of a previously-processed
- message within that window, and that no predecessor sequenced
- messages are missing relative to the last received message (if
- any) processed on the context with a correct cryptographic
- checkvalue.
-
- 2. GSS_S_DUPLICATE_TOKEN indicates that the integrity check value
- on the received message was correct, but that the message was
- recognized as a duplicate of a previously-processed message.
-
- 3. GSS_S_OLD_TOKEN indicates that the integrity check value on the
- received message was correct, but that the token is too old to be
- checked for duplication.
-
- 4. GSS_S_UNSEQ_TOKEN indicates that the cryptographic checkvalue
- on the received message was correct, but that it is earlier in a
- sequenced stream than a message already processed on the context.
- [Note: Mechanisms can be architected to provide a stricter form of
- sequencing service, delivering particular messages to recipients
- only after all predecessor messages in an ordered stream have been
- delivered. This type of support is incompatible with the GSS-API
- paradigm in which recipients receive all messages, whether in
- order or not, and provide them (one at a time, without intra-GSS-
- API message buffering) to GSS-API routines for validation. GSS-
- API facilities provide supportive functions, aiding clients to
- achieve strict message stream integrity in an efficient manner in
- conjunction with sequencing provisions in communications
- protocols, but the GSS-API does not offer this level of message
- stream integrity service by itself.]
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 19]
-
-RFC 2078 GSS-API January 1997
-
-
- 5. GSS_S_GAP_TOKEN indicates that the cryptographic checkvalue on
- the received message was correct, but that one or more predecessor
- sequenced messages have not been successfully processed relative
- to the last received message (if any) processed on the context
- with a correct cryptographic checkvalue.
-
- As the message stream integrity features (especially sequencing) may
- interfere with certain applications' intended communications
- paradigms, and since support for such features is likely to be
- resource intensive, it is highly recommended that mech_types
- supporting these features allow them to be activated selectively on
- initiator request when a context is established. A context initiator
- and target are provided with corresponding indicators
- (replay_det_state and sequence_state), signifying whether these
- features are active on a given context.
-
- An example mech_type supporting per-message replay detection could
- (when replay_det_state is TRUE) implement the feature as follows: The
- underlying mechanism would insert timestamps in data elements output
- by GSS_GetMIC() and GSS_Wrap(), and would maintain (within a time-
- limited window) a cache (qualified by originator-recipient pair)
- identifying received data elements processed by GSS_VerifyMIC() and
- GSS_Unwrap(). When this feature is active, exception status returns
- (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN) will be provided when
- GSS_VerifyMIC() or GSS_Unwrap() is presented with a message which is
- either a detected duplicate of a prior message or which is too old to
- validate against a cache of recently received messages.
-
-1.2.4: Quality of Protection
-
- Some mech_types provide their users with fine granularity control
- over the means used to provide per-message protection, allowing
- callers to trade off security processing overhead dynamically against
- the protection requirements of particular messages. A per-message
- quality-of-protection parameter (analogous to quality-of-service, or
- QOS) selects among different QOP options supported by that mechanism.
- On context establishment for a multi-QOP mech_type, context-level
- data provides the prerequisite data for a range of protection
- qualities.
-
- It is expected that the majority of callers will not wish to exert
- explicit mechanism-specific QOP control and will therefore request
- selection of a default QOP. Definitions of, and choices among, non-
- default QOP values are mechanism-specific, and no ordered sequences
- of QOP values can be assumed equivalent across different mechanisms.
- Meaningful use of non-default QOP values demands that callers be
- familiar with the QOP definitions of an underlying mechanism or
- mechanisms, and is therefore a non-portable construct. The
-
-
-
-Linn Standards Track [Page 20]
-
-RFC 2078 GSS-API January 1997
-
-
- GSS_S_BAD_QOP major_status value is defined in order to indicate that
- a provided QOP value is unsupported for a security context, most
- likely because that value is unrecognized by the underlying
- mechanism.
-
-1.2.5: Anonymity Support
-
- In certain situations or environments, an application may wish to
- authenticate a peer and/or protect communications using GSS-API per-
- message services without revealing its own identity. For example,
- consider an application which provides read access to a research
- database, and which permits queries by arbitrary requestors. A
- client of such a service might wish to authenticate the service, to
- establish trust in the information received from it, but might not
- wish to disclose its identity to the service for privacy reasons.
-
- In ordinary GSS-API usage, a context initiator's identity is made
- available to the context acceptor as part of the context
- establishment process. To provide for anonymity support, a facility
- (input anon_req_flag to GSS_Init_sec_context()) is provided through
- which context initiators may request that their identity not be
- provided to the context acceptor. Mechanisms are not required to
- honor this request, but a caller will be informed (via returned
- anon_state indicator from GSS_Init_sec_context()) whether or not the
- request is honored. Note that authentication as the anonymous
- principal does not necessarily imply that credentials are not
- required in order to establish a context.
-
- The following Object Identifier value is provided as a means to
- identify anonymous names, and can be compared against in order to
- determine, in a mechanism-independent fashion, whether a name refers
- to an anonymous principal:
-
- {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
- 3(gss-anonymous-name)}
-
- The recommended symbolic name corresponding to this definition is
- GSS_C_NT_ANONYMOUS.
-
- Four possible combinations of anon_state and mutual_state are
- possible, with the following results:
-
- anon_state == FALSE, mutual_state == FALSE: initiator
- authenticated to target.
-
- anon_state == FALSE, mutual_state == TRUE: initiator authenticated
- to target, target authenticated to initiator.
-
-
-
-
-Linn Standards Track [Page 21]
-
-RFC 2078 GSS-API January 1997
-
-
- anon_state == TRUE, mutual_state == FALSE: initiator authenticated
- as anonymous principal to target.
-
- anon_state == TRUE, mutual_state == TRUE: initiator authenticated
- as anonymous principal to target, target authenticated to
- initiator.
-
-1.2.6: Initialization
-
- No initialization calls (i.e., calls which must be invoked prior to
- invocation of other facilities in the interface) are defined in GSS-
- API. As an implication of this fact, GSS-API implementations must
- themselves be self-initializing.
-
-1.2.7: Per-Message Protection During Context Establishment
-
- A facility is defined in GSS-V2 to enable protection and buffering of
- data messages for later transfer while a security context's
- establishment is in GSS_S_CONTINUE_NEEDED status, to be used in cases
- where the caller side already possesses the necessary session key to
- enable this processing. Specifically, a new state Boolean, called
- prot_ready_state, is added to the set of information returned by
- GSS_Init_sec_context(), GSS_Accept_sec_context(), and
- GSS_Inquire_context().
-
- For context establishment calls, this state Boolean is valid and
- interpretable when the associated major_status is either
- GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE. Callers of GSS-API (both
- initiators and acceptors) can assume that per-message protection (via
- GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is
- available and ready for use if either: prot_ready_state == TRUE, or
- major_status == GSS_S_COMPLETE, though mutual authentication (if
- requested) cannot be guaranteed until GSS_S_COMPLETE is returned.
-
- This achieves full, transparent backward compatibility for GSS-API V1
- callers, who need not even know of the existence of prot_ready_state,
- and who will get the expected behavior from GSS_S_COMPLETE, but who
- will not be able to use per-message protection before GSS_S_COMPLETE
- is returned.
-
- It is not a requirement that GSS-V2 mechanisms ever return TRUE
- prot_ready_state before completion of context establishment (indeed,
- some mechanisms will not evolve usable message protection keys,
- especially at the context acceptor, before context establishment is
- complete). It is expected but not required that GSS-V2 mechanisms
- will return TRUE prot_ready_state upon completion of context
- establishment if they support per-message protection at all (however
- GSS-V2 applications should not assume that TRUE prot_ready_state will
-
-
-
-Linn Standards Track [Page 22]
-
-RFC 2078 GSS-API January 1997
-
-
- always be returned together with the GSS_S_COMPLETE major_status,
- since GSS-V2 implementations may continue to support GSS-V1 mechanism
- code, which will never return TRUE prot_ready_state).
-
- When prot_ready_state is returned TRUE, mechanisms shall also set
- those context service indicator flags (deleg_state, mutual_state,
- replay_det_state, sequence_state, anon_state, trans_state,
- conf_avail, integ_avail) which represent facilities confirmed, at
- that time, to be available on the context being established. In
- situations where prot_ready_state is returned before GSS_S_COMPLETE,
- it is possible that additional facilities may be confirmed and
- subsequently indicated when GSS_S_COMPLETE is returned.
-
-1.2.8: Implementation Robustness
-
- This section recommends aspects of GSS-API implementation behavior in
- the interests of overall robustness.
-
- If a token is presented for processing on a GSS-API security context
- and that token is determined to be invalid for that context, the
- context's state should not be disrupted for purposes of processing
- subsequent valid tokens.
-
- Certain local conditions at a GSS-API implementation (e.g.,
- unavailability of memory) may preclude, temporarily or permanently,
- the successful processing of tokens on a GSS-API security context,
- typically generating GSS_S_FAILURE major_status returns along with
- locally-significant minor_status. For robust operation under such
- conditions, the following recommendations are made:
-
- Failing calls should free any memory they allocate, so that
- callers may retry without causing further loss of resources.
-
- Failure of an individual call on an established context should not
- preclude subsequent calls from succeeding on the same context.
-
- Whenever possible, it should be possible for
- GSS_Delete_sec_context() calls to be successfully processed even
- if other calls cannot succeed, thereby enabling context-related
- resources to be released.
-
-2: Interface Descriptions
-
- This section describes the GSS-API's service interface, dividing the
- set of calls offered into four groups. Credential management calls
- are related to the acquisition and release of credentials by
- principals. Context-level calls are related to the management of
- security contexts between principals. Per-message calls are related
-
-
-
-Linn Standards Track [Page 23]
-
-RFC 2078 GSS-API January 1997
-
-
- to the protection of individual messages on established security
- contexts. Support calls provide ancillary functions useful to GSS-API
- callers. Table 2 groups and summarizes the calls in tabular fashion.
-
-Table 2: GSS-API Calls
-
- CREDENTIAL MANAGEMENT
-
- GSS_Acquire_cred acquire credentials for use
- GSS_Release_cred release credentials after use
- GSS_Inquire_cred display information about
- credentials
- GSS_Add_cred construct credentials incrementally
- GSS_Inquire_cred_by_mech display per-mechanism credential
- information
-
- CONTEXT-LEVEL CALLS
-
- GSS_Init_sec_context initiate outbound security context
- GSS_Accept_sec_context accept inbound security context
- GSS_Delete_sec_context flush context when no longer needed
- GSS_Process_context_token process received control token on
- context
- GSS_Context_time indicate validity time remaining on
- context
- GSS_Inquire_context display information about context
- GSS_Wrap_size_limit determine GSS_Wrap token size limit
- GSS_Export_sec_context transfer context to other process
- GSS_Import_sec_context import transferred context
-
- PER-MESSAGE CALLS
-
- GSS_GetMIC apply integrity check, receive as
- token separate from message
- GSS_VerifyMIC validate integrity check token
- along with message
- GSS_Wrap sign, optionally encrypt,
- encapsulate
- GSS_Unwrap decapsulate, decrypt if needed,
- validate integrity check
-
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 24]
-
-RFC 2078 GSS-API January 1997
-
-
- SUPPORT CALLS
-
- GSS_Display_status translate status codes to printable
- form
- GSS_Indicate_mechs indicate mech_types supported on
- local system
- GSS_Compare_name compare two names for equality
- GSS_Display_name translate name to printable form
- GSS_Import_name convert printable name to
- normalized form
- GSS_Release_name free storage of normalized-form
- name
- GSS_Release_buffer free storage of printable name
- GSS_Release_OID free storage of OID object
- GSS_Release_OID_set free storage of OID set object
- GSS_Create_empty_OID_set create empty OID set
- GSS_Add_OID_set_member add member to OID set
- GSS_Test_OID_set_member test if OID is member of OID set
- GSS_OID_to_str display OID as string
- GSS_Str_to_OID construct OID from string
- GSS_Inquire_names_for_mech indicate name types supported by
- mechanism
- GSS_Inquire_mechs_for_name indicates mechanisms supporting name
- type
- GSS_Canonicalize_name translate name to per-mechanism form
- GSS_Export_name externalize per-mechanism name
- GSS_Duplicate_name duplicate name object
-
-2.1: Credential management calls
-
- These GSS-API calls provide functions related to the management of
- credentials. Their characterization with regard to whether or not
- they may block pending exchanges with other network entities (e.g.,
- directories or authentication servers) depends in part on OS-specific
- (extra-GSS-API) issues, so is not specified in this document.
-
- The GSS_Acquire_cred() call is defined within the GSS-API in support
- of application portability, with a particular orientation towards
- support of portable server applications. It is recognized that (for
- certain systems and mechanisms) credentials for interactive users may
- be managed differently from credentials for server processes; in such
- environments, it is the GSS-API implementation's responsibility to
- distinguish these cases and the procedures for making this
- distinction are a local matter. The GSS_Release_cred() call provides
- a means for callers to indicate to the GSS-API that use of a
- credentials structure is no longer required. The GSS_Inquire_cred()
- call allows callers to determine information about a credentials
- structure. The GSS_Add_cred() call enables callers to append
-
-
-
-Linn Standards Track [Page 25]
-
-RFC 2078 GSS-API January 1997
-
-
- elements to an existing credential structure, allowing iterative
- construction of a multi-mechanism credential. The
- GSS_Inquire_cred_by_mech() call enables callers to extract per-
- mechanism information describing a credentials structure.
-
-2.1.1: GSS_Acquire_cred call
-
- Inputs:
-
- o desired_name INTERNAL NAME, -NULL requests locally-determined
- default
-
- o lifetime_req INTEGER,-in seconds; 0 requests default
-
- o desired_mechs SET OF OBJECT IDENTIFIER,-empty set requests
- system-selected default
-
- o cred_usage INTEGER -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
- 2=ACCEPT-ONLY
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_cred_handle CREDENTIAL HANDLE,
-
- o actual_mechs SET OF OBJECT IDENTIFIER,
-
- o lifetime_rec INTEGER -in seconds, or reserved value for
- INDEFINITE
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that requested credentials were
- successfully established, for the duration indicated in
- lifetime_rec, suitable for the usage requested in cred_usage,
- for the set of mech_types indicated in actual_mechs, and that
- those credentials can be referenced for subsequent use with
- the handle returned in output_cred_handle.
-
- o GSS_S_BAD_MECH indicates that a mech_type unsupported by the
- GSS-API implementation type was requested, causing the
- credential establishment operation to fail.
-
-
-
-
-
-
-Linn Standards Track [Page 26]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_BAD_NAMETYPE indicates that the provided desired_name is
- uninterpretable or of a type unsupported by the applicable
- underlying GSS-API mechanism(s), so no credentials could be
- established for the accompanying desired_name.
-
- o GSS_S_BAD_NAME indicates that the provided desired_name is
- inconsistent in terms of internally-incorporated type specifier
- information, so no credentials could be established for the
- accompanying desired_name.
-
- o GSS_S_FAILURE indicates that credential establishment failed
- for reasons unspecified at the GSS-API level, including lack
- of authorization to establish and use credentials associated
- with the identity named in the input desired_name argument.
-
- GSS_Acquire_cred() is used to acquire credentials so that a
- principal can (as a function of the input cred_usage parameter)
- initiate and/or accept security contexts under the identity
- represented by the desired_name input argument. On successful
- completion, the returned output_cred_handle result provides a handle
- for subsequent references to the acquired credentials. Typically,
- single-user client processes requesting that default credential
- behavior be applied for context establishment purposes will have no
- need to invoke this call.
-
- A caller may provide the value NULL for desired_name, signifying a
- request for credentials corresponding to a principal identity
- selected by default for the caller. The procedures used by GSS-API
- implementations to select the appropriate principal identity in
- response to such a request are local matters. It is possible that
- multiple pre-established credentials may exist for the same principal
- identity (for example, as a result of multiple user login sessions)
- when GSS_Acquire_cred() is called; the means used in such cases to
- select a specific credential are local matters. The input
- lifetime_req argument to GSS_Acquire_cred() may provide useful
- information for local GSS-API implementations to employ in making
- this disambiguation in a manner which will best satisfy a caller's
- intent.
-
- The lifetime_rec result indicates the length of time for which the
- acquired credentials will be valid, as an offset from the present. A
- mechanism may return a reserved value indicating INDEFINITE if no
- constraints on credential lifetime are imposed. A caller of
- GSS_Acquire_cred() can request a length of time for which acquired
- credentials are to be valid (lifetime_req argument), beginning at the
- present, or can request credentials with a default validity interval.
- (Requests for postdated credentials are not supported within the
- GSS-API.) Certain mechanisms and implementations may bind in
-
-
-
-Linn Standards Track [Page 27]
-
-RFC 2078 GSS-API January 1997
-
-
- credential validity period specifiers at a point preliminary to
- invocation of the GSS_Acquire_cred() call (e.g., in conjunction with
- user login procedures). As a result, callers requesting non-default
- values for lifetime_req must recognize that such requests cannot
- always be honored and must be prepared to accommodate the use of
- returned credentials with different lifetimes as indicated in
- lifetime_rec.
-
- The caller of GSS_Acquire_cred() can explicitly specify a set of
- mech_types which are to be accommodated in the returned credentials
- (desired_mechs argument), or can request credentials for a system-
- defined default set of mech_types. Selection of the system-specified
- default set is recommended in the interests of application
- portability. The actual_mechs return value may be interrogated by the
- caller to determine the set of mechanisms with which the returned
- credentials may be used.
-
-2.1.2: GSS_Release_cred call
-
- Input:
-
- o cred_handle CREDENTIAL HANDLE - NULL specifies that
- the credential elements used when default credential behavior
- is requested be released.
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the credentials referenced by the
- input cred_handle were released for purposes of subsequent
- access by the caller. The effect on other processes which may
- be authorized shared access to such credentials is a local
- matter.
-
- o GSS_S_NO_CRED indicates that no release operation was
- performed, either because the input cred_handle was invalid or
- because the caller lacks authorization to access the
- referenced credentials.
-
- o GSS_S_FAILURE indicates that the release operation failed for
- reasons unspecified at the GSS-API level.
-
-
-
-
-
-Linn Standards Track [Page 28]
-
-RFC 2078 GSS-API January 1997
-
-
- Provides a means for a caller to explicitly request that credentials
- be released when their use is no longer required. Note that system-
- specific credential management functions are also likely to exist,
- for example to assure that credentials shared among processes are
- properly deleted when all affected processes terminate, even if no
- explicit release requests are issued by those processes. Given the
- fact that multiple callers are not precluded from gaining authorized
- access to the same credentials, invocation of GSS_Release_cred()
- cannot be assumed to delete a particular set of credentials on a
- system-wide basis.
-
-2.1.3: GSS_Inquire_cred call
-
- Input:
-
- o cred_handle CREDENTIAL HANDLE -NULL specifies that the
- credential elements used when default credential behavior is
- requested are to be queried
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o cred_name INTERNAL NAME,
-
- o lifetime_rec INTEGER -in seconds, or reserved value for
- INDEFINITE
-
- o cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
- 2=ACCEPT-ONLY
-
- o mech_set SET OF OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the credentials referenced by the
- input cred_handle argument were valid, and that the output
- cred_name, lifetime_rec, and cred_usage values represent,
- respectively, the credentials' associated principal name,
- remaining lifetime, suitable usage modes, and supported
- mechanism types.
-
- o GSS_S_NO_CRED indicates that no information could be returned
- about the referenced credentials, either because the input
- cred_handle was invalid or because the caller lacks
- authorization to access the referenced credentials.
-
-
-
-Linn Standards Track [Page 29]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
- credentials are invalid.
-
- o GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
- credentials have expired.
-
- o GSS_S_FAILURE indicates that the operation failed for
- reasons unspecified at the GSS-API level.
-
- The GSS_Inquire_cred() call is defined primarily for the use of those
- callers which request use of default credential behavior rather than
- acquiring credentials explicitly with GSS_Acquire_cred(). It enables
- callers to determine a credential structure's associated principal
- name, remaining validity period, usability for security context
- initiation and/or acceptance, and supported mechanisms.
-
- For a multi-mechanism credential, the returned "lifetime" specifier
- indicates the shortest lifetime of any of the mechanisms' elements in
- the credential (for either context initiation or acceptance
- purposes).
-
- GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for
- "cred_usage" if both of the following conditions hold:
-
- (1) there exists in the credential an element which allows context
- initiation using some mechanism
-
- (2) there exists in the credential an element which allows context
- acceptance using some mechanism (allowably, but not necessarily,
- one of the same mechanism(s) qualifying for (1)).
-
- If condition (1) holds but not condition (2), GSS_Inquire_cred()
- should indicate INITIATE-ONLY for "cred_usage". If condition (2)
- holds but not condition (1), GSS_Inquire_cred() should indicate
- ACCEPT-ONLY for "cred_usage".
-
- Callers requiring finer disambiguation among available combinations
- of lifetimes, usage modes, and mechanisms should call the
- GSS_Inquire_cred_by_mech() routine, passing that routine one of the
- mech OIDs returned by GSS_Inquire_cred().
-
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 30]
-
-RFC 2078 GSS-API January 1997
-
-
-2.1.4: GSS_Add_cred call
-
- Inputs:
-
- o input_cred_handle CREDENTIAL HANDLE - handle to credential
- structure created with prior GSS_Acquire_cred() or
- GSS_Add_cred() call, or NULL to append elements to the set
- which are applied for the caller when default credential
- behavior is specified.
-
- o desired_name INTERNAL NAME - NULL requests locally-determined
- default
-
- o initiator_time_req INTEGER - in seconds; 0 requests default
-
- o acceptor_time_req INTEGER - in seconds; 0 requests default
-
- o desired_mech OBJECT IDENTIFIER
-
- o cred_usage INTEGER - 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
- 2=ACCEPT-ONLY
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_cred_handle CREDENTIAL HANDLE, - NULL to request that
- credential elements be added "in place" to the credential
- structure identified by input_cred_handle, non-NULL pointer
- to request that a new credential structure and handle be created.
-
- o actual_mechs SET OF OBJECT IDENTIFIER,
-
- o initiator_time_rec INTEGER - in seconds, or reserved value for
- INDEFINITE
-
- o acceptor_time_rec INTEGER - in seconds, or reserved value for
- INDEFINITE
-
- o cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
- 2=ACCEPT-ONLY
-
- o mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms
- supported by resulting credential.
-
-
-
-
-
-Linn Standards Track [Page 31]
-
-RFC 2078 GSS-API January 1997
-
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the credentials referenced by
- the input_cred_handle argument were valid, and that the
- resulting credential from GSS_Add_cred() is valid for the
- durations indicated in initiator_time_rec and acceptor_time_rec,
- suitable for the usage requested in cred_usage, and for the
- mechanisms indicated in actual_mechs.
-
- o GSS_S_DUPLICATE_ELEMENT indicates that the input desired_mech
- specified a mechanism for which the referenced credential
- already contained a credential element with overlapping
- cred_usage and validity time specifiers.
-
- o GSS_S_BAD_MECH indicates that the input desired_mech specified
- a mechanism unsupported by the GSS-API implementation, causing
- the GSS_Add_cred() operation to fail.
-
- o GSS_S_BAD_NAMETYPE indicates that the provided desired_name
- is uninterpretable or of a type unsupported by the applicable
- underlying GSS-API mechanism(s), so the GSS_Add_cred() operation
- could not be performed for that name.
-
- o GSS_S_BAD_NAME indicates that the provided desired_name is
- inconsistent in terms of internally-incorporated type specifier
- information, so the GSS_Add_cred() operation could not be
- performed for that name.
-
- o GSS_S_NO_CRED indicates that the input_cred_handle referenced
- invalid or inaccessible credentials.
-
- o GSS_S_FAILURE indicates that the operation failed for
- reasons unspecified at the GSS-API level, including lack of
- authorization to establish or use credentials representing
- the requested identity.
-
- GSS_Add_cred() enables callers to construct credentials iteratively
- by adding credential elements in successive operations, corresponding
- to different mechanisms. This offers particular value in multi-
- mechanism environments, as the major_status and minor_status values
- returned on each iteration are individually visible and can therefore
- be interpreted unambiguously on a per-mechanism basis.
-
- The same input desired_name, or default reference, should be used on
- all GSS_Acquire_cred() and GSS_Add_cred() calls corresponding to a
- particular credential.
-
-
-
-
-
-Linn Standards Track [Page 32]
-
-RFC 2078 GSS-API January 1997
-
-
-2.1.5: GSS_Inquire_cred_by_mech call
-
- Inputs:
-
- o cred_handle CREDENTIAL HANDLE -- NULL specifies that the
- credential elements used when default credential behavior is
- requested are to be queried
-
- o mech_type OBJECT IDENTIFIER -- specific mechanism for
- which credentials are being queried
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o cred_name INTERNAL NAME, -- guaranteed to be MN
-
- o lifetime_rec_initiate INTEGER -- in seconds, or reserved value for
- INDEFINITE
-
- o lifetime_rec_accept INTEGER -- in seconds, or reserved value for
- INDEFINITE
-
- o cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
- 2=ACCEPT-ONLY
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the credentials referenced by the
- input cred_handle argument were valid, that the mechanism
- indicated by the input mech_type was represented with elements
- within those credentials, and that the output cred_name,
- lifetime_rec_initiate, lifetime_rec_accept, and cred_usage values
- represent, respectively, the credentials' associated principal
- name, remaining lifetimes, and suitable usage modes.
-
- o GSS_S_NO_CRED indicates that no information could be returned
- about the referenced credentials, either because the input
- cred_handle was invalid or because the caller lacks
- authorization to access the referenced credentials.
-
- o GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
- credentials are invalid.
-
- o GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
- credentials have expired.
-
-
-
-Linn Standards Track [Page 33]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_BAD_MECH indicates that the referenced credentials do not
- contain elements for the requested mechanism.
-
- o GSS_S_FAILURE indicates that the operation failed for reasons
- unspecified at the GSS-API level.
-
- The GSS_Inquire_cred_by_mech() call enables callers in multi-
- mechanism environments to acquire specific data about available
- combinations of lifetimes, usage modes, and mechanisms within a
- credential structure. The lifetime_rec_initiate result indicates the
- available lifetime for context initiation purposes; the
- lifetime_rec_accept result indicates the available lifetime for
- context acceptance purposes.
-
-2.2: Context-level calls
-
- This group of calls is devoted to the establishment and management of
- security contexts between peers. A context's initiator calls
- GSS_Init_sec_context(), resulting in generation of a token which the
- caller passes to the target. At the target, that token is passed to
- GSS_Accept_sec_context(). Depending on the underlying mech_type and
- specified options, additional token exchanges may be performed in the
- course of context establishment; such exchanges are accommodated by
- GSS_S_CONTINUE_NEEDED status returns from GSS_Init_sec_context() and
- GSS_Accept_sec_context().
-
- Either party to an established context may invoke
- GSS_Delete_sec_context() to flush context information when a context
- is no longer required. GSS_Process_context_token() is used to
- process received tokens carrying context-level control information.
- GSS_Context_time() allows a caller to determine the length of time
- for which an established context will remain valid.
- GSS_Inquire_context() returns status information describing context
- characteristics. GSS_Wrap_size_limit() allows a caller to determine
- the size of a token which will be generated by a GSS_Wrap()
- operation. GSS_Export_sec_context() and GSS_Import_sec_context()
- enable transfer of active contexts between processes on an end
- system.
-
-2.2.1: GSS_Init_sec_context call
-
- Inputs:
-
- o claimant_cred_handle CREDENTIAL HANDLE, -NULL specifies "use
- default"
-
- o input_context_handle CONTEXT HANDLE, -0 specifies "none assigned
- yet"
-
-
-
-Linn Standards Track [Page 34]
-
-RFC 2078 GSS-API January 1997
-
-
- o targ_name INTERNAL NAME,
-
- o mech_type OBJECT IDENTIFIER, -NULL parameter specifies "use
- default"
-
- o deleg_req_flag BOOLEAN,
-
- o mutual_req_flag BOOLEAN,
-
- o replay_det_req_flag BOOLEAN,
-
- o sequence_req_flag BOOLEAN,
-
- o anon_req_flag BOOLEAN,
-
- o lifetime_req INTEGER,-0 specifies default lifetime
-
- o chan_bindings OCTET STRING,
-
- o input_token OCTET STRING-NULL or token received from target
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_context_handle CONTEXT HANDLE,
-
- o mech_type OBJECT IDENTIFIER, -actual mechanism always
- indicated, never NULL
-
- o output_token OCTET STRING, -NULL or token to pass to context
- target
-
- o deleg_state BOOLEAN,
-
- o mutual_state BOOLEAN,
-
- o replay_det_state BOOLEAN,
-
- o sequence_state BOOLEAN,
-
- o anon_state BOOLEAN,
-
- o trans_state BOOLEAN,
-
- o prot_ready_state BOOLEAN, -- see Section 1.2.7
-
-
-
-Linn Standards Track [Page 35]
-
-RFC 2078 GSS-API January 1997
-
-
- o conf_avail BOOLEAN,
-
- o integ_avail BOOLEAN,
-
- o lifetime_rec INTEGER - in seconds, or reserved value for
- INDEFINITE
-
- This call may block pending network interactions for those mech_types
- in which an authentication server or other network entity must be
- consulted on behalf of a context initiator in order to generate an
- output_token suitable for presentation to a specified target.
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that context-level information was
- successfully initialized, and that the returned output_token
- will provide sufficient information for the target to perform
- per-message processing on the newly-established context.
-
- o GSS_S_CONTINUE_NEEDED indicates that control information in the
- returned output_token must be sent to the target, and that a
- reply must be received and passed as the input_token argument
- to a continuation call to GSS_Init_sec_context(), before
- per-message processing can be performed in conjunction with
- this context.
-
- o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks
- performed on the input_token failed, preventing further
- processing from being performed based on that token.
-
- o GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
- performed on the credential structure referenced by
- claimant_cred_handle failed, preventing further processing from
- being performed using that credential structure.
-
- o GSS_S_BAD_SIG indicates that the received input_token
- contains an incorrect integrity check, so context setup cannot
- be accomplished.
-
- o GSS_S_NO_CRED indicates that no context was established,
- either because the input cred_handle was invalid, because the
- referenced credentials are valid for context acceptor use
- only, or because the caller lacks authorization to access the
- referenced credentials.
-
- o GSS_S_CREDENTIALS_EXPIRED indicates that the credentials
- provided through the input claimant_cred_handle argument are no
- longer valid, so context establishment cannot be completed.
-
-
-
-Linn Standards Track [Page 36]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_BAD_BINDINGS indicates that a mismatch between the
- caller-provided chan_bindings and those extracted from the
- input_token was detected, signifying a security-relevant
- event and preventing context establishment. (This result will
- be returned by GSS_Init_sec_context only for contexts where
- mutual_state is TRUE.)
-
- o GSS_S_OLD_TOKEN indicates that the input_token is too old to
- be checked for integrity. This is a fatal error during context
- establishment.
-
- o GSS_S_DUPLICATE_TOKEN indicates that the input token has a
- correct integrity check, but is a duplicate of a token already
- processed. This is a fatal error during context establishment.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided; this major status will
- be returned only for successor calls following GSS_S_CONTINUE_
- NEEDED status returns.
-
- o GSS_S_BAD_NAMETYPE indicates that the provided targ_name is
- of a type uninterpretable or unsupported by the applicable
- underlying GSS-API mechanism(s), so context establishment
- cannot be completed.
-
- o GSS_S_BAD_NAME indicates that the provided targ_name is
- inconsistent in terms of internally-incorporated type specifier
- information, so context establishment cannot be accomplished.
-
- o GSS_S_BAD_MECH indicates receipt of a context establishment token
- or of a caller request specifying a mechanism unsupported by
- the local system or with the caller's active credentials
-
- o GSS_S_FAILURE indicates that context setup could not be
- accomplished for reasons unspecified at the GSS-API level, and
- that no interface-defined recovery action is available.
-
- This routine is used by a context initiator, and ordinarily emits one
- (or, for the case of a multi-step exchange, more than one)
- output_token suitable for use by the target within the selected
- mech_type's protocol. Using information in the credentials structure
- referenced by claimant_cred_handle, GSS_Init_sec_context()
- initializes the data structures required to establish a security
- context with target targ_name. The targ_name may be any valid
- INTERNAL NAME; it need not be an MN. The claimant_cred_handle must
- correspond to the same valid credentials structure on the initial
- call to GSS_Init_sec_context() and on any successor calls resulting
- from GSS_S_CONTINUE_NEEDED status returns; different protocol
-
-
-
-Linn Standards Track [Page 37]
-
-RFC 2078 GSS-API January 1997
-
-
- sequences modeled by the GSS_S_CONTINUE_NEEDED facility will require
- access to credentials at different points in the context
- establishment sequence.
-
- The input_context_handle argument is 0, specifying "not yet
- assigned", on the first GSS_Init_sec_context() call relating to a
- given context. If successful (i.e., if accompanied by major_status
- GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful, the
- initial GSS_Init_sec_context() call returns a non-zero
- output_context_handle for use in future references to this context.
- Once a non-zero output_context_handle has been returned, GSS-API
- callers should call GSS_Delete_sec_context() to release context-
- related resources if errors occur in later phases of context
- establishment, or when an established context is no longer required.
-
- When continuation attempts to GSS_Init_sec_context() are needed to
- perform context establishment, the previously-returned non-zero
- handle value is entered into the input_context_handle argument and
- will be echoed in the returned output_context_handle argument. On
- such continuation attempts (and only on continuation attempts) the
- input_token value is used, to provide the token returned from the
- context's target.
-
- The chan_bindings argument is used by the caller to provide
- information binding the security context to security-related
- characteristics (e.g., addresses, cryptographic keys) of the
- underlying communications channel. See Section 1.1.6 of this document
- for more discussion of this argument's usage.
-
- The input_token argument contains a message received from the target,
- and is significant only on a call to GSS_Init_sec_context() which
- follows a previous return indicating GSS_S_CONTINUE_NEEDED
- major_status.
-
- It is the caller's responsibility to establish a communications path
- to the target, and to transmit any returned output_token (independent
- of the accompanying returned major_status value) to the target over
- that path. The output_token can, however, be transmitted along with
- the first application-provided input message to be processed by
- GSS_GetMIC() or GSS_Wrap() in conjunction with a successfully-
- established context.
-
- The initiator may request various context-level functions through
- input flags: the deleg_req_flag requests delegation of access rights,
- the mutual_req_flag requests mutual authentication, the
- replay_det_req_flag requests that replay detection features be
- applied to messages transferred on the established context, and the
- sequence_req_flag requests that sequencing be enforced. (See Section
-
-
-
-Linn Standards Track [Page 38]
-
-RFC 2078 GSS-API January 1997
-
-
- 1.2.3 for more information on replay detection and sequencing
- features.) The anon_req_flag requests that the initiator's identity
- not be transferred within tokens to be sent to the acceptor.
-
- Not all of the optionally-requestable features will be available in
- all underlying mech_types. The corresponding return state values
- deleg_state, mutual_state, replay_det_state, and sequence_state
- indicate, as a function of mech_type processing capabilities and
- initiator-provided input flags, the set of features which will be
- active on the context. The returned trans_state value indicates
- whether the context is transferable to other processes through use of
- GSS_Export_sec_context(). These state indicators' values are
- undefined unless either the routine's major_status indicates
- GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with
- GSS_S_CONTINUE_NEEDED major_status; for the latter case, it is
- possible that additional features, not confirmed or indicated along
- with TRUE prot_ready_state, will be confirmed and indicated when
- GSS_S_COMPLETE is subsequently returned.
-
- The returned anon_state and prot_ready_state values are significant
- for both GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED major_status
- returns from GSS_Init_sec_context(). When anon_state is returned
- TRUE, this indicates that neither the current token nor its
- predecessors delivers or has delivered the initiator's identity.
- Callers wishing to perform context establishment only if anonymity
- support is provided should transfer a returned token from
- GSS_Init_sec_context() to the peer only if it is accompanied by a
- TRUE anon_state indicator. When prot_ready_state is returned TRUE in
- conjunction with GSS_S_CONTINUE_NEEDED major_status, this indicates
- that per-message protection operations may be applied on the context:
- see Section 1.2.7 for further discussion of this facility.
-
- Failure to provide the precise set of features requested by the
- caller does not cause context establishment to fail; it is the
- caller's prerogative to delete the context if the feature set
- provided is unsuitable for the caller's use.
-
- The returned mech_type value indicates the specific mechanism
- employed on the context, is valid only along with major_status
- GSS_S_COMPLETE, and will never indicate the value for "default".
- Note that, for the case of certain mechanisms which themselves
- perform negotiation, the returned mech_type result may indicate
- selection of a mechanism identified by an OID different than that
- passed in the input mech_type argument.
-
- The conf_avail return value indicates whether the context supports
- per-message confidentiality services, and so informs the caller
- whether or not a request for encryption through the conf_req_flag
-
-
-
-Linn Standards Track [Page 39]
-
-RFC 2078 GSS-API January 1997
-
-
- input to GSS_Wrap() can be honored. In similar fashion, the
- integ_avail return value indicates whether per-message integrity
- services are available (through either GSS_GetMIC() or GSS_Wrap()) on
- the established context. These state indicators' values are undefined
- unless either the routine's major_status indicates GSS_S_COMPLETE, or
- TRUE prot_ready_state is returned along with GSS_S_CONTINUE_NEEDED
- major_status.
-
- The lifetime_req input specifies a desired upper bound for the
- lifetime of the context to be established, with a value of 0 used to
- request a default lifetime. The lifetime_rec return value indicates
- the length of time for which the context will be valid, expressed as
- an offset from the present; depending on mechanism capabilities,
- credential lifetimes, and local policy, it may not correspond to the
- value requested in lifetime_req. If no constraints on context
- lifetime are imposed, this may be indicated by returning a reserved
- value representing INDEFINITE lifetime_req. The value of lifetime_rec
- is undefined unless the routine's major_status indicates
- GSS_S_COMPLETE.
-
- If the mutual_state is TRUE, this fact will be reflected within the
- output_token. A call to GSS_Accept_sec_context() at the target in
- conjunction with such a context will return a token, to be processed
- by a continuation call to GSS_Init_sec_context(), in order to
- achieve mutual authentication.
-
-2.2.2: GSS_Accept_sec_context call
-
- Inputs:
-
- o acceptor_cred_handle CREDENTIAL HANDLE, -- NULL specifies
- "use default"
-
- o input_context_handle CONTEXT HANDLE, -- 0 specifies
- "not yet assigned"
-
- o chan_bindings OCTET STRING,
-
- o input_token OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o src_name INTERNAL NAME, -- guaranteed to be MN
-
-
-
-
-Linn Standards Track [Page 40]
-
-RFC 2078 GSS-API January 1997
-
-
- o mech_type OBJECT IDENTIFIER,
-
- o output_context_handle CONTEXT HANDLE,
-
- o deleg_state BOOLEAN,
-
- o mutual_state BOOLEAN,
-
- o replay_det_state BOOLEAN,
-
- o sequence_state BOOLEAN,
-
- o anon_state BOOLEAN,
-
- o trans_state BOOLEAN,
-
- o prot_ready_state BOOLEAN, -- see Section 1.2.7 for discussion
-
- o conf_avail BOOLEAN,
-
- o integ_avail BOOLEAN,
-
- o lifetime_rec INTEGER, - in seconds, or reserved value for
- INDEFINITE
-
- o delegated_cred_handle CREDENTIAL HANDLE,
-
- o output_token OCTET STRING -NULL or token to pass to context
- initiator
-
- This call may block pending network interactions for those mech_types
- in which a directory service or other network entity must be
- consulted on behalf of a context acceptor in order to validate a
- received input_token.
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that context-level data structures
- were successfully initialized, and that per-message processing
- can now be performed in conjunction with this context.
-
- o GSS_S_CONTINUE_NEEDED indicates that control information in the
- returned output_token must be sent to the initiator, and that
- a response must be received and passed as the input_token
- argument to a continuation call to GSS_Accept_sec_context(),
- before per-message processing can be performed in conjunction
- with this context.
-
-
-
-
-Linn Standards Track [Page 41]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
- on the input_token failed, preventing further processing from
- being performed based on that token.
-
- o GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
- performed on the credential structure referenced by
- acceptor_cred_handle failed, preventing further processing from
- being performed using that credential structure.
-
- o GSS_S_BAD_SIG indicates that the received input_token contains
- an incorrect integrity check, so context setup cannot be
- accomplished.
-
- o GSS_S_DUPLICATE_TOKEN indicates that the integrity check on the
- received input_token was correct, but that the input_token
- was recognized as a duplicate of an input_token already
- processed. No new context is established.
-
- o GSS_S_OLD_TOKEN indicates that the integrity check on the received
- input_token was correct, but that the input_token is too old
- to be checked for duplication against previously-processed
- input_tokens. No new context is established.
-
- o GSS_S_NO_CRED indicates that no context was established, either
- because the input cred_handle was invalid, because the
- referenced credentials are valid for context initiator use
- only, or because the caller lacks authorization to access the
- referenced credentials.
-
- o GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided
- through the input acceptor_cred_handle argument are no
- longer valid, so context establishment cannot be completed.
-
- o GSS_S_BAD_BINDINGS indicates that a mismatch between the
- caller-provided chan_bindings and those extracted from the
- input_token was detected, signifying a security-relevant
- event and preventing context establishment.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided; this major status will
- be returned only for successor calls following GSS_S_CONTINUE_
- NEEDED status returns.
-
- o GSS_S_BAD_MECH indicates receipt of a context establishment token
- specifying a mechanism unsupported by the local system or with
- the caller's active credentials.
-
-
-
-
-
-Linn Standards Track [Page 42]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_FAILURE indicates that context setup could not be
- accomplished for reasons unspecified at the GSS-API level, and
- that no interface-defined recovery action is available.
-
- The GSS_Accept_sec_context() routine is used by a context target.
- Using information in the credentials structure referenced by the
- input acceptor_cred_handle, it verifies the incoming input_token and
- (following the successful completion of a context establishment
- sequence) returns the authenticated src_name and the mech_type used.
- The returned src_name is guaranteed to be an MN, processed by the
- mechanism under which the context was established. The
- acceptor_cred_handle must correspond to the same valid credentials
- structure on the initial call to GSS_Accept_sec_context() and on any
- successor calls resulting from GSS_S_CONTINUE_NEEDED status returns;
- different protocol sequences modeled by the GSS_S_CONTINUE_NEEDED
- mechanism will require access to credentials at different points in
- the context establishment sequence.
-
- The input_context_handle argument is 0, specifying "not yet
- assigned", on the first GSS_Accept_sec_context() call relating to a
- given context. If successful (i.e., if accompanied by major_status
- GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful, the
- initial GSS_Accept_sec_context() call returns a non-zero
- output_context_handle for use in future references to this context.
- Once a non-zero output_context_handle has been returned, GSS-API
- callers should call GSS_Delete_sec_context() to release context-
- related resources if errors occur in later phases of context
- establishment, or when an established context is no longer required.
-
- The chan_bindings argument is used by the caller to provide
- information binding the security context to security-related
- characteristics (e.g., addresses, cryptographic keys) of the
- underlying communications channel. See Section 1.1.6 of this document
- for more discussion of this argument's usage.
-
- The returned state results (deleg_state, mutual_state,
- replay_det_state, sequence_state, anon_state, trans_state, and
- prot_ready_state) reflect the same information as described for
- GSS_Init_sec_context(), and their values are significant under the
- same return state conditions.
-
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 43]
-
-RFC 2078 GSS-API January 1997
-
-
- The conf_avail return value indicates whether the context supports
- per-message confidentiality services, and so informs the caller
- whether or not a request for encryption through the conf_req_flag
- input to GSS_Wrap() can be honored. In similar fashion, the
- integ_avail return value indicates whether per-message integrity
- services are available (through either GSS_GetMIC() or GSS_Wrap())
- on the established context. These values are significant under the
- same return state conditions as described under
- GSS_Init_sec_context().
-
- The lifetime_rec return value is significant only in conjunction with
- GSS_S_COMPLETE major_status, and indicates the length of time for
- which the context will be valid, expressed as an offset from the
- present.
-
- The mech_type return value indicates the specific mechanism employed
- on the context, is valid only along with major_status GSS_S_COMPLETE,
- and will never indicate the value for "default".
-
- The delegated_cred_handle result is significant only when deleg_state
- is TRUE, and provides a means for the target to reference the
- delegated credentials. The output_token result, when non-NULL,
- provides a context-level token to be returned to the context
- initiator to continue a multi-step context establishment sequence. As
- noted with GSS_Init_sec_context(), any returned token should be
- transferred to the context's peer (in this case, the context
- initiator), independent of the value of the accompanying returned
- major_status.
-
- Note: A target must be able to distinguish a context-level
- input_token, which is passed to GSS_Accept_sec_context(), from the
- per-message data elements passed to GSS_VerifyMIC() or GSS_Unwrap().
- These data elements may arrive in a single application message, and
- GSS_Accept_sec_context() must be performed before per-message
- processing can be performed successfully.
-
-2.2.3: GSS_Delete_sec_context call
-
- Input:
-
- o context_handle CONTEXT HANDLE
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
-
-
-
-Linn Standards Track [Page 44]
-
-RFC 2078 GSS-API January 1997
-
-
- o output_context_token OCTET STRING
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the context was recognized, and that
- relevant context-specific information was flushed. If the caller
- provides a non-null buffer to receive an output_context_token, and
- the mechanism returns a non-NULL token into that buffer, the
- returned output_context_token is ready for transfer to the
- context's peer.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided, so no deletion was
- performed.
-
- o GSS_S_FAILURE indicates that the context is recognized, but
- that the GSS_Delete_sec_context() operation could not be
- performed for reasons unspecified at the GSS-API level.
-
- This call may block pending network interactions for mech_types in
- which active notification must be made to a central server when a
- security context is to be deleted.
-
- This call can be made by either peer in a security context, to flush
- context-specific information. If a non-null output_context_token
- parameter is provided by the caller, an output_context_token may be
- returned to the caller. If an output_context_token is provided to
- the caller, it can be passed to the context's peer to inform the
- peer's GSS-API implementation that the peer's corresponding context
- information can also be flushed. (Once a context is established, the
- peers involved are expected to retain cached credential and context-
- related information until the information's expiration time is
- reached or until a GSS_Delete_sec_context() call is made.)
-
- The facility for context_token usage to signal context deletion is
- retained for compatibility with GSS-API Version 1. For current
- usage, it is recommended that both peers to a context invoke
- GSS_Delete_sec_context() independently, passing a null
- output_context_token buffer to indicate that no context_token is
- required. Implementations of GSS_Delete_sec_context() should delete
- relevant locally-stored context information.
-
- Attempts to perform per-message processing on a deleted context will
- result in error returns.
-
-
-
-
-
-
-
-Linn Standards Track [Page 45]
-
-RFC 2078 GSS-API January 1997
-
-
-2.2.4: GSS_Process_context_token call
-
- Inputs:
-
- o context_handle CONTEXT HANDLE,
-
- o input_context_token OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the input_context_token was
- successfully processed in conjunction with the context
- referenced by context_handle.
-
- o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks
- performed on the received context_token failed, preventing
- further processing from being performed with that token.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided.
-
- o GSS_S_FAILURE indicates that the context is recognized, but
- that the GSS_Process_context_token() operation could not be
- performed for reasons unspecified at the GSS-API level.
-
- This call is used to process context_tokens received from a peer once
- a context has been established, with corresponding impact on
- context-level state information. One use for this facility is
- processing of the context_tokens generated by
- GSS_Delete_sec_context(); GSS_Process_context_token() will not block
- pending network interactions for that purpose. Another use is to
- process tokens indicating remote-peer context establishment failures
- after the point where the local GSS-API implementation has already
- indicated GSS_S_COMPLETE status.
-
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 46]
-
-RFC 2078 GSS-API January 1997
-
-
-2.2.5: GSS_Context_time call
-
- Input:
-
- o context_handle CONTEXT HANDLE,
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o lifetime_rec INTEGER - in seconds, or reserved value for
- INDEFINITE
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the referenced context is valid,
- and will remain valid for the amount of time indicated in
- lifetime_rec.
-
- o GSS_S_CONTEXT_EXPIRED indicates that data items related to the
- referenced context have expired.
-
- o GSS_S_CREDENTIALS_EXPIRED indicates that the context is
- recognized, but that its associated credentials have expired.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided.
-
- o GSS_S_FAILURE indicates that the requested operation failed for
- reasons unspecified at the GSS-API level.
-
- This call is used to determine the amount of time for which a
- currently established context will remain valid.
-
-2.2.6: GSS_Inquire_context call
-
- Input:
-
- o context_handle CONTEXT HANDLE,
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
-
-
-
-Linn Standards Track [Page 47]
-
-RFC 2078 GSS-API January 1997
-
-
- o src_name INTERNAL NAME, -- name of context initiator,
- -- guaranteed to be MN
-
- o targ_name INTERNAL NAME, -- name of context target,
- -- guaranteed to be MN
-
-
- o lifetime_rec INTEGER -- in seconds, or reserved value for
- INDEFINITE,
-
- o mech_type OBJECT IDENTIFIER, -- the mechanism supporting this
- security context
-
- o deleg_state BOOLEAN,
-
- o mutual_state BOOLEAN,
-
- o replay_det_state BOOLEAN,
-
- o sequence_state BOOLEAN,
-
- o anon_state BOOLEAN,
-
- o trans_state BOOLEAN,
-
- o prot_ready_state BOOLEAN,
-
- o conf_avail BOOLEAN,
-
- o integ_avail BOOLEAN,
-
- o locally_initiated BOOLEAN, -- TRUE if initiator, FALSE if acceptor
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the referenced context is valid
- and that src_name, targ_name, lifetime_rec, mech_type, deleg_state,
- mutual_state, replay_det_state, sequence_state, anon_state,
- trans_state, prot_ready_state, conf_avail, integ_avail, and
- locally_initiated return values describe the corresponding
- characteristics of the context.
-
- o GSS_S_CONTEXT_EXPIRED indicates that the provided input
- context_handle is recognized, but that the referenced context
- has expired. Return values other than major_status and
- minor_status are undefined.
-
-
-
-
-
-Linn Standards Track [Page 48]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided. Return values other than
- major_status and minor_status are undefined.
-
- o GSS_S_FAILURE indicates that the requested operation failed for
- reasons unspecified at the GSS-API level. Return values other than
- major_status and minor_status are undefined.
-
- This call is used to extract information describing characteristics
- of a security context.
-
-2.2.7: GSS_Wrap_size_limit call
-
- Inputs:
-
- o context_handle CONTEXT HANDLE,
-
- o qop INTEGER,
-
- o output_size INTEGER
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o max_input_size INTEGER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates a successful token size determination:
- an input message with a length in octets equal to the
- returned max_input_size value will, when passed to GSS_Wrap()
- for processing on the context identified by the context_handle
- parameter and with the quality of protection specifier provided
- in the qop parameter, yield an output token no larger than the
- value of the provided output_size parameter.
-
- o GSS_S_CONTEXT_EXPIRED indicates that the provided input
- context_handle is recognized, but that the referenced context
- has expired. Return values other than major_status and
- minor_status are undefined.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided. Return values other than
- major_status and minor_status are undefined.
-
-
-
-
-Linn Standards Track [Page 49]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_BAD_QOP indicates that the provided QOP value is not
- recognized or supported for the context.
-
- o GSS_S_FAILURE indicates that the requested operation failed for
- reasons unspecified at the GSS-API level. Return values other than
- major_status and minor_status are undefined.
-
- This call is used to determine the largest input datum which may be
- passed to GSS_Wrap() without yielding an output token larger than a
- caller-specified value.
-
-2.2.8: GSS_Export_sec_context call
-
- Inputs:
-
- o context_handle CONTEXT HANDLE
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o interprocess_token OCTET STRING
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the referenced context has been
- successfully exported to a representation in the interprocess_token,
- and is no longer available for use by the caller.
-
- o GSS_S_UNAVAILABLE indicates that the context export facility
- is not available for use on the referenced context. (This status
- should occur only for contexts for which the trans_state value is
- FALSE.) Return values other than major_status and minor_status are
- undefined.
-
- o GSS_S_CONTEXT_EXPIRED indicates that the provided input
- context_handle is recognized, but that the referenced context has
- expired. Return values other than major_status and minor_status are
- undefined.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided. Return values other than
- major_status and minor_status are undefined.
-
-
-
-
-
-
-Linn Standards Track [Page 50]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_FAILURE indicates that the requested operation failed for
- reasons unspecified at the GSS-API level. Return values other than
- major_status and minor_status are undefined.
-
- This call generates an interprocess token for transfer to another
- process within an end system, in order to transfer control of a
- security context to that process. The recipient of the interprocess
- token will call GSS_Import_sec_context() to accept the transfer. The
- GSS_Export_sec_context() operation is defined for use only with
- security contexts which are fully and successfully established (i.e.,
- those for which GSS_Init_sec_context() and GSS_Accept_sec_context()
- have returned GSS_S_COMPLETE major_status).
-
- To ensure portability, a caller of GSS_Export_sec_context() must not
- assume that a context may continue to be used once it has been
- exported; following export, the context referenced by the
- context_handle cannot be assumed to remain valid. Further, portable
- callers must not assume that a given interprocess token can be
- imported by GSS_Import_sec_context() more than once, thereby creating
- multiple instantiations of a single context. GSS-API implementations
- may detect and reject attempted multiple imports, but are not
- required to do so.
-
- The internal representation contained within the interprocess token
- is an implementation-defined local matter. Interprocess tokens
- cannot be assumed to be transferable across different GSS-API
- implementations.
-
- It is recommended that GSS-API implementations adopt policies suited
- to their operational environments in order to define the set of
- processes eligible to import a context, but specific constraints in
- this area are local matters. Candidate examples include transfers
- between processes operating on behalf of the same user identity, or
- processes comprising a common job. However, it may be impossible to
- enforce such policies in some implementations.
-
- In support of the above goals, implementations may protect the
- transferred context data by using cryptography to protect data within
- the interprocess token, or by using interprocess tokens as a means to
- reference local interprocess communication facilities (protected by
- other means) rather than storing the context data directly within the
- tokens.
-
- Transfer of an open context may, for certain mechanisms and
- implementations, reveal data about the credential which was used to
- establish the context. Callers should, therefore, be cautious about
- the trustworthiness of processes to which they transfer contexts.
- Although the GSS-API implementation may provide its own set of
-
-
-
-Linn Standards Track [Page 51]
-
-RFC 2078 GSS-API January 1997
-
-
- protections over the exported context, the caller is responsible for
- protecting the interprocess token from disclosure, and for taking
- care that the context is transferred to an appropriate destination
- process.
-
-2.2.9: GSS_Import_sec_context call
-
- Inputs:
-
- o interprocess_token OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o context_handle CONTEXT HANDLE
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the context represented by the
- input interprocess_token has been successfully transferred to
- the caller, and is available for future use via the output
- context_handle.
-
- o GSS_S_CONTEXT_EXPIRED indicates that the context represented by
- the input interprocess_token has expired. Return values other
- than major_status and minor_status are undefined.
-
- o GSS_S_NO_CONTEXT indicates that the context represented by the
- input interprocess_token was invalid. Return values other than
- major_status and minor_status are undefined.
-
- o GSS_S_DEFECTIVE_TOKEN indicates that the input interprocess_token
- was defective. Return values other than major_status and
- minor_status are undefined.
-
- o GSS_S_UNAVAILABLE indicates that the context import facility
- is not available for use on the referenced context. Return values
- other than major_status and minor_status are undefined.
-
- o GSS_S_UNAUTHORIZED indicates that the context represented by
- the input interprocess_token is unauthorized for transfer to the
- caller. Return values other than major_status and minor_status
- are undefined.
-
-
-
-
-
-Linn Standards Track [Page 52]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_FAILURE indicates that the requested operation failed for
- reasons unspecified at the GSS-API level. Return values other than
- major_status and minor_status are undefined.
-
- This call processes an interprocess token generated by
- GSS_Export_sec_context(), making the transferred context available
- for use by the caller. After a successful GSS_Import_sec_context()
- operation, the imported context is available for use by the importing
- process.
-
- For further discussion of the security and authorization issues
- regarding this call, please see the discussion in Section 2.2.8.
-
-2.3: Per-message calls
-
- This group of calls is used to perform per-message protection
- processing on an established security context. None of these calls
- block pending network interactions. These calls may be invoked by a
- context's initiator or by the context's target. The four members of
- this group should be considered as two pairs; the output from
- GSS_GetMIC() is properly input to GSS_VerifyMIC(), and the output
- from GSS_Wrap() is properly input to GSS_Unwrap().
-
- GSS_GetMIC() and GSS_VerifyMIC() support data origin authentication
- and data integrity services. When GSS_GetMIC() is invoked on an
- input message, it yields a per-message token containing data items
- which allow underlying mechanisms to provide the specified security
- services. The original message, along with the generated per-message
- token, is passed to the remote peer; these two data elements are
- processed by GSS_VerifyMIC(), which validates the message in
- conjunction with the separate token.
-
- GSS_Wrap() and GSS_Unwrap() support caller-requested confidentiality
- in addition to the data origin authentication and data integrity
- services offered by GSS_GetMIC() and GSS_VerifyMIC(). GSS_Wrap()
- outputs a single data element, encapsulating optionally enciphered
- user data as well as associated token data items. The data element
- output from GSS_Wrap() is passed to the remote peer and processed by
- GSS_Unwrap() at that system. GSS_Unwrap() combines decipherment (as
- required) with validation of data items related to authentication and
- integrity.
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 53]
-
-RFC 2078 GSS-API January 1997
-
-
-2.3.1: GSS_GetMIC call
-
- Note: This call is functionally equivalent to the GSS_Sign call as
- defined in previous versions of this specification. In the interests
- of backward compatibility, it is recommended that implementations
- support this function under both names for the present; future
- references to this function as GSS_Sign are deprecated.
-
- Inputs:
-
- o context_handle CONTEXT HANDLE,
-
- o qop_req INTEGER,-0 specifies default QOP
-
- o message OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o per_msg_token OCTET STRING
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that an integrity check, suitable for an
- established security context, was successfully applied and
- that the message and corresponding per_msg_token are ready
- for transmission.
-
- o GSS_S_CONTEXT_EXPIRED indicates that context-related data
- items have expired, so that the requested operation cannot be
- performed.
-
- o GSS_S_CREDENTIALS_EXPIRED indicates that the context is recognized,
- but that its associated credentials have expired, so
- that the requested operation cannot be performed.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided.
-
- o GSS_S_BAD_QOP indicates that the provided QOP value is not
- recognized or supported for the context.
-
- o GSS_S_FAILURE indicates that the context is recognized, but
- that the requested operation could not be performed for
- reasons unspecified at the GSS-API level.
-
-
-
-Linn Standards Track [Page 54]
-
-RFC 2078 GSS-API January 1997
-
-
- Using the security context referenced by context_handle, apply an
- integrity check to the input message (along with timestamps and/or
- other data included in support of mech_type-specific mechanisms) and
- return the result in per_msg_token. The qop_req parameter,
- interpretation of which is discussed in Section 1.2.4, allows
- quality-of-protection control. The caller passes the message and the
- per_msg_token to the target.
-
- The GSS_GetMIC() function completes before the message and
- per_msg_token is sent to the peer; successful application of
- GSS_GetMIC() does not guarantee that a corresponding GSS_VerifyMIC()
- has been (or can necessarily be) performed successfully when the
- message arrives at the destination.
-
- Mechanisms which do not support per-message protection services
- should return GSS_S_FAILURE if this routine is called.
-
-2.3.2: GSS_VerifyMIC call
-
- Note: This call is functionally equivalent to the GSS_Verify call as
- defined in previous versions of this specification. In the interests
- of backward compatibility, it is recommended that implementations
- support this function under both names for the present; future
- references to this function as GSS_Verify are deprecated.
-
- Inputs:
-
- o context_handle CONTEXT HANDLE,
-
- o message OCTET STRING,
-
- o per_msg_token OCTET STRING
-
- Outputs:
-
- o qop_state INTEGER,
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the message was successfully
- verified.
-
-
-
-
-
-
-Linn Standards Track [Page 55]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
- on the received per_msg_token failed, preventing
- further processing from being performed with that token.
-
- o GSS_S_BAD_SIG indicates that the received per_msg_token contains
- an incorrect integrity check for the message.
-
- o GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN,
- and GSS_S_GAP_TOKEN values appear in conjunction with the
- optional per-message replay detection features described
- in Section 1.2.3; their semantics are described in that section.
-
- o GSS_S_CONTEXT_EXPIRED indicates that context-related data
- items have expired, so that the requested operation cannot be
- performed.
-
- o GSS_S_CREDENTIALS_EXPIRED indicates that the context is
- recognized,
- but that its associated credentials have expired, so
- that the requested operation cannot be performed.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided.
-
- o GSS_S_FAILURE indicates that the context is recognized, but
- that the GSS_VerifyMIC() operation could not be performed for
- reasons unspecified at the GSS-API level.
-
- Using the security context referenced by context_handle, verify that
- the input per_msg_token contains an appropriate integrity check for
- the input message, and apply any active replay detection or
- sequencing features. Return an indication of the quality-of-
- protection applied to the processed message in the qop_state result.
- Since the GSS_VerifyMIC() routine never provides a confidentiality
- service, its implementations should not return non-zero values in the
- confidentiality fields of the output qop_state.
-
- Mechanisms which do not support per-message protection services
- should return GSS_S_FAILURE if this routine is called.
-
-2.3.3: GSS_Wrap call
-
- Note: This call is functionally equivalent to the GSS_Seal call as
- defined in previous versions of this specification. In the interests
- of backward compatibility, it is recommended that implementations
- support this function under both names for the present; future
- references to this function as GSS_Seal are deprecated.
-
-
-
-
-Linn Standards Track [Page 56]
-
-RFC 2078 GSS-API January 1997
-
-
- Inputs:
-
- o context_handle CONTEXT HANDLE,
-
- o conf_req_flag BOOLEAN,
-
- o qop_req INTEGER,-0 specifies default QOP
-
- o input_message OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o conf_state BOOLEAN,
-
- o output_message OCTET STRING
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the input_message was successfully
- processed and that the output_message is ready for
- transmission.
-
- o GSS_S_CONTEXT_EXPIRED indicates that context-related data
- items have expired, so that the requested operation cannot be
- performed.
-
- o GSS_S_CREDENTIALS_EXPIRED indicates that the context is
- recognized,
- but that its associated credentials have expired, so
- that the requested operation cannot be performed.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided.
-
- o GSS_S_BAD_QOP indicates that the provided QOP value is not
- recognized or supported for the context.
-
- o GSS_S_FAILURE indicates that the context is recognized, but
- that the GSS_Wrap() operation could not be performed for
- reasons unspecified at the GSS-API level.
-
- Performs the data origin authentication and data integrity functions
- of GSS_GetMIC(). If the input conf_req_flag is TRUE, requests that
- confidentiality be applied to the input_message. Confidentiality may
-
-
-
-Linn Standards Track [Page 57]
-
-RFC 2078 GSS-API January 1997
-
-
- not be supported in all mech_types or by all implementations; the
- returned conf_state flag indicates whether confidentiality was
- provided for the input_message. The qop_req parameter, interpretation
- of which is discussed in Section 1.2.4, allows quality-of-protection
- control.
-
- In all cases, the GSS_Wrap() call yields a single output_message
- data element containing (optionally enciphered) user data as well as
- control information.
-
- Mechanisms which do not support per-message protection services
- should return GSS_S_FAILURE if this routine is called.
-
-2.3.4: GSS_Unwrap call
-
- Note: This call is functionally equivalent to the GSS_Unseal call as
- defined in previous versions of this specification. In the interests
- of backward compatibility, it is recommended that implementations
- support this function under both names for the present; future
- references to this function as GSS_Unseal are deprecated.
-
- Inputs:
-
- o context_handle CONTEXT HANDLE,
-
- o input_message OCTET STRING
-
- Outputs:
-
- o conf_state BOOLEAN,
-
- o qop_state INTEGER,
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_message OCTET STRING
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the input_message was
- successfully processed and that the resulting output_message is
- available.
-
- o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
- on the per_msg_token extracted from the input_message
- failed, preventing further processing from being performed.
-
-
-
-Linn Standards Track [Page 58]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_BAD_SIG indicates that an incorrect integrity check was
- detected
- for the message.
-
- o GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN,
- and GSS_S_GAP_TOKEN values appear in conjunction with the
- optional per-message replay detection features described
- in Section 1.2.3; their semantics are described in that section.
-
- o GSS_S_CONTEXT_EXPIRED indicates that context-related data
- items have expired, so that the requested operation cannot be
- performed.
-
- o GSS_S_CREDENTIALS_EXPIRED indicates that the context is
- recognized,
- but that its associated credentials have expired, so
- that the requested operation cannot be performed.
-
- o GSS_S_NO_CONTEXT indicates that no valid context was recognized
- for the input context_handle provided.
-
- o GSS_S_FAILURE indicates that the context is recognized, but
- that the GSS_Unwrap() operation could not be performed for
- reasons unspecified at the GSS-API level.
-
- Processes a data element generated (and optionally enciphered) by
- GSS_Wrap(), provided as input_message. The returned conf_state value
- indicates whether confidentiality was applied to the input_message.
- If conf_state is TRUE, GSS_Unwrap() deciphers the input_message.
- Returns an indication of the quality-of-protection applied to the
- processed message in the qop_state result. GSS_Wrap() performs the
- data integrity and data origin authentication checking functions of
- GSS_VerifyMIC() on the plaintext data. Plaintext data is returned in
- output_message.
-
- Mechanisms which do not support per-message protection services
- should return GSS_S_FAILURE if this routine is called.
-
-2.4: Support calls
-
- This group of calls provides support functions useful to GSS-API
- callers, independent of the state of established contexts. Their
- characterization with regard to blocking or non-blocking status in
- terms of network interactions is unspecified.
-
-
-
-
-
-
-
-Linn Standards Track [Page 59]
-
-RFC 2078 GSS-API January 1997
-
-
-2.4.1: GSS_Display_status call
-
- Inputs:
-
- o status_value INTEGER,-GSS-API major_status or minor_status
- return value
-
- o status_type INTEGER,-1 if major_status, 2 if minor_status
-
- o mech_type OBJECT IDENTIFIER-mech_type to be used for minor_
- status translation
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o status_string_set SET OF OCTET STRING
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that a valid printable status
- representation (possibly representing more than one status event
- encoded within the status_value) is available in the returned
- status_string_set.
-
- o GSS_S_BAD_MECH indicates that translation in accordance with an
- unsupported mech_type was requested, so translation could not
- be performed.
-
- o GSS_S_BAD_STATUS indicates that the input status_value was
- invalid, or that the input status_type carried a value other
- than 1 or 2, so translation could not be performed.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- Provides a means for callers to translate GSS-API-returned major and
- minor status codes into printable string representations.
-
-2.4.2: GSS_Indicate_mechs call
-
- Input:
-
- o (none)
-
-
-
-
-
-Linn Standards Track [Page 60]
-
-RFC 2078 GSS-API January 1997
-
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o mech_set SET OF OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that a set of available mechanisms has
- been returned in mech_set.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- Allows callers to determine the set of mechanism types available on
- the local system. This call is intended for support of specialized
- callers who need to request non-default mech_type sets from
- GSS_Acquire_cred(), and should not be needed by other callers.
-
-2.4.3: GSS_Compare_name call
-
- Inputs:
-
- o name1 INTERNAL NAME,
-
- o name2 INTERNAL NAME
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o name_equal BOOLEAN
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that name1 and name2 were comparable,
- and that the name_equal result indicates whether name1 and
- name2 represent the same entity.
-
- o GSS_S_BAD_NAMETYPE indicates that one or both of name1 and
- name2 contained internal type specifiers uninterpretable
- by the applicable underlying GSS-API mechanism(s), or that
- the two names' types are different and incomparable, so that
- the comparison operation could not be completed.
-
-
-
-Linn Standards Track [Page 61]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_BAD_NAME indicates that one or both of the input names
- was ill-formed in terms of its internal type specifier, so
- the comparison operation could not be completed.
-
- o GSS_S_FAILURE indicates that the call's operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- Allows callers to compare two internal name representations to
- determine whether they refer to the same entity. If either name
- presented to GSS_Compare_name() denotes an anonymous principal,
- GSS_Compare_name() shall indicate FALSE. It is not required that
- either or both inputs name1 and name2 be MNs; for some
- implementations and cases, GSS_S_BAD_NAMETYPE may be returned,
- indicating name incomparability, for the case where neither input
- name is an MN.
-
-2.4.4: GSS_Display_name call
-
- Inputs:
-
- o name INTERNAL NAME
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o name_string OCTET STRING,
-
- o name_type OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that a valid printable name
- representation is available in the returned name_string.
-
- o GSS_S_BAD_NAMETYPE indicates that the provided name was of a
- type uninterpretable by the applicable underlying GSS-API
- mechanism(s), so no printable representation could be generated.
-
- o GSS_S_BAD_NAME indicates that the contents of the provided name
- were inconsistent with the internally-indicated name type, so
- no printable representation could be generated.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
-
-
-
-Linn Standards Track [Page 62]
-
-RFC 2078 GSS-API January 1997
-
-
- Allows callers to translate an internal name representation into a
- printable form with associated namespace type descriptor. The syntax
- of the printable form is a local matter.
-
- If the input name represents an anonymous identity, a reserved value
- (GSS_C_NT_ANONYMOUS) shall be returned for name_type.
-
-2.4.5: GSS_Import_name call
-
- Inputs:
-
- o input_name_string OCTET STRING,
-
- o input_name_type OBJECT IDENTIFIER
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_name INTERNAL NAME
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that a valid name representation is
- output in output_name and described by the type value in
- output_name_type.
-
- o GSS_S_BAD_NAMETYPE indicates that the input_name_type is unsupported
- by the applicable underlying GSS-API mechanism(s), so the import
- operation could not be completed.
-
- o GSS_S_BAD_NAME indicates that the provided input_name_string
- is ill-formed in terms of the input_name_type, so the import
- operation could not be completed.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- Allows callers to provide a name representation as a contiguous octet
- string, designate the type of namespace in conjunction with which it
- should be parsed, and convert that representation to an internal form
- suitable for input to other GSS-API routines. The syntax of the
- input_name_string is defined in conjunction with its associated name
- type; depending on the input_name_type, the associated
- input_name_string may or may not be a printable string. Note: The
- input_name_type argument serves to describe and qualify the
-
-
-
-Linn Standards Track [Page 63]
-
-RFC 2078 GSS-API January 1997
-
-
- interpretation of the associated input_name_string; it does not
- specify the data type of the returned output_name.
-
- If a mechanism claims support for a particular name type, its
- GSS_Import_name() operation shall be able to accept all possible
- values conformant to the external name syntax as defined for that
- name type. These imported values may correspond to:
-
- (1) locally registered entities (for which credentials may be
- acquired),
-
- (2) non-local entities (for which local credentials cannot be
- acquired, but which may be referenced as targets of initiated
- security contexts or initiators of accepted security contexts), or
- to
-
- (3) neither of the above.
-
- Determination of whether a particular name belongs to class (1), (2),
- or (3) as described above is not guaranteed to be performed by the
- GSS_Import_name() function.
-
- The internal name generated by a GSS_Import_name() operation may be a
- single-mechanism MN, and is likely to be an MN within a single-
- mechanism implementation, but portable callers must not depend on
- this property (and must not, therefore, assume that the output from
- GSS_Import_name() can be passed directly to GSS_Export_name() without
- first being processed through GSS_Canonicalize_name()).
-
-2.4.6: GSS_Release_name call
-
- Inputs:
-
- o name INTERNAL NAME
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the storage associated with the
- input name was successfully released.
-
- o GSS_S_BAD_NAME indicates that the input name argument did not
- contain a valid name.
-
-
-
-Linn Standards Track [Page 64]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- Allows callers to release the storage associated with an internal
- name representation. This call's specific behavior depends on the
- language and programming environment within which a GSS-API
- implementation operates, and is therefore detailed within applicable
- bindings specifications; in particular, this call may be superfluous
- within bindings where memory management is automatic.
-
-2.4.7: GSS_Release_buffer call
-
- Inputs:
-
- o buffer OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the storage associated with the
- input buffer was successfully released.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- Allows callers to release the storage associated with an OCTET STRING
- buffer allocated by another GSS-API call. This call's specific
- behavior depends on the language and programming environment within
- which a GSS-API implementation operates, and is therefore detailed
- within applicable bindings specifications; in particular, this call
- may be superfluous within bindings where memory management is
- automatic.
-
-2.4.8: GSS_Release_OID_set call
-
- Inputs:
-
- o buffer SET OF OBJECT IDENTIFIER
-
- Outputs:
-
- o major_status INTEGER,
-
-
-
-
-Linn Standards Track [Page 65]
-
-RFC 2078 GSS-API January 1997
-
-
- o minor_status INTEGER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the storage associated with the
- input object identifier set was successfully released.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- Allows callers to release the storage associated with an object
- identifier set object allocated by another GSS-API call. This call's
- specific behavior depends on the language and programming environment
- within which a GSS-API implementation operates, and is therefore
- detailed within applicable bindings specifications; in particular,
- this call may be superfluous within bindings where memory management
- is automatic.
-
-2.4.9: GSS_Create_empty_OID_set call
-
- Inputs:
-
- o (none)
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o oid_set SET OF OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates successful completion
-
- o GSS_S_FAILURE indicates that the operation failed
-
- Creates an object identifier set containing no object identifiers, to
- which members may be subsequently added using the
- GSS_Add_OID_set_member() routine. These routines are intended to be
- used to construct sets of mechanism object identifiers, for input to
- GSS_Acquire_cred().
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 66]
-
-RFC 2078 GSS-API January 1997
-
-
-2.4.10: GSS_Add_OID_set_member call
-
- Inputs:
-
- o member_oid OBJECT IDENTIFIER,
-
- o oid_set SET OF OBJECT IDENTIFIER
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates successful completion
-
- o GSS_S_FAILURE indicates that the operation failed
-
- Adds an Object Identifier to an Object Identifier set. This routine
- is intended for use in conjunction with GSS_Create_empty_OID_set()
- when constructing a set of mechanism OIDs for input to
- GSS_Acquire_cred().
-
-2.4.11: GSS_Test_OID_set_member call
-
- Inputs:
-
- o member OBJECT IDENTIFIER,
-
- o set SET OF OBJECT IDENTIFIER
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o present BOOLEAN
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates successful completion
-
- o GSS_S_FAILURE indicates that the operation failed
-
-
-
-
-
-Linn Standards Track [Page 67]
-
-RFC 2078 GSS-API January 1997
-
-
- Interrogates an Object Identifier set to determine whether a
- specified Object Identifier is a member. This routine is intended to
- be used with OID sets returned by GSS_Indicate_mechs(),
- GSS_Acquire_cred(), and GSS_Inquire_cred().
-
-2.4.12: GSS_Release_OID call
-
- Inputs:
-
- o oid OBJECT IDENTIFIER
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates successful completion
-
- o GSS_S_FAILURE indicates that the operation failed
-
- Allows the caller to release the storage associated with an OBJECT
- IDENTIFIER buffer allocated by another GSS-API call. This call's
- specific behavior depends on the language and programming environment
- within which a GSS-API implementation operates, and is therefore
- detailed within applicable bindings specifications; in particular,
- this call may be superfluous within bindings where memory management
- is automatic.
-
-2.4.13: GSS_OID_to_str call
-
- Inputs:
-
- o oid OBJECT IDENTIFIER
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o oid_str OCTET STRING
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates successful completion
-
-
-
-Linn Standards Track [Page 68]
-
-RFC 2078 GSS-API January 1997
-
-
- o GSS_S_FAILURE indicates that the operation failed
-
- The function GSS_OID_to_str() returns a string representing the input
- OID in numeric ASN.1 syntax format (curly-brace enclosed, space-
- delimited, e.g., "{2 16 840 1 113687 1 2 1}"). The string is
- releasable using GSS_Release_buffer(). If the input "oid" does not
- represent a syntactically valid object identifier, GSS_S_FAILURE
- status is returned and the returned oid_str result is NULL.
-
-2.4.14: GSS_Str_to_OID call
-
- Inputs:
-
- o oid_str OCTET STRING
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o oid OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates successful completion
-
- o GSS_S_FAILURE indicates that the operation failed
-
- The function GSS_Str_to_OID() constructs and returns an OID from its
- printable form; implementations should be able to accept the numeric
- ASN.1 syntax form as described for GSS_OID_to_str(), and this form
- should be used for portability, but implementations of this routine
- may also accept other formats (e.g., "1.2.3.3"). The OID is suitable
- for release using the function GSS_Release_OID(). If the input
- oid_str cannot be translated into an OID, GSS_S_FAILURE status is
- returned and the "oid" result is NULL.
-
-2.4.15: GSS_Inquire_names_for_mech call
-
- Input:
-
- o input_mech_type OBJECT IDENTIFIER, -- mechanism type
-
- Outputs:
-
- o major_status INTEGER,
-
-
-
-
-Linn Standards Track [Page 69]
-
-RFC 2078 GSS-API January 1997
-
-
- o minor_status INTEGER,
-
- o name_type_set SET OF OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that the output name_type_set contains
- a list of name types which are supported by the locally available
- mechanism identified by input_mech_type.
-
- o GSS_S_BAD_MECH indicates that the mechanism identified by
- input_mech_type was unsupported within the local implementation,
- causing the query to fail.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- Allows callers to determine the set of name types which are
- supportable by a specific locally-available mechanism.
-
-2.4.16: GSS_Inquire_mechs_for_name call
-
- Inputs:
-
- o input_name INTERNAL NAME,
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o mech_types SET OF OBJECT IDENTIFIER
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that a set of object identifiers,
- corresponding to the set of mechanisms suitable for processing
- the input_name, is available in mech_types.
-
- o GSS_S_BAD_NAME indicates that the input_name could not be
- processed.
-
- o GSS_S_BAD_NAMETYPE indicates that the type of the input_name
- is unsupported by the GSS-API implementation.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
-
-
-Linn Standards Track [Page 70]
-
-RFC 2078 GSS-API January 1997
-
-
- This routine returns the mechanism set with which the input_name may
- be processed. After use, the mech_types object should be freed by
- the caller via the GSS_Release_OID_set() call. Note: it is
- anticipated that implementations of GSS_Inquire_mechs_for_name() will
- commonly operate based on type information describing the
- capabilities of available mechanisms; it is not guaranteed that all
- identified mechanisms will necessarily be able to canonicalize (via
- GSS_Canonicalize_name()) a particular name.
-
-2.4.17: GSS_Canonicalize_name call
-
- Inputs:
-
- o input_name INTERNAL NAME,
-
- o mech_type OBJECT IDENTIFIER -- must be explicit mechanism,
- not "default" specifier
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_name INTERNAL NAME
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that a mechanism-specific reduction of
- the input_name, as processed by the mechanism identified by
- mech_type, is available in output_name.
-
- o GSS_S_BAD_MECH indicates that the identified mechanism is
- unsupported.
-
- o GSS_S_BAD_NAMETYPE indicates that the input name does not
- contain an element with suitable type for processing by the
- identified mechanism.
-
- o GSS_S_BAD_NAME indicates that the input name contains an
- element with suitable type for processing by the identified
- mechanism, but that this element could not be processed
- successfully.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
-
-
-
-
-Linn Standards Track [Page 71]
-
-RFC 2078 GSS-API January 1997
-
-
- This routine reduces a GSS-API internal name, which may in general
- contain elements corresponding to multiple mechanisms, to a
- mechanism-specific Mechanism Name (MN) by applying the translations
- corresponding to the mechanism identified by mech_type.
-
-2.4.18: GSS_Export_name call
-
- Inputs:
-
- o input_name INTERNAL NAME, -- required to be MN
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o output_name OCTET STRING
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that a flat representation of the
- input name is available in output_name.
-
- o GSS_S_NAME_NOT_MN indicates that the input name contained
- elements corresponding to multiple mechanisms, so cannot
- be exported into a single-mechanism flat form.
-
- o GSS_S_BAD_NAME indicates that the input name was an MN,
- but could not be processed.
-
- o GSS_S_BAD_NAMETYPE indicates that the input name was an MN,
- but that its type is unsupported by the GSS-API implementation.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- This routine creates a flat name representation, suitable for
- bytewise comparison or for input to GSS_Import_name() in conjunction
- with the reserved GSS-API Exported Name Object OID, from a internal-
- form Mechanism Name (MN) as emitted, e.g., by GSS_Canonicalize_name()
- or GSS_Accept_sec_context().
-
- The emitted GSS-API Exported Name Object is self-describing; no
- associated parameter-level OID need be emitted by this call. This
- flat representation consists of a mechanism-independent wrapper
- layer, defined in Section 3.2 of this document, enclosing a
- mechanism-defined name representation.
-
-
-
-Linn Standards Track [Page 72]
-
-RFC 2078 GSS-API January 1997
-
-
- In all cases, the flat name output by GSS_Export_name() to correspond
- to a particular input MN must be invariant over time within a
- particular installation.
-
- The GSS_S_NAME_NOT_MN status code is provided to enable
- implementations to reject input names which are not MNs. It is not,
- however, required for purposes of conformance to this specification
- that all non-MN input names must necessarily be rejected.
-
-2.4.19: GSS_Duplicate_name call
-
- Inputs:
-
- o src_name INTERNAL NAME
-
- Outputs:
-
- o major_status INTEGER,
-
- o minor_status INTEGER,
-
- o dest_name INTERNAL NAME
-
- Return major_status codes:
-
- o GSS_S_COMPLETE indicates that dest_name references an internal
- name object containing the same name as passed to src_name.
-
- o GSS_S_BAD_NAME indicates that the input name was invalid.
-
- o GSS_S_BAD_NAMETYPE indicates that the input name's type
- is unsupported by the GSS-API implementation.
-
- o GSS_S_FAILURE indicates that the requested operation could not
- be performed for reasons unspecified at the GSS-API level.
-
- This routine takes input internal name src_name, and returns another
- reference (dest_name) to that name which can be used even if src_name
- is later freed. (Note: This may be implemented by copying or through
- use of reference counts.)
-
-3: Data Structure Definitions for GSS-V2 Usage
-
- Subsections of this section define, for interoperability and
- portability purposes, certain data structures for use with GSS-V2.
-
-
-
-
-
-
-Linn Standards Track [Page 73]
-
-RFC 2078 GSS-API January 1997
-
-
-3.1: Mechanism-Independent Token Format
-
- This section specifies a mechanism-independent level of encapsulating
- representation for the initial token of a GSS-API context
- establishment sequence, incorporating an identifier of the mechanism
- type to be used on that context and enabling tokens to be interpreted
- unambiguously at GSS-API peers. Use of this format is required for
- initial context establishment tokens of Internet standards-track
- GSS-API mechanisms; use in non-initial tokens is optional.
-
- The encoding format for the token tag is derived from ASN.1 and DER
- (per illustrative ASN.1 syntax included later within this
- subsection), but its concrete representation is defined directly in
- terms of octets rather than at the ASN.1 level in order to facilitate
- interoperable implementation without use of general ASN.1 processing
- code. The token tag consists of the following elements, in order:
-
- 1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that
- constructed form, definite length encoding follows.
-
- 2. Token length octets, specifying length of subsequent data
- (i.e., the summed lengths of elements 3-5 in this list, and of the
- mechanism-defined token object following the tag). This element
- comprises a variable number of octets:
-
- 2a. If the indicated value is less than 128, it shall be
- represented in a single octet with bit 8 (high order) set to "0"
- and the remaining bits representing the value.
-
- 2b. If the indicated value is 128 or more, it shall be represented
- in two or more octets, with bit 8 of the first octet set to "1"
- and the remaining bits of the first octet specifying the number of
- additional octets. The subsequent octets carry the value, 8 bits
- per octet, most significant digit first. The minimum number of
- octets shall be used to encode the length (i.e., no octets
- representing leading zeros shall be included within the length
- encoding).
-
- 3. 0x06 -- Tag for OBJECT IDENTIFIER
-
- 4. Object identifier length -- length (number of octets) of the
- encoded object identifier contained in element 5, encoded per
- rules as described in 2a. and 2b. above.
-
- 5. Object identifier octets -- variable number of octets, encoded
- per ASN.1 BER rules:
-
-
-
-
-
-Linn Standards Track [Page 74]
-
-RFC 2078 GSS-API January 1997
-
-
- 5a. The first octet contains the sum of two values: (1) the top-
- level object identifier component, multiplied by 40 (decimal), and
- (2) the second-level object identifier component. This special
- case is the only point within an object identifier encoding where
- a single octet represents contents of more than one component.
-
- 5b. Subsequent octets, if required, encode successively-lower
- components in the represented object identifier. A component's
- encoding may span multiple octets, encoding 7 bits per octet (most
- significant bits first) and with bit 8 set to "1" on all but the
- final octet in the component's encoding. The minimum number of
- octets shall be used to encode each component (i.e., no octets
- representing leading zeros shall be included within a component's
- encoding).
-
- (Note: In many implementations, elements 3-5 may be stored and
- referenced as a contiguous string constant.)
-
- The token tag is immediately followed by a mechanism-defined token
- object. Note that no independent size specifier intervenes following
- the object identifier value to indicate the size of the mechanism-
- defined token object. While ASN.1 usage within mechanism-defined
- tokens is permitted, there is no requirement that the mechanism-
- specific innerContextToken, innerMsgToken, and sealedUserData data
- elements must employ ASN.1 BER/DER encoding conventions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 75]
-
-RFC 2078 GSS-API January 1997
-
-
- The following ASN.1 syntax is included for descriptive purposes only,
- to illustrate structural relationships among token and tag objects.
- For interoperability purposes, token and tag encoding shall be
- performed using the concrete encoding procedures described earlier in
- this subsection.
-
- GSS-API DEFINITIONS ::=
-
- BEGIN
-
- MechType ::= OBJECT IDENTIFIER
- -- data structure definitions
-
- -- callers must be able to distinguish among
- -- InitialContextToken, SubsequentContextToken,
- -- PerMsgToken, and SealedMessage data elements
- -- based on the usage in which they occur
-
- InitialContextToken ::=
- -- option indication (delegation, etc.) indicated within
- -- mechanism-specific token
- [APPLICATION 0] IMPLICIT SEQUENCE {
- thisMech MechType,
- innerContextToken ANY DEFINED BY thisMech
- -- contents mechanism-specific
- -- ASN.1 structure not required
- }
-
- SubsequentContextToken ::= innerContextToken ANY
- -- interpretation based on predecessor InitialContextToken
- -- ASN.1 structure not required
-
- PerMsgToken ::=
- -- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
- -- ASN.1 structure not required
- innerMsgToken ANY
-
- SealedMessage ::=
- -- as emitted by GSS_Wrap and processed by GSS_Unwrap
- -- includes internal, mechanism-defined indicator
- -- of whether or not encrypted
- -- ASN.1 structure not required
- sealedUserData ANY
-
- END
-
-
-
-
-
-
-Linn Standards Track [Page 76]
-
-RFC 2078 GSS-API January 1997
-
-
-3.2: Mechanism-Independent Exported Name Object Format
-
- This section specifies a mechanism-independent level of encapsulating
- representation for names exported via the GSS_Export_name() call,
- including an object identifier representing the exporting mechanism.
- The format of names encapsulated via this representation shall be
- defined within individual mechanism drafts. Name objects of this
- type will be identified with the following Object Identifier:
-
- {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
- 4(gss-api-exported-name)}
-
- No name type OID is included in this mechanism-independent level of
- format definition, since (depending on individual mechanism
- specifications) the enclosed name may be implicitly typed or may be
- explicitly typed using a means other than OID encoding.
-
- Length Name Description
-
- 2 TOK_ID Token Identifier
- For exported name objects, this
- must be hex 04 01.
- 2 MECH_OID_LEN Length of the Mechanism OID
- MECH_OID_LEN MECH_OID Mechanism OID, in DER
- 4 NAME_LEN Length of name
- NAME_LEN NAME Exported name; format defined in
- applicable mechanism draft.
-
-4: Name Type Definitions
-
- This section includes definitions for name types and associated
- syntaxes which are defined in a mechanism-independent fashion at the
- GSS-API level rather than being defined in individual mechanism
- specifications.
-
-4.1: Host-Based Service Name Form
-
- The following Object Identifier value is provided as a means to
- identify this name form:
-
- {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
- 2(gss-host-based-services)}
-
- The recommended symbolic name for this type is
- "GSS_C_NT_HOSTBASED_SERVICE".
-
-
-
-
-
-
-Linn Standards Track [Page 77]
-
-RFC 2078 GSS-API January 1997
-
-
- This name type is used to represent services associated with host
- computers. This name form is constructed using two elements,
- "service" and "hostname", as follows:
-
- service@hostname
-
- When a reference to a name of this type is resolved, the "hostname"
- is canonicalized by attempting a DNS lookup and using the fully-
- qualified domain name which is returned, or by using the "hostname"
- as provided if the DNS lookup fails. The canonicalization operation
- also maps the host's name into lower-case characters.
-
- The "hostname" element may be omitted. If no "@" separator is
- included, the entire name is interpreted as the service specifier,
- with the "hostname" defaulted to the canonicalized name of the local
- host.
-
- Values for the "service" element are registered with the IANA.
-
-4.2: User Name Form
-
- This name form shall be represented by the Object Identifier {iso(1)
- member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- generic(1) user_name(1)}. The recommended mechanism-independent
- symbolic name for this type is "GSS_C_NT_USER_NAME". (Note: the same
- name form and OID is defined within the Kerberos V5 GSS-API
- mechanism, but the symbolic name recommended there begins with a
- "GSS_KRB5_NT_" prefix.)
-
- This name type is used to indicate a named user on a local system.
- Its interpretation is OS-specific. This name form is constructed as:
-
- username
-
-4.3: Machine UID Form
-
- This name form shall be represented by the Object Identifier {iso(1)
- member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- generic(1) machine_uid_name(2)}. The recommended mechanism-
- independent symbolic name for this type is
- "GSS_C_NT_MACHINE_UID_NAME". (Note: the same name form and OID is
- defined within the Kerberos V5 GSS-API mechanism, but the symbolic
- name recommended there begins with a "GSS_KRB5_NT_" prefix.)
-
- This name type is used to indicate a numeric user identifier
- corresponding to a user on a local system. Its interpretation is
- OS-specific. The gss_buffer_desc representing a name of this type
- should contain a locally-significant uid_t, represented in host byte
-
-
-
-Linn Standards Track [Page 78]
-
-RFC 2078 GSS-API January 1997
-
-
- order. The GSS_Import_name() operation resolves this uid into a
- username, which is then treated as the User Name Form.
-
-4.4: String UID Form
-
- This name form shall be represented by the Object Identifier {iso(1)
- member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- generic(1) string_uid_name(3)}. The recommended symbolic name for
- this type is "GSS_C_NT_STRING_UID_NAME". (Note: the same name form
- and OID is defined within the Kerberos V5 GSS-API mechanism, but the
- symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
-
- This name type is used to indicate a string of digits representing
- the numeric user identifier of a user on a local system. Its
- interpretation is OS-specific. This name type is similar to the
- Machine UID Form, except that the buffer contains a string
- representing the uid_t.
-
-5: Mechanism-Specific Example Scenarios
-
- This section provides illustrative overviews of the use of various
- candidate mechanism types to support the GSS-API. These discussions
- are intended primarily for readers familiar with specific security
- technologies, demonstrating how GSS-API functions can be used and
- implemented by candidate underlying mechanisms. They should not be
- regarded as constrictive to implementations or as defining the only
- means through which GSS-API functions can be realized with a
- particular underlying technology, and do not demonstrate all GSS-API
- features with each technology.
-
-5.1: Kerberos V5, single-TGT
-
- OS-specific login functions yield a TGT to the local realm Kerberos
- server; TGT is placed in a credentials structure for the client.
- Client calls GSS_Acquire_cred() to acquire a cred_handle in order to
- reference the credentials for use in establishing security contexts.
-
- Client calls GSS_Init_sec_context(). If the requested service is
- located in a different realm, GSS_Init_sec_context() gets the
- necessary TGT/key pairs needed to traverse the path from local to
- target realm; these data are placed in the owner's TGT cache. After
- any needed remote realm resolution, GSS_Init_sec_context() yields a
- service ticket to the requested service with a corresponding session
- key; these data are stored in conjunction with the context. GSS-API
- code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP
- response(s) (in the successful case) or KRB_ERROR.
-
-
-
-
-
-Linn Standards Track [Page 79]
-
-RFC 2078 GSS-API January 1997
-
-
- Assuming success, GSS_Init_sec_context() builds a Kerberos-formatted
- KRB_AP_REQ message, and returns it in output_token. The client sends
- the output_token to the service.
-
- The service passes the received token as the input_token argument to
- GSS_Accept_sec_context(), which verifies the authenticator, provides
- the service with the client's authenticated name, and returns an
- output_context_handle.
-
- Both parties now hold the session key associated with the service
- ticket, and can use this key in subsequent GSS_GetMIC(),
- GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap() operations.
-
-5.2: Kerberos V5, double-TGT
-
- TGT acquisition as above.
-
- Note: To avoid unnecessary frequent invocations of error paths when
- implementing the GSS-API atop Kerberos V5, it seems appropriate to
- represent "single-TGT K-V5" and "double-TGT K-V5" with separate
- mech_types, and this discussion makes that assumption.
-
- Based on the (specified or defaulted) mech_type,
- GSS_Init_sec_context() determines that the double-TGT protocol
- should be employed for the specified target. GSS_Init_sec_context()
- returns GSS_S_CONTINUE_NEEDED major_status, and its returned
- output_token contains a request to the service for the service's TGT.
- (If a service TGT with suitably long remaining lifetime already
- exists in a cache, it may be usable, obviating the need for this
- step.) The client passes the output_token to the service. Note: this
- scenario illustrates a different use for the GSS_S_CONTINUE_NEEDED
- status return facility than for support of mutual authentication;
- note that both uses can coexist as successive operations within a
- single context establishment operation.
-
- The service passes the received token as the input_token argument to
- GSS_Accept_sec_context(), which recognizes it as a request for TGT.
- (Note that current Kerberos V5 defines no intra-protocol mechanism to
- represent such a request.) GSS_Accept_sec_context() returns
- GSS_S_CONTINUE_NEEDED major_status and provides the service's TGT in
- its output_token. The service sends the output_token to the client.
-
- The client passes the received token as the input_token argument to a
- continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches
- the received service TGT and uses it as part of a service ticket
- request to the Kerberos authentication server, storing the returned
- service ticket and session key in conjunction with the context.
- GSS_Init_sec_context() builds a Kerberos-formatted authenticator,
-
-
-
-Linn Standards Track [Page 80]
-
-RFC 2078 GSS-API January 1997
-
-
- and returns it in output_token along with GSS_S_COMPLETE return
- major_status. The client sends the output_token to the service.
-
- Service passes the received token as the input_token argument to a
- continuation call to GSS_Accept_sec_context().
- GSS_Accept_sec_context() verifies the authenticator, provides the
- service with the client's authenticated name, and returns
- major_status GSS_S_COMPLETE.
-
- GSS_GetMIC(), GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap() as
- above.
-
-5.3: X.509 Authentication Framework
-
- This example illustrates use of the GSS-API in conjunction with
- public-key mechanisms, consistent with the X.509 Directory
- Authentication Framework.
-
- The GSS_Acquire_cred() call establishes a credentials structure,
- making the client's private key accessible for use on behalf of the
- client.
-
- The client calls GSS_Init_sec_context(), which interrogates the
- Directory to acquire (and validate) a chain of public-key
- certificates, thereby collecting the public key of the service. The
- certificate validation operation determines that suitable integrity
- checks were applied by trusted authorities and that those
- certificates have not expired. GSS_Init_sec_context() generates a
- secret key for use in per-message protection operations on the
- context, and enciphers that secret key under the service's public
- key.
-
- The enciphered secret key, along with an authenticator quantity
- signed with the client's private key, is included in the output_token
- from GSS_Init_sec_context(). The output_token also carries a
- certification path, consisting of a certificate chain leading from
- the service to the client; a variant approach would defer this path
- resolution to be performed by the service instead of being asserted
- by the client. The client application sends the output_token to the
- service.
-
- The service passes the received token as the input_token argument to
- GSS_Accept_sec_context(). GSS_Accept_sec_context() validates the
- certification path, and as a result determines a certified binding
- between the client's distinguished name and the client's public key.
- Given that public key, GSS_Accept_sec_context() can process the
- input_token's authenticator quantity and verify that the client's
- private key was used to sign the input_token. At this point, the
-
-
-
-Linn Standards Track [Page 81]
-
-RFC 2078 GSS-API January 1997
-
-
- client is authenticated to the service. The service uses its private
- key to decipher the enciphered secret key provided to it for per-
- message protection operations on the context.
-
- The client calls GSS_GetMIC() or GSS_Wrap() on a data message, which
- causes per-message authentication, integrity, and (optional)
- confidentiality facilities to be applied to that message. The service
- uses the context's shared secret key to perform corresponding
- GSS_VerifyMIC() and GSS_Unwrap() calls.
-
-6: Security Considerations
-
- Security issues are discussed throughout this memo.
-
-7: Related Activities
-
- In order to implement the GSS-API atop existing, emerging, and future
- security mechanisms:
-
- object identifiers must be assigned to candidate GSS-API
- mechanisms and the name types which they support
-
- concrete data element formats and processing procedures must be
- defined for candidate mechanisms
-
- Calling applications must implement formatting conventions which will
- enable them to distinguish GSS-API tokens from other data carried in
- their application protocols.
-
- Concrete language bindings are required for the programming
- environments in which the GSS-API is to be employed, as RFC-1509
- defines for the C programming language and GSS-V1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 82]
-
-RFC 2078 GSS-API January 1997
-
-
-APPENDIX A
-
-MECHANISM DESIGN CONSTRAINTS
-
- The following constraints on GSS-API mechanism designs are adopted in
- response to observed caller protocol requirements, and adherence
- thereto is anticipated in subsequent descriptions of GSS-API
- mechanisms to be documented in standards-track Internet
- specifications.
-
- It is strongly recommended that mechanisms offering per-message
- protection services also offer at least one of the replay detection
- and sequencing services, as mechanisms offering neither of the latter
- will fail to satisfy recognized requirements of certain candidate
- caller protocols.
-
-APPENDIX B
-
- COMPATIBILITY WITH GSS-V1
-
- It is the intent of this document to define an interface and
- procedures which preserve compatibility between GSS-V1 (RFC-1508)
- callers and GSS- V2 providers. All calls defined in GSS-V1 are
- preserved, and it has been a goal that GSS-V1 callers should be able
- to operate atop GSS-V2 provider implementations. Certain detailed
- changes, summarized in this section, have been made in order to
- resolve omissions identified in GSS-V1.
-
- The following GSS-V1 constructs, while supported within GSS-V2, are
- deprecated:
-
- Names for per-message processing routines: GSS_Seal() deprecated
- in favor of GSS_Wrap(); GSS_Sign() deprecated in favor of
- GSS_GetMIC(); GSS_Unseal() deprecated in favor of GSS_Unwrap();
- GSS_Verify() deprecated in favor of GSS_VerifyMIC().
-
- GSS_Delete_sec_context() facility for context_token usage,
- allowing mechanisms to signal context deletion, is retained for
- compatibility with GSS-V1. For current usage, it is recommended
- that both peers to a context invoke GSS_Delete_sec_context()
- independently, passing a null output_context_token buffer to
- indicate that no context_token is required. Implementations of
- GSS_Delete_sec_context() should delete relevant locally-stored
- context information.
-
-
-
-
-
-
-
-Linn Standards Track [Page 83]
-
-RFC 2078 GSS-API January 1997
-
-
- This GSS-V2 specification adds the following calls which are not
- present in GSS-V1:
-
- Credential management calls: GSS_Add_cred(),
- GSS_Inquire_cred_by_mech().
-
- Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(),
- GSS_Export_sec_context(), GSS_Import_sec_context().
-
- Per-message calls: No new calls. Existing calls have been renamed.
-
- Support calls: GSS_Create_empty_OID_set(),
- GSS_Add_OID_set_member(), GSS_Test_OID_set_member(),
- GSS_Release_OID(), GSS_OID_to_str(), GSS_Str_to_OID(),
- GSS_Inquire_names_for_mech(), GSS_Inquire_mechs_for_name(),
- GSS_Canonicalize_name(), GSS_Export_name(), GSS_Duplicate_name().
-
- This GSS-V2 specification introduces three new facilities applicable
- to security contexts, indicated using the following context state
- values which are not present in GSS-V1:
-
- anon_state, set TRUE to indicate that a context's initiator is
- anonymous from the viewpoint of the target; Section 1.2.5 of this
- specification provides a summary description of the GSS-V2
- anonymity support facility, support and use of which is optional.
-
- prot_ready_state, set TRUE to indicate that a context may be used
- for per-message protection before final completion of context
- establishment; Section 1.2.7 of this specification provides a
- summary description of the GSS-V2 facility enabling mechanisms to
- selectively permit per-message protection during context
- establishment, support and use of which is optional.
-
- trans_state, set TRUE to indicate that a context is transferable to
- another process using the GSS-V2 GSS_Export_sec_context() facility.
-
- These state values are represented (at the C bindings level) in
- positions within a bit vector which are unused in GSS-V1, and may be
- safely ignored by GSS-V1 callers.
-
- Relative to GSS-V1, GSS-V2 provides additional guidance to GSS-API
- implementors in the following areas: implementation robustness,
- credential management, behavior in multi-mechanism configurations,
- naming support, and inclusion of optional sequencing services. The
- token tagging facility as defined in GSS-V2, Section 3.1, is now
- described directly in terms of octets to facilitate interoperable
- implementation without general ASN.1 processing code; the
- corresponding ASN.1 syntax, included for descriptive purposes, is
-
-
-
-Linn Standards Track [Page 84]
-
-RFC 2078 GSS-API January 1997
-
-
- unchanged from that in GSS-V1. For use in conjunction with added
- naming support facilities, a new Exported Name Object construct is
- added. Additional name types are introduced in Section 4.
-
- This GSS-V2 specification adds the following major_status values
- which are not defined in GSS-V1:
-
- GSS_S_BAD_QOP unsupported QOP value
- GSS_S_UNAUTHORIZED operation unauthorized
- GSS_S_UNAVAILABLE operation unavailable
- GSS_S_DUPLICATE_ELEMENT duplicate credential element requested
- GSS_S_NAME_NOT_MN name contains multi-mechanism elements
- GSS_S_GAP_TOKEN skipped predecessor token(s)
- detected
-
- Of these added status codes, only two values are defined to be
- returnable by calls existing in GSS-V1: GSS_S_BAD_QOP (returnable by
- GSS_GetMIC() and GSS_Wrap()), and GSS_S_GAP_TOKEN (returnable by
- GSS_VerifyMIC() and GSS_Unwrap()).
-
- Additionally, GSS-V2 descriptions of certain calls present in GSS-V1
- have been updated to allow return of additional major_status values
- from the set as defined in GSS-V1: GSS_Inquire_cred() has
- GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as
- returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN,
- GSS_S_DUPLICATE_TOKEN, and GSS_S_BAD_MECH defined as returnable, and
- GSS_Accept_sec_context() has GSS_S_BAD_MECH defined as returnable.
-
-Author's Address
-
- John Linn
- OpenVision Technologies
- One Main St.
- Cambridge, MA 02142 USA
-
- Phone: +1 617.374.2245
- EMail: John.Linn@ov.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn Standards Track [Page 85]
-
diff --git a/doc/standardisation/rfc2228.txt b/doc/standardisation/rfc2228.txt
deleted file mode 100644
index 1fbfcbfa09fc95a4998dbb1058d3b7725ba9a0d8..0000000000000000000000000000000000000000
--- a/doc/standardisation/rfc2228.txt
+++ /dev/null
@@ -1,1515 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Horowitz
-Request for Comments: 2228 Cygnus Solutions
-Updates: 959 S. Lunt
-Category: Standards Track Bellcore
- October 1997
-
- FTP Security Extensions
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-Abstract
-
- This document defines extensions to the FTP specification STD 9, RFC
- 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions
- provide strong authentication, integrity, and confidentiality on both
- the control and data channels with the introduction of new optional
- commands, replies, and file transfer encodings.
-
- The following new optional commands are introduced in this
- specification:
-
- AUTH (Authentication/Security Mechanism),
- ADAT (Authentication/Security Data),
- PROT (Data Channel Protection Level),
- PBSZ (Protection Buffer Size),
- CCC (Clear Command Channel),
- MIC (Integrity Protected Command),
- CONF (Confidentiality Protected Command), and
- ENC (Privacy Protected Command).
-
- A new class of reply types (6yz) is also introduced for protected
- replies.
-
- None of the above commands are required to be implemented, but
- interdependencies exist. These dependencies are documented with the
- commands.
-
- Note that this specification is compatible with STD 9, RFC 959.
-
-
-
-Horowitz & Lunt Standards Track [Page 1]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
-1. Introduction
-
- The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959
- and in place on the Internet uses usernames and passwords passed in
- cleartext to authenticate clients to servers (via the USER and PASS
- commands). Except for services such as "anonymous" FTP archives,
- this represents a security risk whereby passwords can be stolen
- through monitoring of local and wide-area networks. This either aids
- potential attackers through password exposure and/or limits
- accessibility of files by FTP servers who cannot or will not accept
- the inherent security risks.
-
- Aside from the problem of authenticating users in a secure manner,
- there is also the problem of authenticating servers, protecting
- sensitive data and/or verifying its integrity. An attacker may be
- able to access valuable or sensitive data merely by monitoring a
- network, or through active means may be able to delete or modify the
- data being transferred so as to corrupt its integrity. An active
- attacker may also initiate spurious file transfers to and from a site
- of the attacker's choice, and may invoke other commands on the
- server. FTP does not currently have any provision for the encryption
- or verification of the authenticity of commands, replies, or
- transferred data. Note that these security services have value even
- to anonymous file access.
-
- Current practice for sending files securely is generally either:
-
- 1. via FTP of files pre-encrypted under keys which are manually
- distributed,
-
- 2. via electronic mail containing an encoding of a file encrypted
- under keys which are manually distributed,
-
- 3. via a PEM message, or
-
- 4. via the rcp command enhanced to use Kerberos.
-
- None of these means could be considered even a de facto standard, and
- none are truly interactive. A need exists to securely transfer files
- using FTP in a secure manner which is supported within the FTP
- protocol in a consistent manner and which takes advantage of existing
- security infrastructure and technology. Extensions are necessary to
- the FTP specification if these security services are to be introduced
- into the protocol in an interoperable way.
-
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 2]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- Although the FTP control connection follows the Telnet protocol, and
- Telnet has defined an authentication and encryption option [TELNET-
- SEC], [RFC-1123] explicitly forbids the use of Telnet option
- negotiation over the control connection (other than Synch and IP).
-
- Also, the Telnet authentication and encryption option does not
- provide for integrity protection only (without confidentiality), and
- does not address the protection of the data channel.
-
-2. FTP Security Overview
-
- At the highest level, the FTP security extensions seek to provide an
- abstract mechanism for authenticating and/or authorizing connections,
- and integrity and/or confidentiality protecting commands, replies,
- and data transfers.
-
- In the context of FTP security, authentication is the establishment
- of a client's identity and/or a server's identity in a secure way,
- usually using cryptographic techniques. The basic FTP protocol does
- not have a concept of authentication.
-
- Authorization is the process of validating a user for login. The
- basic authorization process involves the USER, PASS, and ACCT
- commands. With the FTP security extensions, authentication
- established using a security mechanism may also be used to make the
- authorization decision.
-
- Without the security extensions, authentication of the client, as
- this term is usually understood, never happens. FTP authorization is
- accomplished with a password, passed on the network in the clear as
- the argument to the PASS command. The possessor of this password is
- assumed to be authorized to transfer files as the user named in the
- USER command, but the identity of the client is never securely
- established.
-
- An FTP security interaction begins with a client telling the server
- what security mechanism it wants to use with the AUTH command. The
- server will either accept this mechanism, reject this mechanism, or,
- in the case of a server which does not implement the security
- extensions, reject the command completely. The client may try
- multiple security mechanisms until it requests one which the server
- accepts. This allows a rudimentary form of negotiation to take
- place. (If more complex negotiation is desired, this may be
- implemented as a security mechanism.) The server's reply will
- indicate if the client must respond with additional data for the
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 3]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- security mechanism to interpret. If none is needed, this will
- usually mean that the mechanism is one where the password (specified
- by the PASS command) is to be interpreted differently, such as with a
- token or one-time password system.
-
- If the server requires additional security information, then the
- client and server will enter into a security data exchange. The
- client will send an ADAT command containing the first block of
- security data. The server's reply will indicate if the data exchange
- is complete, if there was an error, or if more data is needed. The
- server's reply can optionally contain security data for the client to
- interpret. If more data is needed, the client will send another ADAT
- command containing the next block of data, and await the server's
- reply. This exchange can continue as many times as necessary. Once
- this exchange completes, the client and server have established a
- security association. This security association may include
- authentication (client, server, or mutual) and keying information for
- integrity and/or confidentiality, depending on the mechanism in use.
-
- The term "security data" here is carefully chosen. The purpose of
- the security data exchange is to establish a security association,
- which might not actually include any authentication at all, between
- the client and the server as described above. For instance, a
- Diffie-Hellman exchange establishes a secret key, but no
- authentication takes place. If an FTP server has an RSA key pair but
- the client does not, then the client can authenticate the server, but
- the server cannot authenticate the client.
-
- Once a security association is established, authentication which is a
- part of this association may be used instead of or in addition to the
- standard username/password exchange for authorizing a user to connect
- to the server. A username specified by the USER command is always
- required to specify the identity to be used on the server.
-
- In order to prevent an attacker from inserting or deleting commands
- on the control stream, if the security association supports
- integrity, then the server and client must use integrity protection
- on the control stream, unless it first transmits a CCC command to
- turn off this requirement. Integrity protection is performed with
- the MIC and ENC commands, and the 63z reply codes. The CCC command
- and its reply must be transmitted with integrity protection.
- Commands and replies may be transmitted without integrity (that is,
- in the clear or with confidentiality only) only if no security
- association is established, the negotiated security association does
- not support integrity, or the CCC command has succeeded.
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 4]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- Once the client and server have negotiated with the PBSZ command an
- acceptable buffer size for encapsulating protected data over the data
- channel, the security mechanism may also be used to protect data
- channel transfers.
-
- Policy is not specified by this document. In particular, client and
- server implementations may choose to implement restrictions on what
- operations can be performed depending on the security association
- which exists. For example, a server may require that a client
- authorize via a security mechanism rather than using a password,
- require that the client provide a one-time password from a token,
- require at least integrity protection on the command channel, or
- require that certain files only be transmitted encrypted. An
- anonymous ftp client might refuse to do file transfers without
- integrity protection in order to insure the validity of files
- downloaded.
-
- No particular set of functionality is required, except as
- dependencies described in the next section. This means that none of
- authentication, integrity, or confidentiality are required of an
- implementation, although a mechanism which does none of these is not
- of much use. For example, it is acceptable for a mechanism to
- implement only integrity protection, one-way authentication and/or
- encryption, encryption without any authentication or integrity
- protection, or any other subset of functionality if policy or
- technical considerations make this desirable. Of course, one peer
- might require as a matter of policy stronger protection than the
- other is able to provide, preventing perfect interoperability.
-
-3. New FTP Commands
-
- The following commands are optional, but dependent on each other.
- They are extensions to the FTP Access Control Commands.
-
- The reply codes documented here are generally described as
- recommended, rather than required. The intent is that reply codes
- describing the full range of success and failure modes exist, but
- that servers be allowed to limit information presented to the client.
- For example, a server might implement a particular security
- mechanism, but have a policy restriction against using it. The
- server should respond with a 534 reply code in this case, but may
- respond with a 504 reply code if it does not wish to divulge that the
- disallowed mechanism is supported. If the server does choose to use
- a different reply code than the recommended one, it should try to use
- a reply code which only differs in the last digit. In all cases, the
- server must use a reply code which is documented as returnable from
- the command received, and this reply code must begin with the same
- digit as the recommended reply code for the situation.
-
-
-
-Horowitz & Lunt Standards Track [Page 5]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- AUTHENTICATION/SECURITY MECHANISM (AUTH)
-
- The argument field is a Telnet string identifying a supported
- mechanism. This string is case-insensitive. Values must be
- registered with the IANA, except that values beginning with "X-"
- are reserved for local use.
-
- If the server does not recognize the AUTH command, it must respond
- with reply code 500. This is intended to encompass the large
- deployed base of non-security-aware ftp servers, which will
- respond with reply code 500 to any unrecognized command. If the
- server does recognize the AUTH command but does not implement the
- security extensions, it should respond with reply code 502.
-
- If the server does not understand the named security mechanism, it
- should respond with reply code 504.
-
- If the server is not willing to accept the named security
- mechanism, it should respond with reply code 534.
-
- If the server is not able to accept the named security mechanism,
- such as if a required resource is unavailable, it should respond
- with reply code 431.
-
- If the server is willing to accept the named security mechanism,
- but requires security data, it must respond with reply code 334.
-
- If the server is willing to accept the named security mechanism,
- and does not require any security data, it must respond with reply
- code 234.
-
- If the server is responding with a 334 reply code, it may include
- security data as described in the next section.
-
- Some servers will allow the AUTH command to be reissued in order
- to establish new authentication. The AUTH command, if accepted,
- removes any state associated with prior FTP Security commands.
- The server must also require that the user reauthorize (that is,
- reissue some or all of the USER, PASS, and ACCT commands) in this
- case (see section 4 for an explanation of "authorize" in this
- context).
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 6]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- AUTHENTICATION/SECURITY DATA (ADAT)
-
- The argument field is a Telnet string representing base 64 encoded
- security data (see Section 9, "Base 64 Encoding"). If a reply
- code indicating success is returned, the server may also use a
- string of the form "ADAT=base64data" as the text part of the reply
- if it wishes to convey security data back to the client.
-
- The data in both cases is specific to the security mechanism
- specified by the previous AUTH command. The ADAT command, and the
- associated replies, allow the client and server to conduct an
- arbitrary security protocol. The security data exchange must
- include enough information for both peers to be aware of which
- optional features are available. For example, if the client does
- not support data encryption, the server must be made aware of
- this, so it will know not to send encrypted command channel
- replies. It is strongly recommended that the security mechanism
- provide sequencing on the command channel, to insure that commands
- are not deleted, reordered, or replayed.
-
- The ADAT command must be preceded by a successful AUTH command,
- and cannot be issued once a security data exchange completes
- (successfully or unsuccessfully), unless it is preceded by an AUTH
- command to reset the security state.
-
- If the server has not yet received an AUTH command, or if a prior
- security data exchange completed, but the security state has not
- been reset with an AUTH command, it should respond with reply code
- 503.
-
- If the server cannot base 64 decode the argument, it should
- respond with reply code 501.
-
- If the server rejects the security data (if a checksum fails, for
- instance), it should respond with reply code 535.
-
- If the server accepts the security data, and requires additional
- data, it should respond with reply code 335.
-
- If the server accepts the security data, but does not require any
- additional data (i.e., the security data exchange has completed
- successfully), it must respond with reply code 235.
-
- If the server is responding with a 235 or 335 reply code, then it
- may include security data in the text part of the reply as
- specified above.
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 7]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- If the ADAT command returns an error, the security data exchange
- will fail, and the client must reset its internal security state.
- If the client becomes unsynchronized with the server (for example,
- the server sends a 234 reply code to an AUTH command, but the
- client has more data to transmit), then the client must reset the
- server's security state.
-
- PROTECTION BUFFER SIZE (PBSZ)
-
- The argument is a decimal integer representing the maximum size,
- in bytes, of the encoded data blocks to be sent or received during
- file transfer. This number shall be no greater than can be
- represented in a 32-bit unsigned integer.
-
- This command allows the FTP client and server to negotiate a
- maximum protected buffer size for the connection. There is no
- default size; the client must issue a PBSZ command before it can
- issue the first PROT command.
-
- The PBSZ command must be preceded by a successful security data
- exchange.
-
- If the server cannot parse the argument, or if it will not fit in
- 32 bits, it should respond with a 501 reply code.
-
- If the server has not completed a security data exchange with the
- client, it should respond with a 503 reply code.
-
- Otherwise, the server must reply with a 200 reply code. If the
- size provided by the client is too large for the server, it must
- use a string of the form "PBSZ=number" in the text part of the
- reply to indicate a smaller buffer size. The client and the
- server must use the smaller of the two buffer sizes if both buffer
- sizes are specified.
-
- DATA CHANNEL PROTECTION LEVEL (PROT)
-
- The argument is a single Telnet character code specifying the data
- channel protection level.
-
- This command indicates to the server what type of data channel
- protection the client and server will be using. The following
- codes are assigned:
-
- C - Clear
- S - Safe
- E - Confidential
- P - Private
-
-
-
-Horowitz & Lunt Standards Track [Page 8]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- The default protection level if no other level is specified is
- Clear. The Clear protection level indicates that the data channel
- will carry the raw data of the file transfer, with no security
- applied. The Safe protection level indicates that the data will
- be integrity protected. The Confidential protection level
- indicates that the data will be confidentiality protected. The
- Private protection level indicates that the data will be integrity
- and confidentiality protected.
-
- It is reasonable for a security mechanism not to provide all data
- channel protection levels. It is also reasonable for a mechanism
- to provide more protection at a level than is required (for
- instance, a mechanism might provide Confidential protection, but
- include integrity-protection in that encoding, due to API or other
- considerations).
-
- The PROT command must be preceded by a successful protection
- buffer size negotiation.
-
- If the server does not understand the specified protection level,
- it should respond with reply code 504.
-
- If the current security mechanism does not support the specified
- protection level, the server should respond with reply code 536.
-
- If the server has not completed a protection buffer size
- negotiation with the client, it should respond with a 503 reply
- code.
-
- The PROT command will be rejected and the server should reply 503
- if no previous PBSZ command was issued.
-
- If the server is not willing to accept the specified protection
- level, it should respond with reply code 534.
-
- If the server is not able to accept the specified protection
- level, such as if a required resource is unavailable, it should
- respond with reply code 431.
-
- Otherwise, the server must reply with a 200 reply code to indicate
- that the specified protection level is accepted.
-
- CLEAR COMMAND CHANNEL (CCC)
-
- This command does not take an argument.
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 9]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- It is desirable in some environments to use a security mechanism
- to authenticate and/or authorize the client and server, but not to
- perform any integrity checking on the subsequent commands. This
- might be used in an environment where IP security is in place,
- insuring that the hosts are authenticated and that TCP streams
- cannot be tampered, but where user authentication is desired.
-
- If unprotected commands are allowed on any connection, then an
- attacker could insert a command on the control stream, and the
- server would have no way to know that it was invalid. In order to
- prevent such attacks, once a security data exchange completes
- successfully, if the security mechanism supports integrity, then
- integrity (via the MIC or ENC command, and 631 or 632 reply) must
- be used, until the CCC command is issued to enable non-integrity
- protected control channel messages. The CCC command itself must
- be integrity protected.
-
- Once the CCC command completes successfully, if a command is not
- protected, then the reply to that command must also not be
- protected. This is to support interoperability with clients which
- do not support protection once the CCC command has been issued.
-
- This command must be preceded by a successful security data
- exchange.
-
- If the command is not integrity-protected, the server must respond
- with a 533 reply code.
-
- If the server is not willing to turn off the integrity
- requirement, it should respond with a 534 reply code.
-
- Otherwise, the server must reply with a 200 reply code to indicate
- that unprotected commands and replies may now be used on the
- command channel.
-
- INTEGRITY PROTECTED COMMAND (MIC) and
- CONFIDENTIALITY PROTECTED COMMAND (CONF) and
- PRIVACY PROTECTED COMMAND (ENC)
-
- The argument field of MIC is a Telnet string consisting of a base
- 64 encoded "safe" message produced by a security mechanism
- specific message integrity procedure. The argument field of CONF
- is a Telnet string consisting of a base 64 encoded "confidential"
- message produced by a security mechanism specific confidentiality
- procedure. The argument field of ENC is a Telnet string
- consisting of a base 64 encoded "private" message produced by a
- security mechanism specific message integrity and confidentiality
- procedure.
-
-
-
-Horowitz & Lunt Standards Track [Page 10]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- The server will decode and/or verify the encoded message.
-
- This command must be preceded by a successful security data
- exchange.
-
- A server may require that the first command after a successful
- security data exchange be CCC, and not implement the protection
- commands at all. In this case, the server should respond with a
- 502 reply code.
-
- If the server cannot base 64 decode the argument, it should
- respond with a 501 reply code.
-
- If the server has not completed a security data exchange with the
- client, it should respond with a 503 reply code.
-
- If the server has completed a security data exchange with the
- client using a mechanism which supports integrity, and requires a
- CCC command due to policy or implementation limitations, it should
- respond with a 503 reply code.
-
- If the server rejects the command because it is not supported by
- the current security mechanism, the server should respond with
- reply code 537.
-
- If the server rejects the command (if a checksum fails, for
- instance), it should respond with reply code 535.
-
- If the server is not willing to accept the command (if privacy is
- required by policy, for instance, or if a CONF command is received
- before a CCC command), it should respond with reply code 533.
-
- Otherwise, the command will be interpreted as an FTP command. An
- end-of-line code need not be included, but if one is included, it
- must be a Telnet end-of-line code, not a local end-of-line code.
-
- The server may require that, under some or all circumstances, all
- commands be protected. In this case, it should make a 533 reply
- to commands other than MIC, CONF, and ENC.
-
-4. Login Authorization
-
- The security data exchange may, among other things, establish the
- identity of the client in a secure way to the server. This identity
- may be used as one input to the login authorization process.
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 11]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- In response to the FTP login commands (AUTH, PASS, ACCT), the server
- may choose to change the sequence of commands and replies specified
- by RFC 959 as follows. There are also some new replies available.
-
- If the server is willing to allow the user named by the USER command
- to log in based on the identity established by the security data
- exchange, it should respond with reply code 232.
-
- If the security mechanism requires a challenge/response password, it
- should respond to the USER command with reply code 336. The text
- part of the reply should contain the challenge. The client must
- display the challenge to the user before prompting for the password
- in this case. This is particularly relevant to more sophisticated
- clients or graphical user interfaces which provide dialog boxes or
- other modal input. These clients should be careful not to prompt for
- the password before the username has been sent to the server, in case
- the user needs the challenge in the 336 reply to construct a valid
- password.
-
-5. New FTP Replies
-
- The new reply codes are divided into two classes. The first class is
- new replies made necessary by the new FTP Security commands. The
- second class is a new reply type to indicate protected replies.
-
- 5.1. New individual reply codes
-
- 232 User logged in, authorized by security data exchange.
- 234 Security data exchange complete.
- 235 [ADAT=base64data]
- ; This reply indicates that the security data exchange
- ; completed successfully. The square brackets are not
- ; to be included in the reply, but indicate that
- ; security data in the reply is optional.
-
- 334 [ADAT=base64data]
- ; This reply indicates that the requested security mechanism
- ; is ok, and includes security data to be used by the client
- ; to construct the next command. The square brackets are not
- ; to be included in the reply, but indicate that
- ; security data in the reply is optional.
- 335 [ADAT=base64data]
- ; This reply indicates that the security data is
- ; acceptable, and more is required to complete the
- ; security data exchange. The square brackets
- ; are not to be included in the reply, but indicate
- ; that security data in the reply is optional.
-
-
-
-
-Horowitz & Lunt Standards Track [Page 12]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- 336 Username okay, need password. Challenge is "...."
- ; The exact representation of the challenge should be chosen
- ; by the mechanism to be sensible to the human user of the
- ; system.
-
- 431 Need some unavailable resource to process security.
-
- 533 Command protection level denied for policy reasons.
- 534 Request denied for policy reasons.
- 535 Failed security check (hash, sequence, etc).
- 536 Requested PROT level not supported by mechanism.
- 537 Command protection level not supported by security mechanism.
-
- 5.2. Protected replies.
-
- One new reply type is introduced:
-
- 6yz Protected reply
-
- There are three reply codes of this type. The first, reply
- code 631 indicates an integrity protected reply. The
- second, reply code 632, indicates a confidentiality and
- integrity protected reply. the third, reply code 633,
- indicates a confidentiality protected reply.
-
- The text part of a 631 reply is a Telnet string consisting
- of a base 64 encoded "safe" message produced by a security
- mechanism specific message integrity procedure. The text
- part of a 632 reply is a Telnet string consisting of a base
- 64 encoded "private" message produced by a security
- mechanism specific message confidentiality and integrity
- procedure. The text part of a 633 reply is a Telnet string
- consisting of a base 64 encoded "confidential" message
- produced by a security mechanism specific message
- confidentiality procedure.
-
- The client will decode and verify the encoded reply. How
- failures decoding or verifying replies are handled is
- implementation-specific. An end-of-line code need not be
- included, but if one is included, it must be a Telnet end-
- of-line code, not a local end-of-line code.
-
- A protected reply may only be sent if a security data
- exchange has succeeded.
-
- The 63z reply may be a multiline reply. In this case, the
- plaintext reply must be broken up into a number of
- fragments. Each fragment must be protected, then base 64
-
-
-
-Horowitz & Lunt Standards Track [Page 13]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- encoded in order into a separate line of the multiline
- reply. There need not be any correspondence between the
- line breaks in the plaintext reply and the encoded reply.
- Telnet end-of-line codes must appear in the plaintext of the
- encoded reply, except for the final end-of-line code, which
- is optional.
-
- The multiline reply must be formatted more strictly than the
- continuation specification in RFC 959. In particular, each
- line before the last must be formed by the reply code,
- followed immediately by a hyphen, followed by a base 64
- encoded fragment of the reply.
-
- For example, if the plaintext reply is
-
- 123-First line
- Second line
- 234 A line beginning with numbers
- 123 The last line
-
- then the resulting protected reply could be any of the
- following (the first example has a line break only to fit
- within the margins):
-
- 631 base64(protect("123-First line\r\nSecond line\r\n 234 A line
- 631-base64(protect("123-First line\r\n"))
- 631-base64(protect("Second line\r\n"))
- 631-base64(protect(" 234 A line beginning with numbers\r\n"))
- 631 base64(protect("123 The last line"))
-
- 631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b"))
- 631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
-
-6. Data Channel Encapsulation
-
- When data transfers are protected between the client and server (in
- either direction), certain transformations and encapsulations must be
- performed so that the recipient can properly decode the transmitted
- file.
-
- The sender must apply all protection services after transformations
- associated with the representation type, file structure, and transfer
- mode have been performed. The data sent over the data channel is,
- for the purposes of protection, to be treated as a byte stream.
-
- When performing a data transfer in an authenticated manner, the
- authentication checks are performed on individual blocks of the file,
- rather than on the file as a whole. Consequently, it is possible for
-
-
-
-Horowitz & Lunt Standards Track [Page 14]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- insertion attacks to insert blocks into the data stream (i.e.,
- replays) that authenticate correctly, but result in a corrupted file
- being undetected by the receiver. To guard against such attacks, the
- specific security mechanism employed should include mechanisms to
- protect against such attacks. Many GSS-API mechanisms usable with
- the specification in Appendix I, and the Kerberos mechanism in
- Appendix II do so.
-
- The sender must take the input byte stream, and break it up into
- blocks such that each block, when encoded using a security mechanism
- specific procedure, will be no larger than the buffer size negotiated
- by the client with the PBSZ command. Each block must be encoded,
- then transmitted with the length of the encoded block prepended as a
- four byte unsigned integer, most significant byte first.
-
- When the end of the file is reached, the sender must encode a block
- of zero bytes, and send this final block to the recipient before
- closing the data connection.
-
- The recipient will read the four byte length, read a block of data
- that many bytes long, then decode and verify this block with a
- security mechanism specific procedure. This must be repeated until a
- block encoding a buffer of zero bytes is received. This indicates
- the end of the encoded byte stream.
-
- Any transformations associated with the representation type, file
- structure, and transfer mode are to be performed by the recipient on
- the byte stream resulting from the above process.
-
- When using block transfer mode, the sender's (cleartext) buffer size
- is independent of the block size.
-
- The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE
- command if the current protection level is not at the level dictated
- by the server's security requirements for the particular file
- transfer.
-
- If any data protection services fail at any time during data transfer
- at the server end (including an attempt to send a buffer size greater
- than the negotiated maximum), the server will send a 535 reply to the
- data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 15]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
-7. Potential policy considerations
-
- While there are no restrictions on client and server policy, there
- are a few recommendations which an implementation should implement.
-
- - Once a security data exchange takes place, a server should require
- all commands be protected (with integrity and/or confidentiality),
- and it should protect all replies. Replies should use the same
- level of protection as the command which produced them. This
- includes replies which indicate failure of the MIC, CONF, and ENC
- commands. In particular, it is not meaningful to require that
- AUTH and ADAT be protected; it is meaningful and useful to require
- that PROT and PBSZ be protected. In particular, the use of CCC is
- not recommended, but is defined in the interest of
- interoperability between implementations which might desire such
- functionality.
-
- - A client should encrypt the PASS command whenever possible. It is
- reasonable for the server to refuse to accept a non-encrypted PASS
- command if the server knows encryption is available.
-
- - Although no security commands are required to be implemented, it
- is recommended that an implementation provide all commands which
- can be implemented, given the mechanisms supported and the policy
- considerations of the site (export controls, for instance).
-
-8. Declarative specifications
-
- These sections are modelled after sections 5.3 and 5.4 of RFC 959,
- which describe the same information, except for the standard FTP
- commands and replies.
-
- 8.1. FTP Security commands and arguments
-
- AUTH <SP> <mechanism-name> <CRLF>
- ADAT <SP> <base64data> <CRLF>
- PROT <SP> <prot-code> <CRLF>
- PBSZ <SP> <decimal-integer> <CRLF>
- MIC <SP> <base64data> <CRLF>
- CONF <SP> <base64data> <CRLF>
- ENC <SP> <base64data> <CRLF>
-
- <mechanism-name> ::= <string>
- <base64data> ::= <string>
- ; must be formatted as described in section 9
- <prot-code> ::= C | S | E | P
- <decimal-integer> ::= any decimal integer from 1 to (2^32)-1
-
-
-
-
-Horowitz & Lunt Standards Track [Page 16]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- 8.2. Command-Reply sequences
-
- Security Association Setup
- AUTH
- 234
- 334
- 502, 504, 534, 431
- 500, 501, 421
- ADAT
- 235
- 335
- 503, 501, 535
- 500, 501, 421
- Data protection negotiation commands
- PBSZ
- 200
- 503
- 500, 501, 421, 530
- PROT
- 200
- 504, 536, 503, 534, 431
- 500, 501, 421, 530
- Command channel protection commands
- MIC
- 535, 533
- 500, 501, 421
- CONF
- 535, 533
- 500, 501, 421
- ENC
- 535, 533
- 500, 501, 421
- Security-Enhanced login commands (only new replies listed)
- USER
- 232
- 336
- Data channel commands (only new replies listed)
- STOR
- 534, 535
- STOU
- 534, 535
- RETR
- 534, 535
-
-
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 17]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- LIST
- 534, 535
- NLST
- 534, 535
- APPE
- 534, 535
-
- In addition to these reply codes, any security command can return
- 500, 501, 502, 533, or 421. Any ftp command can return a reply
- code encapsulated in a 631, 632, or 633 reply once a security data
- exchange has completed successfully.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 18]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
-9. State Diagrams
-
- This section includes a state diagram which demonstrates the flow of
- authentication and authorization in a security enhanced FTP
- implementation. The rectangular blocks show states where the client
- must issue a command, and the diamond blocks show states where the
- server must issue a response.
-
-
- ,------------------, USER
- __\| Unauthenticated |_________\
- | /| (new connection) | /|
- | `------------------' |
- | | |
- | | AUTH |
- | V |
- | / \ |
- | 4yz,5yz / \ 234 |
- |<--------< >------------->. |
- | \ / | |
- | \_/ | |
- | | | |
- | | 334 | |
- | V | |
- | ,--------------------, | |
- | | Need Security Data |<--. | |
- | `--------------------' | | |
- | | | | |
- | | ADAT | | |
- | V | | |
- | / \ | | |
- | 4yz,5yz / \ 335 | | |
- `<--------< >-----------' | |
- \ / | |
- \_/ | |
- | | |
- | 235 | |
- V | |
- ,---------------. | |
- ,--->| Authenticated |<--------' | After the client and server
- | `---------------' | have completed authenti-
- | | | cation, command must be
- | | USER | integrity-protected if
- | | | integrity is available. The
- | |<-------------------' CCC command may be issued to
- | V relax this restriction.
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 19]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- | / \
- | 4yz,5yz / \ 2yz
- |<--------< >------------->.
- | \ / |
- | \_/ |
- | | |
- | | 3yz |
- | V |
- | ,---------------. |
- | | Need Password | |
- | `---------------' |
- | | |
- | | PASS |
- | V |
- | / \ |
- | 4yz,5yz / \ 2yz |
- |<--------< >------------->|
- | \ / |
- | \_/ |
- | | |
- | | 3yz |
- | V |
- | ,--------------. |
- | | Need Account | |
- | `--------------' |
- | | |
- | | ACCT |
- | V |
- | / \ |
- | 4yz,5yz / \ 2yz |
- `<--------< >------------->|
- \ / |
- \_/ |
- | |
- | 3yz |
- V |
- ,-------------. |
- | Authorized |/________|
- | (Logged in) |\
- `-------------'
-
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 20]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
-10. Base 64 Encoding
-
- Base 64 encoding is the same as the Printable Encoding described in
- Section 4.3.2.4 of [RFC-1421], except that line breaks must not be
- included. This encoding is defined as follows.
-
- Proceeding from left to right, the bit string resulting from the
- mechanism specific protection routine is encoded into characters
- which are universally representable at all sites, though not
- necessarily with the same bit patterns (e.g., although the character
- "E" is represented in an ASCII-based system as hexadecimal 45 and as
- hexadecimal C5 in an EBCDIC-based system, the local significance of
- the two representations is equivalent).
-
- A 64-character subset of International Alphabet IA5 is used, enabling
- 6 bits to be represented per printable character. (The proposed
- subset of characters is represented identically in IA5 and ASCII.)
- The character "=" signifies a special processing function used for
- padding within the printable encoding procedure.
-
- The encoding process represents 24-bit groups of input bits as output
- strings of 4 encoded characters. Proceeding from left to right
- across a 24-bit input group output from the security mechanism
- specific message protection procedure, each 6-bit group is used as an
- index into an array of 64 printable characters, namely "[A-Z][a-
- z][0-9]+/". The character referenced by the index is placed in the
- output string. These characters are selected so as to be universally
- representable, and the set excludes characters with particular
- significance to Telnet (e.g., "<CR>", "<LF>", IAC).
-
- Special processing is performed if fewer than 24 bits are available
- in an input group at the end of a message. A full encoding quantum
- is always completed at the end of a message. When fewer than 24
- input bits are available in an input group, zero bits are added (on
- the right) to form an integral number of 6-bit groups. Output
- character positions which are not required to represent actual input
- data are set to the character "=". Since all canonically encoded
- output is an integral number of octets, only the following cases can
- arise: (1) the final quantum of encoding input is an integral
- multiple of 24 bits; here, the final unit of encoded output will be
- an integral multiple of 4 characters with no "=" padding, (2) the
- final quantum of encoding input is exactly 8 bits; here, the final
- unit of encoded output will be two characters followed by two "="
- padding characters, or (3) the final quantum of encoding input is
- exactly 16 bits; here, the final unit of encoded output will be three
- characters followed by one "=" padding character.
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 21]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- Implementors must keep in mind that the base 64 encodings in ADAT,
- MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily
- long. Thus, the entire line must be read before it can be processed.
- Several successive reads on the control channel may be necessary. It
- is not appropriate to for a server to reject a command containing a
- base 64 encoding simply because it is too long (assuming that the
- decoding is otherwise well formed in the context in which it was
- sent).
-
- Case must not be ignored when reading commands and replies containing
- base 64 encodings.
-
-11. Security Considerations
-
- This entire document deals with security considerations related to
- the File Transfer Protocol.
-
- Third party file transfers cannot be secured using these extensions,
- since a security context cannot be established between two servers
- using these facilities (no control connection exists between servers
- over which to pass ADAT tokens). Further work in this area is
- deferred.
-
-12. Acknowledgements
-
- I would like to thank the members of the CAT WG, as well as all
- participants in discussions on the "cat-ietf@mit.edu" mailing list,
- for their contributions to this document. I would especially like to
- thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut,
- Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri Balk
- for their contributions to this work. Of course, without Steve Lunt,
- the author of the first six revisions of this document, it would not
- exist at all.
-
-13. References
-
- [TELNET-SEC] Borman, D., "Telnet Authentication and Encryption
- Option", Work in Progress.
-
- [RFC-1123] Braden, R., "Requirements for Internet Hosts --
- Application and Support", STD 3, RFC 1123, October 1989.
-
- [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
- Mail: Part I: Message Encryption and Authentication Procedures",
- RFC 1421, February 1993.
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 22]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
-14. Author's Address
-
- Marc Horowitz
- Cygnus Solutions
- 955 Massachusetts Avenue
- Cambridge, MA 02139
-
- Phone: +1 617 354 7688
- EMail: marc@cygnus.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 23]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
-Appendix I: Specification under the GSSAPI
-
- In order to maximise the utility of new security mechanisms, it is
- desirable that new mechanisms be implemented as GSSAPI mechanisms
- rather than as FTP security mechanisms. This will enable existing
- ftp implementations to support the new mechanisms more easily, since
- little or no code will need to be changed. In addition, the
- mechanism will be usable by other protocols, such as IMAP, which are
- built on top of the GSSAPI, with no additional specification or
- implementation work needed by the mechanism designers.
-
- The security mechanism name (for the AUTH command) associated with
- all mechanisms employing the GSSAPI is GSSAPI. If the server
- supports a security mechanism employing the GSSAPI, it must respond
- with a 334 reply code indicating that an ADAT command is expected
- next.
-
- The client must begin the authentication exchange by calling
- GSS_Init_Sec_Context, passing in 0 for input_context_handle
- (initially), and a targ_name equal to output_name from
- GSS_Import_Name called with input_name_type of Host-Based Service and
- input_name_string of "ftp@hostname" where "hostname" is the fully
- qualified host name of the server with all letters in lower case.
- (Failing this, the client may try again using input_name_string of
- "host@hostname".) The output_token must then be base 64 encoded and
- sent to the server as the argument to an ADAT command. If
- GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client
- must expect a token to be returned in the reply to the ADAT command.
- This token must subsequently be passed to another call to
- GSS_Init_Sec_Context. In this case, if GSS_Init_Sec_Context returns
- no output_token, then the reply code from the server for the previous
- ADAT command must have been 235. If GSS_Init_Sec_Context returns
- GSS_S_COMPLETE, then no further tokens are expected from the server,
- and the client must consider the server authenticated.
-
- The server must base 64 decode the argument to the ADAT command and
- pass the resultant token to GSS_Accept_Sec_Context as input_token,
- setting acceptor_cred_handle to NULL (for "use default credentials"),
- and 0 for input_context_handle (initially). If an output_token is
- returned, it must be base 64 encoded and returned to the client by
- including "ADAT=base64string" in the text of the reply. If
- GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be
- 235, and the server must consider the client authenticated. If
- GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code
- must be 335. Otherwise, the reply code should be 535, and the text
- of the reply should contain a descriptive error message.
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 24]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- The chan_bindings input to GSS_Init_Sec_Context and
- GSS_Accept_Sec_Context should use the client internet address and
- server internet address as the initiator and acceptor addresses,
- respectively. The address type for both should be GSS_C_AF_INET. No
- application data should be specified.
-
- Since GSSAPI supports anonymous peers to security contexts, it is
- possible that the client's authentication of the server does not
- actually establish an identity.
-
- The procedure associated with MIC commands, 631 replies, and Safe
- file transfers is:
-
- GSS_Wrap for the sender, with conf_flag == FALSE
-
- GSS_Unwrap for the receiver
-
- The procedure associated with ENC commands, 632 replies, and Private
- file transfers is:
-
- GSS_Wrap for the sender, with conf_flag == TRUE
- GSS_Unwrap for the receiver
-
- CONF commands and 633 replies are not supported.
-
- Both the client and server should inspect the value of conf_avail to
- determine whether the peer supports confidentiality services.
-
- When the security state is reset (when AUTH is received a second
- time, or when REIN is received), this should be done by calling the
- GSS_Delete_sec_context function.
-
-Appendix II: Specification under Kerberos version 4
-
- The security mechanism name (for the AUTH command) associated with
- Kerberos Version 4 is KERBEROS_V4. If the server supports
- KERBEROS_V4, it must respond with a 334 reply code indicating that an
- ADAT command is expected next.
-
- The client must retrieve a ticket for the Kerberos principal
- "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
- of "ftp", an instance equal to the first part of the canonical host
- name of the server with all letters in lower case (as returned by
- krb_get_phost(3)), the server's realm name (as returned by
- krb_realmofhost(3)), and an arbitrary checksum. The ticket must then
- be base 64 encoded and sent as the argument to an ADAT command.
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 25]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
- If the "ftp" principal name is not a registered principal in the
- Kerberos database, then the client may fall back on the "rcmd"
- principal name (same instance and realm). However, servers must
- accept only one or the other of these principal names, and must not
- be willing to accept either. Generally, if the server has a key for
- the "ftp" principal in its srvtab, then that principal only must be
- used, otherwise the "rcmd" principal only must be used.
-
- The server must base 64 decode the argument to the ADAT command and
- pass the result to krb_rd_req(3). The server must add one to the
- checksum from the authenticator, convert the result to network byte
- order (most significant byte first), and sign it using
- krb_mk_safe(3), and base 64 encode the result. Upon success, the
- server must reply to the client with a 235 code and include
- "ADAT=base64string" in the text of the reply. Upon failure, the
- server should reply 535.
-
- Upon receipt of the 235 reply from the server, the client must parse
- the text of the reply for the base 64 encoded data, decode it,
- convert it from network byte order, and pass the result to
- krb_rd_safe(3). The client must consider the server authenticated if
- the resultant checksum is equal to one plus the value previously
- sent.
-
- The procedure associated with MIC commands, 631 replies, and Safe
- file transfers is:
-
- krb_mk_safe(3) for the sender
- krb_rd_safe(3) for the receiver
-
- The procedure associated with ENC commands, 632 replies, and Private
- file transfers is:
-
- krb_mk_priv(3) for the sender
- krb_rd_priv(3) for the receiver
-
- CONF commands and 633 replies are not supported.
-
- Note that this specification for KERBEROS_V4 contains no provision
- for negotiating alternate means for integrity and confidentiality
- routines. Note also that the ADAT exchange does not convey whether
- the peer supports confidentiality services.
-
- In order to stay within the allowed PBSZ, implementors must take note
- that a cleartext buffer will grow by 31 bytes when processed by
- krb_mk_safe(3) and will grow by 26 bytes when processed by
- krb_mk_priv(3).
-
-
-
-
-Horowitz & Lunt Standards Track [Page 26]
-
-RFC 2228 FTP Security Extensions October 1997
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). 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
- andand 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt Standards Track [Page 27]
-
diff --git a/kadmin/server.c b/kadmin/server.c
deleted file mode 100644
index 7212df5ff9b438287193d7f4d2ad3e7db6557b86..0000000000000000000000000000000000000000
--- a/kadmin/server.c
+++ /dev/null
@@ -1,296 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-kadm5_ret_t
-kadmind_dispatch(void *kadm_handle, krb5_storage *sp)
-{
- kadm5_ret_t ret;
- int32_t cmd, mask, tmp;
- kadm5_server_context *context = kadm_handle;
- char client[128], name[128], name2[128];
- char *op = "";
- krb5_principal princ, princ2;
- kadm5_principal_ent_rec ent;
- char *password, *exp;
- krb5_keyblock *new_keys;
- int n_keys;
- char **princs;
- int n_princs;
-
- krb5_unparse_name_fixed(context->context, context->caller,
- client, sizeof(client));
-
- krb5_ret_int32(sp, &cmd);
- switch(cmd){
- case kadm_get:{
- op = "GET";
- ret = krb5_ret_principal(sp, &princ);
- if(ret)
- goto fail;
- ret = krb5_ret_int32(sp, &mask);
- if(ret){
- krb5_free_principal(context->context, princ);
- goto fail;
- }
- krb5_unparse_name_fixed(context->context, princ, name, sizeof(name));
- krb5_warnx(context->context, "%s: %s %s", client, op, name);
- ret = _kadm5_acl_check_permission(context, KADM5_PRIV_GET);
- if(ret){
- krb5_free_principal(context->context, princ);
- goto fail;
- }
- ret = kadm5_get_principal(kadm_handle, princ, &ent, mask);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- if(ret == 0){
- kadm5_store_principal_ent(sp, &ent);
- kadm5_free_principal_ent(kadm_handle, &ent);
- }
- krb5_free_principal(context->context, princ);
- break;
- }
- case kadm_delete:{
- op = "DELETE";
- ret = krb5_ret_principal(sp, &princ);
- if(ret)
- goto fail;
- krb5_unparse_name_fixed(context->context, princ, name, sizeof(name));
- krb5_warnx(context->context, "%s: %s %s", client, op, name);
- ret = _kadm5_acl_check_permission(context, KADM5_PRIV_DELETE);
- if(ret){
- krb5_free_principal(context->context, princ);
- goto fail;
- }
- ret = kadm5_delete_principal(kadm_handle, princ);
- krb5_free_principal(context->context, princ);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- break;
- }
- case kadm_create:{
- op = "CREATE";
- ret = kadm5_ret_principal_ent(sp, &ent);
- if(ret)
- goto fail;
- ret = krb5_ret_int32(sp, &mask);
- if(ret){
- kadm5_free_principal_ent(context->context, &ent);
- goto fail;
- }
- ret = krb5_ret_string(sp, &password);
- if(ret){
- kadm5_free_principal_ent(context->context, &ent);
- goto fail;
- }
- krb5_unparse_name_fixed(context->context, ent.principal,
- name, sizeof(name));
- krb5_warnx(context->context, "%s: %s %s", client, op, name);
- ret = _kadm5_acl_check_permission(context, KADM5_PRIV_ADD);
- if(ret){
- kadm5_free_principal_ent(context->context, &ent);
- memset(password, 0, strlen(password));
- free(password);
- goto fail;
- }
- ret = kadm5_create_principal(kadm_handle, &ent,
- mask, password);
- kadm5_free_principal_ent(kadm_handle, &ent);
- memset(password, 0, strlen(password));
- free(password);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- break;
- }
- case kadm_modify:{
- op = "MODIFY";
- ret = kadm5_ret_principal_ent(sp, &ent);
- if(ret)
- goto fail;
- ret = krb5_ret_int32(sp, &mask);
- if(ret){
- kadm5_free_principal_ent(context, &ent);
- goto fail;
- }
- krb5_unparse_name_fixed(context->context, ent.principal,
- name, sizeof(name));
- krb5_warnx(context->context, "%s: %s %s", client, op, name);
- ret = _kadm5_acl_check_permission(context, KADM5_PRIV_MODIFY);
- if(ret){
- kadm5_free_principal_ent(context, &ent);
- goto fail;
- }
- ret = kadm5_modify_principal(kadm_handle, &ent, mask);
- kadm5_free_principal_ent(kadm_handle, &ent);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- break;
- }
- case kadm_rename:{
- op = "RENAME";
- ret = krb5_ret_principal(sp, &princ);
- if(ret)
- goto fail;
- ret = krb5_ret_principal(sp, &princ2);
- if(ret){
- krb5_free_principal(context->context, princ);
- goto fail;
- }
- krb5_unparse_name_fixed(context->context, princ, name, sizeof(name));
- krb5_unparse_name_fixed(context->context, princ2, name2, sizeof(name2));
- krb5_warnx(context->context, "%s: %s %s -> %s",
- client, op, name, name2);
- ret = _kadm5_acl_check_permission(context,
- KADM5_PRIV_ADD|KADM5_PRIV_DELETE);
- if(ret){
- krb5_free_principal(context->context, princ);
- goto fail;
- }
- ret = kadm5_rename_principal(kadm_handle, princ, princ2);
- krb5_free_principal(context->context, princ);
- krb5_free_principal(context->context, princ2);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- break;
- }
- case kadm_chpass:{
- op = "CHPASS";
- ret = krb5_ret_principal(sp, &princ);
- if(ret)
- goto fail;
- ret = krb5_ret_string(sp, &password);
- if(ret){
- krb5_free_principal(context->context, princ);
- goto fail;
- }
- krb5_unparse_name_fixed(context->context, princ, name, sizeof(name));
- krb5_warnx(context->context, "%s: %s %s", client, op, name);
- ret = _kadm5_acl_check_permission(context, KADM5_PRIV_CPW);
- if(ret){
- krb5_free_principal(context->context, princ);
- goto fail;
- }
- ret = kadm5_chpass_principal(kadm_handle, princ, password);
- krb5_free_principal(context->context, princ);
- memset(password, 0, strlen(password));
- free(password);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- break;
- }
- case kadm_randkey:{
- op = "RANDKEY";
- ret = krb5_ret_principal(sp, &princ);
- if(ret)
- goto fail;
- krb5_unparse_name_fixed(context->context, princ, name, sizeof(name));
- krb5_warnx(context->context, "%s: %s %s", client, op, name);
- ret = _kadm5_acl_check_permission(context, KADM5_PRIV_CPW);
- if(ret){
- krb5_free_principal(context->context, princ);
- goto fail;
- }
- ret = kadm5_randkey_principal(kadm_handle, princ,
- &new_keys, &n_keys);
- krb5_free_principal(context->context, princ);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- if(ret == 0){
- int i;
- krb5_store_int32(sp, n_keys);
- for(i = 0; i < n_keys; i++){
- krb5_store_keyblock(sp, new_keys[i]);
- krb5_free_keyblock_contents(context->context, &new_keys[i]);
- }
- }
- break;
- }
- case kadm_get_privs:{
- ret = kadm5_get_privs(kadm_handle, &mask);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- if(ret == 0)
- krb5_store_int32(sp, mask);
- break;
- }
- case kadm_get_princs:{
- op = "LIST";
- ret = krb5_ret_int32(sp, &tmp);
- if(ret)
- goto fail;
- if(tmp){
- ret = krb5_ret_string(sp, &exp);
- if(ret)
- goto fail;
- }else
- exp = NULL;
- krb5_warnx(context->context, "%s: %s %s", client, op, exp ? exp : "*");
- ret = _kadm5_acl_check_permission(context, KADM5_PRIV_LIST);
- if(ret){
- free(exp);
- goto fail;
- }
- ret = kadm5_get_principals(kadm_handle, exp, &princs, &n_princs);
- free(exp);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- if(ret == 0){
- int i;
- krb5_store_int32(sp, n_princs);
- for(i = 0; i < n_princs; i++)
- krb5_store_string(sp, princs[i]);
- kadm5_free_name_list(kadm_handle, princs, &n_princs);
- }
- break;
- }
- default:
- krb5_warnx(context->context, "%s: UNKNOWN OP %d", client, cmd);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, KADM5_FAILURE);
- break;
- }
- return 0;
-fail:
- krb5_warnx(context->context, "%s", op);
- sp->seek(sp, 0, SEEK_SET);
- krb5_store_int32(sp, ret);
- return 0;
-}
diff --git a/lib/asn1/asn1_err.et b/lib/asn1/asn1_err.et
deleted file mode 100644
index 548c2ba61d3440ef02ec34e9a048d671e29abd73..0000000000000000000000000000000000000000
--- a/lib/asn1/asn1_err.et
+++ /dev/null
@@ -1,20 +0,0 @@
-#
-# Error messages for the asn.1 library
-#
-# This might look like a com_err file, but is not
-#
-id $Id$
-
-error_table asn1
-prefix ASN1
-error_code BAD_TIMEFORMAT, "ASN.1 failed call to system time library"
-error_code MISSING_FIELD, "ASN.1 structure is missing a required field"
-error_code MISPLACED_FIELD, "ASN.1 unexpected field number"
-error_code TYPE_MISMATCH, "ASN.1 type numbers are inconsistent"
-error_code OVERFLOW, "ASN.1 value too large"
-error_code OVERRUN, "ASN.1 encoding ended unexpectedly"
-error_code BAD_ID, "ASN.1 identifier doesn't match expected value"
-error_code BAD_LENGTH, "ASN.1 length doesn't match expected value"
-error_code BAD_FORMAT, "ASN.1 badly-formatted encoding"
-error_code PARSE_ERROR, "ASN.1 parse error"
-end
diff --git a/lib/auth/Makefile.in b/lib/auth/Makefile.in
deleted file mode 100644
index c9a457a5715c47324e04dc8cb4256db562b18594..0000000000000000000000000000000000000000
--- a/lib/auth/Makefile.in
+++ /dev/null
@@ -1,53 +0,0 @@
-#
-# $Id$
-#
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-
-SHELL = /bin/sh
-
-@SET_MAKE@
-
-SUBDIRS = @LIB_AUTH_SUBDIRS@
-
-all:
- SUBDIRS='$(SUBDIRS)'; \
- for i in $$SUBDIRS; \
- do (cd $$i && $(MAKE) $(MFLAGS) all); done
-
-Wall:
- make CFLAGS="-g -Wall -Wno-comment -Wmissing-prototypes -Wmissing-declarations -D__USE_FIXED_PROTOTYPES__"
-
-install:
- SUBDIRS=$(SUBDIRS); \
- for i in $$SUBDIRS; \
- do (cd $$i && $(MAKE) $(MFLAGS) install); done
-
-uninstall:
- SUBDIRS=$(SUBDIRS); \
- for i in $$SUBDIRS; \
- do (cd $$i && $(MAKE) $(MFLAGS) uninstall); done
-
-check:
- SUBDIRS=$(SUBDIRS); \
- for i in $$SUBDIRS; \
- do (cd $$i && $(MAKE) $(MFLAGS) check); done
-
-clean:
- SUBDIRS=$(SUBDIRS); \
- for i in $$SUBDIRS; \
- do (cd $$i && $(MAKE) $(MFLAGS) clean); done
-
-mostlyclean: clean
-
-distclean:
- SUBDIRS=$(SUBDIRS); \
- for i in $$SUBDIRS; \
- do (cd $$i && $(MAKE) $(MFLAGS) distclean); done
- rm -f Makefile *~
-
-realclean:
- SUBDIRS=$(SUBDIRS); \
- for i in $$SUBDIRS; \
- do (cd $$i && $(MAKE) $(MFLAGS) realclean); done
diff --git a/lib/auth/afskauthlib/Makefile.in b/lib/auth/afskauthlib/Makefile.in
deleted file mode 100644
index 37a9ea7a2e4d5adc716a3b6f0eba6999cff13c60..0000000000000000000000000000000000000000
--- a/lib/auth/afskauthlib/Makefile.in
+++ /dev/null
@@ -1,78 +0,0 @@
-#
-# $Id$
-#
-
-SHELL = /bin/sh
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-
-CC = @CC@
-AR = ar
-LN_S = @LN_S@
-RANLIB = @RANLIB@
-DEFS = @DEFS@
-CFLAGS = @CFLAGS@
-
-INSTALL = @INSTALL@
-INSTALL_DATA = @INSTALL_DATA@
-MKINSTALLDIRS = @top_srcdir@/mkinstalldirs
-
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-libdir = @libdir@
-
-PICFLAGS = @REAL_PICFLAGS@
-LDSHARED = @LDSHARED@
-SHLIBEXT = @REAL_SHLIBEXT@
-LD_FLAGS = @REAL_LD_FLAGS@
-
-LIB = afskauthlib.$(SHLIBEXT)
-
-SOURCES = verify.c
-
-OBJECTS = verify.o
-
-all: $(LIB)
-
-Wall:
- make CFLAGS="-g -Wall -Wno-comment -Wmissing-prototypes -Wmissing-declarations -D__USE_FIXED_PROTOTYPES__"
-
-.c.o:
- $(CC) -c $(CPPFLAGS) $(DEFS) -I../../../include -I$(srcdir) $(CFLAGS) $(PICFLAGS) $<
-
-install: all
- $(MKINSTALLDIRS) $(libdir)
- -if test "$(LIB)" != ""; then \
- $(INSTALL_DATA) -m 0555 $(LIB) $(libdir) ; \
- fi
-
-uninstall:
-
-TAGS: $(SOURCES)
- etags $(SOURCES)
-
-check:
-
-clean:
- rm -f $(LIB) *.o
-
-mostlyclean: clean
-
-distclean: clean
- rm -f Makefile *.tab.c *~
-
-realclean: distclean
- rm -f TAGS
-
-dist: $(DISTFILES)
- for file in $(DISTFILES); do \
- ln $$file ../`cat ../.fname`/lib \
- || cp -p $$file ../`cat ../.fname`/lib; \
- done
-
-$(OBJECTS): ../../../include/config.h
-
-$(LIB): $(OBJECTS)
- rm -f $@
- $(LDSHARED) -o $@ $(OBJECTS) $(LD_FLAGS) -L../../kafs -lkafs -L../../krb -lkrb -L../../des -ldes -L../../roken -lroken
diff --git a/lib/auth/afskauthlib/verify.c b/lib/auth/afskauthlib/verify.c
deleted file mode 100644
index e8877988b3f1c33dc353372069cf70dbecb18139..0000000000000000000000000000000000000000
--- a/lib/auth/afskauthlib/verify.c
+++ /dev/null
@@ -1,90 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-#endif
-#include <unistd.h>
-#include <sys/types.h>
-#include <pwd.h>
-#include <krb.h>
-#include <kafs.h>
-#include <roken.h>
-
-/*
- *
- */
-
-int
-afs_verify(char *name,
- char *password,
- int32_t *exp,
- int quiet)
-{
- int ret = 1;
- char lrealm[REALM_SZ + 1];
- char tkt_string[MaxPathLen];
- struct passwd *pwd;
-
- if (krb_get_lrealm (lrealm, 1) != KFAILURE &&
- (pwd = k_getpwnam (name)) != NULL) {
- snprintf (tkt_string, sizeof(tkt_string),
- "%s%d_%d", TKT_ROOT,
- (unsigned)pwd->pw_uid, (unsigned)getpid());
- krb_set_tkt_string (tkt_string);
- ret = krb_verify_user (name, "", lrealm, password, 1, NULL, "");
- if (ret == KSUCCESS) {
- if (k_hasafs()) {
- k_setpag ();
- krb_afslog_uid (0, 0, pwd->pw_uid);
- }
- } else if (!quiet)
- printf ("%s\n", krb_get_err_text (ret));
- }
- if (ret)
- ret = unix_verify_user (name, password);
-
- return ret;
-}
-
-char *
-afs_gettktstring (void)
-{
- return tkt_string ();
-}
diff --git a/lib/auth/pam/Makefile.in b/lib/auth/pam/Makefile.in
deleted file mode 100644
index af512156795b92604eddb6a9e131e01fd5ea67a8..0000000000000000000000000000000000000000
--- a/lib/auth/pam/Makefile.in
+++ /dev/null
@@ -1,79 +0,0 @@
-#
-# $Id$
-#
-
-SHELL = /bin/sh
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-
-CC = @CC@
-AR = ar
-RANLIB = @RANLIB@
-DEFS = @DEFS@
-CFLAGS = @CFLAGS@
-
-INSTALL = @INSTALL@
-INSTALL_DATA = @INSTALL_DATA@
-MKINSTALLDIRS = @top_srcdir@/mkinstalldirs
-
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-libdir = @libdir@
-
-PICFLAGS = @REAL_PICFLAGS@
-LDSHARED = @LDSHARED@
-SHLIBEXT = @REAL_SHLIBEXT@
-LD_FLAGS = @REAL_LD_FLAGS@
-
-LIB = pam_krb4.$(SHLIBEXT)
-
-SOURCES = pam.c
-
-OBJECTS = pam.o
-
-all: $(LIB)
-
-Wall:
- make CFLAGS="-g -Wall -Wno-comment -Wmissing-prototypes -Wmissing-declarations -D__USE_FIXED_PROTOTYPES__"
-
-.c.o:
- $(CC) -c $(CPPFLAGS) $(DEFS) -I../../../include -I$(srcdir) $(CFLAGS) $(PICFLAGS) $<
-
-install: all
- $(MKINSTALLDIRS) $(libdir)
- -if test "$(LIB)" != ""; then \
- $(INSTALL_DATA) -m 0555 $(LIB) $(libdir) ; \
- fi
-
-uninstall:
-
-TAGS: $(SOURCES)
- etags $(SOURCES)
-
-check:
-
-clean:
- rm -f $(LIB) *.o
-
-mostlyclean: clean
-
-distclean: clean
- rm -f Makefile *.tab.c *~
-
-realclean: distclean
- rm -f TAGS
-
-dist: $(DISTFILES)
- for file in $(DISTFILES); do \
- ln $$file ../`cat ../.fname`/lib \
- || cp -p $$file ../`cat ../.fname`/lib; \
- done
-
-
-$(OBJECTS): ../../../include/config.h
-
-$(LIB): $(OBJECTS)
- rm -f $@
- $(LDSHARED) -o $@ $(OBJECTS) $(LD_FLAGS) -L../../kafs -L../../krb -L../../des -L../../roken -lkafs -lkrb -ldes -lroken
-# $(CC) -shared -Wl,-x -o $(LIB) $(OBJECTS) ../../kafs/libkafs.a ../../krb/libkrb.a ../../des/libdes.a
diff --git a/lib/auth/pam/pam.c b/lib/auth/pam/pam.c
deleted file mode 100644
index 58fdc45fbd41bd2e357b4acb38c6dcf08c3e78f4..0000000000000000000000000000000000000000
--- a/lib/auth/pam/pam.c
+++ /dev/null
@@ -1,233 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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 code is extremely ugly, and would probably be better off
- beeing completely rewritten */
-
-
-#ifdef HAVE_CONFIG_H
-#include<config.h>
-RCSID("$Id$");
-#endif
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <pwd.h>
-#include <unistd.h>
-#include <sys/types.h>
-
-#define PAM_SM_AUTH
-#define PAM_SM_SESSION
-#include <security/pam_appl.h>
-#include <security/pam_modules.h>
-
-#include <netinet/in.h>
-#include <krb.h>
-#include <kafs.h>
-
-static int
-cleanup(pam_handle_t *pamh, void *data, int error_code)
-{
- if(error_code != PAM_SUCCESS)
- dest_tkt();
- free(data);
- return PAM_SUCCESS;
-}
-
-static int
-doit(pam_handle_t *pamh, char *name, char *inst, char *pwd, char *tkt)
-{
- char realm[REALM_SZ];
- int ret;
-
- pam_set_data(pamh, "KRBTKFILE", strdup(tkt), cleanup);
- krb_set_tkt_string(tkt);
-
- krb_get_lrealm(realm, 1);
- ret = krb_verify_user(name, inst, realm, pwd, 1, NULL, "");
- memset(pwd, 0, strlen(pwd));
- switch(ret){
- case KSUCCESS:
- return PAM_SUCCESS;
- case KDC_PR_UNKNOWN:
- return PAM_USER_UNKNOWN;
- case SKDC_CANT:
- case SKDC_RETRY:
- case RD_AP_TIME:
- return PAM_AUTHINFO_UNAVAIL;
- default:
- return PAM_AUTH_ERR;
- }
-}
-
-static int
-auth_login(pam_handle_t *pamh, int flags, char *user, struct pam_conv *conv)
-{
- int ret;
- struct pam_message msg, *pmsg;
- struct pam_response *resp;
- char prompt[128];
-
- pmsg = &msg;
- msg.msg_style = PAM_PROMPT_ECHO_OFF;
- snprintf(prompt, sizeof(prompt), "%s's Password: ", user);
- msg.msg = prompt;
-
- ret = conv->conv(1, (const struct pam_message**)&pmsg,
- &resp, conv->appdata_ptr);
- if(ret != PAM_SUCCESS)
- return ret;
-
- {
- char tkt[1024];
- struct passwd *pw = getpwnam(user);
-
- if(pw){
- snprintf(tkt, sizeof(tkt),
- "%s%u", TKT_ROOT, (unsigned)pw->pw_uid);
- ret = doit(pamh, user, "", resp->resp, tkt);
- if(ret == PAM_SUCCESS)
- chown(tkt, pw->pw_uid, pw->pw_gid);
- }else
- ret = PAM_USER_UNKNOWN;
- memset(resp->resp, 0, strlen(resp->resp));
- free(resp->resp);
- free(resp);
- }
- return ret;
-}
-
-static int
-auth_su(pam_handle_t *pamh, int flags, char *user, struct pam_conv *conv)
-{
- int ret;
- struct passwd *pw;
- struct pam_message msg, *pmsg;
- struct pam_response *resp;
- char prompt[128];
- krb_principal pr;
-
- pr.realm[0] = 0;
- ret = pam_get_user(pamh, &user, "login: ");
- if(ret != PAM_SUCCESS)
- return ret;
-
- pw = getpwuid(getuid());
- if(strcmp(user, "root") == 0){
- strcpy(pr.name, pw->pw_name);
- strcpy(pr.instance, "root");
- }else{
- strcpy(pr.name, user);
- pr.instance[0] = 0;
- }
- pmsg = &msg;
- msg.msg_style = PAM_PROMPT_ECHO_OFF;
- snprintf(prompt, sizeof(prompt), "%s's Password: ", krb_unparse_name(&pr));
- msg.msg = prompt;
-
- ret = conv->conv(1, (const struct pam_message**)&pmsg,
- &resp, conv->appdata_ptr);
- if(ret != PAM_SUCCESS)
- return ret;
-
- {
- char tkt[1024];
-
- snprintf(tkt, sizeof(tkt),"%s_%s_to_%s",
- TKT_ROOT, pw->pw_name, user);
- ret = doit(pamh, pr.name, pr.instance, resp->resp, tkt);
- if(ret == PAM_SUCCESS)
- chown(tkt, pw->pw_uid, pw->pw_gid);
- memset(resp->resp, 0, strlen(resp->resp));
- free(resp->resp);
- free(resp);
- }
- return ret;
-}
-
-int
-pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv)
-{
- char *user;
- int ret;
- struct pam_conv *conv;
- ret = pam_get_user(pamh, &user, "login: ");
- if(ret != PAM_SUCCESS)
- return ret;
-
- ret = pam_get_item(pamh, PAM_CONV, (void*)&conv);
- if(ret != PAM_SUCCESS)
- return ret;
-
-
- if(getuid() != geteuid())
- return auth_su(pamh, flags, user, conv);
- else
- return auth_login(pamh, flags, user, conv);
-}
-
-int
-pam_sm_setcred(pam_handle_t *pamh, int flags, int argc, const char **argv)
-{
- return PAM_SUCCESS;
-}
-
-
-int
-pam_sm_open_session(pam_handle_t *pamh, int flags, int argc, const char **argv)
-{
- char *tkt;
- pam_get_data(pamh, "KRBTKFILE", (const void**)&tkt);
- setenv("KRBTKFILE", tkt, 1);
- if(k_hasafs()){
- k_setpag();
- krb_afslog(0, 0);
- }
- return PAM_SUCCESS;
-}
-
-
-int
-pam_sm_close_session(pam_handle_t *pamh, int flags, int argc, const char **argv)
-{
- dest_tkt();
- if(k_hasafs())
- k_unlog();
- return PAM_SUCCESS;
-}
diff --git a/lib/auth/pam/pam.conf.add b/lib/auth/pam/pam.conf.add
deleted file mode 100644
index 1bfb30eb948efb79faf334285a4e135637185477..0000000000000000000000000000000000000000
--- a/lib/auth/pam/pam.conf.add
+++ /dev/null
@@ -1,13 +0,0 @@
-# To get this to work, you will have to add entries to /etc/pam.conf
-#
-# To make login kerberos-aware, you might change pam.conf to look
-# like:
-
-# login authorization
-login auth sufficient /lib/security/pam_krb4.so
-login auth required /lib/security/pam_securetty.so
-login auth required /lib/security/pam_unix_auth.so
-login account required /lib/security/pam_unix_acct.so
-login password required /lib/security/pam_unix_passwd.so
-login session required /lib/security/pam_krb4.so
-login session required /lib/security/pam_unix_session.so
diff --git a/lib/auth/sia/Makefile.in b/lib/auth/sia/Makefile.in
deleted file mode 100644
index 52bfab9d8abf236c50e97b8707abcd9caca89762..0000000000000000000000000000000000000000
--- a/lib/auth/sia/Makefile.in
+++ /dev/null
@@ -1,80 +0,0 @@
-#
-# $Id$
-#
-
-SHELL = /bin/sh
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-
-CC = @CC@
-AR = ar
-RANLIB = @RANLIB@
-DEFS = @DEFS@
-CFLAGS = @CFLAGS@
-
-INSTALL = @INSTALL@
-INSTALL_DATA = @INSTALL_DATA@
-MKINSTALLDIRS = @top_srcdir@/mkinstalldirs
-
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-libdir = @libdir@
-
-PICFLAGS = @REAL_PICFLAGS@
-SHARED = @SHARED@
-LDSHARED = @LDSHARED@
-SHLIBEXT = @REAL_SHLIBEXT@
-LD_FLAGS = @REAL_LD_FLAGS@
-
-LIB = libsia_krb4.$(SHLIBEXT)
-
-SOURCES = sia.c
-
-OBJECTS = sia.o
-
-all: $(LIB)
-
-Wall:
- make CFLAGS="-g -Wall -Wno-comment -Wmissing-prototypes -Wmissing-declarations -D__USE_FIXED_PROTOTYPES__"
-
-.c.o:
- $(CC) -c $(CPPFLAGS) $(DEFS) -I../../../include -I$(srcdir) $(CFLAGS) $(PICFLAGS) $<
-
-install: all
- $(MKINSTALLDIRS) $(libdir)
- -if test "$(LIB)" != ""; then \
- $(INSTALL_DATA) -m 0555 $(LIB) $(libdir) ; \
- fi
-
-uninstall:
-
-TAGS: $(SOURCES)
- etags $(SOURCES)
-
-check:
-
-clean:
- rm -f $(LIB) *.o
-
-mostlyclean: clean
-
-distclean: clean
- rm -f Makefile *.tab.c *~
-
-realclean: distclean
- rm -f TAGS
-
-dist: $(DISTFILES)
- for file in $(DISTFILES); do \
- ln $$file ../`cat ../.fname`/lib \
- || cp -p $$file ../`cat ../.fname`/lib; \
- done
-
-
-$(OBJECTS): ../../../include/config.h
-
-$(LIB): $(OBJECTS)
- rm -f $@
- $(LDSHARED) -shared -o $@ -rpath $(libdir) -hidden -exported_symbol siad_\* $(OBJECTS) -L../../kafs -lkafs -L../../krb -lkrb -L../../des -ldes -L../../roken -lroken @LIB_getpwnam_r@ -lc
-# ld -shared -o $@ -hidden -exported_symbol siad_\* $(OBJECTS) ../../kafs/libkafs.a ../../krb/libkrb.a ../../des/libdes.a ../../roken/libroken.a @LIB_getpwnam_r@ -lc
diff --git a/lib/auth/sia/krb4+c2_matrix.conf b/lib/auth/sia/krb4+c2_matrix.conf
deleted file mode 100644
index ecc839da5a0d77796b8fbe09a8d4b1df8fbed4b8..0000000000000000000000000000000000000000
--- a/lib/auth/sia/krb4+c2_matrix.conf
+++ /dev/null
@@ -1,38 +0,0 @@
-# $Id$
-
-# sia matrix configuration file (Kerberos 4 + C2)
-
-siad_init=(KRB4,/usr/athena/lib/libsia_krb4.so)(BSD,libc.so)
-siad_chk_invoker=(OSFC2,/usr/shlib/libsecurity.so)
-siad_ses_init=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsecurity
-.so)
-siad_ses_authent=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsecur
-ity.so)
-siad_ses_estab=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsecurit
-y.so)
-siad_ses_launch=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsecuri
-ty.so)
-siad_ses_suauthent=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsec
-urity.so)
-siad_ses_reauthent=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsec
-urity.so)
-siad_chg_finger=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsecuri
-ty.so)
-siad_chg_password=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsecu
-rity.so)
-siad_chg_shell=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsecurit
-y.so)
-siad_getpwent=(BSD,libc.so)
-siad_getpwuid=(BSD,libc.so)
-siad_getpwnam=(BSD,libc.so)
-siad_setpwent=(BSD,libc.so)
-siad_endpwent=(BSD,libc.so)
-siad_getgrent=(BSD,libc.so)
-siad_getgrgid=(BSD,libc.so)
-siad_getgrnam=(BSD,libc.so)
-siad_setgrent=(BSD,libc.so)
-siad_endgrent=(BSD,libc.so)
-siad_ses_release=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsecur
-ity.so)
-siad_chk_user=(KRB4,/usr/athena/lib/libsia_krb4.so)(OSFC2,/usr/shlib/libsecurity
-.so)
diff --git a/lib/auth/sia/krb4_matrix.conf b/lib/auth/sia/krb4_matrix.conf
deleted file mode 100644
index d19d24f7613be2b46cb2caa5e84b7289e8447ff6..0000000000000000000000000000000000000000
--- a/lib/auth/sia/krb4_matrix.conf
+++ /dev/null
@@ -1,28 +0,0 @@
-# $Id$
-
-# sia matrix configuration file (Kerberos 4 + BSD)
-
-siad_init=(KRB4,/usr/athena/lib/libsia_krb4.so)(BSD,libc.so)
-siad_chk_invoker=(BSD,libc.so)
-siad_ses_init=(KRB4,/usr/athena/lib/libsia_krb4.so)
-siad_ses_authent=(KRB4,/usr/athena/lib/libsia_krb4.so)(BSD,libc.so)
-siad_ses_estab=(BSD,libc.so)
-siad_ses_launch=(KRB4,/usr/athena/lib/libsia_krb4.so)(BSD,libc.so)
-siad_ses_suauthent=(KRB4,/usr/athena/lib/libsia_krb4.so)(BSD,libc.so)
-siad_ses_reauthent=(BSD,libc.so)
-siad_chg_finger=(BSD,libc.so)
-siad_chg_password=(BSD,libc.so)
-siad_chg_shell=(BSD,libc.so)
-siad_getpwent=(BSD,libc.so)
-siad_getpwuid=(BSD,libc.so)
-siad_getpwnam=(BSD,libc.so)
-siad_setpwent=(BSD,libc.so)
-siad_endpwent=(BSD,libc.so)
-siad_getgrent=(BSD,libc.so)
-siad_getgrgid=(BSD,libc.so)
-siad_getgrnam=(BSD,libc.so)
-siad_setgrent=(BSD,libc.so)
-siad_endgrent=(BSD,libc.so)
-siad_ses_release=(KRB4,/usr/athena/lib/libsia_krb4.so)(BSD,libc.so)
-siad_chk_user=(BSD,libc.so)
-
diff --git a/lib/auth/sia/security.patch b/lib/auth/sia/security.patch
deleted file mode 100644
index c407876d636238735764fc12a1c1eb43245481fa..0000000000000000000000000000000000000000
--- a/lib/auth/sia/security.patch
+++ /dev/null
@@ -1,11 +0,0 @@
---- /sbin/init.d/security~ Tue Aug 20 22:44:09 1996
-+++ /sbin/init.d/security Fri Nov 1 14:52:56 1996
-@@ -49,7 +49,7 @@
- SECURITY=BASE
- fi
- ;;
-- BASE)
-+ BASE|KRB4)
- ;;
- *)
- echo "security configuration set to default (BASE)."
diff --git a/lib/auth/sia/sia.c b/lib/auth/sia/sia.c
deleted file mode 100644
index 70566ff690c6c3468c43e9e234b445413fc4da94..0000000000000000000000000000000000000000
--- a/lib/auth/sia/sia.c
+++ /dev/null
@@ -1,445 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-#endif
-#include <stdio.h>
-#include <string.h>
-#include <siad.h>
-#include <pwd.h>
-
-#include <krb.h>
-#include <kafs.h>
-
-
-#ifndef POSIX_GETPWNAM_R
-
-/* These functions translate from the old Digital UNIX 3.x interface
- * to POSIX.1c.
- */
-
-static int
-posix_getpwnam_r(const char *name, struct passwd *pwd,
- char *buffer, int len, struct passwd **result)
-{
- int ret = getpwnam_r(name, pwd, buffer, len);
- if(ret == 0)
- *result = pwd;
- else{
- *result = NULL;
- ret = _Geterrno();
- if(ret == 0){
- ret = ERANGE;
- _Seterrno(ret);
- }
- }
- return ret;
-}
-
-#define getpwnam_r posix_getpwnam_r
-
-static int
-posix_getpwuid_r(uid_t uid, struct passwd *pwd,
- char *buffer, int len, struct passwd **result)
-{
- int ret = getpwuid_r(uid, pwd, buffer, len);
- if(ret == 0)
- *result = pwd;
- else{
- *result = NULL;
- ret = _Geterrno();
- if(ret == 0){
- ret = ERANGE;
- _Seterrno(ret);
- }
- }
- return ret;
-}
-
-#define getpwuid_r posix_getpwuid_r
-
-#endif /* POSIX_GETPWNAM_R */
-
-struct state{
- char ticket[MaxPathLen];
- int valid;
-};
-
-int
-siad_init(void)
-{
- return SIADSUCCESS;
-}
-
-int
-siad_chk_invoker(void)
-{
- return SIADFAIL;
-}
-
-int
-siad_ses_init(SIAENTITY *entity, int pkgind)
-{
- struct state *s = malloc(sizeof(*s));
- if(s == NULL)
- return SIADFAIL;
- memset(s, 0, sizeof(*s));
- entity->mech[pkgind] = (int*)s;
- return SIADSUCCESS;
-}
-
-static int
-setup_name(SIAENTITY *e, prompt_t *p)
-{
- e->name = malloc(SIANAMEMIN+1);
- if(e->name == NULL)
- return SIADFAIL;
- p->prompt = (unsigned char*)"login: ";
- p->result = (unsigned char*)e->name;
- p->min_result_length = 1;
- p->max_result_length = SIANAMEMIN;
- p->control_flags = 0;
- return SIADSUCCESS;
-}
-
-static int
-setup_password(SIAENTITY *e, prompt_t *p)
-{
- e->password = malloc(SIAMXPASSWORD+1);
- if(e->password == NULL)
- return SIADFAIL;
- p->prompt = (unsigned char*)"Password: ";
- p->result = (unsigned char*)e->password;
- p->min_result_length = 0;
- p->max_result_length = SIAMXPASSWORD;
- p->control_flags = SIARESINVIS;
- return SIADSUCCESS;
-}
-
-
-static int
-common_auth(sia_collect_func_t *collect,
- SIAENTITY *entity,
- int siastat,
- int pkgind)
-{
- prompt_t prompts[2], *pr;
- char *toname, *toinst;
-
- if((siastat == SIADSUCCESS) && (geteuid() == 0))
- return SIADSUCCESS;
- if(entity == NULL)
- return SIADFAIL | SIADSTOP;
- if((entity->acctname != NULL) || (entity->pwd != NULL))
- return SIADFAIL | SIADSTOP;
-
- if((collect != NULL) && entity->colinput) {
- int num;
- pr = prompts;
- if(entity->name == NULL){
- if(setup_name(entity, pr) != SIADSUCCESS)
- return SIADFAIL;
- pr++;
- }
- if(entity->password == NULL){
- if(setup_password(entity, pr) != SIADSUCCESS)
- return SIADFAIL;
- pr++;
- }
- num = pr - prompts;
- if(num == 1){
- if((*collect)(240, SIAONELINER, (unsigned char*)"", num,
- prompts) != SIACOLSUCCESS)
- return SIADFAIL | SIADSTOP;
- } else if(num > 0){
- if((*collect)(0, SIAFORM, (unsigned char*)"", num,
- prompts) != SIACOLSUCCESS)
- return SIADFAIL | SIADSTOP;
- }
- }
-
- if(entity->password == NULL || strlen(entity->password) > SIAMXPASSWORD)
- return SIADFAIL;
- if(entity->name[0] == 0)
- return SIADFAIL;
-
- {
- char realm[REALM_SZ];
- int ret;
- struct passwd pw, *pwd, fpw, *fpwd;
- char pwbuf[1024], fpwbuf[1024];
- struct state *s = (struct state*)entity->mech[pkgind];
-
- if(getpwnam_r(entity->name, &pw, pwbuf, sizeof(pwbuf), &pwd) != 0)
- return SIADFAIL;
-
- snprintf(s->ticket, sizeof(s->ticket),
- TKT_ROOT "%u_%u", (unsigned)pwd->pw_uid, (unsigned)getpid());
- krb_get_lrealm(realm, 1);
- toname = entity->name;
- toinst = "";
- if(entity->authtype == SIA_A_SUAUTH){
- uid_t ouid;
-#ifdef SIAENTITY_HAS_OUID
- ouid = entity->ouid;
-#else
- ouid = getuid();
-#endif
- if(getpwuid_r(ouid, &fpw, fpwbuf, sizeof(fpwbuf), &fpwd) != 0)
- return SIADFAIL;
- snprintf(s->ticket, sizeof(s->ticket), TKT_ROOT "_%s_to_%s_%d",
- fpwd->pw_name, pwd->pw_name, getpid());
- if(strcmp(pwd->pw_name, "root") == 0){
- toname = fpwd->pw_name;
- toinst = pwd->pw_name;
- }
- }
-
- krb_set_tkt_string(s->ticket);
-
- setuid(0); /* XXX fix for fix in tf_util.c */
- if(krb_kuserok(toname, toinst, realm, entity->name))
- return SIADFAIL;
- ret = krb_verify_user(toname, toinst, realm,
- entity->password, 1, NULL, "");
- if(ret){
- if(ret != KDC_PR_UNKNOWN)
- /* since this is most likely a local user (such as
- root), just silently return failure when the
- principal doesn't exist */
- SIALOG("WARNING", "krb_verify_user(%s.%s): %s",
- toname, toinst, krb_get_err_text(ret));
- return SIADFAIL;
- }
- if(sia_make_entity_pwd(pwd, entity) == SIAFAIL)
- return SIADFAIL;
- s->valid = 1;
- }
- return SIADSUCCESS;
-}
-
-
-int
-siad_ses_authent(sia_collect_func_t *collect,
- SIAENTITY *entity,
- int siastat,
- int pkgind)
-{
- return common_auth(collect, entity, siastat, pkgind);
-}
-
-int
-siad_ses_estab(sia_collect_func_t *collect,
- SIAENTITY *entity, int pkgind)
-{
- return SIADFAIL;
-}
-
-int
-siad_ses_launch(sia_collect_func_t *collect,
- SIAENTITY *entity,
- int pkgind)
-{
- char buf[MaxPathLen];
- static char env[MaxPathLen];
- struct state *s = (struct state*)entity->mech[pkgind];
- if(s->valid){
- chown(s->ticket, entity->pwd->pw_uid, entity->pwd->pw_gid);
- snprintf(env, sizeof(env), "KRBTKFILE=%s", s->ticket);
- putenv(env);
- }
- if (k_hasafs()) {
- char cell[64];
- k_setpag();
- if(k_afs_cell_of_file(entity->pwd->pw_dir, cell, sizeof(cell)) == 0)
- krb_afslog(cell, 0);
- krb_afslog(0, 0);
- }
- return SIADSUCCESS;
-}
-
-int
-siad_ses_release(SIAENTITY *entity, int pkgind)
-{
- if(entity->mech[pkgind])
- free(entity->mech[pkgind]);
- return SIADSUCCESS;
-}
-
-int
-siad_ses_suauthent(sia_collect_func_t *collect,
- SIAENTITY *entity,
- int siastat,
- int pkgind)
-{
- if(geteuid() != 0)
- return SIADFAIL;
- if(entity->name == NULL)
- return SIADFAIL;
- if(entity->name[0] == 0)
- strcpy(entity->name, "root");
- return common_auth(collect, entity, siastat, pkgind);
-}
-
-/* The following functions returns the default fail */
-
-int
-siad_ses_reauthent (sia_collect_func_t *collect,
- SIAENTITY *entity,
- int siastat,
- int pkgind)
-{
- return SIADFAIL;
-}
-
-int
-siad_chg_finger (sia_collect_func_t *collect,
- const char *username,
- int argc,
- char *argv[])
-{
- return SIADFAIL;
-}
-
-int
-siad_chg_passwd (sia_collect_func_t *collect,
- const char *username,
- int argc,
- char *argv[])
-{
- return SIADFAIL;
-}
-
-int
-siad_chg_shell (sia_collect_func_t *collect,
- const char *username,
- int argc,
- char *argv[])
-{
- return SIADFAIL;
-}
-
-int
-siad_getpwent(struct passwd *result,
- char *buf,
- int bufsize,
- struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_getpwuid (uid_t uid,
- struct passwd *result,
- char *buf,
- int bufsize,
- struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_getpwnam (const char *name,
- struct passwd *result,
- char *buf,
- int bufsize,
- struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_setpwent (struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_endpwent (struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_getgrent(struct group *result,
- char *buf,
- int bufsize,
- struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_getgrgid (gid_t gid,
- struct group *result,
- char *buf,
- int bufsize,
- struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_getgrnam (const char *name,
- struct group *result,
- char *buf,
- int bufsize,
- struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_setgrent (struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_endgrent (struct sia_context *context)
-{
- return SIADFAIL;
-}
-
-int
-siad_chk_user (const char *logname, int checkflag)
-{
- return SIADFAIL;
-}
diff --git a/lib/com_err/.cvsignore b/lib/com_err/.cvsignore
deleted file mode 100644
index 70845e08eb0b807b1022dc47cd27e67f726d4a0f..0000000000000000000000000000000000000000
--- a/lib/com_err/.cvsignore
+++ /dev/null
@@ -1 +0,0 @@
-Makefile.in
diff --git a/lib/com_err/Makefile.am b/lib/com_err/Makefile.am
deleted file mode 100644
index 5a5625d3718d57a3ab39c973bd95facad8368676..0000000000000000000000000000000000000000
--- a/lib/com_err/Makefile.am
+++ /dev/null
@@ -1,15 +0,0 @@
-# $Id$
-
-AUTOMAKE_OPTIONS = no-dependencies foreign
-
-INCLUDES = -I$(top_builddir)/include -I$(srcdir)
-
-lib_LIBRARIES = libcom_err.a
-
-bin_PROGRAMS = compile_et
-
-libcom_err_a_SOURCES = error.c comerr.c
-
-compile_et: $(srcdir)/compile_et.in
- sed -e 's/@awk@/$(AWK)/' -e "/#awksrc/r $(srcdir)/compile_et.awk" $(srcdir)/compile_et.in > compile_et
- chmod +x compile_et
diff --git a/lib/com_err/Makefile.in b/lib/com_err/Makefile.in
deleted file mode 100644
index 5670b593646c9cf9d00093cfb1ddcacf5b69a46f..0000000000000000000000000000000000000000
--- a/lib/com_err/Makefile.in
+++ /dev/null
@@ -1,91 +0,0 @@
-#
-# $Id$
-#
-
-SHELL = /bin/sh
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-
-CC = @CC@
-AR = ar
-RANLIB = @RANLIB@
-LN_S = @LN_S@
-DEFS = @DEFS@
-CFLAGS = @CFLAGS@
-LD_FLAGS = @LD_FLAGS@
-EXECSUFFIX=@EXECSUFFIX@
-
-AWK = @AWK@
-
-INSTALL = @INSTALL@
-INSTALL_DATA = @INSTALL_DATA@
-MKINSTALLDIRS = @top_srcdir@/mkinstalldirs
-
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-libdir = @libdir@
-bindir = @bindir@
-
-PICFLAGS = @PICFLAGS@
-
-PROGS = compile_et
-LIBNAME = $(LIBPREFIX)com_err
-LIBEXT = @LIBEXT@
-SHLIBEXT = @SHLIBEXT@
-LIBPREFIX = @LIBPREFIX@
-LDSHARED = @LDSHARED@
-LIB = $(LIBNAME).$(LIBEXT)
-
-SOURCES = error.c com_err.c
-OBJECTS = error.o com_err.o
-
-all: $(LIB) $(PROGS)
-
-Wall:
- make CFLAGS="-g -Wall -Wno-comment -Wmissing-prototypes -Wmissing-declarations -D__USE_FIXED_PROTOTYPES__"
-
-.c.o:
- $(CC) -c $(CPPFLAGS) $(DEFS) -I../../include -I$(srcdir) $(CFLAGS) $(PICFLAGS) $<
-
-install: all
- $(MKINSTALLDIRS) $(libdir)
- $(INSTALL_DATA) -m 0555 $(LIB) $(libdir)
- $(MKINSTALLDIRS) $(bindir)
- $(INSTALL_DATA) -m 0555 $(PROGS) $(bindir)
-
-uninstall:
- rm -f $(libdir)/$(LIB)
-
-TAGS: $(SOURCES)
- etags $(SOURCES)
-
-clean:
- rm -f $(LIB) *.o *.a krb_err.c krb_err.h $(PROGS) $(EXTRA_SOURCE)
-
-mostlyclean: clean
-
-distclean: clean
- rm -f Makefile *.tab.c *~
-
-realclean: distclean
- rm -f TAGS
-
-dist: $(DISTFILES)
- for file in $(DISTFILES); do \
- ln $$file ../`cat ../.fname`/lib \
- || cp -p $$file ../`cat ../.fname`/lib; \
- done
-
-$(LIBNAME).a: $(OBJECTS)
- rm -f $@
- $(AR) cr $@ $(OBJECTS)
- -$(RANLIB) $@
-
-$(LIBNAME).$(SHLIBEXT): $(OBJECTS) $(LDOBJ)
- rm -f $@
- $(LDSHARED) -o $@ $(OBJECTS) $(LDOBJ) $(LIBDES)
-
-compile_et: $(srcdir)/compile_et.in
- sed -e 's/@awk@/$(AWK)/' -e "/#awksrc/r $(srcdir)/compile_et.awk" $(srcdir)/compile_et.in > compile_et
- chmod +x compile_et
diff --git a/lib/com_err/com_err.c b/lib/com_err/com_err.c
deleted file mode 100644
index 9a4cebae52413f4343bdbd9a04269ef27d32dee8..0000000000000000000000000000000000000000
--- a/lib/com_err/com_err.c
+++ /dev/null
@@ -1,137 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-#endif
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include "com_err.h"
-
-static struct error_table *et_list;
-
-const char *
-error_message (long code)
-{
- static char msg[128];
- const char *p = com_right(et_list, code);
- if(p){
- strncpy(msg, p, sizeof(msg));
- msg[sizeof(msg)-1] = '\0';
- } else{
- snprintf(msg, sizeof(msg), "Unknown error %d", 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)
-{
- char f[sizeof("%s: %s %s\r\n")] = "";
- char *x;
- const void *arg[3], **ap = arg;
-
- if(whoami) {
- strcat(f, "%s: ");
- *ap++ = whoami;
- }
- if(code) {
- strcat(f, "%s ");
- *ap++ = error_message(code);
- }
- if(fmt) {
- strcat(f, "%s");
- *ap++ = fmt;
- }
- strcat(f, "\r\n");
- asprintf(&x, f, arg[0], arg[1], arg[2]);
- vfprintf(stderr, x, args);
- free(x);
- fflush(stderr);
-}
-
-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);
-}
diff --git a/lib/com_err/com_err.h b/lib/com_err/com_err.h
deleted file mode 100644
index 88a557491419bfc34a72ac0d503a769390af8a4e..0000000000000000000000000000000000000000
--- a/lib/com_err/com_err.h
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-/* MIT compatible com_err library */
-
-#ifndef __COM_ERR_H__
-#define __COM_ERR_H__
-
-#ifdef __STDC__
-#include <stdarg.h>
-#endif
-
-#ifndef __P
-#ifdef __STDC__
-#define __P(X) X
-#else
-#define __P(X) ()
-#endif
-#endif
-
-#include <error.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));
-
-#endif /* __COM_ERR_H__ */
diff --git a/lib/com_err/com_right.h b/lib/com_err/com_right.h
deleted file mode 100644
index 1fe7c0f9cfbce94e223ce5e00989514169e2c3d1..0000000000000000000000000000000000000000
--- a/lib/com_err/com_right.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifndef __ERROR_H__
-#define __ERROR_H__
-
-struct error_table {
- char const * const * msgs;
- long base;
- int n_msgs;
- struct error_table *next;
-};
-
-const char *com_right(struct error_table *list, long code);
-void initialize_error_table_r(struct error_table**, const char**, int, long);
-void free_error_table(struct error_table*);
-
-#endif /* __ERROR_H__ */
diff --git a/lib/com_err/compile_et.awk b/lib/com_err/compile_et.awk
deleted file mode 100644
index 8d985d821592ec533ce5cd064b3bddf153fad0d2..0000000000000000000000000000000000000000
--- a/lib/com_err/compile_et.awk
+++ /dev/null
@@ -1,119 +0,0 @@
-# Copyright (c) 1997 Kungliga Tekniska Högskolan
-# (Royal Institute of Technology, Stockholm, Sweden).
-# All rights reserved.
-#
-# $Id$
-#
-
-$1 == "error_table" || $1 == "et" {
- name = $2
- base = 0
- if(NF < 3)
- base_str = name
- else
- base_str = $3
- for(i = 1; i <= length(base_str); i++){
- base = base * 64 + index("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_", substr(base_str, i, 1))
- }
- base *= 256
- if(base >= 2147483648){ # 0x80000000
- base = -(4294967295 - base + 1) # 0xffffffff
- }
- split(name, x, "\\.")
- name=x[1]
- c_file = name "_err.c"
- h_file = name "_err.h"
- h = ""
-# gsub("[^a-zA-Z0-9]", "_", H_FILE)
- for(i = 1; i <= length(h_file); i++){
- c = substr(h_file, i, 1)
- if(c ~ /[^a-zA-Z0-9]/)
- c = "_"
- h = h c
- }
- H_FILE= "__" h "__"
- number = 0
- print "/* Generated from " FILENAME " */" > c_file
- if(id_str != "")
- print id_str > c_file
- print "" > c_file
- print "#include <stddef.h>" > c_file # NULL
- print "#include <error.h>" > c_file
- print "#include <" h_file ">" > c_file
- print "" > c_file
- print "static const char *text[] = {" > c_file
-
- print "/* Generated from " FILENAME " */" > h_file
- if(id_str != "")
- print id_str > h_file
- print "" > h_file
- print "#ifndef " H_FILE > h_file
- print "#define " H_FILE > h_file
- print "" > h_file
- print "#include <error.h>" > h_file
- print "" > h_file
- print "void initialize_" name "_error_table_r(struct error_table**);" > h_file
- print "" > h_file
- n = "initialize_" name "_error_table"
- print "void " n "(void);" > h_file
- print "" > h_file
- print "#define init_" name "_err_tbl " n > h_file
- print "typedef enum " name "_error_number{" > h_file
- print "\tERROR_TABLE_BASE_" name " = " base "," > h_file
- print "\t" name "_err_base = " base "," > h_file
- next
-}
-
-$1 == "index" {
- newnumber = $2
- for(; number < newnumber; number++) {
-# printf("\t%s = %d,\n", toupper(name) "_ERROR_" number, base+ number) > h_file
- printf("\t/* %3d */ %s,\n", number, "\"Reserved error number " number "\"") > c_file
- }
- next
-}
-$1 == "prefix" {
- prefix = $2
- if(prefix != "")
- prefix = prefix "_"
- next
-}
-
-$1 == "error_code" || $1 == "ec" {
- code = $2
- split(code, x, ",")
- code = prefix x[1]
- split($0, x, "\"")
- string = x[2]
- printf("\t%s = %d,\n", code, number + base) > h_file
- printf("\t/* %3d */ \"%s\",\n", number, string) > c_file
- number++;
- next
-}
-$1 == "id" {
-# sub("id *", "")
- for(i = 3; i <= length && substr($0, i, 1) ~ /[ \t]/; i++);
- id_str ="/* " substr($0, i, length($0)) " */"
-}
-END {
- print "\tNULL" > c_file
- print "};" > c_file
- print "" > c_file
- printf "void initialize_" name "_error_table_r " > c_file
- print "(struct error_table **list)" > c_file
- print "{" > c_file
- printf " initialize_error_table_r(list, text, " > c_file
- print name "_num_errors, ERROR_TABLE_BASE_" name ");" > c_file
- print "}" > c_file
- print "" > c_file
- print "void initialize_" name "_error_table(void)" > c_file
- print "{" > c_file
- printf " init_error_table(text, ERROR_TABLE_BASE_" name ", " > c_file
- print name "_num_errors);" > c_file
- print "}" > c_file
-
- print "\t" name "_num_errors = " number > h_file
- print "} " name "_error_number;" > h_file
- print "" > h_file
- print "#endif /* " H_FILE " */" > h_file
-}
diff --git a/lib/com_err/compile_et.in b/lib/com_err/compile_et.in
deleted file mode 100755
index 8bfba5af10949e22280bb5aae265230a63d033e2..0000000000000000000000000000000000000000
--- a/lib/com_err/compile_et.in
+++ /dev/null
@@ -1,24 +0,0 @@
-#!/bin/sh
-
-# $Id$
-
-while :; do
- case "$1" in
- -lang*)
- shift
- shift
- ;;
- -debug)
- shift
- ;;
- *)
- break
- ;;
- esac
-done
-
-for i do
- @awk@ '
-#awksrc
-' "$i"
-done
diff --git a/lib/com_err/error.c b/lib/com_err/error.c
deleted file mode 100644
index 992fdcd5c82bcbad44876ed3457993d6d629dced..0000000000000000000000000000000000000000
--- a/lib/com_err/error.c
+++ /dev/null
@@ -1,88 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-#endif
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <error.h>
-
-const char *
-com_right(struct error_table *list, long code)
-{
- struct error_table *p;
- for(p = list; p; p = p->next){
- if(code >= p->base && code < p->base + p->n_msgs)
- return p->msgs[code - p->base];
- }
- return NULL;
-}
-
-void
-initialize_error_table_r(struct error_table **list,
- const char **messages,
- int num_errors,
- long base)
-{
- struct error_table *et;
- for(et = *list; et; et = et->next)
- if(et->msgs == messages)
- return;
- et = malloc(sizeof(*et));
- if (et == NULL)
- return;
- et->msgs = messages;
- et->n_msgs = num_errors;
- et->base = base;
- et->next = *list;
- *list = et;
-}
-
-
-void
-free_error_table(struct error_table *et)
-{
- while(et){
- struct error_table *p = et;
- et = et->next;
- free(p);
- }
-}
diff --git a/lib/com_err/error.h b/lib/com_err/error.h
deleted file mode 100644
index 1fe7c0f9cfbce94e223ce5e00989514169e2c3d1..0000000000000000000000000000000000000000
--- a/lib/com_err/error.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifndef __ERROR_H__
-#define __ERROR_H__
-
-struct error_table {
- char const * const * msgs;
- long base;
- int n_msgs;
- struct error_table *next;
-};
-
-const char *com_right(struct error_table *list, long code);
-void initialize_error_table_r(struct error_table**, const char**, int, long);
-void free_error_table(struct error_table*);
-
-#endif /* __ERROR_H__ */
diff --git a/lib/des/des.1 b/lib/des/des.1
deleted file mode 100644
index 734119906b8f18bcb260d5deb8c614dbf6df3937..0000000000000000000000000000000000000000
--- a/lib/des/des.1
+++ /dev/null
@@ -1,186 +0,0 @@
-.TH DES 1
-.SH NAME
-des - encrypt or decrypt data using Data Encryption Standard
-.SH SYNOPSIS
-.B des
-(
-.B \-e
-|
-.B \-E
-) | (
-.B \-d
-|
-.B \-D
-) | (
-.B \-\fR[\fPcC\fR][\fPckname\fR]\fP
-) |
-[
-.B \-b3hfs
-] [
-.B \-k
-.I key
-]
-] [
-.B \-u\fR[\fIuuname\fR]
-[
-.I input-file
-[
-.I output-file
-] ]
-.SH DESCRIPTION
-.B des
-encrypts and decrypts data using the
-Data Encryption Standard algorithm.
-One of
-.B \-e, \-E
-(for encrypt) or
-.B \-d, \-D
-(for decrypt) must be specified.
-It is also possible to use
-.B \-c
-or
-.B \-C
-in conjunction or instead of the a encrypt/decrypt option to generate
-a 16 character hexadecimal checksum, generated via the
-.I des_cbc_cksum.
-.LP
-Two standard encryption modes are supported by the
-.B des
-program, Cipher Block Chaining (the default) and Electronic Code Book
-(specified with
-.B \-b
-).
-.LP
-The key used for the DES
-algorithm is obtained by prompting the user unless the
-.B `\-k
-.I key'
-option is given.
-If the key is an argument to the
-.B des
-command, it is potentially visible to users executing
-.BR ps (1)
-or a derivative. To minimise this possibility,
-.B des
-takes care to destroy the key argument immediately upon entry.
-If your shell keeps a history file be careful to make sure it is not
-world readable.
-.LP
-Since this program attempts to maintain compatability with sunOS's
-des(1) command, there are 2 different methods used to convert the user
-supplied key to a des key.
-Whenever and one or more of
-.B \-E, \-D, \-C
-or
-.B \-3
-options are used, the key conversion procedure will not be compatible
-with the sunOS des(1) version but will use all the user supplied
-character to generate the des key.
-.B des
-command reads from standard input unless
-.I input-file
-is specified and writes to standard output unless
-.I output-file
-is given.
-.SH OPTIONS
-.TP
-.B \-b
-Select ECB
-(eight bytes at a time) encryption mode.
-.TP
-.B \-3
-Encrypt using triple encryption.
-By default triple cbc encryption is used but if the
-.B \-b
-option is used then triple ecb encryption is performed.
-If the key is less than 8 characters long, the flag has no effect.
-.TP
-.B \-e
-Encrypt data using an 8 byte key in a manner compatible with sunOS
-des(1).
-.TP
-.B \-E
-Encrypt data using a key of nearly unlimited length (1024 bytes).
-This will product a more secure encryption.
-.TP
-.B \-d
-Decrypt data that was encrypted with the \-e option.
-.TP
-.B \-D
-Decrypt data that was encrypted with the \-E option.
-.TP
-.B \-c
-Generate a 16 character hexadecimal cbc checksum and output this to
-stderr.
-If a filename was specified after the
-.B \-c
-option, the checksum is output to that file.
-The checksum is generated using a key generated in a sunOS compatible
-manner.
-.TP
-.B \-C
-A cbc checksum is generated in the same manner as described for the
-.B \-c
-option but the DES key is generated in the same manner as used for the
-.B \-E
-and
-.B \-D
-options
-.TP
-.B \-f
-Does nothing - allowed for compatibility with sunOS des(1) command.
-.TP
-.B \-s
-Does nothing - allowed for compatibility with sunOS des(1) command.
-.TP
-.B "\-k \fIkey\fP"
-Use the encryption
-.I key
-specified.
-.TP
-.B "\-h"
-The
-.I key
-is assumed to be a 16 character hexadecimal number.
-If the
-.B "\-3"
-option is used the key is assumed to be a 32 character hexadecimal
-number.
-.TP
-.B \-u
-This flag is used to read and write uuencoded files. If decrypting,
-the input file is assumed to contain uuencoded, DES encrypted data.
-If encrypting, the characters following the -u are used as the name of
-the uuencoded file to embed in the begin line of the uuencoded
-output. If there is no name specified after the -u, the name text.des
-will be embedded in the header.
-.SH SEE ALSO
-.B ps (1)
-.B des_crypt(3)
-.SH BUGS
-.LP
-The problem with using the
-.B -e
-option is the short key length.
-It would be better to use a real 56-bit key rather than an
-ASCII-based 56-bit pattern. Knowing that the key was derived from ASCII
-radically reduces the time necessary for a brute-force cryptographic attack.
-My attempt to remove this problem is to add an alternative text-key to
-DES-key function. This alternative function (accessed via
-.B -E, -D, -S
-and
-.B -3
-)
-uses DES to help generate the key.
-.LP
-Be carefully when using the -u option. Doing des -ud <filename> will
-not decrypt filename (the -u option will gobble the d option).
-.LP
-The VMS operating system operates in a world where files are always a
-multiple of 512 bytes. This causes problems when encrypted data is
-send from unix to VMS since a 88 byte file will suddenly be padded
-with 424 null bytes. To get around this problem, use the -u option
-to uuencode the data before it is send to the VMS system.
-.SH AUTHOR
-.LP
-Eric Young (eay@mincom.oz.au or eay@psych.psy.uq.oz.au)
diff --git a/lib/des/des_crypt.3 b/lib/des/des_crypt.3
deleted file mode 100644
index a381041a3ed7f0898efad7122a2083b1bb887bcd..0000000000000000000000000000000000000000
--- a/lib/des/des_crypt.3
+++ /dev/null
@@ -1,379 +0,0 @@
-.\" $Id$
-.\" Copyright 1989 by the Massachusetts Institute of Technology.
-.\"
-.\" For copying and distribution information,
-.\" please see the file <mit-copyright.h>.
-.\"
-.TH DES_CRYPT 3 "Kerberos Version 4.0" "MIT Project Athena"
-.SH NAME
-des_read_password, des_string_to_key, des_random_key, des_set_key,
-des_ecb_encrypt, des_cbc_encrypt, des_pcbc_encrypt, des_cbc_cksum,
-des_quad_cksum, \- (new) DES encryption
-.SH SYNOPSIS
-.nf
-.nj
-.ft B
-#include <des.h>
-.PP
-.ft B
-.B int des_read_password(key,prompt,verify)
-des_cblock *key;
-char *prompt;
-int verify;
-.PP
-.ft B
-int des_string_to_key(str,key)
-char *str;
-des_cblock key;
-.PP
-.ft B
-int des_random_key(key)
-des_cblock *key;
-.PP
-.ft B
-int des_set_key(key,schedule)
-des_cblock *key;
-des_key_schedule schedule;
-.PP
-.ft B
-int des_ecb_encrypt(input,output,schedule,encrypt)
-des_cblock *input;
-des_cblock *output;
-des_key_schedule schedule;
-int encrypt;
-.PP
-.ft B
-int des_cbc_encrypt(input,output,length,schedule,ivec,encrypt)
-des_cblock *input;
-des_cblock *output;
-long length;
-des_key_schedule schedule;
-des_cblock *ivec;
-int encrypt;
-.PP
-.ft B
-int des_pcbc_encrypt(input,output,length,schedule,ivec,encrypt)
-des_cblock *input;
-des_cblock *output;
-long length;
-des_key_schedule schedule;
-des_cblock *ivec;
-int encrypt;
-.PP
-.ft B
-unsigned long des_cbc_cksum(input,output,length,schedule,ivec)
-des_cblock *input;
-des_cblock *output;
-long length;
-des_key_schedule schedule;
-des_cblock *ivec;
-.PP
-.ft B
-unsigned long quad_cksum(input,output,length,out_count,seed)
-des_cblock *input;
-des_cblock *output;
-long length;
-int out_count;
-des_cblock *seed;
-.PP
-.fi
-.SH DESCRIPTION
-This library supports various DES encryption related operations. It differs
-from the
-.I crypt, setkey, and encrypt
-library routines in that it provides
-a true DES encryption, without modifying the algorithm,
-and executes much faster.
-.PP
-For each key that may be simultaneously active, create a
-.B des_key_schedule
-struct,
-defined in "des.h". Next, create key schedules (from the 8-byte keys) as
-needed, via
-.I des_set_key,
-prior to using the encryption or checksum routines. Then
-setup the input and output areas. Make sure to note the restrictions
-on lengths being multiples of eight bytes. Finally, invoke the
-encryption/decryption routines,
-.I des_ecb_encrypt
-or
-.I des_cbc_encrypt
-or
-.I des_pcbc_encrypt,
-or, to generate a cryptographic checksum, use
-.I quad_cksum
-(fast) or
-.I des_cbc_cksum
-(slow).
-.PP
-A
-.I des_cblock
-struct is an 8 byte block used as the fundamental unit for DES data and
-keys, and is defined as:
-.PP
-.B typedef unsigned char des_cblock[8];
-.PP
-and a
-.I des_key_schedule,
-is defined as:
-.PP
-.B typedef struct des_ks_struct {des_cblock _;} des_key_schedule[16];
-.PP
-.I des_read_password
-writes the string specified by
-.I prompt
-to the standard
-output, turns off echo (if possible)
-and reads an input string from standard input until terminated with a newline.
-If
-.I verify
-is non-zero, it prompts and reads input again, for use
-in applications such as changing a password; both
-versions are compared, and the input is requested repeatedly until they
-match. Then
-.I des_read_password
-converts the input string into a valid DES key, internally
-using the
-.I des_string_to_key
-routine. The newly created key is copied to the
-area pointed to by the
-.I key
-argument.
-.I des_read_password
-returns a zero if no errors occurred, or a -1
-indicating that an error
-occurred trying to manipulate the terminal echo.
-.PP
-.PP
-.I des_string_to_key
-converts an arbitrary length null-terminated string
-to an 8 byte DES key, with odd byte parity, per FIPS specification.
-A one-way function is used to convert the string to a key, making it
-very difficult to reconstruct the string from the key.
-The
-.I str
-argument is a pointer to the string, and
-.I key
-should
-point to a
-.I des_cblock
-supplied by the caller to receive the generated key.
-No meaningful value is returned. Void is not used for compatibility with
-other compilers.
-.PP
-.PP
-.I des_random_key
-generates a random DES encryption key (eight bytes), set to odd parity per
-FIPS
-specifications.
-This routine uses the current time, process id, and a counter
-as a seed for the random number generator.
-The caller must supply space for the output key, pointed to
-by argument
-.I key,
-then after calling
-.I des_random_key
-should
-call the
-.I des_set_key
-routine when needed.
-No meaningful value is returned. Void is not used for compatibility
-with other compilers.
-.PP
-.PP
-.I des_set_key
-calculates a key schedule from all eight bytes of the input key, pointed
-to by the
-.I key
-argument, and outputs the schedule into the
-.I des_key_schedule
-indicated by the
-.I schedule
-argument. Make sure to pass a valid eight byte
-key; no padding is done. The key schedule may then be used in subsequent
-encryption/decryption/checksum operations. Many key schedules may be
-cached for later use. The user is responsible to clear keys and schedules
-as soon as no longer needed, to prevent their disclosure.
-The routine also checks the key
-parity, and returns a zero if the key parity is correct (odd), a -1
-indicating a key parity error, or a -2 indicating use of an illegal
-weak key. If an error is returned, the key schedule was not created.
-.PP
-.PP
-.I des_ecb_encrypt
-is the basic DES encryption routine that encrypts or decrypts a single 8-byte
-block in
-.B electronic code book
-mode. It always transforms the input data, pointed to by
-.I input,
-into the output data, pointed to by the
-.I output
-argument.
-.PP
-If the
-.I encrypt
-argument is non-zero, the
-.I input
-(cleartext) is encrypted into the
-.I output
-(ciphertext) using the key_schedule specified by the
-.I schedule
-argument, previously set via
-.I des_set_key
-.PP
-If encrypt is zero, the
-.I input
-(now ciphertext) is decrypted into the
-.I output
-(now cleartext).
-.PP
-Input and output may overlap.
-.PP
-No meaningful value is returned. Void is not used for compatibility
-with other compilers.
-.PP
-.PP
-.I des_cbc_encrypt
-encrypts/decrypts using the
-.B cipher-block-chaining mode of DES.
-If the
-.I encrypt
-argument is non-zero, the routine cipher-block-chain encrypts
-the cleartext data pointed to by the
-.I input
-argument into the ciphertext pointed to by the
-.I output
-argument, using the key schedule provided by the
-.I schedule
-argument, and initialization vector provided by the
-.I ivec
-argument.
-If the
-.I length
-argument is not an integral
-multiple of eight bytes, the last block is copied to a temp and zero
-filled (highest addresses). The output is ALWAYS an integral multiple
-of eight bytes.
-.PP
-If
-.I encrypt
-is zero, the routine cipher-block chain decrypts the (now) ciphertext
-data pointed to by the
-.I input
-argument into (now) cleartext pointed to by the
-.I output
-argument using the key schedule provided by the
-.I schedule
-argument, and initialization vector provided by the
-.I ivec
-argument. Decryption ALWAYS operates on integral
-multiples of 8 bytes, so it will round the
-.I length
-provided up to the
-appropriate multiple. Consequently, it will always produce the rounded-up
-number of bytes of output cleartext. The application must determine if
-the output cleartext was zero-padded due to original cleartext lengths that
-were not integral multiples of 8.
-.PP
-No errors or meaningful values are returned. Void is not used for
-compatibility with other compilers.
-.PP
-A characteristic of cbc mode is that changing a single bit of the
-cleartext, then encrypting using cbc mode,
-affects ALL the subsequent ciphertext. This makes cryptanalysis
-much more difficult. However, modifying a single bit of the ciphertext,
-then decrypting, only affects the resulting cleartext from
-the modified block and the succeeding block. Therefore,
-.I des_pcbc_encrypt
-is STRONGLY recommended for applications where
-indefinite propagation of errors is required in order to detect modifications.
-.PP
-.PP
-.I des_pcbc_encrypt
-encrypts/decrypts using a modified block chaining mode. Its calling
-sequence is identical to
-.I des_cbc_encrypt.
-It differs in its error propagation characteristics.
-.PP
-.I des_pcbc_encrypt
-is highly recommended for most encryption purposes, in that
-modification of a single bit of the ciphertext will affect ALL the
-subsequent (decrypted) cleartext. Similarly, modifying a single bit of
-the cleartext will affect ALL the subsequent (encrypted) ciphertext.
-"PCBC" mode, on encryption, "xors" both the
-cleartext of block N and the ciphertext resulting from block N with the
-cleartext for block N+1 prior to encrypting block N+1.
-.PP
-.I des_cbc_cksum
-produces an 8 byte cryptographic checksum by cipher-block-chain
-encrypting the cleartext data pointed to by the
-.I input
-argument. All of the ciphertext output is discarded, except the
-last 8-byte ciphertext block, which is written into the area pointed to by
-the
-.I output
-argument.
-It uses the key schedule,
-provided by the
-.I schedule
-argument and initialization vector provided by the
-.I ivec
-argument.
-If the
-.I length
-argument is not an integral
-multiple of eight bytes, the last cleartext block is copied to a temp and zero
-filled (highest addresses). The output is ALWAYS eight bytes.
-.PP
-The routine also returns an unsigned long, which is the last (highest address)
-half of the 8 byte checksum computed.
-.PP
-.PP
-.I quad_cksum
-produces a checksum by chaining quadratic operations on the cleartext data
-pointed to by the
-.I input
-argument. The
-.I length
-argument specifies the length of the
-input -- only exactly that many bytes are included for the checksum,
-without any padding.
-.PP
-The algorithm may be iterated over the same input data, if the
-.I out_count
-argument is 2, 3 or 4, and the optional
-.I output
-argument is a non-null pointer .
-The default is one iteration, and it will not run
-more than 4 times. Multiple iterations run slower, but provide
-a longer checksum if desired. The
-.I seed
-argument provides an 8-byte seed for the first iteration. If multiple iterations are
-requested, the results of one iteration are automatically used as
-the seed for the next iteration.
-.PP
-It returns both an unsigned long checksum value, and
-if the
-.I output
-argument is not a null pointer, up to 16 bytes of
-the computed checksum are written into the output.
-.PP
-.PP
-.SH FILES
-/usr/include/des.h
-.br
-/usr/lib/libdes.a
-.SH "SEE ALSO"
-.SH DIAGNOSTICS
-.SH BUGS
-This software has not yet been compiled or tested on machines other than the
-VAX and the IBM PC.
-.SH AUTHORS
-Steve Miller, MIT Project Athena/Digital Equipment Corporation
-.SH RESTRICTIONS
-COPYRIGHT 1985,1986 Massachusetts Institute of Technology
-.PP
-This software may not be exported outside of the US without a special
-license from the US Dept of Commerce. It may be replaced by any secret
-key block cipher with block length and key length of 8 bytes, as long
-as the interface is the same as described here.
diff --git a/lib/gssapi/krb5/8003.c b/lib/gssapi/krb5/8003.c
deleted file mode 100644
index fbf632c4907f225cea88cda125214c0f6eb46c3c..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/8003.c
+++ /dev/null
@@ -1,116 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-static krb5_error_code
-encode_om_uint32(OM_uint32 n, u_char *p)
-{
- p[0] = (n >> 0) & 0xFF;
- p[1] = (n >> 8) & 0xFF;
- p[2] = (n >> 16) & 0xFF;
- p[3] = (n >> 24) & 0xFF;
- return 0;
-}
-
-static krb5_error_code
-hash_input_chan_bindings (const gss_channel_bindings_t b,
- u_char *p)
-{
- u_char num[4];
- struct md5 md5;
-
- md5_init(&md5);
- encode_om_uint32 (b->initiator_addrtype, num);
- md5_update (&md5, num, sizeof(num));
- encode_om_uint32 (b->initiator_address.length, num);
- md5_update (&md5, num, sizeof(num));
- if (b->initiator_address.length)
- md5_update (&md5,
- b->initiator_address.value,
- b->initiator_address.length);
- encode_om_uint32 (b->acceptor_addrtype, num);
- md5_update (&md5, num, sizeof(num));
- encode_om_uint32 (b->acceptor_address.length, num);
- md5_update (&md5, num, sizeof(num));
- if (b->acceptor_address.length)
- md5_update (&md5,
- b->acceptor_address.value,
- b->acceptor_address.length);
- encode_om_uint32 (b->application_data.length, num);
- md5_update (&md5, num, sizeof(num));
- if (b->application_data.length)
- md5_update (&md5,
- b->application_data.value,
- b->application_data.length);
- md5_finito (&md5, p);
- return 0;
-}
-
-krb5_error_code
-gssapi_krb5_create_8003_checksum (
- const gss_channel_bindings_t input_chan_bindings,
- OM_uint32 flags,
- Checksum *result)
-{
- u_char *p;
-
- result->cksumtype = 0x8003;
- result->checksum.length = 24;
- result->checksum.data = malloc (result->checksum.length);
- if (result->checksum.data == NULL)
- return ENOMEM;
-
- p = result->checksum.data;
- encode_om_uint32 (16, p);
- p += 4;
- if (input_chan_bindings == GSS_C_NO_CHANNEL_BINDINGS) {
- memset (p, 0, 16);
- } else {
- hash_input_chan_bindings (input_chan_bindings, p);
- }
- p += 16;
- encode_om_uint32 (flags, p);
- p += 4;
- if (p - (u_char *)result->checksum.data != result->checksum.length)
- abort ();
- return 0;
-}
-
diff --git a/lib/gssapi/krb5/Makefile.am b/lib/gssapi/krb5/Makefile.am
deleted file mode 100644
index 5e3174cd5ff48df1f7e2a842cf402bb736f0768b..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/Makefile.am
+++ /dev/null
@@ -1,40 +0,0 @@
-# $Id$
-
-AUTOMAKE_OPTIONS = no-dependencies foreign
-
-INCLUDES = -I$(top_builddir)/include -I$(srcdir)/../krb5
-
-lib_LIBRARIES = libgssapi.a
-
-libgssapi_a_SOURCES = \
- 8003.c \
- accept_sec_context.c \
- acquire_cred.c \
- add_oid_set_member.c \
- canonicalize_name.c \
- compare_name.c \
- context_time.c \
- create_emtpy_oid_set.c \
- decapsulate.c \
- delete_sec_context.c \
- display_name.c \
- duplicate_name.c \
- encapsulate.c \
- export_name.c \
- external.c \
- get_mic.c \
- import_name.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
diff --git a/lib/gssapi/krb5/accept_sec_context.c b/lib/gssapi/krb5/accept_sec_context.c
deleted file mode 100644
index 8141a3920340ed23b2e2bcf31644d45bc171b2d5..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/accept_sec_context.c
+++ /dev/null
@@ -1,228 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-static krb5_keytab_data gss_keytab = { NULL };
-
-OM_uint32 gsskrb5_register_acceptor_identity
- (char *identity)
-{
- if (gss_keytab.filename != NULL)
- free(gss_keytab.filename);
- gss_keytab.filename = strdup(identity);
- return GSS_S_COMPLETE;
-}
-
-OM_uint32 gss_accept_sec_context
- (OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- const gss_cred_id_t acceptor_cred_handle,
- const gss_buffer_t input_token_buffer,
- const gss_channel_bindings_t input_chan_bindings,
- gss_name_t * src_name,
- gss_OID * mech_type,
- gss_buffer_t output_token,
- OM_uint32 * ret_flags,
- OM_uint32 * time_rec,
- gss_cred_id_t * delegated_cred_handle
- )
-{
- krb5_error_code kret;
- OM_uint32 ret;
- krb5_data indata;
- krb5_flags ap_options;
- OM_uint32 flags;
- krb5_ticket *ticket;
- Checksum cksum;
- krb5_keytab_data *keytab = NULL;
-
- gssapi_krb5_init ();
-
- if (*context_handle != GSS_C_NO_CONTEXT) {
- *context_handle = malloc(sizeof(**context_handle));
- if (*context_handle == GSS_C_NO_CONTEXT)
- return GSS_S_FAILURE;
- }
-
- (*context_handle)->auth_context = NULL;
- (*context_handle)->source = NULL;
- (*context_handle)->target = NULL;
- (*context_handle)->flags = 0;
- (*context_handle)->more_flags = 0;
-
- kret = krb5_auth_con_init (gssapi_krb5_context,
- &(*context_handle)->auth_context);
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- {
- int32_t tmp;
-
- krb5_auth_con_getflags(gssapi_krb5_context,
- (*context_handle)->auth_context,
- &tmp);
- tmp |= KRB5_AUTH_CONTEXT_DO_SEQUENCE;
- krb5_auth_con_setflags(gssapi_krb5_context,
- (*context_handle)->auth_context,
- tmp);
- }
-
- ret = gssapi_krb5_decapsulate (input_token_buffer,
- &indata,
- "\x01\x00");
- if (ret)
- goto failure;
-
- if (acceptor_cred_handle == GSS_C_NO_CREDENTIAL) {
- if (gss_keytab.filename != NULL) {
- keytab = &gss_keytab;
- }
- } else if (acceptor_cred_handle->keytab != NULL) {
- keytab = acceptor_cred_handle->keytab;
- }
-
- kret = krb5_rd_req (gssapi_krb5_context,
- &(*context_handle)->auth_context,
- &indata,
- (acceptor_cred_handle == GSS_C_NO_CREDENTIAL) ? NULL
- : acceptor_cred_handle->principal,
- keytab,
- &ap_options,
- &ticket);
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- kret = krb5_copy_principal (gssapi_krb5_context,
- ticket->client,
- &(*context_handle)->source);
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- if (src_name) {
- kret = krb5_copy_principal (gssapi_krb5_context,
- ticket->client,
- src_name);
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
- }
-
- flags = 0;
- if (ap_options & AP_OPTS_MUTUAL_REQUIRED)
- flags |= GSS_C_MUTUAL_FLAG;
- flags |= GSS_C_CONF_FLAG;
- flags |= GSS_C_INTEG_FLAG;
- flags |= GSS_C_SEQUENCE_FLAG;
-
- kret = gssapi_krb5_create_8003_checksum (input_chan_bindings,
- flags,
- &cksum);
-
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- {
- Checksum *c2 = (*context_handle)->auth_context->authenticator->cksum;
- if (cksum.cksumtype != c2->cksumtype ||
- cksum.checksum.length != c2->checksum.length ||
- memcmp(cksum.checksum.data,
- c2->checksum.data,
- cksum.checksum.length)) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
- }
-
- if (ret_flags)
- *ret_flags = flags;
- (*context_handle)->flags = flags;
- (*context_handle)->more_flags |= OPEN;
-
- if (mech_type)
- *mech_type = GSS_KRB5_MECHANISM;
-
- if (time_rec)
- *time_rec = GSS_C_INDEFINITE;
-
- if(flags & GSS_C_MUTUAL_FLAG) {
- krb5_data outbuf;
-
- kret = krb5_mk_rep (gssapi_krb5_context,
- &(*context_handle)->auth_context,
- &outbuf);
- if (kret) {
- krb5_data_free (&outbuf);
- ret = GSS_S_FAILURE;
- goto failure;
- }
- ret = gssapi_krb5_encapsulate (&outbuf,
- output_token,
- "\x02\x00");
- if (ret)
- goto failure;
- } else {
- output_token->length = 0;
- }
-
- return GSS_S_COMPLETE;
-
-failure:
- krb5_auth_con_free (gssapi_krb5_context,
- (*context_handle)->auth_context);
- if((*context_handle)->source)
- krb5_free_principal (gssapi_krb5_context,
- (*context_handle)->source);
- if((*context_handle)->target)
- krb5_free_principal (gssapi_krb5_context,
- (*context_handle)->target);
- free (*context_handle);
- *context_handle = GSS_C_NO_CONTEXT;
- return GSS_S_FAILURE;
-}
diff --git a/lib/gssapi/krb5/acquire_cred.c b/lib/gssapi/krb5/acquire_cred.c
deleted file mode 100644
index bb58c8aa56d8eb867270a96d52f9f10635d83ead..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/acquire_cred.c
+++ /dev/null
@@ -1,92 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_acquire_cred
- (OM_uint32 * minor_status,
- const gss_name_t desired_name,
- OM_uint32 time_req,
- const gss_OID_set desired_mechs,
- gss_cred_usage_t cred_usage,
- gss_cred_id_t * output_cred_handle,
- gss_OID_set * actual_mechs,
- OM_uint32 * time_rec
- )
-{
- gss_cred_id_t handle;
- OM_uint32 ret;
-
- handle = (gss_cred_id_t)malloc(sizeof(*handle));
- if (handle == GSS_C_NO_CREDENTIAL) {
- return GSS_S_FAILURE;
- }
-
- ret = gss_duplicate_name(minor_status, desired_name, &handle->principal);
- if (ret) {
- return ret;
- }
-
- /* XXX */
- handle->lifetime = time_req;
-
- handle->keytab = NULL;
- handle->usage = cred_usage;
-
- ret = gss_create_empty_oid_set(minor_status, &handle->mechanisms);
- if (ret) {
- return ret;
- }
- ret = gss_add_oid_set_member(minor_status, GSS_KRB5_MECHANISM,
- &handle->mechanisms);
- if (ret) {
- return ret;
- }
-
- ret = gss_inquire_cred(minor_status, handle, NULL, time_rec, NULL,
- actual_mechs);
- if (ret) {
- return ret;
- }
-
- *output_cred_handle = handle;
-
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/add_oid_set_member.c b/lib/gssapi/krb5/add_oid_set_member.c
deleted file mode 100644
index 54f8db4ca5b1032b6ba99646feb5990002d1411b..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/add_oid_set_member.c
+++ /dev/null
@@ -1,59 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_add_oid_set_member (
- OM_uint32 * minor_status,
- const gss_OID member_oid,
- gss_OID_set * oid_set
- )
-{
- size_t n = (*oid_set)->count;
-
- (*oid_set)->elements = realloc ((*oid_set)->elements,
- n * sizeof(gss_OID_desc));
- if ((*oid_set)->elements == NULL) {
- return GSS_S_FAILURE;
- }
- (*oid_set)->count = n;
- (*oid_set)->elements[n-1] = *member_oid;
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/canonicalize_name.c b/lib/gssapi/krb5/canonicalize_name.c
deleted file mode 100644
index 117e2ada50aa573c43a8ca1ca8193f2253ef5944..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/canonicalize_name.c
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_canonicalize_name (
- OM_uint32 * minor_status,
- const gss_name_t input_name,
- const gss_OID mech_type,
- gss_name_t * output_name
- )
-{
- return gss_duplicate_name (minor_status, input_name, output_name);
-}
diff --git a/lib/gssapi/krb5/compare_name.c b/lib/gssapi/krb5/compare_name.c
deleted file mode 100644
index f139403dd09906017de6723b446caa6de74b7b51..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/compare_name.c
+++ /dev/null
@@ -1,54 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_compare_name
- (OM_uint32 * minor_status,
- const gss_name_t name1,
- const gss_name_t name2,
- int * name_equal
- )
-{
- gssapi_krb5_init ();
- *name_equal = krb5_principal_compare (gssapi_krb5_context,
- name1, name2);
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/context_time.c b/lib/gssapi/krb5/context_time.c
deleted file mode 100644
index 817f3022b188b28590b0abee7b409df92a13ea96..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/context_time.c
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_context_time
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- OM_uint32 * time_rec
- )
-{
- OM_uint32 lifetime;
- OM_uint32 ret;
- krb5_error_code kret;
- int32_t timeret;
-
- gssapi_krb5_init();
-
- ret = gss_inquire_context(minor_status, context_handle,
- NULL, NULL, &lifetime, NULL, NULL, NULL, NULL);
- if (ret) {
- return ret;
- }
-
- kret = krb5_timeofday(gssapi_krb5_context, &timeret);
- if (kret) {
- return GSS_S_FAILURE;
- }
-
- *time_rec = lifetime - timeret;
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/create_emtpy_oid_set.c b/lib/gssapi/krb5/create_emtpy_oid_set.c
deleted file mode 100644
index 0240c617064e5fa6aeb09d9a805d2ffa018ababd..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/create_emtpy_oid_set.c
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_create_empty_oid_set (
- OM_uint32 * minor_status,
- gss_OID_set * oid_set
- )
-{
- *oid_set = malloc(sizeof(**oid_set));
- if (*oid_set == NULL) {
- return GSS_S_FAILURE;
- }
- (*oid_set)->count = 0;
- (*oid_set)->elements = NULL;
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/decapsulate.c b/lib/gssapi/krb5/decapsulate.c
deleted file mode 100644
index 57fabee8f6cd2f9fc8d09e576a4d2faf75be0953..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/decapsulate.c
+++ /dev/null
@@ -1,105 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32
-gssapi_krb5_verify_header(u_char **str,
- size_t total_len,
- u_char *type)
-{
- size_t len, len_len, mech_len, foo;
- int e;
- u_char *p = *str;
-
- if (*p++ != 0x60)
- return GSS_S_DEFECTIVE_TOKEN;
- e = der_get_length (p, total_len - 1, &len, &len_len);
- if (e || 1 + len_len + len != total_len)
- abort ();
- p += len_len;
- if (*p++ != 0x06)
- return GSS_S_DEFECTIVE_TOKEN;
- e = der_get_length (p, total_len - 1 - len_len - 1,
- &mech_len, &foo);
- if (e)
- abort ();
- p += foo;
- if (mech_len != GSS_KRB5_MECHANISM->length)
- return GSS_S_BAD_MECH;
- if (memcmp(p,
- GSS_KRB5_MECHANISM->elements,
- GSS_KRB5_MECHANISM->length) != 0)
- return GSS_S_BAD_MECH;
- p += mech_len;
- if (memcmp (p, type, 2) != 0)
- return GSS_S_DEFECTIVE_TOKEN;
- p += 2;
- *str = p;
- return GSS_S_COMPLETE;
-}
-
-/*
- * Remove the GSS-API wrapping from `in_token' giving `out_data.
- * Does not copy data, so just free `in_token'.
- */
-
-OM_uint32
-gssapi_krb5_decapsulate(
- gss_buffer_t input_token_buffer,
- krb5_data *out_data,
- u_char *type
-)
-{
- u_char *p;
- OM_uint32 ret;
-
- p = input_token_buffer->value;
- ret = gssapi_krb5_verify_header(&p,
- input_token_buffer->length,
- type);
- if (ret)
- return ret;
-
- out_data->length = input_token_buffer->length -
- (p - (u_char *)input_token_buffer->value);
- out_data->data = p;
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/delete_sec_context.c b/lib/gssapi/krb5/delete_sec_context.c
deleted file mode 100644
index e39a682ace1262c3edb110155bc738c7375d81c1..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/delete_sec_context.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_delete_sec_context
- (OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- gss_buffer_t output_token
- )
-{
- gssapi_krb5_init ();
- krb5_auth_con_free (gssapi_krb5_context,
- (*context_handle)->auth_context);
- if((*context_handle)->source)
- krb5_free_principal (gssapi_krb5_context,
- (*context_handle)->source);
- if((*context_handle)->target)
- krb5_free_principal (gssapi_krb5_context,
- (*context_handle)->target);
- free (*context_handle);
- if (output_token)
- output_token->length = 0;
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/display_name.c b/lib/gssapi/krb5/display_name.c
deleted file mode 100644
index 03fcff3b31689aa7b9453a31aa1cde8c4ca87770..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/display_name.c
+++ /dev/null
@@ -1,72 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_display_name
- (OM_uint32 * minor_status,
- const gss_name_t input_name,
- gss_buffer_t output_name_buffer,
- gss_OID * output_name_type
- )
-{
- krb5_error_code kret;
- char *buf;
- size_t len;
-
- gssapi_krb5_init ();
- kret = krb5_unparse_name (gssapi_krb5_context,
- input_name,
- &buf);
- if (kret)
- return GSS_S_FAILURE;
- len = strlen (buf);
- output_name_buffer->length = len;
- output_name_buffer->value = malloc(len);
- if (output_name_buffer->value == NULL) {
- free (buf);
- return GSS_S_FAILURE;
- }
- memcpy (output_name_buffer->value, buf, len);
- free (buf);
- if (output_name_type)
- *output_name_type = GSS_KRB5_NT_PRINCIPAL_NAME;
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/duplicate_name.c b/lib/gssapi/krb5/duplicate_name.c
deleted file mode 100644
index 037bacb7c5ba1be473f183d63040aa443e52a478..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/duplicate_name.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_duplicate_name (
- OM_uint32 * minor_status,
- const gss_name_t src_name,
- gss_name_t * dest_name
- )
-{
- krb5_error_code kret;
-
- gssapi_krb5_init ();
-
- kret = krb5_copy_principal (gssapi_krb5_context,
- src_name,
- dest_name);
- if (kret)
- return GSS_S_FAILURE;
- else
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/encapsulate.c b/lib/gssapi/krb5/encapsulate.c
deleted file mode 100644
index 77c69a271cb1f5a31ec1af7b3c8db692ebfddc40..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/encapsulate.c
+++ /dev/null
@@ -1,105 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-void
-gssapi_krb5_encap_length (size_t data_len,
- size_t *len,
- size_t *total_len)
-{
- size_t len_len;
-
- *len = 1 + 1 + GSS_KRB5_MECHANISM->length + 2 + data_len;
-
- len_len = length_len(*len);
-
- *total_len = 1 + len_len + *len;
-}
-
-u_char *
-gssapi_krb5_make_header (u_char *p,
- size_t len,
- u_char *type)
-{
- int e;
- size_t len_len, foo;
-
- *p++ = 0x60;
- len_len = length_len(len);
- e = der_put_length (p + len_len - 1, len_len, len, &foo);
- if(e || foo != len_len)
- abort ();
- p += len_len;
- *p++ = 0x06;
- *p++ = GSS_KRB5_MECHANISM->length;
- memcpy (p, GSS_KRB5_MECHANISM->elements, GSS_KRB5_MECHANISM->length);
- p += GSS_KRB5_MECHANISM->length;
- memcpy (p, type, 2);
- p += 2;
- return p;
-}
-
-/*
- * Give it a krb5_data and it will encapsulate with extra GSS-API wrappings.
- */
-
-OM_uint32
-gssapi_krb5_encapsulate(
- krb5_data *in_data,
- gss_buffer_t output_token,
- u_char *type
-)
-{
- size_t len, outer_len;
- u_char *p;
-
- gssapi_krb5_encap_length (in_data->length, &len, &outer_len);
-
- output_token->length = outer_len;
- output_token->value = malloc (outer_len);
- if (output_token->value == NULL)
- return GSS_S_FAILURE;
-
- p = gssapi_krb5_make_header (output_token->value, len, type);
- memcpy (p, in_data->data, in_data->length);
- krb5_data_free (in_data);
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/export_name.c b/lib/gssapi/krb5/export_name.c
deleted file mode 100644
index dc9b75f5c4631436d172130a30814a63d802f49a..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/export_name.c
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_export_name
- (OM_uint32 * minor_status,
- const gss_name_t input_name,
- gss_buffer_t exported_name
- )
-{
- return gss_display_name(minor_status,
- input_name,
- exported_name,
- NULL);
-}
diff --git a/lib/gssapi/krb5/external.c b/lib/gssapi/krb5/external.c
deleted file mode 100644
index 7e0ac1d84057459eee91c3b033e5f0134113aa71..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/external.c
+++ /dev/null
@@ -1,217 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- * "\x01\x02\x01\x01"},
- * corresponding to an object-identifier value of
- * {iso(1) member-body(2) United States(840) mit(113554)
- * infosys(1) gssapi(2) generic(1) user_name(1)}. The constant
- * GSS_C_NT_USER_NAME should be initialized to point
- * to that gss_OID_desc.
- */
-
-static gss_OID_desc gss_c_nt_user_name_oid_desc =
-{10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- "\x01\x02\x01\x01"};
-
-gss_OID GSS_C_NT_USER_NAME = &gss_c_nt_user_name_oid_desc;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- * "\x01\x02\x01\x02"},
- * corresponding to an object-identifier value of
- * {iso(1) member-body(2) United States(840) mit(113554)
- * infosys(1) gssapi(2) generic(1) machine_uid_name(2)}.
- * The constant GSS_C_NT_MACHINE_UID_NAME should be
- * initialized to point to that gss_OID_desc.
- */
-
-static gss_OID_desc gss_c_nt_machine_uid_name_oid_desc =
-{10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- "\x01\x02\x01\x02"};
-
-gss_OID GSS_C_NT_MACHINE_UID_NAME = &gss_c_nt_machine_uid_name_oid_desc;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- * "\x01\x02\x01\x03"},
- * corresponding to an object-identifier value of
- * {iso(1) member-body(2) United States(840) mit(113554)
- * infosys(1) gssapi(2) generic(1) string_uid_name(3)}.
- * The constant GSS_C_NT_STRING_UID_NAME should be
- * initialized to point to that gss_OID_desc.
- */
-
-static gss_OID_desc gss_c_nt_string_uid_name_oid_desc =
-{10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- "\x01\x02\x01\x03"};
-
-gss_OID GSS_C_NT_STRING_UID_NAME = &gss_c_nt_string_uid_name_oid_desc;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {6, (void *)"\x2b\x06\x01\x05\x06\x02"},
- * corresponding to an object-identifier value of
- * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
- * 6(nametypes), 2(gss-host-based-services)}. The constant
- * GSS_C_NT_HOSTBASED_SERVICE should be initialized to point
- * to that gss_OID_desc.
- */
-
-static gss_OID_desc gss_c_nt_hostbased_service_oid_desc =
-{6, (void *)"\x2b\x06\x01\x05\x06\x02"};
-
-gss_OID GSS_C_NT_HOSTBASED_SERVICE = &gss_c_nt_hostbased_service_oid_desc;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {6, (void *)"\x2b\x06\01\x05\x06\x03"},
- * corresponding to an object identifier value of
- * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
- * 6(nametypes), 3(gss-anonymous-name)}. The constant
- * and GSS_C_NT_ANONYMOUS should be initialized to point
- * to that gss_OID_desc.
- */
-
-static gss_OID_desc gss_c_nt_anonymous_oid_desc =
-{6, (void *)"\x2b\x06\01\x05\x06\x03"};
-
-gss_OID GSS_C_NT_ANONYMOUS = &gss_c_nt_anonymous_oid_desc;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {6, (void *)"\x2b\x06\x01\x05\x06\x04"},
- * corresponding to an object-identifier value of
- * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
- * 6(nametypes), 4(gss-api-exported-name)}. The constant
- * GSS_C_NT_EXPORT_NAME should be initialized to point
- * to that gss_OID_desc.
- */
-
-static gss_OID_desc gss_c_nt_export_name_oid_desc =
-{6, (void *)"\x2b\x06\x01\x05\x06\x04"};
-
-gss_OID GSS_C_NT_EXPORT_NAME = &gss_c_nt_export_name_oid_desc;
-
-/*
- * This name form shall be represented by the Object Identifier {iso(1)
- * member-body(2) United States(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".
- */
-
-static gss_OID_desc gss_krb5_nt_principal_name_oid_desc =
-{10, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x02\x01"};
-
-gss_OID GSS_KRB5_NT_PRINCIPAL_NAME = &gss_krb5_nt_principal_name_oid_desc;
-
-/*
- * This name form shall be represented by the Object Identifier {iso(1)
- * member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- * generic(1) user_name(1)}. The recommended symbolic name for this
- * type is "GSS_KRB5_NT_USER_NAME".
- */
-
-gss_OID GSS_KRB5_NT_USER_NAME = &gss_c_nt_user_name_oid_desc;
-
-/*
- * This name form shall be represented by the Object Identifier {iso(1)
- * member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- * generic(1) machine_uid_name(2)}. The recommended symbolic name for
- * this type is "GSS_KRB5_NT_MACHINE_UID_NAME".
- */
-
-gss_OID GSS_KRB5_NT_MACHINE_UID_NAME = &gss_c_nt_machine_uid_name_oid_desc;
-
-/*
- * This name form shall be represented by the Object Identifier {iso(1)
- * member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
- * generic(1) string_uid_name(3)}. The recommended symbolic name for
- * this type is "GSS_KRB5_NT_STRING_UID_NAME".
- */
-
-gss_OID GSS_KRB5_NT_STRING_UID_NAME = &gss_c_nt_string_uid_name_oid_desc;
-
-/*
- * To support ongoing experimentation, testing, and evolution of the
- * specification, the Kerberos V5 GSS-API mechanism as defined in this
- * and any successor memos will be identified with the following Object
- * Identifier, as defined in RFC-1510, until the specification is
- * advanced to the level of Proposed Standard RFC:
- *
- * {iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)}
- *
- * Upon advancement to the level of Proposed Standard RFC, the Kerberos
- * V5 GSS-API mechanism will be identified by an Object Identifier
- * having the value:
- *
- * {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
- * gssapi(2) krb5(2)}
- */
-
-#if 0 /* This is the old OID */
-
-static gss_OID_desc gss_krb5_mechanism_oid_desc =
-{5, (void *)"\x2b\x05\x01\x05\x02"};
-
-#endif
-
-static gss_OID_desc gss_krb5_mechanism_oid_desc =
-{9, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x02"};
-
-gss_OID GSS_KRB5_MECHANISM = &gss_krb5_mechanism_oid_desc;
-
-/*
- * Context for krb5 calls.
- */
-
-krb5_context gssapi_krb5_context;
diff --git a/lib/gssapi/krb5/get_mic.c b/lib/gssapi/krb5/get_mic.c
deleted file mode 100644
index 7ad1fbbb1ffa109b4e503fef8df4b0ec8b377280..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/get_mic.c
+++ /dev/null
@@ -1,125 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_get_mic
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- gss_qop_t qop_req,
- const gss_buffer_t message_buffer,
- gss_buffer_t message_token
- )
-{
- u_char *p;
- struct md5 md5;
- u_char hash[16];
- des_key_schedule schedule;
- des_cblock key;
- des_cblock zero;
- int32_t seq_number;
- size_t len, total_len;
-
- gssapi_krb5_encap_length (22, &len, &total_len);
-
- message_token->length = total_len;
- message_token->value = malloc (total_len);
- if (message_token->value == NULL)
- return GSS_S_FAILURE;
-
- p = gssapi_krb5_make_header(message_token->value,
- len,
- "\x01\x01");
-
- memcpy (p, "\x00\x00", 2);
- p += 2;
- memcpy (p, "\xff\xff\xff\xff", 4);
- p += 4;
-
- /* Fill in later */
- memset (p, 0, 16);
- p += 16;
-
- /* checksum */
- md5_init (&md5);
- md5_update (&md5, p - 24, 8);
- md5_update (&md5, message_buffer->value,
- message_buffer->length);
- md5_finito (&md5, hash);
-
- memset (&zero, 0, sizeof(zero));
-#if 0
- memcpy (&key, context_handle->auth_context->key.keyvalue.data,
- sizeof(key));
-#endif
- memcpy (&key, context_handle->auth_context->local_subkey->keyvalue.data,
- sizeof(key));
- des_set_key (&key, schedule);
- des_cbc_cksum ((des_cblock *)hash,
- (des_cblock *)hash, sizeof(hash), schedule, &zero);
- memcpy (p - 8, hash, 8);
-
- /* sequence number */
- krb5_auth_getlocalseqnumber (gssapi_krb5_context,
- context_handle->auth_context,
- &seq_number);
-
- p -= 16;
- p[0] = (seq_number >> 0) & 0xFF;
- p[1] = (seq_number >> 8) & 0xFF;
- p[2] = (seq_number >> 16) & 0xFF;
- p[3] = (seq_number >> 24) & 0xFF;
- memset (p + 4,
- (context_handle->more_flags & LOCAL) ? 0 : 0xFF,
- 4);
-
- des_set_key (&key, schedule);
- des_cbc_encrypt ((des_cblock *)p, (des_cblock *)p, 8,
- schedule, (des_cblock *)(p + 8), DES_ENCRYPT);
-
- krb5_auth_setlocalseqnumber (gssapi_krb5_context,
- context_handle->auth_context,
- ++seq_number);
-
- memset (key, 0, sizeof(key));
- memset (schedule, 0, sizeof(schedule));
-
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/gssapi.h b/lib/gssapi/krb5/gssapi.h
deleted file mode 100644
index 1f4b4980711d44a97f87e4d2cd93cbf40eb50471..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/gssapi.h
+++ /dev/null
@@ -1,745 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifndef GSSAPI_H_
-#define GSSAPI_H_
-
-/*
- * First, include stddef.h to get size_t defined.
- */
-#include <stddef.h>
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-
-#include <sys/types.h>
-
-#include <krb5-types.h>
-
-/*
- * Now define the three implementation-dependent types.
- */
-
-typedef u_int32_t OM_uint32;
-
-/*
- * This is to avoid having to include <krb5.h>
- */
-
-struct krb5_auth_context_data;
-
-struct Principal;
-
-/* typedef void *gss_name_t; */
-
-typedef struct Principal *gss_name_t;
-
-typedef struct gss_ctx_id_t_desc_struct {
- struct krb5_auth_context_data *auth_context;
- gss_name_t source, target;
- OM_uint32 flags;
- enum { LOCAL = 1, OPEN = 2} more_flags;
-} gss_ctx_id_t_desc;
-
-typedef gss_ctx_id_t_desc *gss_ctx_id_t;
-
-typedef struct gss_OID_desc_struct {
- OM_uint32 length;
- void *elements;
-} gss_OID_desc, *gss_OID;
-
-typedef struct gss_OID_set_desc_struct {
- size_t count;
- gss_OID elements;
-} gss_OID_set_desc, *gss_OID_set;
-
-struct krb5_keytab_data;
-
-typedef int gss_cred_usage_t;
-
-typedef struct gss_cred_id_t_desc_struct {
- gss_name_t principal;
- struct krb5_keytab_data *keytab;
- OM_uint32 lifetime;
- gss_cred_usage_t usage;
- gss_OID_set mechanisms;
-} gss_cred_id_t_desc;
-
-typedef gss_cred_id_t_desc *gss_cred_id_t;
-
-typedef struct gss_buffer_desc_struct {
- size_t length;
- void *value;
-} gss_buffer_desc, *gss_buffer_t;
-
-typedef struct gss_channel_bindings_struct {
- OM_uint32 initiator_addrtype;
- gss_buffer_desc initiator_address;
- OM_uint32 acceptor_addrtype;
- gss_buffer_desc acceptor_address;
- gss_buffer_desc application_data;
-} *gss_channel_bindings_t;
-
-/*
- * For now, define a QOP-type as an OM_uint32
- */
-typedef OM_uint32 gss_qop_t;
-
-/*
- * Flag bits for context-level services.
- */
-#define GSS_C_DELEG_FLAG 1
-#define GSS_C_MUTUAL_FLAG 2
-#define GSS_C_REPLAY_FLAG 4
-#define GSS_C_SEQUENCE_FLAG 8
-#define GSS_C_CONF_FLAG 16
-#define GSS_C_INTEG_FLAG 32
-#define GSS_C_ANON_FLAG 64
-#define GSS_C_PROT_READY_FLAG 128
-#define GSS_C_TRANS_FLAG 256
-
-/*
- * Credential usage options
- */
-#define GSS_C_BOTH 0
-#define GSS_C_INITIATE 1
-#define GSS_C_ACCEPT 2
-
-/*
- * Status code types for gss_display_status
- */
-#define GSS_C_GSS_CODE 1
-#define GSS_C_MECH_CODE 2
-
-/*
- * The constant definitions for channel-bindings address families
- */
-#define GSS_C_AF_UNSPEC 0
-#define GSS_C_AF_LOCAL 1
-#define GSS_C_AF_INET 2
-#define GSS_C_AF_IMPLINK 3
-#define GSS_C_AF_PUP 4
-#define GSS_C_AF_CHAOS 5
-#define GSS_C_AF_NS 6
-#define GSS_C_AF_NBS 7
-#define GSS_C_AF_ECMA 8
-#define GSS_C_AF_DATAKIT 9
-#define GSS_C_AF_CCITT 10
-#define GSS_C_AF_SNA 11
-#define GSS_C_AF_DECnet 12
-#define GSS_C_AF_DLI 13
-#define GSS_C_AF_LAT 14
-#define GSS_C_AF_HYLINK 15
-#define GSS_C_AF_APPLETALK 16
-#define GSS_C_AF_BSC 17
-#define GSS_C_AF_DSS 18
-#define GSS_C_AF_OSI 19
-#define GSS_C_AF_X25 21
-
-#define GSS_C_AF_NULLADDR 255
-
-/*
- * Various Null values
- */
-#define GSS_C_NO_NAME ((gss_name_t) 0)
-#define GSS_C_NO_BUFFER ((gss_buffer_t) 0)
-#define GSS_C_NO_OID ((gss_OID) 0)
-#define GSS_C_NO_OID_SET ((gss_OID_set) 0)
-#define GSS_C_NO_CONTEXT ((gss_ctx_id_t) 0)
-#define GSS_C_NO_CREDENTIAL ((gss_cred_id_t) 0)
-#define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
-#define GSS_C_EMPTY_BUFFER {0, NULL}
-
-/*
- * Some alternate names for a couple of the above
- * values. These are defined for V1 compatibility.
- */
-#define GSS_C_NULL_OID GSS_C_NO_OID
-#define GSS_C_NULL_OID_SET GSS_C_NO_OID_SET
-
-/*
- * Define the default Quality of Protection for per-message
- * services. Note that an implementation that offers multiple
- * levels of QOP may define GSS_C_QOP_DEFAULT to be either zero
- * (as done here) to mean "default protection", or to a specific
- * explicit QOP value. However, a value of 0 should always be
- * interpreted by a GSSAPI implementation as a request for the
- * default protection level.
- */
-#define GSS_C_QOP_DEFAULT 0
-
-/*
- * Expiration time of 2^32-1 seconds means infinite lifetime for a
- * credential or security context
- */
-#define GSS_C_INDEFINITE 0xfffffffful
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- * "\x01\x02\x01\x01"},
- * corresponding to an object-identifier value of
- * {iso(1) member-body(2) United States(840) mit(113554)
- * infosys(1) gssapi(2) generic(1) user_name(1)}. The constant
- * GSS_C_NT_USER_NAME should be initialized to point
- * to that gss_OID_desc.
- */
-extern gss_OID GSS_C_NT_USER_NAME;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- * "\x01\x02\x01\x02"},
- * corresponding to an object-identifier value of
- * {iso(1) member-body(2) United States(840) mit(113554)
- * infosys(1) gssapi(2) generic(1) machine_uid_name(2)}.
- * The constant GSS_C_NT_MACHINE_UID_NAME should be
- * initialized to point to that gss_OID_desc.
- */
-extern gss_OID GSS_C_NT_MACHINE_UID_NAME;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
- * "\x01\x02\x01\x03"},
- * corresponding to an object-identifier value of
- * {iso(1) member-body(2) United States(840) mit(113554)
- * infosys(1) gssapi(2) generic(1) string_uid_name(3)}.
- * The constant GSS_C_NT_STRING_UID_NAME should be
- * initialized to point to that gss_OID_desc.
- */
-extern gss_OID GSS_C_NT_STRING_UID_NAME;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {6, (void *)"\x2b\x06\x01\x05\x06\x02"},
- * corresponding to an object-identifier value of
- * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
- * 6(nametypes), 2(gss-host-based-services)}. The constant
- * GSS_C_NT_HOSTBASED_SERVICE should be initialized to point
- * to that gss_OID_desc.
- */
-extern gss_OID GSS_C_NT_HOSTBASED_SERVICE;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {6, (void *)"\x2b\x06\01\x05\x06\x03"},
- * corresponding to an object identifier value of
- * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
- * 6(nametypes), 3(gss-anonymous-name)}. The constant
- * and GSS_C_NT_ANONYMOUS should be initialized to point
- * to that gss_OID_desc.
- */
-extern gss_OID GSS_C_NT_ANONYMOUS;
-
-/*
- * The implementation must reserve static storage for a
- * gss_OID_desc object containing the value
- * {6, (void *)"\x2b\x06\x01\x05\x06\x04"},
- * corresponding to an object-identifier value of
- * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
- * 6(nametypes), 4(gss-api-exported-name)}. The constant
- * GSS_C_NT_EXPORT_NAME should be initialized to point
- * to that gss_OID_desc.
- */
-extern gss_OID GSS_C_NT_EXPORT_NAME;
-
-/*
- * This if for kerberos5 names.
- */
-
-extern gss_OID GSS_KRB5_NT_PRINCIPAL_NAME;
-extern gss_OID GSS_KRB5_NT_USER_NAME;
-extern gss_OID GSS_KRB5_NT_MACHINE_UID_NAME;
-extern gss_OID GSS_KRB5_NT_STRING_UID_NAME;
-
-extern gss_OID GSS_KRB5_MECHANISM;
-
-/* Major status codes */
-
-#define GSS_S_COMPLETE 0
-
-/*
- * Some "helper" definitions to make the status code macros obvious.
- */
-#define GSS_C_CALLING_ERROR_OFFSET 24
-#define GSS_C_ROUTINE_ERROR_OFFSET 16
-#define GSS_C_SUPPLEMENTARY_OFFSET 0
-#define GSS_C_CALLING_ERROR_MASK 0377ul
-#define GSS_C_ROUTINE_ERROR_MASK 0377ul
-#define GSS_C_SUPPLEMENTARY_MASK 0177777ul
-
-/*
- * The macros that test status codes for error conditions.
- * Note that the GSS_ERROR() macro has changed slightly from
- * the V1 GSSAPI so that it now evaluates its argument
- * only once.
- */
-#define GSS_CALLING_ERROR(x) \
- (x & (GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET))
-#define GSS_ROUTINE_ERROR(x) \
- (x & (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET))
-#define GSS_SUPPLEMENTARY_INFO(x) \
- (x & (GSS_C_SUPPLEMENTARY_MASK << GSS_C_SUPPLEMENTARY_OFFSET))
-#define GSS_ERROR(x) \
- (x & ((GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET) | \
- (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET)))
-
-/*
- * Now the actual status code definitions
- */
-
-/*
- * Calling errors:
- */
-#define GSS_S_CALL_INACCESSIBLE_READ \
- (1ul << GSS_C_CALLING_ERROR_OFFSET)
-#define GSS_S_CALL_INACCESSIBLE_WRITE \
- (2ul << GSS_C_CALLING_ERROR_OFFSET)
-#define GSS_S_CALL_BAD_STRUCTURE \
- (3ul << GSS_C_CALLING_ERROR_OFFSET)
-
-/*
- * Routine errors:
- */
-#define GSS_S_BAD_MECH (1ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_BAD_NAME (2ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_BAD_NAMETYPE (3ul << GSS_C_ROUTINE_ERROR_OFFSET)
-
-#define GSS_S_BAD_BINDINGS (4ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_BAD_STATUS (5ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_BAD_SIG (6ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_BAD_MIC GSS_S_BAD_SIG
-#define GSS_S_NO_CRED (7ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_NO_CONTEXT (8ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_DEFECTIVE_CREDENTIAL (10ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_CREDENTIALS_EXPIRED (11ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_CONTEXT_EXPIRED (12ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_FAILURE (13ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_BAD_QOP (14ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_UNAUTHORIZED (15ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_UNAVAILABLE (16ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_DUPLICATE_ELEMENT (17ul << GSS_C_ROUTINE_ERROR_OFFSET)
-#define GSS_S_NAME_NOT_MN (18ul << GSS_C_ROUTINE_ERROR_OFFSET)
-
-/*
- * Supplementary info bits:
- */
-#define GSS_S_CONTINUE_NEEDED (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 0))
-#define GSS_S_DUPLICATE_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 1))
-#define GSS_S_OLD_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 2))
-#define GSS_S_UNSEQ_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 3))
-#define GSS_S_GAP_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 4))
-
-/*
- * From RFC1964:
- *
- * 4.1.1. Non-Kerberos-specific codes
- */
-
-#define GSS_KRB5_S_G_BAD_SERVICE_NAME 1
- /* "No @ in SERVICE-NAME name string" */
-#define GSS_KRB5_S_G_BAD_STRING_UID 2
- /* "STRING-UID-NAME contains nondigits" */
-#define GSS_KRB5_S_G_NOUSER 3
- /* "UID does not resolve to username" */
-#define GSS_KRB5_S_G_VALIDATE_FAILED 4
- /* "Validation error" */
-#define GSS_KRB5_S_G_BUFFER_ALLOC 5
- /* "Couldn't allocate gss_buffer_t data" */
-#define GSS_KRB5_S_G_BAD_MSG_CTX 6
- /* "Message context invalid" */
-#define GSS_KRB5_S_G_WRONG_SIZE 7
- /* "Buffer is the wrong size" */
-#define GSS_KRB5_S_G_BAD_USAGE 8
- /* "Credential usage type is unknown" */
-#define GSS_KRB5_S_G_UNKNOWN_QOP 9
- /* "Unknown quality of protection specified" */
-
- /*
- * 4.1.2. Kerberos-specific-codes
- */
-
-#define GSS_KRB5_S_KG_CCACHE_NOMATCH 10
- /* "Principal in credential cache does not match desired name" */
-#define GSS_KRB5_S_KG_KEYTAB_NOMATCH 11
- /* "No principal in keytab matches desired name" */
-#define GSS_KRB5_S_KG_TGT_MISSING 12
- /* "Credential cache has no TGT" */
-#define GSS_KRB5_S_KG_NO_SUBKEY 13
- /* "Authenticator has no subkey" */
-#define GSS_KRB5_S_KG_CONTEXT_ESTABLISHED 14
- /* "Context is already fully established" */
-#define GSS_KRB5_S_KG_BAD_SIGN_TYPE 15
- /* "Unknown signature type in token" */
-#define GSS_KRB5_S_KG_BAD_LENGTH 16
- /* "Invalid field length in token" */
-#define GSS_KRB5_S_KG_CTX_INCOMPLETE 17
- /* "Attempt to use incomplete security context" */
-
-/*
- * Finally, function prototypes for the GSS-API routines.
- */
-
-OM_uint32 gss_acquire_cred
- (OM_uint32 * minor_status,
- const gss_name_t desired_name,
- OM_uint32 time_req,
- const gss_OID_set desired_mechs,
- gss_cred_usage_t cred_usage,
- gss_cred_id_t * output_cred_handle,
- gss_OID_set * actual_mechs,
- OM_uint32 * time_rec
- );
-
-OM_uint32 gss_release_cred
- (OM_uint32 * minor_status,
- gss_cred_id_t * cred_handle
- );
-
-OM_uint32 gss_init_sec_context
- (OM_uint32 * minor_status,
- const gss_cred_id_t initiator_cred_handle,
- gss_ctx_id_t * context_handle,
- const gss_name_t target_name,
- const gss_OID mech_type,
- OM_uint32 req_flags,
- OM_uint32 time_req,
- const gss_channel_bindings_t input_chan_bindings,
- const gss_buffer_t input_token,
- gss_OID * actual_mech_type,
- gss_buffer_t output_token,
- OM_uint32 * ret_flags,
- OM_uint32 * time_rec
- );
-
-OM_uint32 gss_accept_sec_context
- (OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- const gss_cred_id_t acceptor_cred_handle,
- const gss_buffer_t input_token_buffer,
- const gss_channel_bindings_t input_chan_bindings,
- gss_name_t * src_name,
- gss_OID * mech_type,
- gss_buffer_t output_token,
- OM_uint32 * ret_flags,
- OM_uint32 * time_rec,
- gss_cred_id_t * delegated_cred_handle
- );
-
-OM_uint32 gss_process_context_token
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- const gss_buffer_t token_buffer
- );
-
-OM_uint32 gss_delete_sec_context
- (OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- gss_buffer_t output_token
- );
-
-OM_uint32 gss_context_time
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- OM_uint32 * time_rec
- );
-
-OM_uint32 gss_get_mic
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- gss_qop_t qop_req,
- const gss_buffer_t message_buffer,
- gss_buffer_t message_token
- );
-
-OM_uint32 gss_verify_mic
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- const gss_buffer_t message_buffer,
- const gss_buffer_t token_buffer,
- gss_qop_t * qop_state
- );
-
-OM_uint32 gss_wrap
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- int conf_req_flag,
- gss_qop_t qop_req,
- const gss_buffer_t input_message_buffer,
- int * conf_state,
- gss_buffer_t output_message_buffer
- );
-
-OM_uint32 gss_unwrap
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- const gss_buffer_t input_message_buffer,
- gss_buffer_t output_message_buffer,
- int * conf_state,
- gss_qop_t * qop_state
- );
-
-OM_uint32 gss_display_status
- (OM_uint32 * minor_status,
- OM_uint32 status_value,
- int status_type,
- const gss_OID mech_type,
- OM_uint32 * message_context,
- gss_buffer_t status_string
- );
-
-OM_uint32 gss_indicate_mechs
- (OM_uint32 * minor_status,
- gss_OID_set * mech_set
- );
-
-OM_uint32 gss_compare_name
- (OM_uint32 * minor_status,
- const gss_name_t name1,
- const gss_name_t name2,
- int * name_equal
- );
-
-OM_uint32 gss_display_name
- (OM_uint32 * minor_status,
- const gss_name_t input_name,
- gss_buffer_t output_name_buffer,
- gss_OID * output_name_type
- );
-
-OM_uint32 gss_import_name
- (OM_uint32 * minor_status,
- const gss_buffer_t input_name_buffer,
- const gss_OID input_name_type,
- gss_name_t * output_name
- );
-
-OM_uint32 gss_export_name
- (OM_uint32 * minor_status,
- const gss_name_t input_name,
- gss_buffer_t exported_name
- );
-
-OM_uint32 gss_release_name
- (OM_uint32 * minor_status,
- gss_name_t * input_name
- );
-
-OM_uint32 gss_release_buffer
- (OM_uint32 * minor_status,
- gss_buffer_t buffer
- );
-
-OM_uint32 gss_release_oid_set
- (OM_uint32 * minor_status,
- gss_OID_set * set
- );
-
-OM_uint32 gss_inquire_cred
- (OM_uint32 * minor_status,
- const gss_cred_id_t cred_handle,
- gss_name_t * name,
- OM_uint32 * lifetime,
- gss_cred_usage_t * cred_usage,
- gss_OID_set * mechanisms
- );
-
-OM_uint32 gss_inquire_context (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- gss_name_t * src_name,
- gss_name_t * targ_name,
- OM_uint32 * lifetime_rec,
- gss_OID * mech_type,
- OM_uint32 * ctx_flags,
- int * locally_initiated,
- int * open
- );
-
-OM_uint32 gss_wrap_size_limit (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- int conf_req_flag,
- gss_qop_t qop_req,
- OM_uint32 req_output_size,
- OM_uint32 * max_input_size
- );
-
-OM_uint32 gss_add_cred (
- OM_uint32 * minor_status,
- const gss_cred_id_t input_cred_handle,
- const gss_name_t desired_name,
- const gss_OID desired_mech,
- gss_cred_usage_t cred_usage,
- OM_uint32 initiator_time_req,
- OM_uint32 acceptor_time_req,
- gss_cred_id_t * output_cred_handle,
- gss_OID_set * actual_mechs,
- OM_uint32 * initiator_time_rec,
- OM_uint32 * acceptor_time_rec
- );
-
-OM_uint32 gss_inquire_cred_by_mech (
- OM_uint32 * minor_status,
- const gss_cred_id_t cred_handle,
- const gss_OID mech_type,
- gss_name_t * name,
- OM_uint32 * initiator_lifetime,
- OM_uint32 * acceptor_lifetime,
- gss_cred_usage_t * cred_usage
- );
-
-OM_uint32 gss_export_sec_context (
- OM_uint32 * minor_status,
- gss_ctx_id_t * context_handle,
- gss_buffer_t interprocess_token
- );
-
-OM_uint32 gss_import_sec_context (
- OM_uint32 * minor_status,
- const gss_buffer_t interprocess_token,
- gss_ctx_id_t * context_handle
- );
-
-OM_uint32 gss_create_empty_oid_set (
- OM_uint32 * minor_status,
- gss_OID_set * oid_set
- );
-
-OM_uint32 gss_add_oid_set_member (
- OM_uint32 * minor_status,
- const gss_OID member_oid,
- gss_OID_set * oid_set
- );
-
-OM_uint32 gss_test_oid_set_member (
- OM_uint32 * minor_status,
- const gss_OID member,
- const gss_OID_set set,
- int * present
- );
-
-OM_uint32 gss_inquire_names_for_mech (
- OM_uint32 * minor_status,
- const gss_OID mechanism,
- gss_OID_set * name_types
- );
-
-OM_uint32 gss_inquire_mechs_for_name (
- OM_uint32 * minor_status,
- const gss_name_t input_name,
- gss_OID_set * mech_types
- );
-
-OM_uint32 gss_canonicalize_name (
- OM_uint32 * minor_status,
- const gss_name_t input_name,
- const gss_OID mech_type,
- gss_name_t * output_name
- );
-
-OM_uint32 gss_duplicate_name (
- OM_uint32 * minor_status,
- const gss_name_t src_name,
- gss_name_t * dest_name
- );
-
-/*
- * The following routines are obsolete variants of gss_get_mic,
- * gss_verify_mic, gss_wrap and gss_unwrap. They should be
- * provided by GSSAPI V2 implementations for backwards
- * compatibility with V1 applications. Distinct entrypoints
- * (as opposed to #defines) should be provided, both to allow
- * GSSAPI V1 applications to link against GSSAPI V2 implementations,
- * and to retain the slight parameter type differences between the
- * obsolete versions of these routines and their current forms.
- */
-
-OM_uint32 gss_sign
- (OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- int qop_req,
- gss_buffer_t message_buffer,
- gss_buffer_t message_token
- );
-
-OM_uint32 gss_verify
- (OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- gss_buffer_t message_buffer,
- gss_buffer_t token_buffer,
- int * qop_state
- );
-
-OM_uint32 gss_seal
- (OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- int conf_req_flag,
- int qop_req,
- gss_buffer_t input_message_buffer,
- int * conf_state,
- gss_buffer_t output_message_buffer
- );
-
-OM_uint32 gss_unseal
- (OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- gss_buffer_t input_message_buffer,
- gss_buffer_t output_message_buffer,
- int * conf_state,
- int * qop_state
- );
-
-/*
- * kerberos mechanism specific functions
- */
-
-OM_uint32 gsskrb5_register_acceptor_identity
- (char *identity);
-
-#endif /* GSSAPI_H_ */
diff --git a/lib/gssapi/krb5/gssapi_locl.h b/lib/gssapi/krb5/gssapi_locl.h
deleted file mode 100644
index 2903a4489ba3c6693c3a44e9e37d5903e128fef6..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/gssapi_locl.h
+++ /dev/null
@@ -1,95 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#ifndef GSSAPI_LOCL_H
-#define GSSAPI_LOCL_H
-
-#include <stdlib.h>
-#include <string.h>
-
-#ifdef HAVE_NETDB_H
-#include <netdb.h>
-#endif
-
-#include <gssapi.h>
-
-#include <krb5.h>
-#include <des.h>
-#include <krb5_locl.h>
-#include <der.h>
-
-extern krb5_context gssapi_krb5_context;
-
-void gssapi_krb5_init (void);
-
-krb5_error_code
-gssapi_krb5_create_8003_checksum (
- const gss_channel_bindings_t input_chan_bindings,
- OM_uint32 flags,
- Checksum *result);
-
-OM_uint32
-gssapi_krb5_encapsulate(
- krb5_data *in_data,
- gss_buffer_t output_token,
- u_char *type);
-
-OM_uint32
-gssapi_krb5_decapsulate(
- gss_buffer_t input_token_buffer,
- krb5_data *out_data,
- u_char *type);
-
-void
-gssapi_krb5_encap_length (size_t data_len,
- size_t *len,
- size_t *total_len);
-
-u_char *
-gssapi_krb5_make_header (u_char *p,
- size_t len,
- u_char *type);
-
-OM_uint32
-gssapi_krb5_verify_header(u_char **str,
- size_t total_len,
- u_char *type);
-
-#endif
diff --git a/lib/gssapi/krb5/import_name.c b/lib/gssapi/krb5/import_name.c
deleted file mode 100644
index 784149ecd3176aa7400d9811a09787e66f78ee81..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/import_name.c
+++ /dev/null
@@ -1,138 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-static OM_uint32
-import_krb5_name (OM_uint32 *minor_status,
- const gss_buffer_t input_name_buffer,
- gss_name_t *output_name)
-{
- krb5_error_code kerr;
- char *tmp;
-
- tmp = malloc (input_name_buffer->length + 1);
- if (tmp == NULL)
- return GSS_S_FAILURE;
- memcpy (tmp,
- input_name_buffer->value,
- input_name_buffer->length);
- tmp[input_name_buffer->length] = '\0';
-
- kerr = krb5_parse_name (gssapi_krb5_context,
- tmp,
- output_name);
- free (tmp);
- if (kerr == 0)
- return GSS_S_COMPLETE;
- else if (kerr == KRB5_PARSE_ILLCHAR || kerr == KRB5_PARSE_MALFORMED)
- return GSS_S_BAD_NAME;
- else
- return GSS_S_FAILURE;
-}
-
-static OM_uint32
-import_hostbased_name (OM_uint32 *minor_status,
- const gss_buffer_t input_name_buffer,
- gss_name_t *output_name)
-{
- krb5_error_code kerr;
- char *tmp;
- char *p;
- char *host;
- char local_hostname[MAXHOSTNAMELEN];
-
- tmp = malloc (input_name_buffer->length + 1);
- if (tmp == NULL)
- return GSS_S_FAILURE;
- memcpy (tmp,
- input_name_buffer->value,
- input_name_buffer->length);
- tmp[input_name_buffer->length] = '\0';
-
- p = strchr (tmp, '@');
- if (p != NULL) {
- *p = '\0';
- host = p + 1;
- } else {
- if (gethostname(local_hostname, sizeof(local_hostname)) < 0) {
- free (tmp);
- return GSS_S_FAILURE;
- }
- host = local_hostname;
- }
-
- kerr = krb5_sname_to_principal (gssapi_krb5_context,
- host,
- tmp,
- KRB5_NT_SRV_HST,
- output_name);
- free (tmp);
- if (kerr == 0)
- return GSS_S_COMPLETE;
- else if (kerr == KRB5_PARSE_ILLCHAR || kerr == KRB5_PARSE_MALFORMED)
- return GSS_S_BAD_NAME;
- else
- return GSS_S_FAILURE;
-}
-
-OM_uint32 gss_import_name
- (OM_uint32 * minor_status,
- const gss_buffer_t input_name_buffer,
- const gss_OID input_name_type,
- gss_name_t * output_name
- )
-{
- gssapi_krb5_init ();
-
- if (input_name_type == GSS_C_NT_HOSTBASED_SERVICE)
- return import_hostbased_name (minor_status,
- input_name_buffer,
- output_name);
- else if (input_name_type == GSS_C_NO_OID
- || input_name_type == GSS_C_NT_USER_NAME
- || input_name_type == GSS_KRB5_NT_PRINCIPAL_NAME)
- /* default printable syntax */
- return import_krb5_name (minor_status,
- input_name_buffer,
- output_name);
- else
- return GSS_S_BAD_NAMETYPE;
-}
diff --git a/lib/gssapi/krb5/indicate_mechs.c b/lib/gssapi/krb5/indicate_mechs.c
deleted file mode 100644
index 5cbcba25deee7bf4773bda6d49f56c02f6acd2c5..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/indicate_mechs.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_indicate_mechs
- (OM_uint32 * minor_status,
- gss_OID_set * mech_set
- )
-{
- *mech_set = malloc(sizeof(**mech_set));
- if (*mech_set == NULL) {
- return GSS_S_FAILURE;
- }
- (*mech_set)->count = 1;
- (*mech_set)->elements = malloc((*mech_set)->count * sizeof(gss_OID_desc));
- if ((*mech_set)->elements == NULL) {
- free (*mech_set);
- return GSS_S_FAILURE;
- }
- (*mech_set)->elements[0] = *GSS_KRB5_MECHANISM;
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/init.c b/lib/gssapi/krb5/init.c
deleted file mode 100644
index d2aeaba29d2a72e2f6cd6c91cbd15700e0706e4f..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/init.c
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-void
-gssapi_krb5_init (void)
-{
- static int donep = 0;
-
- if (donep)
- return;
-
- krb5_init_context (&gssapi_krb5_context);
- donep = 1;
-}
diff --git a/lib/gssapi/krb5/init_sec_context.c b/lib/gssapi/krb5/init_sec_context.c
deleted file mode 100644
index 59d02c7fd3d4f631ab9a64f5dff959099130d1d8..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/init_sec_context.c
+++ /dev/null
@@ -1,349 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-static OM_uint32
-init_auth
- (OM_uint32 * minor_status,
- const gss_cred_id_t initiator_cred_handle,
- gss_ctx_id_t * context_handle,
- const gss_name_t target_name,
- const gss_OID mech_type,
- OM_uint32 req_flags,
- OM_uint32 time_req,
- const gss_channel_bindings_t input_chan_bindings,
- const gss_buffer_t input_token,
- gss_OID * actual_mech_type,
- gss_buffer_t output_token,
- OM_uint32 * ret_flags,
- OM_uint32 * time_rec
- )
-{
- OM_uint32 ret;
- krb5_error_code kret;
- krb5_flags ap_options;
- krb5_creds this_cred, *cred;
- krb5_data outbuf;
- krb5_ccache ccache;
- u_int32_t flags;
- Authenticator *auth;
- krb5_data authenticator;
- Checksum cksum;
- krb5_enctype enctype;
-
- gssapi_krb5_init ();
-
- outbuf.length = 0;
- outbuf.data = NULL;
-
-
-
-
- *context_handle = malloc(sizeof(**context_handle));
- if (*context_handle == NULL)
- return GSS_S_FAILURE;
-
- (*context_handle)->auth_context = NULL;
- (*context_handle)->source = NULL;
- (*context_handle)->target = NULL;
- (*context_handle)->flags = 0;
- (*context_handle)->more_flags = 0;
-
- kret = krb5_auth_con_init (gssapi_krb5_context,
- &(*context_handle)->auth_context);
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- {
- int32_t tmp;
-
- krb5_auth_con_getflags(gssapi_krb5_context,
- (*context_handle)->auth_context,
- &tmp);
- tmp |= KRB5_AUTH_CONTEXT_DO_SEQUENCE;
- krb5_auth_con_setflags(gssapi_krb5_context,
- (*context_handle)->auth_context,
- tmp);
- }
-
- if (actual_mech_type)
- *actual_mech_type = GSS_KRB5_MECHANISM;
-
- flags = 0;
- ap_options = 0;
- if (req_flags & GSS_C_DELEG_FLAG)
- ; /* XXX */
- if (req_flags & GSS_C_MUTUAL_FLAG) {
- flags |= GSS_C_MUTUAL_FLAG;
- ap_options |= AP_OPTS_MUTUAL_REQUIRED;
- }
- if (req_flags & GSS_C_REPLAY_FLAG)
- ; /* XXX */
- if (req_flags & GSS_C_SEQUENCE_FLAG)
- ; /* XXX */
- if (req_flags & GSS_C_ANON_FLAG)
- ; /* XXX */
- flags |= GSS_C_CONF_FLAG;
- flags |= GSS_C_INTEG_FLAG;
- flags |= GSS_C_SEQUENCE_FLAG;
-
- if (ret_flags)
- *ret_flags = flags;
- (*context_handle)->flags = flags;
- (*context_handle)->more_flags = LOCAL;
-
- kret = krb5_cc_default (gssapi_krb5_context, &ccache);
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- kret = krb5_cc_get_principal (gssapi_krb5_context,
- ccache,
- &(*context_handle)->source);
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- kret = krb5_copy_principal (gssapi_krb5_context,
- target_name,
- &(*context_handle)->target);
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- this_cred.client = (*context_handle)->source;
- this_cred.server = (*context_handle)->target;
- this_cred.times.endtime = 0;
-
- kret = krb5_get_credentials (gssapi_krb5_context,
- 0,
- ccache,
- &this_cred,
- &cred);
-
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- {
- /* XXX ugly */
- krb5_keyblock *c;
- krb5_auth_con_getkey(gssapi_krb5_context,
- (*context_handle)->auth_context,
- &c);
- cred->session = *c;
- free(c);
- }
-
- kret = gssapi_krb5_create_8003_checksum (input_chan_bindings,
- flags,
- &cksum);
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- if ((*context_handle)->auth_context->enctype)
- enctype = (*context_handle)->auth_context->enctype;
- else {
- kret = krb5_keytype_to_etype(gssapi_krb5_context,
- (*context_handle)->auth_context->keyblock->keytype,
- &enctype);
- if (kret)
- return kret;
- }
-
-
-
- kret = krb5_build_authenticator (gssapi_krb5_context,
- (*context_handle)->auth_context,
- enctype,
- cred,
- &cksum,
- &auth,
- &authenticator);
-
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- kret = krb5_build_ap_req (gssapi_krb5_context,
- enctype,
- cred,
- ap_options,
- authenticator,
- &outbuf);
-
- if (kret) {
- ret = GSS_S_FAILURE;
- goto failure;
- }
-
- ret = gssapi_krb5_encapsulate (&outbuf,
- output_token,
- "\x01\x00");
- if (ret)
- goto failure;
-
- if (flags & GSS_C_MUTUAL_FLAG) {
- return GSS_S_CONTINUE_NEEDED;
- } else {
- (*context_handle)->more_flags |= OPEN;
- return GSS_S_COMPLETE;
- }
-
-failure:
- krb5_auth_con_free (gssapi_krb5_context,
- (*context_handle)->auth_context);
- if((*context_handle)->source)
- krb5_free_principal (gssapi_krb5_context,
- (*context_handle)->source);
- if((*context_handle)->target)
- krb5_free_principal (gssapi_krb5_context,
- (*context_handle)->target);
- free (*context_handle);
- krb5_data_free (&outbuf);
- *context_handle = GSS_C_NO_CONTEXT;
- return GSS_S_FAILURE;
-}
-
-static OM_uint32
-repl_mutual
- (OM_uint32 * minor_status,
- const gss_cred_id_t initiator_cred_handle,
- gss_ctx_id_t * context_handle,
- const gss_name_t target_name,
- const gss_OID mech_type,
- OM_uint32 req_flags,
- OM_uint32 time_req,
- const gss_channel_bindings_t input_chan_bindings,
- const gss_buffer_t input_token,
- gss_OID * actual_mech_type,
- gss_buffer_t output_token,
- OM_uint32 * ret_flags,
- OM_uint32 * time_rec
- )
-{
- OM_uint32 ret;
- krb5_error_code kret;
- krb5_data indata;
- krb5_ap_rep_enc_part *repl;
-
- ret = gssapi_krb5_decapsulate (input_token,
- &indata,
- "\x02\x00");
- if (ret) {
- /* XXX - Handle AP_ERROR */
- return GSS_S_FAILURE;
- }
-
- kret = krb5_rd_rep (gssapi_krb5_context,
- (*context_handle)->auth_context,
- &indata,
- &repl);
- if (kret)
- return GSS_S_FAILURE;
- krb5_free_ap_rep_enc_part (gssapi_krb5_context,
- repl);
-
- (*context_handle)->more_flags |= OPEN;
-
- return GSS_S_COMPLETE;
-}
-
-/*
- * gss_init_sec_context
- */
-
-OM_uint32 gss_init_sec_context
- (OM_uint32 * minor_status,
- const gss_cred_id_t initiator_cred_handle,
- gss_ctx_id_t * context_handle,
- const gss_name_t target_name,
- const gss_OID mech_type,
- OM_uint32 req_flags,
- OM_uint32 time_req,
- const gss_channel_bindings_t input_chan_bindings,
- const gss_buffer_t input_token,
- gss_OID * actual_mech_type,
- gss_buffer_t output_token,
- OM_uint32 * ret_flags,
- OM_uint32 * time_rec
- )
-{
- gssapi_krb5_init ();
-
- if (input_token == GSS_C_NO_BUFFER || input_token->length == 0)
- return init_auth (minor_status,
- initiator_cred_handle,
- context_handle,
- target_name,
- mech_type,
- req_flags,
- time_req,
- input_chan_bindings,
- input_token,
- actual_mech_type,
- output_token,
- ret_flags,
- time_rec);
- else
- return repl_mutual(minor_status,
- initiator_cred_handle,
- context_handle,
- target_name,
- mech_type,
- req_flags,
- time_req,
- input_chan_bindings,
- input_token,
- actual_mech_type,
- output_token,
- ret_flags,
- time_rec);
-}
diff --git a/lib/gssapi/krb5/inquire_context.c b/lib/gssapi/krb5/inquire_context.c
deleted file mode 100644
index 62eafa5b87f0842c0578187e8858c82908294f31..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/inquire_context.c
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_inquire_context (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- gss_name_t * src_name,
- gss_name_t * targ_name,
- OM_uint32 * lifetime_rec,
- gss_OID * mech_type,
- OM_uint32 * ctx_flags,
- int * locally_initiated,
- int * open
- )
-{
- OM_uint32 ret;
-
- if (src_name) {
- ret = gss_duplicate_name (minor_status,
- context_handle->source,
- src_name);
- if (ret)
- return ret;
- }
-
- if (targ_name) {
- ret = gss_duplicate_name (minor_status,
- context_handle->target,
- targ_name);
- if (ret)
- return ret;
- }
-
- if (lifetime_rec)
- *lifetime_rec = GSS_C_INDEFINITE;
-
- if (mech_type)
- *mech_type = GSS_KRB5_MECHANISM;
-
- if (ctx_flags)
- *ctx_flags = context_handle->flags;
-
- if (locally_initiated)
- *locally_initiated = context_handle->more_flags & LOCAL;
-
- if (open)
- *open = context_handle->more_flags & OPEN;
-
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/inquire_cred.c b/lib/gssapi/krb5/inquire_cred.c
deleted file mode 100644
index 7b0e4eaeafbbbe62f89a6bb0527da2dad35b542f..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/inquire_cred.c
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_inquire_cred
- (OM_uint32 * minor_status,
- const gss_cred_id_t cred_handle,
- gss_name_t * name,
- OM_uint32 * lifetime,
- gss_cred_usage_t * cred_usage,
- gss_OID_set * mechanisms
- )
-{
- OM_uint32 ret;
-
- if (cred_handle == GSS_C_NO_CREDENTIAL) {
- return GSS_S_FAILURE;
- }
-
- if (name != NULL) {
- ret = gss_duplicate_name(minor_status, cred_handle->principal, name);
- if (ret) {
- return ret;
- }
- }
- if (lifetime != NULL) {
- *lifetime = cred_handle->lifetime;
- }
- if (cred_usage != NULL) {
- *cred_usage = cred_handle->usage;
- }
- if (mechanisms != NULL) {
- ret = gss_create_empty_oid_set(minor_status, mechanisms);
- if (ret) {
- return ret;
- }
- ret = gss_add_oid_set_member(minor_status,
- &cred_handle->mechanisms->elements[0],
- mechanisms);
- if (ret) {
- return ret;
- }
- }
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/release_buffer.c b/lib/gssapi/krb5/release_buffer.c
deleted file mode 100644
index b3cff838c824fa6f72ed2e6ea87e3c1826059869..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/release_buffer.c
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_release_buffer
- (OM_uint32 * minor_status,
- gss_buffer_t buffer
- )
-{
- free (buffer->value);
- buffer->length = 0;
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/release_cred.c b/lib/gssapi/krb5/release_cred.c
deleted file mode 100644
index 30a41c0e56da54b92a05ea709502b58c6d039b90..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/release_cred.c
+++ /dev/null
@@ -1,65 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_release_cred
- (OM_uint32 * minor_status,
- gss_cred_id_t * cred_handle
- )
-{
- if (*cred_handle == GSS_C_NO_CREDENTIAL) {
- return GSS_S_COMPLETE;
- }
-
- gssapi_krb5_init ();
-
- krb5_free_principal(gssapi_krb5_context, (*cred_handle)->principal);
- if ((*cred_handle)->keytab != NULL) {
- if ((*cred_handle)->keytab->filename != NULL)
- free((*cred_handle)->keytab->filename);
- free((*cred_handle)->keytab);
- }
- gss_release_oid_set(NULL, &(*cred_handle)->mechanisms);
- free(*cred_handle);
- *cred_handle = GSS_C_NO_CREDENTIAL;
- return GSS_S_COMPLETE;
-}
-
diff --git a/lib/gssapi/krb5/release_name.c b/lib/gssapi/krb5/release_name.c
deleted file mode 100644
index c4ef9e07477f10e01d8f6dbbcd822e4c77bcf0a6..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/release_name.c
+++ /dev/null
@@ -1,52 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_release_name
- (OM_uint32 * minor_status,
- gss_name_t * input_name
- )
-{
- gssapi_krb5_init ();
- krb5_free_principal(gssapi_krb5_context,
- *input_name);
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/release_oid_set.c b/lib/gssapi/krb5/release_oid_set.c
deleted file mode 100644
index 01290506dfb2535d8bbf563b063e17b6d4fd94ef..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/release_oid_set.c
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_release_oid_set
- (OM_uint32 * minor_status,
- gss_OID_set * set
- )
-{
- free ((*set)->elements);
- free (*set);
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/test_oid_set_member.c b/lib/gssapi/krb5/test_oid_set_member.c
deleted file mode 100644
index 9f801c65ccdc7b42b9dd1c8eee451f614f1e42aa..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/test_oid_set_member.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_test_oid_set_member (
- OM_uint32 * minor_status,
- const gss_OID member,
- const gss_OID_set set,
- int * present
- )
-{
- size_t i;
-
- *present = 0;
- for (i = 0; i < set->count; ++i)
- if (member->length == set->elements[i].length
- && memcmp (member->elements,
- set->elements[i].elements,
- member->length) == 0) {
- *present = 1;
- break;
- }
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/unwrap.c b/lib/gssapi/krb5/unwrap.c
deleted file mode 100644
index 931862a0f12b11cd68709299c08e43641a7099c7..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/unwrap.c
+++ /dev/null
@@ -1,174 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_unwrap
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- const gss_buffer_t input_message_buffer,
- gss_buffer_t output_message_buffer,
- int * conf_state,
- gss_qop_t * qop_state
- )
-{
- u_char *p, *pad;
- size_t len;
- struct md5 md5;
- u_char hash[16], seq_data[8];
- des_key_schedule schedule;
- des_cblock key;
- des_cblock zero;
- int i;
- int32_t seq_number;
- size_t padlength;
- OM_uint32 ret;
-
- p = input_message_buffer->value;
- ret = gssapi_krb5_verify_header (&p,
- input_message_buffer->length,
- "\x02\x01");
- if (ret)
- return ret;
-
- if (memcmp (p, "\x00\x00", 2) != 0)
- return GSS_S_BAD_SIG;
- p += 2;
- if (memcmp (p, "\x00\x00", 2) != 0)
- return GSS_S_BAD_MIC;
- p += 2;
- if (memcmp (p, "\xff\xff", 2) != 0)
- return GSS_S_DEFECTIVE_TOKEN;
- p += 2;
- p += 16;
-
- len = p - (u_char *)input_message_buffer->value;
-
- /* decrypt data */
-
- memset (&zero, 0, sizeof(zero));
-#if 0
- memcpy (&key, context_handle->auth_context->key.keyvalue.data,
- sizeof(key));
-#endif
- memcpy (&key, context_handle->auth_context->remote_subkey->keyvalue.data,
- sizeof(key));
- for (i = 0; i < sizeof(key); ++i)
- key[i] ^= 0xf0;
- des_set_key (&key, schedule);
- des_cbc_encrypt ((des_cblock *)p,
- (des_cblock *)p,
- input_message_buffer->length - len,
- schedule,
- &zero,
- DES_DECRYPT);
-
- memset (key, 0, sizeof(key));
- memset (schedule, 0, sizeof(schedule));
-
- /* check pad */
-
- pad = (u_char *)input_message_buffer->value + input_message_buffer->length - 1;
- padlength = *pad;
-
- for (i = padlength; i >= 0 && *pad == padlength; i--, pad--)
- ;
- if (i != 0)
- return GSS_S_BAD_MIC;
-
- md5_init (&md5);
- md5_update (&md5, p - 24, 8);
- md5_update (&md5, p, input_message_buffer->length - len);
- md5_finito (&md5, hash);
-
- memset (&zero, 0, sizeof(zero));
-#if 0
- memcpy (&key, context_handle->auth_context->key.keyvalue.data,
- sizeof(key));
-#endif
- memcpy (&key, context_handle->auth_context->remote_subkey->keyvalue.data,
- sizeof(key));
- des_set_key (&key, schedule);
- des_cbc_cksum ((des_cblock *)hash,
- (des_cblock *)hash, sizeof(hash), schedule, &zero);
- if (memcmp (p - 8, hash, 8) != 0)
- return GSS_S_BAD_MIC;
-
- /* verify sequence number */
-
- krb5_auth_getremoteseqnumber (gssapi_krb5_context,
- context_handle->auth_context,
- &seq_number);
- seq_data[0] = (seq_number >> 0) & 0xFF;
- seq_data[1] = (seq_number >> 8) & 0xFF;
- seq_data[2] = (seq_number >> 16) & 0xFF;
- seq_data[3] = (seq_number >> 24) & 0xFF;
- memset (seq_data + 4,
- (context_handle->more_flags & LOCAL) ? 0xFF : 0,
- 4);
-
- p -= 16;
- des_set_key (&key, schedule);
- des_cbc_encrypt ((des_cblock *)p, (des_cblock *)p, 8,
- schedule, (des_cblock *)hash, DES_DECRYPT);
-
- memset (key, 0, sizeof(key));
- memset (schedule, 0, sizeof(schedule));
-
- if (memcmp (p, seq_data, 8) != 0) {
- return GSS_S_BAD_MIC;
- }
-
- krb5_auth_setremoteseqnumber (gssapi_krb5_context,
- context_handle->auth_context,
- ++seq_number);
-
- /* copy out data */
-
- output_message_buffer->length = input_message_buffer->length
- - len - 8 - padlength;
- output_message_buffer->value = malloc(output_message_buffer->length);
- if(output_message_buffer->value == NULL)
- return GSS_S_FAILURE;
- memcpy (output_message_buffer->value,
- p + 24,
- output_message_buffer->length);
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/v1.c b/lib/gssapi/krb5/v1.c
deleted file mode 100644
index 431934e6886b4af74df76a18ec18b58202d20087..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/v1.c
+++ /dev/null
@@ -1,109 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-/* These functions are for V1 compatibility */
-
-OM_uint32 gss_sign
- (OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- int qop_req,
- gss_buffer_t message_buffer,
- gss_buffer_t message_token
- )
-{
- return gss_get_mic(minor_status,
- context_handle,
- (gss_qop_t)qop_req,
- message_buffer,
- message_token);
-}
-
-OM_uint32 gss_verify
- (OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- gss_buffer_t message_buffer,
- gss_buffer_t token_buffer,
- int * qop_state
- )
-{
- return gss_verify_mic(minor_status,
- context_handle,
- message_buffer,
- token_buffer,
- (gss_qop_t *)qop_state);
-}
-
-OM_uint32 gss_seal
- (OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- int conf_req_flag,
- int qop_req,
- gss_buffer_t input_message_buffer,
- int * conf_state,
- gss_buffer_t output_message_buffer
- )
-{
- return gss_wrap(minor_status,
- context_handle,
- conf_req_flag,
- (gss_qop_t)qop_req,
- input_message_buffer,
- conf_state,
- output_message_buffer);
-}
-
-OM_uint32 gss_unseal
- (OM_uint32 * minor_status,
- gss_ctx_id_t context_handle,
- gss_buffer_t input_message_buffer,
- gss_buffer_t output_message_buffer,
- int * conf_state,
- int * qop_state
- )
-{
- return gss_unwrap(minor_status,
- context_handle,
- input_message_buffer,
- output_message_buffer,
- conf_state,
- (gss_qop_t *)qop_state);
-}
diff --git a/lib/gssapi/krb5/verify_mic.c b/lib/gssapi/krb5/verify_mic.c
deleted file mode 100644
index dc20c18a28f3b4c03b6e6e4b2bc667642a3a921d..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/verify_mic.c
+++ /dev/null
@@ -1,129 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_verify_mic
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- const gss_buffer_t message_buffer,
- const gss_buffer_t token_buffer,
- gss_qop_t * qop_state
- )
-{
- u_char *p;
- struct md5 md5;
- u_char hash[16], seq_data[8];
- des_key_schedule schedule;
- des_cblock key;
- des_cblock zero;
- int32_t seq_number;
- OM_uint32 ret;
-
- p = token_buffer->value;
- ret = gssapi_krb5_verify_header (&p,
- token_buffer->length,
- "\x01\x01");
- if (ret)
- return ret;
-
- if (memcmp(p, "\x00\x00", 2) != 0)
- return GSS_S_BAD_SIG;
- p += 2;
- if (memcmp (p, "\xff\xff\xff\xff", 4) != 0)
- return GSS_S_BAD_MIC;
- p += 4;
- p += 16;
-
- /* verify checksum */
- md5_init (&md5);
- md5_update (&md5, p - 24, 8);
- md5_update (&md5, message_buffer->value,
- message_buffer->length);
- md5_finito (&md5, hash);
-
- memset (&zero, 0, sizeof(zero));
-#if 0
- memcpy (&key, context_handle->auth_context->key.keyvalue.data,
- sizeof(key));
-#endif
- memcpy (&key, context_handle->auth_context->remote_subkey->keyvalue.data,
- sizeof(key));
-
- des_set_key (&key, schedule);
- des_cbc_cksum ((des_cblock *)hash,
- (des_cblock *)hash, sizeof(hash), schedule, &zero);
- if (memcmp (p - 8, hash, 8) != 0) {
- memset (key, 0, sizeof(key));
- memset (schedule, 0, sizeof(schedule));
- return GSS_S_BAD_MIC;
- }
-
- /* verify sequence number */
-
- krb5_auth_getremoteseqnumber (gssapi_krb5_context,
- context_handle->auth_context,
- &seq_number);
- seq_data[0] = (seq_number >> 0) & 0xFF;
- seq_data[1] = (seq_number >> 8) & 0xFF;
- seq_data[2] = (seq_number >> 16) & 0xFF;
- seq_data[3] = (seq_number >> 24) & 0xFF;
- memset (seq_data + 4,
- (context_handle->more_flags & LOCAL) ? 0xFF : 0,
- 4);
-
- p -= 16;
- des_set_key (&key, schedule);
- des_cbc_encrypt ((des_cblock *)p, (des_cblock *)p, 8,
- schedule, (des_cblock *)hash, DES_DECRYPT);
-
- memset (key, 0, sizeof(key));
- memset (schedule, 0, sizeof(schedule));
-
- if (memcmp (p, seq_data, 8) != 0) {
- return GSS_S_BAD_MIC;
- }
-
- krb5_auth_setremoteseqnumber (gssapi_krb5_context,
- context_handle->auth_context,
- ++seq_number);
-
- return GSS_S_COMPLETE;
-}
diff --git a/lib/gssapi/krb5/wrap.c b/lib/gssapi/krb5/wrap.c
deleted file mode 100644
index a2d132568bdeeb9e45e0e9650bbc6a621c195a63..0000000000000000000000000000000000000000
--- a/lib/gssapi/krb5/wrap.c
+++ /dev/null
@@ -1,178 +0,0 @@
-/*
- * Copyright (c) 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$");
-
-OM_uint32 gss_wrap_size_limit (
- OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- int conf_req_flag,
- gss_qop_t qop_req,
- OM_uint32 req_output_size,
- OM_uint32 * max_input_size
- )
-{
- size_t len, total_len, padlength;
- padlength = 8 - (req_output_size % 8);
- len = req_output_size + 8 + padlength + 22;
- gssapi_krb5_encap_length(len, &len, &total_len);
- *max_input_size = (OM_uint32)total_len;
- return GSS_S_COMPLETE;
-}
-
-OM_uint32 gss_wrap
- (OM_uint32 * minor_status,
- const gss_ctx_id_t context_handle,
- int conf_req_flag,
- gss_qop_t qop_req,
- const gss_buffer_t input_message_buffer,
- int * conf_state,
- gss_buffer_t output_message_buffer
- )
-{
- u_char *p;
- struct md5 md5;
- u_char hash[16];
- des_key_schedule schedule;
- des_cblock key;
- des_cblock zero;
- int i;
- int32_t seq_number;
- size_t len, total_len, padlength;
-
- padlength = 8 - (input_message_buffer->length % 8);
- len = input_message_buffer->length + 8 + padlength + 22;
- gssapi_krb5_encap_length (len, &len, &total_len);
-
- output_message_buffer->length = total_len;
- output_message_buffer->value = malloc (total_len);
- if (output_message_buffer->value == NULL)
- return GSS_S_FAILURE;
-
- p = gssapi_krb5_make_header(output_message_buffer->value,
- len,
- "\x02\x01");
-
-
- /* SGN_ALG */
- memcpy (p, "\x00\x00", 2);
- p += 2;
- /* SEAL_ALG */
- memcpy (p, "\x00\x00", 2);
- p += 2;
- /* Filler */
- memcpy (p, "\xff\xff", 2);
- p += 2;
-
- /* fill in later */
- memset (p, 0, 16);
- p += 16;
-
- /* confounder + data + pad */
- des_new_random_key((des_cblock*)p);
- memcpy (p + 8, input_message_buffer->value,
- input_message_buffer->length);
- memset (p + 8 + input_message_buffer->length, padlength, padlength);
-
- /* checksum */
- md5_init (&md5);
- md5_update (&md5, p - 24, 8);
- md5_update (&md5, p, input_message_buffer->length + padlength + 8);
- md5_finito (&md5, hash);
-
- memset (&zero, 0, sizeof(zero));
-#if 0
- memcpy (&key, context_handle->auth_context->key.keyvalue.data,
- sizeof(key));
-#endif
- memcpy (&key, context_handle->auth_context->local_subkey->keyvalue.data,
- sizeof(key));
- des_set_key (&key, schedule);
- des_cbc_cksum ((des_cblock *)hash,
- (des_cblock *)hash, sizeof(hash), schedule, &zero);
- memcpy (p - 8, hash, 8);
-
- /* sequence number */
- krb5_auth_getlocalseqnumber (gssapi_krb5_context,
- context_handle->auth_context,
- &seq_number);
-
- p -= 16;
- p[0] = (seq_number >> 0) & 0xFF;
- p[1] = (seq_number >> 8) & 0xFF;
- p[2] = (seq_number >> 16) & 0xFF;
- p[3] = (seq_number >> 24) & 0xFF;
- memset (p + 4,
- (context_handle->more_flags & LOCAL) ? 0 : 0xFF,
- 4);
-
- des_set_key (&key, schedule);
- des_cbc_encrypt ((des_cblock *)p, (des_cblock *)p, 8,
- schedule, (des_cblock *)(p + 8), DES_ENCRYPT);
-
- krb5_auth_setlocalseqnumber (gssapi_krb5_context,
- context_handle->auth_context,
- ++seq_number);
-
- /* encrypt the data */
- p += 16;
-
- memset (&zero, 0, sizeof(zero));
-#if 0
- memcpy (&key, context_handle->auth_context->key.keyvalue.data,
- sizeof(key));
-#endif
- memcpy (&key, context_handle->auth_context->local_subkey->keyvalue.data,
- sizeof(key));
- for (i = 0; i < sizeof(key); ++i)
- key[i] ^= 0xf0;
- des_set_key (&key, schedule);
- des_cbc_encrypt ((des_cblock *)p,
- (des_cblock *)p,
- 8 + input_message_buffer->length + padlength,
- schedule,
- &zero,
- DES_ENCRYPT);
-
- memset (key, 0, sizeof(key));
- memset (schedule, 0, sizeof(schedule));
-
- return GSS_S_COMPLETE;
-}
diff --git a/lib/kafs/kafs.3 b/lib/kafs/kafs.3
deleted file mode 100644
index a7cdcd3d932cd3f1fcbb4e78e91131fb1c85640b..0000000000000000000000000000000000000000
--- a/lib/kafs/kafs.3
+++ /dev/null
@@ -1,143 +0,0 @@
-.\" $Id$
-.\"
-.Dd May 7, 1997
-.Os KTH-KRB
-.Dt KAFS 3
-.Sh NAME
-.Nm k_hasafs ,
-.Nm k_pioctl ,
-.Nm k_unlog ,
-.Nm k_setpag ,
-.Nm k_afs_cell_of_file ,
-.Nm krb_afslog ,
-.Nm krb_afslog_uid
-\" .Nm krb5_afslog ,
-\" .Nm krb5_afslog_uid
-.Nd AFS library
-.Sh SYNOPSIS
-.Fd #include <kafs.h>
-.Ft int
-.Fn k_afs_cell_of_file "const char *path" "char *cell" "int len"
-.Ft int
-.Fn k_hasafs
-.Ft int
-.Fn k_pioctl "char *a_path" "int o_opcode" "struct ViceIoctl *a_paramsP" "int a_followSymlinks"
-.Ft int
-.Fn k_setpag
-.Ft int
-.Fn k_unlog
-.Ft int
-.Fn krb_afslog "char *cell" "char *realm"
-.Ft int
-.Fn krb_afslog_uid "char *cell" "char *realm" "uid_t uid"
-\" .Ft krb5_error_code
-\" .Fn krb5_afslog_uid "krb5_context context" "krb5_ccache id" "const char *cell" "krb5_const_realm realm" "uid_t uid"
-\" .Ft krb5_error_code
-\" .Fn krb5_afslog "krb5_context context" "krb5_ccache id" "const char *cell" "krb5_const_realm realm"
-.Sh DESCRIPTION
-.Fn k_hasafs
-initializes some library internal structures, and tests for the
-presense of AFS in the kernel, none of the other functions should be
-called before
-.Fn k_hasafs
-is called, or if it fails.
-
-.Fn krb_afslog ,
-and
-.Fn krb_afslog_uid
-obtains new tokens (and possibly tickets) for the specified
-.Fa cell
-and
-.Fa realm .
-If
-.Fa cell
-is
-.Dv NULL ,
-the local cell is used. If
-.Fa realm
-is
-.Dv NULL ,
-the function tries to guess what realm to use. Unless you have some good knowledge of what cell or realm to use, you should pass
-.Dv NULL .
-.Fn krb_afslog
-will use the real user-id for the
-.Dv ViceId
-field in the token,
-.Fn krb_afslog_uid
-will use
-.Fa uid .
-
-\" .Fn krb5_afslog ,
-\" and
-\" .Fn krb5_afslog_uid
-\" are the Kerberos 5 equivalents of
-\" .Fn krb_afslog ,
-\" and
-\" .Fn krb_afslog_uid .
-\" The extra arguments are the ubiquitous context, and the cache id where
-\" to store any obtained tickets. Since AFS servers normally can't handle
-\" Kerberos 5 tickets directly, these functions will first obtain version
-\" 5 tickets for the requested cells, and then convert them to version 4
-\" tickets, that can be stashed in the kernel. To convert tickets the
-\" .Fn krb524_convert_creds_kdc
-\" function will be used.
-
-.Fn k_afs_cell_of_file
-will in
-.Fa cell
-return the cell of a specified file, no more than
-.Fa len
-characters is put in
-.Fa cell .
-
-.Fn k_pioctl
-does a
-.Fn pioctl
-syscall with the specified arguments. This function is equivalent to
-.Fn lpioctl .
-
-.Fn k_setpag
-initializes a new PAG.
-
-.Fn k_unlog
-removes destroys all tokens in the current PAG.
-
-.Sh RETURN VALUES
-.Fn k_hasafs
-returns 1 if AFS is present in the kernel, 0 otherwise.
-.Fn krb_afslog
-and
-.Fn krb_afslog_uid
-returns 0 on success, or a kerberos error number on failure.
-.Fn k_afs_cell_of_file ,
-.Fn k_pioctl ,
-.Fn k_setpag ,
-and
-.Fn k_unlog
-all return the value of the underlaying system call, 0 on success.
-.Sh EXAMPLES
-The following code from
-.Nm login
-will obtain a new PAG and tokens for the local cell and the cell of
-the users home directory.
-.Bd -literal
-if (k_hasafs()) {
- char cell[64];
- k_setpag();
- if(k_afs_cell_of_file(pwd->pw_dir, cell, sizeof(cell)) == 0)
- krb_afslog(cell, NULL);
- krb_afslog(NULL, NULL);
-}
-.Ed
-.Sh ERRORS
-If any of these functions (appart from
-.Fn k_hasafs )
-is called without AFS beeing present in the kernel, the process will
-usually (depending on the operating system) receive a SIGSYS signal.
-.Sh SEE ALSO
-.Rs
-.%A Transarc Corporation
-.%J AFS-3 Programmer's Reference
-.%T File Server/Cache Manager Interface
-.%D 1991
-.Re
\ No newline at end of file
diff --git a/lib/krb5/heim_err.et b/lib/krb5/heim_err.et
deleted file mode 100644
index d94dc556b7bb15adf1f4adb80663cbd07a153744..0000000000000000000000000000000000000000
--- a/lib/krb5/heim_err.et
+++ /dev/null
@@ -1,15 +0,0 @@
-#
-# Error messages for the krb5 library
-#
-# This might look like a com_err file, but is not
-#
-id $Id$
-
-error_table heim
-
-prefix HEIM_ERR
-
-error_code LOG_PARSE, "Error parsing log destination"
-error_code V4_PRINC_NO_CONV, "Failed to convert v4 principal"
-
-end
diff --git a/lib/krb5/krb5_err.et b/lib/krb5/krb5_err.et
deleted file mode 100644
index f2b686f7aff7e10c6036cf23b0338a84297cdbe7..0000000000000000000000000000000000000000
--- a/lib/krb5/krb5_err.et
+++ /dev/null
@@ -1,213 +0,0 @@
-#
-# Error messages for the krb5 library
-#
-# This might look like a com_err file, but is not
-#
-id $Id$
-
-error_table krb5
-
-prefix KRB5KDC_ERR
-error_code NONE, "No error"
-error_code NAME_EXP, "Client's entry in database has expired"
-error_code SERVICE_EXP, "Server's entry in database has expired"
-error_code BAD_PVNO, "Requested protocol version not supported"
-error_code C_OLD_MAST_KVNO, "Client's key is encrypted in an old master key"
-error_code S_OLD_MAST_KVNO, "Server's key is encrypted in an old master key"
-error_code C_PRINCIPAL_UNKNOWN, "Client not found in Kerberos database"
-error_code S_PRINCIPAL_UNKNOWN, "Server not found in Kerberos database"
-error_code PRINCIPAL_NOT_UNIQUE,"Principal has multiple entries in Kerberos database"
-error_code NULL_KEY, "Client or server has a null key"
-error_code CANNOT_POSTDATE, "Ticket is ineligible for postdating"
-error_code NEVER_VALID, "Requested effective lifetime is negative or too short"
-error_code POLICY, "KDC policy rejects request"
-error_code BADOPTION, "KDC can't fulfill requested option"
-error_code ETYPE_NOSUPP, "KDC has no support for encryption type"
-error_code SUMTYPE_NOSUPP, "KDC has no support for checksum type"
-error_code PADATA_TYPE_NOSUPP, "KDC has no support for padata type"
-error_code TRTYPE_NOSUPP, "KDC has no support for transited type"
-error_code CLIENT_REVOKED, "Clients credentials have been revoked"
-error_code SERVICE_REVOKED, "Credentials for server have been revoked"
-error_code TGT_REVOKED, "TGT has been revoked"
-error_code CLIENT_NOTYET, "Client not yet valid - try again later"
-error_code SERVICE_NOTYET, "Server not yet valid - try again later"
-error_code KEY_EXPIRED, "Password has expired"
-error_code PREAUTH_FAILED, "Preauthentication failed"
-error_code PREAUTH_REQUIRED, "Additional pre-authentication required"
-error_code SERVER_NOMATCH, "Requested server and ticket don't match"
-
-# 27-30 are reserved
-index 31
-prefix KRB5KRB_AP_ERR
-error_code BAD_INTEGRITY, "Decrypt integrity check failed"
-error_code TKT_EXPIRED, "Ticket expired"
-error_code TKT_NYV, "Ticket not yet valid"
-error_code REPEAT, "Request is a replay"
-error_code NOT_US, "The ticket isn't for us"
-error_code BADMATCH, "Ticket/authenticator don't match"
-error_code SKEW, "Clock skew too great"
-error_code BADADDR, "Incorrect net address"
-error_code BADVERSION, "Protocol version mismatch"
-error_code MSG_TYPE, "Invalid message type"
-error_code MODIFIED, "Message stream modified"
-error_code BADORDER, "Message out of order"
-error_code ILL_CR_TKT, "Illegal cross-realm ticket"
-error_code BADKEYVER, "Key version is not available"
-error_code NOKEY, "Service key not available"
-error_code MUT_FAIL, "Mutual authentication failed"
-error_code BADDIRECTION, "Incorrect message direction"
-error_code METHOD, "Alternative authentication method required"
-error_code BADSEQ, "Incorrect sequence number in message"
-error_code INAPP_CKSUM, "Inappropriate type of checksum in message"
-
-# 51-59 are reserved
-index 60
-prefix KRB5KRB_ERR
-error_code GENERIC, "Generic error (see e-text)"
-error_code FIELD_TOOLONG, "Field is too long for this implementation"
-
-# 62-127 are reserved
-index 128
-prefix
-error_code KRB5_ERR_RCSID, "$Id$"
-
-error_code KRB5_LIBOS_BADLOCKFLAG, "Invalid flag for file lock mode"
-error_code KRB5_LIBOS_CANTREADPWD, "Cannot read password"
-error_code KRB5_LIBOS_BADPWDMATCH, "Password mismatch"
-error_code KRB5_LIBOS_PWDINTR, "Password read interrupted"
-
-error_code KRB5_PARSE_ILLCHAR, "Illegal character in component name"
-error_code KRB5_PARSE_MALFORMED, "Malformed representation of principal"
-
-error_code KRB5_CONFIG_CANTOPEN, "Can't open/find configuration file"
-error_code KRB5_CONFIG_BADFORMAT, "Improper format of configuration file"
-error_code KRB5_CONFIG_NOTENUFSPACE, "Insufficient space to return complete information"
-
-error_code KRB5_BADMSGTYPE, "Invalid message type specified for encoding"
-
-error_code KRB5_CC_BADNAME, "Credential cache name malformed"
-error_code KRB5_CC_UNKNOWN_TYPE, "Unknown credential cache type"
-error_code KRB5_CC_NOTFOUND, "Matching credential not found"
-error_code KRB5_CC_END, "End of credential cache reached"
-
-error_code KRB5_NO_TKT_SUPPLIED, "Request did not supply a ticket"
-
-error_code KRB5KRB_AP_WRONG_PRINC, "Wrong principal in request"
-error_code KRB5KRB_AP_ERR_TKT_INVALID, "Ticket has invalid flag set"
-
-error_code KRB5_PRINC_NOMATCH, "Requested principal and ticket don't match"
-error_code KRB5_KDCREP_MODIFIED, "KDC reply did not match expectations"
-error_code KRB5_KDCREP_SKEW, "Clock skew too great in KDC reply"
-error_code KRB5_IN_TKT_REALM_MISMATCH, "Client/server realm mismatch in initial ticket request"
-
-error_code KRB5_PROG_ETYPE_NOSUPP, "Program lacks support for encryption type"
-error_code KRB5_PROG_KEYTYPE_NOSUPP, "Program lacks support for key type"
-error_code KRB5_WRONG_ETYPE, "Requested encryption type not used in message"
-error_code KRB5_PROG_SUMTYPE_NOSUPP, "Program lacks support for checksum type"
-
-error_code KRB5_REALM_UNKNOWN, "Cannot find KDC for requested realm"
-error_code KRB5_SERVICE_UNKNOWN, "Kerberos service unknown"
-error_code KRB5_KDC_UNREACH, "Cannot contact any KDC for requested realm"
-error_code KRB5_NO_LOCALNAME, "No local name found for principal name"
-
-error_code KRB5_MUTUAL_FAILED, "Mutual authentication failed"
-
-# some of these should be combined/supplanted by system codes
-
-error_code KRB5_RC_TYPE_EXISTS, "Replay cache type is already registered"
-error_code KRB5_RC_MALLOC, "No more memory to allocate (in replay cache code)"
-error_code KRB5_RC_TYPE_NOTFOUND, "Replay cache type is unknown"
-error_code KRB5_RC_UNKNOWN, "Generic unknown RC error"
-error_code KRB5_RC_REPLAY, "Message is a replay"
-error_code KRB5_RC_IO, "Replay I/O operation failed XXX"
-error_code KRB5_RC_NOIO, "Replay cache type does not support non-volatile storage"
-error_code KRB5_RC_PARSE, "Replay cache name parse/format error"
-
-error_code KRB5_RC_IO_EOF, "End-of-file on replay cache I/O"
-error_code KRB5_RC_IO_MALLOC, "No more memory to allocate (in replay cache I/O code)"
-error_code KRB5_RC_IO_PERM, "Permission denied in replay cache code"
-error_code KRB5_RC_IO_IO, "I/O error in replay cache i/o code"
-error_code KRB5_RC_IO_UNKNOWN, "Generic unknown RC/IO error"
-error_code KRB5_RC_IO_SPACE, "Insufficient system space to store replay information"
-
-error_code KRB5_TRANS_CANTOPEN, "Can't open/find realm translation file"
-error_code KRB5_TRANS_BADFORMAT, "Improper format of realm translation file"
-
-error_code KRB5_LNAME_CANTOPEN, "Can't open/find lname translation database"
-error_code KRB5_LNAME_NOTRANS, "No translation available for requested principal"
-error_code KRB5_LNAME_BADFORMAT, "Improper format of translation database entry"
-
-error_code KRB5_CRYPTO_INTERNAL, "Cryptosystem internal error"
-
-error_code KRB5_KT_BADNAME, "Key table name malformed"
-error_code KRB5_KT_UNKNOWN_TYPE, "Unknown Key table type"
-error_code KRB5_KT_NOTFOUND, "Key table entry not found"
-error_code KRB5_KT_END, "End of key table reached"
-error_code KRB5_KT_NOWRITE, "Cannot write to specified key table"
-error_code KRB5_KT_IOERR, "Error writing to key table"
-
-error_code KRB5_NO_TKT_IN_RLM, "Cannot find ticket for requested realm"
-error_code KRB5DES_BAD_KEYPAR, "DES key has bad parity"
-error_code KRB5DES_WEAK_KEY, "DES key is a weak key"
-
-error_code KRB5_BAD_ENCTYPE, "Bad encryption type"
-error_code KRB5_BAD_KEYSIZE, "Key size is incompatible with encryption type"
-error_code KRB5_BAD_MSIZE, "Message size is incompatible with encryption type"
-
-error_code KRB5_CC_TYPE_EXISTS, "Credentials cache type is already registered."
-error_code KRB5_KT_TYPE_EXISTS, "Key table type is already registered."
-
-error_code KRB5_CC_IO, "Credentials cache I/O operation failed XXX"
-error_code KRB5_FCC_PERM, "Credentials cache file permissions incorrect"
-error_code KRB5_FCC_NOFILE, "No credentials cache file found"
-error_code KRB5_FCC_INTERNAL, "Internal file credentials cache error"
-error_code KRB5_CC_WRITE, "Error writing to credentials cache file"
-error_code KRB5_CC_NOMEM, "No more memory to allocate (in credentials cache code)"
-error_code KRB5_CC_FORMAT, "Bad format in credentials cache"
-
-# errors for dual tgt library calls
-error_code KRB5_INVALID_FLAGS, "Invalid KDC option combination (library internal error)"
-error_code KRB5_NO_2ND_TKT, "Request missing second ticket"
-
-error_code KRB5_NOCREDS_SUPPLIED, "No credentials supplied to library routine"
-
-# errors for sendauth (and recvauth)
-
-error_code KRB5_SENDAUTH_BADAUTHVERS, "Bad sendauth version was sent"
-error_code KRB5_SENDAUTH_BADAPPLVERS, "Bad application version was sent (via sendauth)"
-error_code KRB5_SENDAUTH_BADRESPONSE, "Bad response (during sendauth exchange)"
-error_code KRB5_SENDAUTH_REJECTED, "Server rejected authentication (during sendauth exchange)"
-
-# errors for preauthentication
-
-error_code KRB5_PREAUTH_BAD_TYPE, "Unsupported preauthentication type"
-error_code KRB5_PREAUTH_NO_KEY, "Required preauthentication key not supplied"
-error_code KRB5_PREAUTH_FAILED, "Generic preauthentication failure"
-
-# version number errors
-
-error_code KRB5_RCACHE_BADVNO, "Unsupported replay cache format version number"
-error_code KRB5_CCACHE_BADVNO, "Unsupported credentials cache format version number"
-error_code KRB5_KEYTAB_BADVNO, "Unsupported key table format version number"
-
-#
-#
-
-error_code KRB5_PROG_ATYPE_NOSUPP, "Program lacks support for address type"
-error_code KRB5_RC_REQUIRED, "Message replay detection requires rcache parameter"
-error_code KRB5_ERR_BAD_HOSTNAME, "Hostname cannot be canonicalized"
-error_code KRB5_ERR_HOST_REALM_UNKNOWN, "Cannot determine realm for host"
-error_code KRB5_SNAME_UNSUPP_NAMETYPE, "Conversion to service principal undefined for name type"
-
-error_code KRB5KRB_AP_ERR_V4_REPLY, "Initial Ticket response appears to be Version 4"
-error_code KRB5_REALM_CANT_RESOLVE, "Cannot resolve KDC for requested realm"
-error_code KRB5_TKT_NOT_FORWARDABLE, "Requesting ticket can't get forwardable tickets"
-error_code KRB5_FWD_BAD_PRINCIPAL, "Bad principal name while trying to forward credentials"
-
-error_code KRB5_GET_IN_TKT_LOOP, "Looping detected inside krb5_get_in_tkt"
-error_code KRB5_CONFIG_NODEFREALM, "Configuration file does not specify default realm"
-
-error_code KRB5_SAM_UNSUPPORTED, "Bad SAM flags in obtain_sam_padata"
-error_code KRB5_KT_NAME_TOOLONG, "Keytab name too long"
-
-end
diff --git a/lib/roken/err.hin b/lib/roken/err.hin
deleted file mode 100644
index 882835defeecc52debaffbd8f90b0f3b5b828480..0000000000000000000000000000000000000000
--- a/lib/roken/err.hin
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-#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 warnerr(int doerrno, const char *fmt, va_list ap)
- __attribute__ ((format (printf, 2, 0)));
-
-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/lib/roken/fnmatch.hin b/lib/roken/fnmatch.hin
deleted file mode 100644
index 95c91d600b646d4784c4ead28b6354bd05444cf8..0000000000000000000000000000000000000000
--- a/lib/roken/fnmatch.hin
+++ /dev/null
@@ -1,49 +0,0 @@
-/* $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/lib/roken/glob.c b/lib/roken/glob.c
deleted file mode 100644
index 8f19d7ca4dab176a0c7dff11708c28a2a4e56b69..0000000000000000000000000000000000000000
--- a/lib/roken/glob.c
+++ /dev/null
@@ -1,835 +0,0 @@
-/*
- * 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(3) -- a superset of the one defined in POSIX 1003.2.
- *
- * The [!...] convention to negate a range is supported (SysV, Posix, ksh).
- *
- * Optional extra services, controlled by flags not defined by POSIX:
- *
- * GLOB_QUOTE:
- * Escaping convention: \ inhibits any special meaning the following
- * character might have (except \ at end of string is retained).
- * GLOB_MAGCHAR:
- * Set in gl_flags if pattern contained a globbing character.
- * GLOB_NOMAGIC:
- * Same as GLOB_NOCHECK, but it will only append pattern if it did
- * not contain any magic characters. [Used in csh style globbing]
- * GLOB_ALTDIRFUNC:
- * Use alternately specified directory access functions.
- * GLOB_TILDE:
- * expand ~user/foo to the /home/dir/of/user/foo
- * GLOB_BRACE:
- * expand {1,2}{a,b} to 1a 1b 2a 2b
- * gl_matchc:
- * Number of matches in the current invocation of glob.
- */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-
-#ifdef HAVE_SYS_PARAM_H
-#include <sys/param.h>
-#endif
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_STAT_H
-#include <sys/stat.h>
-#endif
-
-#include <ctype.h>
-#ifdef HAVE_DIRENT_H
-#include <dirent.h>
-#endif
-#include <errno.h>
-#ifdef HAVE_PWD_H
-#include <pwd.h>
-#endif
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
-
-#include "glob.h"
-#include "roken.h"
-
-#define CHAR_DOLLAR '$'
-#define CHAR_DOT '.'
-#define CHAR_EOS '\0'
-#define CHAR_LBRACKET '['
-#define CHAR_NOT '!'
-#define CHAR_QUESTION '?'
-#define CHAR_QUOTE '\\'
-#define CHAR_RANGE '-'
-#define CHAR_RBRACKET ']'
-#define CHAR_SEP '/'
-#define CHAR_STAR '*'
-#define CHAR_TILDE '~'
-#define CHAR_UNDERSCORE '_'
-#define CHAR_LBRACE '{'
-#define CHAR_RBRACE '}'
-#define CHAR_SLASH '/'
-#define CHAR_COMMA ','
-
-#ifndef DEBUG
-
-#define M_QUOTE 0x8000
-#define M_PROTECT 0x4000
-#define M_MASK 0xffff
-#define M_ASCII 0x00ff
-
-typedef u_short Char;
-
-#else
-
-#define M_QUOTE 0x80
-#define M_PROTECT 0x40
-#define M_MASK 0xff
-#define M_ASCII 0x7f
-
-typedef char Char;
-
-#endif
-
-
-#define CHAR(c) ((Char)((c)&M_ASCII))
-#define META(c) ((Char)((c)|M_QUOTE))
-#define M_ALL META('*')
-#define M_END META(']')
-#define M_NOT META('!')
-#define M_ONE META('?')
-#define M_RNG META('-')
-#define M_SET META('[')
-#define ismeta(c) (((c)&M_QUOTE) != 0)
-
-
-static int compare (const void *, const void *);
-static void g_Ctoc (const Char *, char *);
-static int g_lstat (Char *, struct stat *, glob_t *);
-static DIR *g_opendir (Char *, glob_t *);
-static Char *g_strchr (Char *, int);
-#ifdef notdef
-static Char *g_strcat (Char *, const Char *);
-#endif
-static int g_stat (Char *, struct stat *, glob_t *);
-static int glob0 (const Char *, glob_t *);
-static int glob1 (Char *, glob_t *);
-static int glob2 (Char *, Char *, Char *, glob_t *);
-static int glob3 (Char *, Char *, Char *, Char *, glob_t *);
-static int globextend (const Char *, glob_t *);
-static const Char * globtilde (const Char *, Char *, glob_t *);
-static int globexp1 (const Char *, glob_t *);
-static int globexp2 (const Char *, const Char *, glob_t *, int *);
-static int match (Char *, Char *, Char *);
-#ifdef DEBUG
-static void qprintf (const char *, Char *);
-#endif
-
-int
-glob(const char *pattern,
- int flags,
- int (*errfunc)(const char *, int),
- glob_t *pglob)
-{
- const u_char *patnext;
- int c;
- Char *bufnext, *bufend, patbuf[MaxPathLen+1];
-
- patnext = (u_char *) pattern;
- if (!(flags & GLOB_APPEND)) {
- pglob->gl_pathc = 0;
- pglob->gl_pathv = NULL;
- if (!(flags & GLOB_DOOFFS))
- pglob->gl_offs = 0;
- }
- pglob->gl_flags = flags & ~GLOB_MAGCHAR;
- pglob->gl_errfunc = errfunc;
- pglob->gl_matchc = 0;
-
- bufnext = patbuf;
- bufend = bufnext + MaxPathLen;
- if (flags & GLOB_QUOTE) {
- /* Protect the quoted characters. */
- while (bufnext < bufend && (c = *patnext++) != CHAR_EOS)
- if (c == CHAR_QUOTE) {
- if ((c = *patnext++) == CHAR_EOS) {
- c = CHAR_QUOTE;
- --patnext;
- }
- *bufnext++ = c | M_PROTECT;
- }
- else
- *bufnext++ = c;
- }
- else
- while (bufnext < bufend && (c = *patnext++) != CHAR_EOS)
- *bufnext++ = c;
- *bufnext = CHAR_EOS;
-
- if (flags & GLOB_BRACE)
- return globexp1(patbuf, pglob);
- else
- return glob0(patbuf, pglob);
-}
-
-/*
- * Expand recursively a glob {} pattern. When there is no more expansion
- * invoke the standard globbing routine to glob the rest of the magic
- * characters
- */
-static int globexp1(const Char *pattern, glob_t *pglob)
-{
- const Char* ptr = pattern;
- int rv;
-
- /* Protect a single {}, for find(1), like csh */
- if (pattern[0] == CHAR_LBRACE && pattern[1] == CHAR_RBRACE && pattern[2] == CHAR_EOS)
- return glob0(pattern, pglob);
-
- while ((ptr = (const Char *) g_strchr((Char *) ptr, CHAR_LBRACE)) != NULL)
- if (!globexp2(ptr, pattern, pglob, &rv))
- return rv;
-
- return glob0(pattern, pglob);
-}
-
-
-/*
- * Recursive brace globbing helper. Tries to expand a single brace.
- * If it succeeds then it invokes globexp1 with the new pattern.
- * If it fails then it tries to glob the rest of the pattern and returns.
- */
-static int globexp2(const Char *ptr, const Char *pattern,
- glob_t *pglob, int *rv)
-{
- int i;
- Char *lm, *ls;
- const Char *pe, *pm, *pl;
- Char patbuf[MaxPathLen + 1];
-
- /* copy part up to the brace */
- for (lm = patbuf, pm = pattern; pm != ptr; *lm++ = *pm++)
- continue;
- ls = lm;
-
- /* Find the balanced brace */
- for (i = 0, pe = ++ptr; *pe; pe++)
- if (*pe == CHAR_LBRACKET) {
- /* Ignore everything between [] */
- for (pm = pe++; *pe != CHAR_RBRACKET && *pe != CHAR_EOS; pe++)
- continue;
- if (*pe == CHAR_EOS) {
- /*
- * We could not find a matching CHAR_RBRACKET.
- * Ignore and just look for CHAR_RBRACE
- */
- pe = pm;
- }
- }
- else if (*pe == CHAR_LBRACE)
- i++;
- else if (*pe == CHAR_RBRACE) {
- if (i == 0)
- break;
- i--;
- }
-
- /* Non matching braces; just glob the pattern */
- if (i != 0 || *pe == CHAR_EOS) {
- *rv = glob0(patbuf, pglob);
- return 0;
- }
-
- for (i = 0, pl = pm = ptr; pm <= pe; pm++)
- switch (*pm) {
- case CHAR_LBRACKET:
- /* Ignore everything between [] */
- for (pl = pm++; *pm != CHAR_RBRACKET && *pm != CHAR_EOS; pm++)
- continue;
- if (*pm == CHAR_EOS) {
- /*
- * We could not find a matching CHAR_RBRACKET.
- * Ignore and just look for CHAR_RBRACE
- */
- pm = pl;
- }
- break;
-
- case CHAR_LBRACE:
- i++;
- break;
-
- case CHAR_RBRACE:
- if (i) {
- i--;
- break;
- }
- /* FALLTHROUGH */
- case CHAR_COMMA:
- if (i && *pm == CHAR_COMMA)
- break;
- else {
- /* Append the current string */
- for (lm = ls; (pl < pm); *lm++ = *pl++)
- continue;
- /*
- * Append the rest of the pattern after the
- * closing brace
- */
- for (pl = pe + 1; (*lm++ = *pl++) != CHAR_EOS;)
- continue;
-
- /* Expand the current pattern */
-#ifdef DEBUG
- qprintf("globexp2:", patbuf);
-#endif
- *rv = globexp1(patbuf, pglob);
-
- /* move after the comma, to the next string */
- pl = pm + 1;
- }
- break;
-
- default:
- break;
- }
- *rv = 0;
- return 0;
-}
-
-
-
-/*
- * expand tilde from the passwd file.
- */
-static const Char *
-globtilde(const Char *pattern, Char *patbuf, glob_t *pglob)
-{
- struct passwd *pwd;
- char *h;
- const Char *p;
- Char *b;
-
- if (*pattern != CHAR_TILDE || !(pglob->gl_flags & GLOB_TILDE))
- return pattern;
-
- /* Copy up to the end of the string or / */
- for (p = pattern + 1, h = (char *) patbuf; *p && *p != CHAR_SLASH;
- *h++ = *p++)
- continue;
-
- *h = CHAR_EOS;
-
- if (((char *) patbuf)[0] == CHAR_EOS) {
- /*
- * handle a plain ~ or ~/ by expanding $HOME
- * first and then trying the password file
- */
- if ((h = getenv("HOME")) == NULL) {
- if ((pwd = k_getpwuid(getuid())) == NULL)
- return pattern;
- else
- h = pwd->pw_dir;
- }
- }
- else {
- /*
- * Expand a ~user
- */
- if ((pwd = k_getpwnam((char*) patbuf)) == NULL)
- return pattern;
- else
- h = pwd->pw_dir;
- }
-
- /* Copy the home directory */
- for (b = patbuf; *h; *b++ = *h++)
- continue;
-
- /* Append the rest of the pattern */
- while ((*b++ = *p++) != CHAR_EOS)
- continue;
-
- return patbuf;
-}
-
-
-/*
- * The main glob() routine: compiles the pattern (optionally processing
- * quotes), calls glob1() to do the real pattern matching, and finally
- * sorts the list (unless unsorted operation is requested). Returns 0
- * if things went well, nonzero if errors occurred. It is not an error
- * to find no matches.
- */
-static int
-glob0(const Char *pattern, glob_t *pglob)
-{
- const Char *qpatnext;
- int c, err, oldpathc;
- Char *bufnext, patbuf[MaxPathLen+1];
-
- qpatnext = globtilde(pattern, patbuf, pglob);
- oldpathc = pglob->gl_pathc;
- bufnext = patbuf;
-
- /* We don't need to check for buffer overflow any more. */
- while ((c = *qpatnext++) != CHAR_EOS) {
- switch (c) {
- case CHAR_LBRACKET:
- c = *qpatnext;
- if (c == CHAR_NOT)
- ++qpatnext;
- if (*qpatnext == CHAR_EOS ||
- g_strchr((Char *) qpatnext+1, CHAR_RBRACKET) == NULL) {
- *bufnext++ = CHAR_LBRACKET;
- if (c == CHAR_NOT)
- --qpatnext;
- break;
- }
- *bufnext++ = M_SET;
- if (c == CHAR_NOT)
- *bufnext++ = M_NOT;
- c = *qpatnext++;
- do {
- *bufnext++ = CHAR(c);
- if (*qpatnext == CHAR_RANGE &&
- (c = qpatnext[1]) != CHAR_RBRACKET) {
- *bufnext++ = M_RNG;
- *bufnext++ = CHAR(c);
- qpatnext += 2;
- }
- } while ((c = *qpatnext++) != CHAR_RBRACKET);
- pglob->gl_flags |= GLOB_MAGCHAR;
- *bufnext++ = M_END;
- break;
- case CHAR_QUESTION:
- pglob->gl_flags |= GLOB_MAGCHAR;
- *bufnext++ = M_ONE;
- break;
- case CHAR_STAR:
- pglob->gl_flags |= GLOB_MAGCHAR;
- /* collapse adjacent stars to one,
- * to avoid exponential behavior
- */
- if (bufnext == patbuf || bufnext[-1] != M_ALL)
- *bufnext++ = M_ALL;
- break;
- default:
- *bufnext++ = CHAR(c);
- break;
- }
- }
- *bufnext = CHAR_EOS;
-#ifdef DEBUG
- qprintf("glob0:", patbuf);
-#endif
-
- if ((err = glob1(patbuf, pglob)) != 0)
- return(err);
-
- /*
- * If there was no match we are going to append the pattern
- * if GLOB_NOCHECK was specified or if GLOB_NOMAGIC was specified
- * and the pattern did not contain any magic characters
- * GLOB_NOMAGIC is there just for compatibility with csh.
- */
- if (pglob->gl_pathc == oldpathc &&
- ((pglob->gl_flags & GLOB_NOCHECK) ||
- ((pglob->gl_flags & GLOB_NOMAGIC) &&
- !(pglob->gl_flags & GLOB_MAGCHAR))))
- return(globextend(pattern, pglob));
- else if (!(pglob->gl_flags & GLOB_NOSORT))
- qsort(pglob->gl_pathv + pglob->gl_offs + oldpathc,
- pglob->gl_pathc - oldpathc, sizeof(char *), compare);
- return(0);
-}
-
-static int
-compare(const void *p, const void *q)
-{
- return(strcmp(*(char **)p, *(char **)q));
-}
-
-static int
-glob1(Char *pattern, glob_t *pglob)
-{
- Char pathbuf[MaxPathLen+1];
-
- /* A null pathname is invalid -- POSIX 1003.1 sect. 2.4. */
- if (*pattern == CHAR_EOS)
- return(0);
- return(glob2(pathbuf, pathbuf, pattern, pglob));
-}
-
-/*
- * The functions glob2 and glob3 are mutually recursive; there is one level
- * of recursion for each segment in the pattern that contains one or more
- * meta characters.
- */
-
-#ifndef S_ISLNK
-#if defined(S_IFLNK) && defined(S_IFMT)
-#define S_ISLNK(mode) (((mode) & S_IFMT) == S_IFLNK)
-#else
-#define S_ISLNK(mode) 0
-#endif
-#endif
-
-static int
-glob2(Char *pathbuf, Char *pathend, Char *pattern, glob_t *pglob)
-{
- struct stat sb;
- Char *p, *q;
- int anymeta;
-
- /*
- * Loop over pattern segments until end of pattern or until
- * segment with meta character found.
- */
- for (anymeta = 0;;) {
- if (*pattern == CHAR_EOS) { /* End of pattern? */
- *pathend = CHAR_EOS;
- if (g_lstat(pathbuf, &sb, pglob))
- return(0);
-
- if (((pglob->gl_flags & GLOB_MARK) &&
- pathend[-1] != CHAR_SEP) && (S_ISDIR(sb.st_mode)
- || (S_ISLNK(sb.st_mode) &&
- (g_stat(pathbuf, &sb, pglob) == 0) &&
- S_ISDIR(sb.st_mode)))) {
- *pathend++ = CHAR_SEP;
- *pathend = CHAR_EOS;
- }
- ++pglob->gl_matchc;
- return(globextend(pathbuf, pglob));
- }
-
- /* Find end of next segment, copy tentatively to pathend. */
- q = pathend;
- p = pattern;
- while (*p != CHAR_EOS && *p != CHAR_SEP) {
- if (ismeta(*p))
- anymeta = 1;
- *q++ = *p++;
- }
-
- if (!anymeta) { /* No expansion, do next segment. */
- pathend = q;
- pattern = p;
- while (*pattern == CHAR_SEP)
- *pathend++ = *pattern++;
- } else /* Need expansion, recurse. */
- return(glob3(pathbuf, pathend, pattern, p, pglob));
- }
- /* CHAR_NOTREACHED */
-}
-
-static int
-glob3(Char *pathbuf, Char *pathend, Char *pattern, Char *restpattern,
- glob_t *pglob)
-{
- struct dirent *dp;
- DIR *dirp;
- int err;
- char buf[MaxPathLen];
-
- /*
- * The readdirfunc declaration can't be prototyped, because it is
- * assigned, below, to two functions which are prototyped in glob.h
- * and dirent.h as taking pointers to differently typed opaque
- * structures.
- */
- struct dirent *(*readdirfunc)(void *);
-
- *pathend = CHAR_EOS;
- errno = 0;
-
- if ((dirp = g_opendir(pathbuf, pglob)) == NULL) {
- /* TODO: don't call for ENOENT or ENOTDIR? */
- if (pglob->gl_errfunc) {
- g_Ctoc(pathbuf, buf);
- if (pglob->gl_errfunc(buf, errno) ||
- pglob->gl_flags & GLOB_ERR)
- return (GLOB_ABEND);
- }
- return(0);
- }
-
- err = 0;
-
- /* Search directory for matching names. */
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- readdirfunc = pglob->gl_readdir;
- else
- readdirfunc = (struct dirent *(*)(void *))readdir;
- while ((dp = (*readdirfunc)(dirp))) {
- u_char *sc;
- Char *dc;
-
- /* Initial CHAR_DOT must be matched literally. */
- if (dp->d_name[0] == CHAR_DOT && *pattern != CHAR_DOT)
- continue;
- for (sc = (u_char *) dp->d_name, dc = pathend;
- (*dc++ = *sc++) != CHAR_EOS;)
- continue;
- if (!match(pathend, pattern, restpattern)) {
- *pathend = CHAR_EOS;
- continue;
- }
- err = glob2(pathbuf, --dc, restpattern, pglob);
- if (err)
- break;
- }
-
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- (*pglob->gl_closedir)(dirp);
- else
- closedir(dirp);
- return(err);
-}
-
-
-/*
- * Extend the gl_pathv member of a glob_t structure to accomodate a new item,
- * add the new item, and update gl_pathc.
- *
- * This assumes the BSD realloc, which only copies the block when its size
- * crosses a power-of-two boundary; for v7 realloc, this would cause quadratic
- * behavior.
- *
- * Return 0 if new item added, error code if memory couldn't be allocated.
- *
- * Invariant of the glob_t structure:
- * Either gl_pathc is zero and gl_pathv is NULL; or gl_pathc > 0 and
- * gl_pathv points to (gl_offs + gl_pathc + 1) items.
- */
-static int
-globextend(const Char *path, glob_t *pglob)
-{
- char **pathv;
- int i;
- u_int newsize;
- char *copy;
- const Char *p;
-
- newsize = sizeof(*pathv) * (2 + pglob->gl_pathc + pglob->gl_offs);
- pathv = pglob->gl_pathv ?
- realloc(pglob->gl_pathv, newsize) :
- malloc(newsize);
- if (pathv == NULL)
- return(GLOB_NOSPACE);
-
- if (pglob->gl_pathv == NULL && pglob->gl_offs > 0) {
- /* first time around -- clear initial gl_offs items */
- pathv += pglob->gl_offs;
- for (i = pglob->gl_offs; --i >= 0; )
- *--pathv = NULL;
- }
- pglob->gl_pathv = pathv;
-
- for (p = path; *p++;)
- continue;
- if ((copy = malloc(p - path)) != NULL) {
- g_Ctoc(path, copy);
- pathv[pglob->gl_offs + pglob->gl_pathc++] = copy;
- }
- pathv[pglob->gl_offs + pglob->gl_pathc] = NULL;
- return(copy == NULL ? GLOB_NOSPACE : 0);
-}
-
-
-/*
- * pattern matching function for filenames. Each occurrence of the *
- * pattern causes a recursion level.
- */
-static int
-match(Char *name, Char *pat, Char *patend)
-{
- int ok, negate_range;
- Char c, k;
-
- while (pat < patend) {
- c = *pat++;
- switch (c & M_MASK) {
- case M_ALL:
- if (pat == patend)
- return(1);
- do
- if (match(name, pat, patend))
- return(1);
- while (*name++ != CHAR_EOS);
- return(0);
- case M_ONE:
- if (*name++ == CHAR_EOS)
- return(0);
- break;
- case M_SET:
- ok = 0;
- if ((k = *name++) == CHAR_EOS)
- return(0);
- if ((negate_range = ((*pat & M_MASK) == M_NOT)) != CHAR_EOS)
- ++pat;
- while (((c = *pat++) & M_MASK) != M_END)
- if ((*pat & M_MASK) == M_RNG) {
- if (c <= k && k <= pat[1])
- ok = 1;
- pat += 2;
- } else if (c == k)
- ok = 1;
- if (ok == negate_range)
- return(0);
- break;
- default:
- if (*name++ != c)
- return(0);
- break;
- }
- }
- return(*name == CHAR_EOS);
-}
-
-/* Free allocated data belonging to a glob_t structure. */
-void
-globfree(glob_t *pglob)
-{
- int i;
- char **pp;
-
- if (pglob->gl_pathv != NULL) {
- pp = pglob->gl_pathv + pglob->gl_offs;
- for (i = pglob->gl_pathc; i--; ++pp)
- if (*pp)
- free(*pp);
- free(pglob->gl_pathv);
- }
-}
-
-static DIR *
-g_opendir(Char *str, glob_t *pglob)
-{
- char buf[MaxPathLen];
-
- if (!*str)
- strcpy(buf, ".");
- else
- g_Ctoc(str, buf);
-
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- return((*pglob->gl_opendir)(buf));
-
- return(opendir(buf));
-}
-
-static int
-g_lstat(Char *fn, struct stat *sb, glob_t *pglob)
-{
- char buf[MaxPathLen];
-
- g_Ctoc(fn, buf);
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- return((*pglob->gl_lstat)(buf, sb));
- return(lstat(buf, sb));
-}
-
-static int
-g_stat(Char *fn, struct stat *sb, glob_t *pglob)
-{
- char buf[MaxPathLen];
-
- g_Ctoc(fn, buf);
- if (pglob->gl_flags & GLOB_ALTDIRFUNC)
- return((*pglob->gl_stat)(buf, sb));
- return(stat(buf, sb));
-}
-
-static Char *
-g_strchr(Char *str, int ch)
-{
- do {
- if (*str == ch)
- return (str);
- } while (*str++);
- return (NULL);
-}
-
-#ifdef notdef
-static Char *
-g_strcat(Char *dst, const Char *src)
-{
- Char *sdst = dst;
-
- while (*dst++)
- continue;
- --dst;
- while((*dst++ = *src++) != CHAR_EOS)
- continue;
-
- return (sdst);
-}
-#endif
-
-static void
-g_Ctoc(const Char *str, char *buf)
-{
- char *dc;
-
- for (dc = buf; (*dc++ = *str++) != CHAR_EOS;)
- continue;
-}
-
-#ifdef DEBUG
-static void
-qprintf(const Char *str, Char *s)
-{
- Char *p;
-
- printf("%s:\n", str);
- for (p = s; *p; p++)
- printf("%c", CHAR(*p));
- printf("\n");
- for (p = s; *p; p++)
- printf("%c", *p & M_PROTECT ? '"' : ' ');
- printf("\n");
- for (p = s; *p; p++)
- printf("%c", ismeta(*p) ? '_' : ' ');
- printf("\n");
-}
-#endif
diff --git a/lib/roken/glob.h b/lib/roken/glob.h
deleted file mode 100644
index bece48a89cd76a787f8824ec319bcd8da22a6773..0000000000000000000000000000000000000000
--- a/lib/roken/glob.h
+++ /dev/null
@@ -1,84 +0,0 @@
-/*
- * 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/lib/roken/glob.hin b/lib/roken/glob.hin
deleted file mode 100644
index bece48a89cd76a787f8824ec319bcd8da22a6773..0000000000000000000000000000000000000000
--- a/lib/roken/glob.hin
+++ /dev/null
@@ -1,84 +0,0 @@
-/*
- * 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/lib/roken/resolve.c b/lib/roken/resolve.c
deleted file mode 100644
index 7de157a648f9078274904af77c7613c42a3089e5..0000000000000000000000000000000000000000
--- a/lib/roken/resolve.c
+++ /dev/null
@@ -1,330 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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 "krb_locl.h"
-#include "resolve.h"
-
-RCSID("$Id$");
-
-#if defined(HAVE_RES_SEARCH) && defined(HAVE_DN_EXPAND)
-
-#define DECL(X) {#X, T_##X}
-
-static struct stot{
- char *name;
- int type;
-}stot[] = {
- DECL(A),
- DECL(NS),
- DECL(CNAME),
- DECL(PTR),
- DECL(MX),
- DECL(TXT),
- DECL(AFSDB),
- DECL(SRV),
- {NULL, 0}
-};
-
-static int
-string_to_type(const char *name)
-{
- struct stot *p = stot;
- for(p = stot; p->name; p++)
- if(strcasecmp(name, p->name) == 0)
- return p->type;
- return -1;
-}
-
-#if 0
-static char *
-type_to_string(int type)
-{
- struct stot *p = stot;
- for(p = stot; p->name; p++)
- if(type == p->type)
- return p->name;
- return NULL;
-}
-#endif
-
-void
-dns_free_data(struct dns_reply *r)
-{
- struct resource_record *rr;
- if(r->q.domain)
- free(r->q.domain);
- for(rr = r->head; rr;){
- struct resource_record *tmp = rr;
- if(rr->domain)
- free(rr->domain);
- if(rr->u.data)
- free(rr->u.data);
- rr = rr->next;
- free(tmp);
- }
- free (r);
-}
-
-static struct dns_reply*
-parse_reply(unsigned char *data, int len)
-{
- unsigned char *p;
- char host[128];
- int status;
-
- struct dns_reply *r;
- struct resource_record **rr;
-
- r = (struct dns_reply*)malloc(sizeof(struct dns_reply));
- if (r == NULL)
- return NULL;
- memset(r, 0, sizeof(struct dns_reply));
-
- p = data;
- memcpy(&r->h, p, sizeof(HEADER));
- p += sizeof(HEADER);
- status = dn_expand(data, data + len, p, host, sizeof(host));
- if(status < 0){
- dns_free_data(r);
- return NULL;
- }
- r->q.domain = strdup(host);
- if(r->q.domain == NULL) {
- dns_free_data(r);
- return NULL;
- }
- p += status;
- r->q.type = (p[0] << 8 | p[1]);
- p += 2;
- r->q.class = (p[0] << 8 | p[1]);
- p += 2;
- rr = &r->head;
- while(p < data + len){
- int type, class, ttl, size;
- status = dn_expand(data, data + len, p, host, sizeof(host));
- if(status < 0){
- dns_free_data(r);
- return NULL;
- }
- p += status;
- type = (p[0] << 8) | p[1];
- p += 2;
- class = (p[0] << 8) | p[1];
- p += 2;
- ttl = (p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3];
- p += 4;
- size = (p[0] << 8) | p[1];
- p += 2;
- *rr = (struct resource_record*)calloc(1,
- sizeof(struct resource_record));
- if(*rr == NULL) {
- dns_free_data(r);
- return NULL;
- }
- (*rr)->domain = strdup(host);
- if((*rr)->domain == NULL) {
- dns_free_data(r);
- return NULL;
- }
- (*rr)->type = type;
- (*rr)->class = class;
- (*rr)->ttl = ttl;
- (*rr)->size = size;
- switch(type){
- case T_NS:
- case T_CNAME:
- case T_PTR:
- status = dn_expand(data, data + len, p, host, sizeof(host));
- if(status < 0){
- dns_free_data(r);
- return NULL;
- }
- (*rr)->u.txt = strdup(host);
- if((*rr)->u.txt == NULL) {
- dns_free_data(r);
- return NULL;
- }
- break;
- case T_MX:
- case T_AFSDB:{
- status = dn_expand(data, data + len, p + 2, host, sizeof(host));
- if(status < 0){
- dns_free_data(r);
- return NULL;
- }
- (*rr)->u.mx = (struct mx_record*)malloc(sizeof(struct mx_record) +
- strlen(host));
- if((*rr)->u.mx == NULL) {
- dns_free_data(r);
- return NULL;
- }
- (*rr)->u.mx->preference = (p[0] << 8) | p[1];
- strcpy((*rr)->u.mx->domain, host);
- break;
- }
- case T_SRV:{
- status = dn_expand(data, data + len, p + 6, host, sizeof(host));
- if(status < 0){
- dns_free_data(r);
- return NULL;
- }
- (*rr)->u.srv =
- (struct srv_record*)malloc(sizeof(struct srv_record) +
- strlen(host));
- if((*rr)->u.srv == NULL) {
- dns_free_data(r);
- return NULL;
- }
- (*rr)->u.srv->priority = (p[0] << 8) | p[1];
- (*rr)->u.srv->weight = (p[2] << 8) | p[3];
- (*rr)->u.srv->port = (p[4] << 8) | p[5];
- strcpy((*rr)->u.srv->target, host);
- break;
- }
- case T_TXT:{
- (*rr)->u.txt = (char*)malloc(size + 1);
- if((*rr)->u.txt == NULL) {
- dns_free_data(r);
- return NULL;
- }
- strncpy((*rr)->u.txt, (char*)p + 1, *p);
- (*rr)->u.txt[*p] = 0;
- break;
- }
-
- default:
- (*rr)->u.data = (unsigned char*)malloc(size);
- if((*rr)->u.data == NULL) {
- dns_free_data(r);
- return NULL;
- }
- memcpy((*rr)->u.data, p, size);
- }
- p += size;
- rr = &(*rr)->next;
- }
- *rr = NULL;
- return r;
-}
-
-struct dns_reply *
-dns_lookup(const char *domain, const char *type_name)
-{
- unsigned char reply[1024];
- int len;
- int type;
- struct dns_reply *r = NULL;
- u_long old_options = 0;
-
- type = string_to_type(type_name);
- if (krb_dns_debug) {
- old_options = _res.options;
- _res.options |= RES_DEBUG;
- krb_warning("dns_lookup(%s, %s)\n", domain, type_name);
- }
- len = res_search(domain, C_IN, type, reply, sizeof(reply));
- if (krb_dns_debug) {
- _res.options = old_options;
- krb_warning("dns_lookup(%s, %s) --> %d\n", domain, type_name, len);
- }
- if (len >= 0)
- r = parse_reply(reply, len);
- return r;
-}
-
-#else /* NOT defined(HAVE_RES_SEARCH) && defined(HAVE_DN_EXPAND) */
-
-struct dns_reply *
-dns_lookup(const char *domain, const char *type_name)
-{
- return NULL;
-}
-
-void
-dns_free_data(struct dns_reply *r)
-{
-}
-
-#endif
-
-#ifdef TEST
-
-int
-main(int argc, char **argv)
-{
- struct dns_reply *r;
- struct resource_record *rr;
- r = dns_lookup(argv[1], argv[2]);
- if(r == NULL){
- printf("No reply.\n");
- return 1;
- }
- for(rr = r->head; rr;rr=rr->next){
- printf("%s %s %d ", rr->domain, type_to_string(rr->type), rr->ttl);
- switch(rr->type){
- case T_NS:
- printf("%s\n", (char*)rr->data);
- break;
- case T_A:
- printf("%d.%d.%d.%d\n",
- ((unsigned char*)rr->data)[0],
- ((unsigned char*)rr->data)[1],
- ((unsigned char*)rr->data)[2],
- ((unsigned char*)rr->data)[3]);
- break;
- case T_MX:
- case T_AFSDB:{
- struct mx_record *mx = (struct mx_record*)rr->data;
- printf("%d %s\n", mx->preference, mx->domain);
- break;
- }
- case T_SRV:{
- struct srv_record *srv = (struct srv_record*)rr->data;
- printf("%d %d %d %s\n", srv->priority, srv->weight,
- srv->port, srv->target);
- break;
- }
- default:
- printf("\n");
- break;
- }
- }
-
- return 0;
-}
-#endif
diff --git a/lib/roken/resolve.h b/lib/roken/resolve.h
deleted file mode 100644
index ecacc5d9cbcb7ddc3e2fe9e1036bbb2e0908bbd1..0000000000000000000000000000000000000000
--- a/lib/roken/resolve.h
+++ /dev/null
@@ -1,110 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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$ */
-
-/* THIS IS NOT (yet) A PUBLIC INTERFACE */
-
-
-#ifndef __RESOLVE_H__
-#define __RESOLVE_H__
-
-/* We use these, but they are not always present in <arpa/nameser.h> */
-
-#ifndef T_TXT
-#define T_TXT 16
-#endif
-#ifndef T_AFSDB
-#define T_AFSDB 18
-#endif
-#ifndef T_SRV
-#define T_SRV 33
-#endif
-
-struct dns_query{
- char *domain;
- unsigned type;
- unsigned class;
-};
-
-struct mx_record{
- unsigned preference;
- char domain[1];
-};
-
-struct srv_record{
- unsigned priority;
- unsigned weight;
- unsigned port;
- char target[1];
-};
-
-struct resource_record{
- char *domain;
- unsigned type;
- unsigned class;
- unsigned ttl;
- unsigned size;
- union {
- void *data;
- struct mx_record *mx;
- struct mx_record *afsdb; /* mx and afsdb are identical */
- struct srv_record *srv;
- struct in_addr *a;
- char *txt;
- }u;
- struct resource_record *next;
-};
-
-
-#ifndef HAVE_ARPA_NAMESER_H /* XXX */
-typedef int HEADER; /* will never be used */
-#endif
-
-struct dns_reply{
- HEADER h;
- struct dns_query q;
- struct resource_record *head;
-};
-
-
-struct dns_reply* dns_lookup(const char *, const char *);
-
-void dns_free_data(struct dns_reply *r);
-
-#endif /* __RESOLVE_H__ */
diff --git a/lib/roken/strlcpy.c b/lib/roken/strlcpy.c
deleted file mode 100644
index 9f2a9e671a44905e2bcbd6ec6abc3ca6e09a6a57..0000000000000000000000000000000000000000
--- a/lib/roken/strlcpy.c
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 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. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * This product includes software developed by the Kungliga Tekniska
- * Högskolan and its contributors.
- *
- * 4. 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>
-#endif
-#include "roken.h"
-
-RCSID("$Id$");
-
-int
-strcpy_truncate (char *dst, const char *src, size_t dst_sz)
-{
- int n;
- char *p;
-
- for (p = dst, n = 0;
- n + 1 < dst_sz && *src != '\0';
- ++p, ++src, ++n)
- *p = *src;
- *p = '\0';
- if (*src == '\0')
- return n;
- else
- return dst_sz;
-}