New upstream version 2.1.26
Ondřej Surý
10 years ago
| 0 | 0 | Rob Siemborski <rjs3+@andrew.cmu.edu> wrote and tested the conversion |
| 1 | 1 | to the SASLv2 API. |
| 2 | 2 | |
| 3 | Ken Murchison <ken@oceana.com> worked on the OTP, NTLM, SRP and SQL | |
| 4 | plugins, as well as helping to track down bugs as they appear. | |
| 3 | Ken Murchison <murch@andrew.cmu.edu> worked on the OTP, NTLM, SRP and SQL | |
| 4 | plugins, as well as helping to track down bugs as they appear. He also | |
| 5 | added support for HTTP authentication. | |
| 5 | 6 | |
| 6 | 7 | Rob Earhart <earhart@cmu.edu> wrote the build/installation procedure, |
| 7 | 8 | wrote and tested some of the code, and provided general guidance and |
| 32 | 33 | |
| 33 | 34 | Larry Greenfield <leg+sasl@andrew.cmu.edu> complained. a lot. |
| 34 | 35 | |
| 35 | Chris Newman <chris.newman@sun.com> wrote the initial version of the | |
| 36 | Chris Newman <chris.newman@oracle.com> wrote the initial version of the | |
| 36 | 37 | SASL API, as well as the version 2 SASL API (documented in sasl.h, |
| 37 | 38 | saslutil.h, saslplug.h, and prop.h). |
| 38 | 39 | |
| 0 | 2012-10-12 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 1 | * Getting ready for 2.1.25. | |
| 2 | ||
| 3 | 2012-07-06 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 4 | * saslauthd/auth_krb5.c: Fixed a crash in the auth_krb5.c | |
| 5 | (bug # 2706). Patch by Nalin Dahyabhai. | |
| 6 | ||
| 7 | 2012-07-03 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 8 | * config/ltconfig: Fixed incorrect Darwin version matching in ltconfig | |
| 9 | (bug # 3713). Patch by Joshua Root. | |
| 10 | ||
| 11 | 2012-06-08 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 12 | * Fixed PLAIN/LOGIN authentication failure when using saslauthd | |
| 13 | with no auxprop plugins (bug # 3590). | |
| 14 | ||
| 15 | 2012-06-08 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 16 | * Added generation of pkg-config .pc file for Cyrus SASL. | |
| 17 | Patch by Dilyan Palauzov. | |
| 18 | ||
| 19 | 2012-06-03 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 20 | * Correctly updated libtool version for libsasl and its plugins due | |
| 21 | to ABI changes (bug # 3692). | |
| 22 | ||
| 23 | 2012-06-02 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 24 | * Better error reporting from auth_getpwent.c/auth_shadow.c | |
| 25 | (bug # 3134). Based on a patch by Greg A. Woods. | |
| 26 | ||
| 27 | 2012-06-02 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 28 | * Improved error logging on failure to load plugins. | |
| 29 | Patch by Greg A. Woods. | |
| 30 | ||
| 31 | 2012-05-30 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 32 | * plugins/otp.c, plugins/srp.c: Removed calling of EVP_cleanup() | |
| 33 | on SRP/OTP plugin shutdown | |
| 34 | ||
| 35 | 2012-05-30 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 36 | * saslauthd/auth_httpform.c: Encode the parameter values passed to | |
| 37 | auth_httpform, not the whole POST data. | |
| 38 | ||
| 39 | 2012-05-30 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 40 | * lib/config.c, saslauthd/cfile.c: Fixed file descriptor leaks | |
| 41 | throughout the code (bug # 3702). Slightly reformatted patch | |
| 42 | by Manfred Weichel. | |
| 43 | ||
| 44 | 2012-05-29 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 45 | * bug in "saslauthd -a rimap" - not reading the whole IMAP greeting | |
| 46 | (bug # 3211). Patch from Lutz Mark (via Red Hat) | |
| 47 | ||
| 48 | 2012-05-29 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 49 | * Modernize SASL malloc/realloc callback prototypes | |
| 50 | ||
| 51 | 2012-05-29 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 52 | * lib/saslutil.c: Fixed broken logic in get_fqhostname() when | |
| 53 | abort_if_no_fqdn is 0 (bug # 3589). Patch by baggins@pld-linux.org | |
| 54 | ||
| 55 | 2012-05-28 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 56 | * sasldb/db_berkeley.c, utils/dbconverter-2.c: Added support for | |
| 57 | BerkleyDB 5.X or later (Patch by Howard Chu) | |
| 58 | ||
| 59 | 2012-04-20 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 60 | * lib/client.c, lib/server.c, lib/saslint.h: Make server and client | |
| 61 | side global callbacks private to server.c/client.c respectively | |
| 62 | ||
| 63 | 2012-02-10 Ken Murchison <murch@andrew.cmu.edu> | |
| 64 | * plugins/digestmd5.c: better handling of HTTP reauth cases. | |
| 65 | ||
| 66 | 2012-01-28 Ken Murchison <murch@andrew.cmu.edu> | |
| 67 | * plugins/digestmd5.c: Correctly send "stale" directive to prevent | |
| 68 | clients from (re)promtping for password | |
| 69 | ||
| 70 | 2011-11-25 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 71 | * plugins/gs2.c: Updated GS2 plugin not to lose minor GSS-API | |
| 72 | status codes on errors (based on a patch from Ralf Haferkamp | |
| 73 | <rhafer@suse.de>) | |
| 74 | ||
| 75 | 2011-11-21 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 76 | * plugins/gssapi.c: Only check out_flags once authentication is | |
| 77 | successfully completed | |
| 78 | ||
| 79 | 2011-11-09 Ken Murchison <murch@andrew.cmu.edu> | |
| 80 | * cmulocal/sasl2.m4, plugins/gssapi.c, utils/testsuite.c: | |
| 81 | Added GSS-SPNEGO plugin which can also be used for HTTP | |
| 82 | Negotiate authentication (RFC 4559) | |
| 83 | ||
| 84 | 2011-11-08 Ken Murchison <murch@andrew.cmu.edu> | |
| 85 | * plugins/ntlm.c: Flag client-side of NTLM plugin as HTTP-ready | |
| 86 | ||
| 87 | 2011-11-08 Ken Murchison <murch@andrew.cmu.edu> | |
| 88 | * include/saslutil.h, lib/config.c, lib/server.c | |
| 89 | Added sasl_config_done() to plug a memory leak when using an | |
| 90 | application specific config file | |
| 91 | ||
| 92 | 2011-10-07 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 93 | * plugins/gssapi.c: Fixed a segfault in gssapi.c | |
| 94 | (patch by Phil Pennock) | |
| 95 | ||
| 96 | 2011-09-22 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 97 | * config/ltconfig, saslauthd/config/ltconfig: Fixed Cyrus SASL | |
| 98 | build on some versions of Mac OS. | |
| 99 | ||
| 100 | 2011-09-22 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 101 | * saslauthd/auth_rimap.c: qstring incorrectly appending | |
| 102 | the closing double quote. (Merge from RedHat) | |
| 103 | ||
| 104 | 2011-09-22 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 105 | * lib/common.c: unlock the mutex in sasl_dispose if the context | |
| 106 | was freed by another thread. (Merge from RedHat) | |
| 107 | ||
| 108 | 2011-09-22 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 109 | * Makefile.am: "lib" should be built before "plugins" | |
| 110 | (Patch from marcandre.lureau@redhat.com) | |
| 111 | ||
| 112 | 2011-09-22 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 113 | * lib/saslutil.c: MINGW32 doesn't have rand_s | |
| 114 | (Patch from marcandre.lureau@redhat.com) | |
| 115 | ||
| 116 | 2011-09-22 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 117 | * configure.in: Various build fixes for MINGW32 | |
| 118 | (including defining sleep()) | |
| 119 | (Patch from marcandre.lureau@redhat.com) | |
| 120 | ||
| 121 | 2011-09-15 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 122 | * sample/client.c: Added additional typecasts to kill warnings | |
| 123 | about incompatible callback types | |
| 124 | ||
| 125 | 2011-09-13 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 126 | * configure.in, config/ltconfig, config/ltmain.sh: | |
| 127 | MacOS X related build fixes: use .plugin when building | |
| 128 | SASL plugins, fixed version number calculation, | |
| 129 | don't generate multiple symlinks. | |
| 130 | Also use LD_RUN_PATH as rpath. (patches by Chris Ridd) | |
| 131 | ||
| 132 | 2011-09-12 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 133 | * win32/common.mak: Add _CRT_SECURE_NO_DEPRECATE define | |
| 134 | to suppress warnings about use of strdup, snprintf, etc. | |
| 135 | ||
| 136 | 2011-09-12 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 137 | * sasldb/db_berkeley.c: | |
| 138 | Fixed warnings about incompatible callback types. | |
| 139 | ||
| 140 | 2011-09-12 Alexey Melnikov <alexey.melnikov@isode.com> | |
| 141 | * lib/NTMakefile plugins/NTMakefile: | |
| 142 | Make sure that copied .c files are only rebuilt when changed. | |
| 143 | ||
| 0 | 144 | 2011-09-07 Ken Murchison <murch@andrew.cmu.edu> |
| 1 | 145 | * plugins/scram.c: |
| 2 | Fixed 3 memory leaks in SCRAM | |
| 146 | Fixed 3 memory leaks in SCRAM. Final 2.1.25. | |
| 3 | 147 | |
| 4 | 148 | 2011-09-07 Alexey Melnikov <alexey.melnikov@isode.com> |
| 5 | 149 | * configure.in, plugins/NTMakefile, plugins/cram.c: |
| 6 | 150 | Allow use of cmusaslsecretCRAM-MD5 property to be disabled. |
| 7 | 151 | |
| 8 | 152 | 2011-09-02 Alexey Melnikov <alexey.melnikov@isode.com> |
| 9 | * config/config.guess, config/config.sub, saslauthd/config/config.guess, | |
| 10 | saslauthd/config/config.sub: Updated config to the latest GNU snapshot. | |
| 153 | * config/config.guess, config/config.sub, | |
| 154 | saslauthd/config/config.guess, saslauthd/config/config.sub: | |
| 155 | Updated config to the latest GNU snapshot. | |
| 11 | 156 | |
| 12 | 157 | 2011-09-01 Alexey Melnikov <alexey.melnikov@isode.com> |
| 13 | 158 | * lib/server.c: Make sure that a failed authorization doesn't preclude |
| 68 | 68 | INSTALLOSX = |
| 69 | 69 | endif |
| 70 | 70 | |
| 71 | SUBDIRS=include sasldb plugins lib utils doc man $(PWC) $(SAM) $(JAV) $(SAD) | |
| 72 | EXTRA_DIST=config cmulocal win32 mac dlcompat-20010505 NTMakefile INSTALL.TXT | |
| 71 | SUBDIRS=include sasldb lib plugins utils doc man $(PWC) $(SAM) $(JAV) $(SAD) | |
| 72 | EXTRA_DIST=config cmulocal win32 mac dlcompat-20010505 NTMakefile INSTALL.TXT \ | |
| 73 | libsasl2.pc.in | |
| 74 | ||
| 75 | pkgconfigdir = $(libdir)/pkgconfig | |
| 76 | pkgconfig_DATA = libsasl2.pc | |
| 73 | 77 | |
| 74 | 78 | dist-hook: |
| 75 | 79 | @find $(distdir) -exec chmod o+w {} ';' |
| 13 | 13 | # PARTICULAR PURPOSE. |
| 14 | 14 | |
| 15 | 15 | @SET_MAKE@ |
| 16 | ||
| 16 | 17 | VPATH = @srcdir@ |
| 17 | 18 | pkgdatadir = $(datadir)/@PACKAGE@ |
| 18 | 19 | pkgincludedir = $(includedir)/@PACKAGE@ |
| 36 | 37 | subdir = . |
| 37 | 38 | DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \ |
| 38 | 39 | $(srcdir)/Makefile.in $(srcdir)/config.h.in \ |
| 39 | $(top_srcdir)/configure AUTHORS COPYING ChangeLog INSTALL NEWS \ | |
| 40 | config/config.guess config/config.sub config/depcomp \ | |
| 41 | config/install-sh config/ltconfig config/ltmain.sh \ | |
| 42 | config/missing config/mkinstalldirs | |
| 40 | $(srcdir)/libsasl2.pc.in $(top_srcdir)/configure AUTHORS \ | |
| 41 | COPYING ChangeLog INSTALL NEWS config/config.guess \ | |
| 42 | config/config.sub config/depcomp config/install-sh \ | |
| 43 | config/ltconfig config/ltmain.sh config/missing \ | |
| 44 | config/mkinstalldirs | |
| 43 | 45 | ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 |
| 44 | 46 | am__aclocal_m4_deps = $(top_srcdir)/config/kerberos_v4.m4 \ |
| 45 | 47 | $(top_srcdir)/config/libtool.m4 $(top_srcdir)/config/plain.m4 \ |
| 60 | 62 | configure.lineno config.status.lineno |
| 61 | 63 | mkinstalldirs = $(SHELL) $(top_srcdir)/config/mkinstalldirs |
| 62 | 64 | CONFIG_HEADER = config.h |
| 63 | CONFIG_CLEAN_FILES = | |
| 65 | CONFIG_CLEAN_FILES = libsasl2.pc | |
| 64 | 66 | CONFIG_CLEAN_VPATH_FILES = |
| 65 | 67 | SOURCES = |
| 66 | 68 | DIST_SOURCES = |
| 71 | 73 | install-pdf-recursive install-ps-recursive install-recursive \ |
| 72 | 74 | installcheck-recursive installdirs-recursive pdf-recursive \ |
| 73 | 75 | ps-recursive uninstall-recursive |
| 76 | am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; | |
| 77 | am__vpath_adj = case $$p in \ | |
| 78 | $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \ | |
| 79 | *) f=$$p;; \ | |
| 80 | esac; | |
| 81 | am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`; | |
| 82 | am__install_max = 40 | |
| 83 | am__nobase_strip_setup = \ | |
| 84 | srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'` | |
| 85 | am__nobase_strip = \ | |
| 86 | for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||" | |
| 87 | am__nobase_list = $(am__nobase_strip_setup); \ | |
| 88 | for p in $$list; do echo "$$p $$p"; done | \ | |
| 89 | sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \ | |
| 90 | $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \ | |
| 91 | if (++n[$$2] == $(am__install_max)) \ | |
| 92 | { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \ | |
| 93 | END { for (dir in files) print dir, files[dir] }' | |
| 94 | am__base_list = \ | |
| 95 | sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \ | |
| 96 | sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | |
| 97 | am__installdirs = "$(DESTDIR)$(pkgconfigdir)" | |
| 98 | DATA = $(pkgconfig_DATA) | |
| 74 | 99 | RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive \ |
| 75 | 100 | distclean-recursive maintainer-clean-recursive |
| 76 | 101 | AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \ |
| 78 | 103 | distdir dist dist-all distcheck |
| 79 | 104 | ETAGS = etags |
| 80 | 105 | CTAGS = ctags |
| 81 | DIST_SUBDIRS = include sasldb plugins lib utils doc man pwcheck sample \ | |
| 106 | DIST_SUBDIRS = include sasldb lib plugins utils doc man pwcheck sample \ | |
| 82 | 107 | java saslauthd |
| 83 | 108 | DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) |
| 84 | 109 | distdir = $(PACKAGE)-$(VERSION) |
| 327 | 352 | @JAVA_TRUE@JAV = java |
| 328 | 353 | @MACOSX_FALSE@INSTALLOSX = |
| 329 | 354 | @MACOSX_TRUE@INSTALLOSX = install-exec-local-osx |
| 330 | SUBDIRS = include sasldb plugins lib utils doc man $(PWC) $(SAM) $(JAV) $(SAD) | |
| 331 | EXTRA_DIST = config cmulocal win32 mac dlcompat-20010505 NTMakefile INSTALL.TXT | |
| 355 | SUBDIRS = include sasldb lib plugins utils doc man $(PWC) $(SAM) $(JAV) $(SAD) | |
| 356 | EXTRA_DIST = config cmulocal win32 mac dlcompat-20010505 NTMakefile INSTALL.TXT \ | |
| 357 | libsasl2.pc.in | |
| 358 | ||
| 359 | pkgconfigdir = $(libdir)/pkgconfig | |
| 360 | pkgconfig_DATA = libsasl2.pc | |
| 332 | 361 | framedir = /Library/Frameworks/SASL2.framework |
| 333 | 362 | all: config.h |
| 334 | 363 | $(MAKE) $(AM_MAKEFLAGS) all-recursive |
| 385 | 414 | |
| 386 | 415 | distclean-hdr: |
| 387 | 416 | -rm -f config.h stamp-h1 |
| 417 | libsasl2.pc: $(top_builddir)/config.status $(srcdir)/libsasl2.pc.in | |
| 418 | cd $(top_builddir) && $(SHELL) ./config.status $@ | |
| 388 | 419 | |
| 389 | 420 | mostlyclean-libtool: |
| 390 | 421 | -rm -f *.lo |
| 394 | 425 | |
| 395 | 426 | distclean-libtool: |
| 396 | 427 | -rm -f libtool config.lt |
| 428 | install-pkgconfigDATA: $(pkgconfig_DATA) | |
| 429 | @$(NORMAL_INSTALL) | |
| 430 | test -z "$(pkgconfigdir)" || $(MKDIR_P) "$(DESTDIR)$(pkgconfigdir)" | |
| 431 | @list='$(pkgconfig_DATA)'; test -n "$(pkgconfigdir)" || list=; \ | |
| 432 | for p in $$list; do \ | |
| 433 | if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ | |
| 434 | echo "$$d$$p"; \ | |
| 435 | done | $(am__base_list) | \ | |
| 436 | while read files; do \ | |
| 437 | echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(pkgconfigdir)'"; \ | |
| 438 | $(INSTALL_DATA) $$files "$(DESTDIR)$(pkgconfigdir)" || exit $$?; \ | |
| 439 | done | |
| 440 | ||
| 441 | uninstall-pkgconfigDATA: | |
| 442 | @$(NORMAL_UNINSTALL) | |
| 443 | @list='$(pkgconfig_DATA)'; test -n "$(pkgconfigdir)" || list=; \ | |
| 444 | files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \ | |
| 445 | test -n "$$files" || exit 0; \ | |
| 446 | echo " ( cd '$(DESTDIR)$(pkgconfigdir)' && rm -f" $$files ")"; \ | |
| 447 | cd "$(DESTDIR)$(pkgconfigdir)" && rm -f $$files | |
| 397 | 448 | |
| 398 | 449 | # This directory's subdirectories are mostly independent; you can cd |
| 399 | 450 | # into them and run `make' without going through this Makefile. |
| 709 | 760 | exit 1; } >&2 |
| 710 | 761 | check-am: all-am |
| 711 | 762 | check: check-recursive |
| 712 | all-am: Makefile config.h | |
| 763 | all-am: Makefile $(DATA) config.h | |
| 713 | 764 | installdirs: installdirs-recursive |
| 714 | 765 | installdirs-am: |
| 766 | for dir in "$(DESTDIR)$(pkgconfigdir)"; do \ | |
| 767 | test -z "$$dir" || $(MKDIR_P) "$$dir"; \ | |
| 768 | done | |
| 715 | 769 | install: install-recursive |
| 716 | 770 | install-exec: install-exec-recursive |
| 717 | 771 | install-data: install-data-recursive |
| 759 | 813 | |
| 760 | 814 | info-am: |
| 761 | 815 | |
| 762 | install-data-am: | |
| 816 | install-data-am: install-pkgconfigDATA | |
| 763 | 817 | |
| 764 | 818 | install-dvi: install-dvi-recursive |
| 765 | 819 | |
| 805 | 859 | |
| 806 | 860 | ps-am: |
| 807 | 861 | |
| 808 | uninstall-am: | |
| 862 | uninstall-am: uninstall-pkgconfigDATA | |
| 809 | 863 | |
| 810 | 864 | .MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) all \ |
| 811 | 865 | ctags-recursive install-am install-strip tags-recursive |
| 820 | 874 | install install-am install-data install-data-am install-dvi \ |
| 821 | 875 | install-dvi-am install-exec install-exec-am install-exec-local \ |
| 822 | 876 | install-html install-html-am install-info install-info-am \ |
| 823 | install-man install-pdf install-pdf-am install-ps \ | |
| 824 | install-ps-am install-strip installcheck installcheck-am \ | |
| 825 | installdirs installdirs-am maintainer-clean \ | |
| 877 | install-man install-pdf install-pdf-am install-pkgconfigDATA \ | |
| 878 | install-ps install-ps-am install-strip installcheck \ | |
| 879 | installcheck-am installdirs installdirs-am maintainer-clean \ | |
| 826 | 880 | maintainer-clean-generic mostlyclean mostlyclean-generic \ |
| 827 | 881 | mostlyclean-libtool pdf pdf-am ps ps-am tags tags-recursive \ |
| 828 | uninstall uninstall-am | |
| 882 | uninstall uninstall-am uninstall-pkgconfigDATA | |
| 829 | 883 | |
| 830 | 884 | |
| 831 | 885 | dist-hook: |
| 0 | New in 2.1.26 | |
| 1 | ------------- | |
| 2 | ||
| 3 | * Modernize SASL malloc/realloc callback prototypes | |
| 4 | * Added sasl_config_done() to plug a memory leak when using an application | |
| 5 | specific config file | |
| 6 | * Fixed PLAIN/LOGIN authentication failure when using saslauthd | |
| 7 | with no auxprop plugins (bug # 3590). | |
| 8 | * unlock the mutex in sasl_dispose if the context was freed by another thread | |
| 9 | * MINGW32 compatibility patches | |
| 10 | * Fixed broken logic in get_fqhostname() when abort_if_no_fqdn is 0 | |
| 11 | * Fixed some memory leaks in libsasl | |
| 12 | * GSSAPI plugin: | |
| 13 | - Fixed a segfault in gssapi.c introduced in 2.1.25. | |
| 14 | - Code refactoring | |
| 15 | - Added support for GSS-SPNEGO SASL mechanism (Unix only), which is also | |
| 16 | HTTP capable | |
| 17 | * GS2 plugin: | |
| 18 | - Updated GS2 plugin not to lose minor GSS-API status codes on errors | |
| 19 | * DIGEST-MD5 plugin: | |
| 20 | - Correctly send "stale" directive to prevent clients from (re)promtping | |
| 21 | for password | |
| 22 | - Better handling of HTTP reauthentication cases | |
| 23 | - fixed some memory leaks | |
| 24 | * SASLDB plugin: | |
| 25 | - Added support for BerkleyDB 5.X or later | |
| 26 | * OTP plugin: | |
| 27 | - Removed calling of EVP_cleanup() on plugin shutdown in order to prevent | |
| 28 | TLS from failing in calling applications | |
| 29 | * SRP plugin: | |
| 30 | - Removed calling of EVP_cleanup() on plugin shutdown in order to prevent | |
| 31 | TLS from failing in calling applications | |
| 32 | * saslauthd: | |
| 33 | - auth_rimap.c: qstring incorrectly appending the closing double quote, | |
| 34 | which might be causing crashes | |
| 35 | - auth_rimap.c: read the whole IMAP greeting | |
| 36 | - better error reporting from some drivers | |
| 37 | - fixed some memory leaks | |
| 38 | ||
| 0 | 39 | New in 2.1.25 |
| 1 | 40 | ------------- |
| 2 | 41 |
| 0 | $Id: README,v 1.33 2008/01/25 01:57:40 murch Exp $ | |
| 1 | ||
| 2 | 0 | This is the Cyrus SASL API implentation. It can be used on the client |
| 3 | 1 | or server side to provide authentication and authorization services. |
| 4 | 2 | See RFC 4422 for more information. |
| 15 | 13 | If you are looking to port SASLv1 applications to SASLv2, please see |
| 16 | 14 | doc/appconvert.html |
| 17 | 15 | |
| 18 | Bugs can be searched/reported at: http://bugzilla.andrew.cmu.edu | |
| 16 | Bugs can be searched/reported at: http://bugzilla.cyrussasl.org | |
| 19 | 17 | |
| 20 | 18 | DOCUMENTATION |
| 21 | 19 | -------------- |
| 405 | 405 | [AMDEP_TRUE="$AMDEP_TRUE" ac_aux_dir="$ac_aux_dir"]) |
| 406 | 406 | ]) |
| 407 | 407 | |
| 408 | # Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005 | |
| 409 | # Free Software Foundation, Inc. | |
| 410 | # | |
| 411 | # This file is free software; the Free Software Foundation | |
| 412 | # gives unlimited permission to copy and/or distribute it, | |
| 413 | # with or without modifications, as long as this notice is preserved. | |
| 414 | ||
| 415 | # serial 8 | |
| 416 | ||
| 417 | # AM_CONFIG_HEADER is obsolete. It has been replaced by AC_CONFIG_HEADERS. | |
| 418 | AU_DEFUN([AM_CONFIG_HEADER], [AC_CONFIG_HEADERS($@)]) | |
| 419 | ||
| 408 | 420 | # Do all the work for Automake. -*- Autoconf -*- |
| 409 | 421 | |
| 410 | 422 | # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, |
| 212 | 212 | fi |
| 213 | 213 | |
| 214 | 214 | saved_LIBS=$LIBS |
| 215 | for dbname in ${with_bdb} db-4.7 db4.7 db47 db-4.6 db4.6 db46 db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 db-4.2 db4.2 db42 db-4.1 db4.1 db41 db-4.0 db4.0 db-4 db40 db4 db-3.3 db3.3 db33 db-3.2 db3.2 db32 db-3.1 db3.1 db31 db-3 db30 db3 db | |
| 216 | do | |
| 215 | for dbname in ${with_bdb} \ | |
| 216 | db-5.2 db5.2 db52 \ | |
| 217 | db-5.1 db5.2 db51 \ | |
| 218 | db-5.0 db5.2 db50 \ | |
| 219 | db-4.8 db4.8 db48 \ | |
| 220 | db-4.7 db4.7 db47 \ | |
| 221 | db-4.6 db4.6 db46 \ | |
| 222 | db-4.5 db4.5 db45 \ | |
| 223 | db-4.4 db4.4 db44 \ | |
| 224 | db-4.3 db4.3 db43 \ | |
| 225 | db-4.2 db4.2 db42 \ | |
| 226 | db-4.1 db4.1 db41 \ | |
| 227 | db-4.0 db4.0 db40 db-4 db4 \ | |
| 228 | db-3.3 db3.3 db33 \ | |
| 229 | db-3.2 db3.2 db32 \ | |
| 230 | db-3.1 db3.1 db31 \ | |
| 231 | db-3.0 db3.0 db30 db-3 db3 \ | |
| 232 | db | |
| 233 | do | |
| 217 | 234 | LIBS="$saved_LIBS -l$dbname" |
| 218 | 235 | AC_TRY_LINK([#include <stdio.h> |
| 219 | 236 | #include <db.h>], |
| 0 | dnl These are the Cyrus OpenDKIM macros. | |
| 1 | ||
| 2 | dnl They are here so that they can be shared between Cyrus IMAPd | |
| 3 | dnl and Cyrus SASL with relative ease. | |
| 4 | ||
| 5 | dnl When we're done, there will be a DKIM_CFLAGS and a DKIM_LIBS which | |
| 6 | dnl should be used when necessary. | |
| 7 | dnl We should probably be smarter about our RPATH dnl handling. | |
| 8 | ||
| 9 | dnl Call these with CYRUS_SQLITE_CHK. | |
| 10 | ||
| 11 | dnl We will also set $opendkimlib to "yes" if we are successful, "no" otherwise. | |
| 12 | ||
| 13 | AC_DEFUN([CYRUS_OPENDKIM_CHK_LIB], | |
| 14 | [ | |
| 15 | OPENDKIM_SAVE_LDFLAGS=$LDFLAGS | |
| 16 | ||
| 17 | if test -d $with_opendkim_lib; then | |
| 18 | CMU_ADD_LIBPATH_TO($with_opendkim_lib, LDFLAGS) | |
| 19 | CMU_ADD_LIBPATH_TO($with_opendkim_lib, OPENDKIM_LIBADD) | |
| 20 | else | |
| 21 | DKIM_LIBS="" | |
| 22 | fi | |
| 23 | ||
| 24 | saved_LIBS=$LIBS | |
| 25 | for libname in ${with_opendkim} opendkim | |
| 26 | do | |
| 27 | LIBS="$saved_LIBS -l$libname" | |
| 28 | AC_TRY_LINK([#include <stdio.h> | |
| 29 | #include <dkim.h>], | |
| 30 | [dkim_init(NULL, NULL);], | |
| 31 | DKIM_LIBS="$DKIM_LIBS -l$libname"; opendkimlib="yes", | |
| 32 | opendkimlib="no") | |
| 33 | if test "$opendkimlib" = "yes"; then break; fi | |
| 34 | done | |
| 35 | LIBS=$saved_LIBS | |
| 36 | ||
| 37 | LDFLAGS=$OPENDKIM_SAVE_LDFLAGS | |
| 38 | ]) | |
| 39 | ||
| 40 | AC_DEFUN([CYRUS_OPENDKIM_OPTS], | |
| 41 | [ | |
| 42 | AC_ARG_WITH(opendkim-libdir, | |
| 43 | [ --with-opendkim-libdir=DIR Opendkim lib files are in DIR], | |
| 44 | with_opendkim_lib=$withval, | |
| 45 | [ test "${with_opendkim_lib+set}" = set || with_opendkim_lib=none]) | |
| 46 | AC_ARG_WITH(opendkim-incdir, | |
| 47 | [ --with-opendkim-incdir=DIR Opendkim include files are in DIR], | |
| 48 | with_opendkim_inc=$withval, | |
| 49 | [ test "${with_opendkim_inc+set}" = set || with_opendkim_inc=none ]) | |
| 50 | ]) | |
| 51 | ||
| 52 | AC_DEFUN([CYRUS_OPENDKIM_CHK], | |
| 53 | [ | |
| 54 | AC_REQUIRE([CYRUS_OPENDKIM_OPTS]) | |
| 55 | ||
| 56 | cmu_save_CPPFLAGS=$CPPFLAGS | |
| 57 | ||
| 58 | if test -d $with_opendkim_inc; then | |
| 59 | CPPFLAGS="$CPPFLAGS -I$with_opendkim_inc" | |
| 60 | DKIM_CFLAGS="-I$with_opendkim_inc" | |
| 61 | else | |
| 62 | DKIM_CFLAGS="" | |
| 63 | fi | |
| 64 | ||
| 65 | AC_CHECK_HEADER(dkim.h, | |
| 66 | [CYRUS_OPENDKIM_CHK_LIB()], | |
| 67 | opendkimlib="no") | |
| 68 | ||
| 69 | CPPFLAGS=$cmu_save_CPPFLAGS | |
| 70 | ]) |
| 0 | ? openssl.m4.libsocket.diff | |
| 1 | Index: openssl.m4 | |
| 2 | =================================================================== | |
| 3 | RCS file: /afs/andrew/system/cvs/src/cmulocal/openssl.m4,v | |
| 4 | retrieving revision 1.11 | |
| 5 | diff -u -r1.11 openssl.m4 | |
| 6 | --- openssl.m4 17 May 2006 18:30:19 -0000 1.11 | |
| 7 | +++ openssl.m4 27 Apr 2009 17:36:01 -0000 | |
| 8 | @@ -33,7 +33,8 @@ | |
| 9 | AC_CHECK_HEADER(openssl/evp.h, [ | |
| 10 | AC_CHECK_LIB(crypto, EVP_DigestInit, | |
| 11 | with_openssl="yes", | |
| 12 | - with_openssl="no", $LIB_RSAREF)], | |
| 13 | + with_openssl="no", | |
| 14 | + $LIB_RSAREF $LIB_SOCKET)], | |
| 15 | with_openssl=no) | |
| 16 | ;; | |
| 17 | esac |
| 0 | 0 | # sasl2.m4--sasl2 libraries and includes |
| 1 | 1 | # Rob Siemborski |
| 2 | # $Id: sasl2.m4,v 1.60 2011/05/23 14:47:11 mel Exp $ | |
| 2 | # $Id: sasl2.m4,v 1.61 2011/11/09 15:49:47 murch Exp $ | |
| 3 | 3 | |
| 4 | 4 | # SASL2_CRYPT_CHK |
| 5 | 5 | # --------------- |
| 278 | 278 | AC_CHECK_FUNCS(gss_get_name_attribute) |
| 279 | 279 | LIBS="$cmu_save_LIBS" |
| 280 | 280 | |
| 281 | cmu_save_LIBS="$LIBS" | |
| 282 | LIBS="$LIBS $GSSAPIBASE_LIBS" | |
| 283 | AC_MSG_CHECKING([for SPNEGO support in GSSAPI libraries]) | |
| 284 | AC_TRY_RUN([ | |
| 285 | #ifdef HAVE_GSSAPI_H | |
| 286 | #include <gssapi.h> | |
| 287 | #else | |
| 288 | #include <gssapi/gssapi.h> | |
| 289 | #endif | |
| 290 | ||
| 291 | int main(void) | |
| 292 | { | |
| 293 | gss_OID_desc spnego_oid = { 6, (void *) "\x2b\x06\x01\x05\x05\x02" }; | |
| 294 | gss_OID_set mech_set; | |
| 295 | OM_uint32 min_stat; | |
| 296 | int have_spnego = 0; | |
| 297 | ||
| 298 | if (gss_indicate_mechs(&min_stat, &mech_set) == GSS_S_COMPLETE) { | |
| 299 | gss_test_oid_set_member(&min_stat, &spnego_oid, mech_set, &have_spnego); | |
| 300 | gss_release_oid_set(&min_stat, &mech_set); | |
| 301 | } | |
| 302 | ||
| 303 | return (!have_spnego); // 0 = success, 1 = failure | |
| 304 | } | |
| 305 | ], | |
| 306 | [ AC_DEFINE(HAVE_GSS_SPNEGO,,[Define if your GSSAPI implementation supports SPNEGO]) | |
| 307 | AC_MSG_RESULT(yes) ], | |
| 308 | AC_MSG_RESULT(no)) | |
| 309 | LIBS="$cmu_save_LIBS" | |
| 310 | ||
| 281 | 311 | else |
| 282 | 312 | AC_MSG_RESULT([disabled]) |
| 283 | 313 | fi |
| 1371 | 1371 | hardcode_shlibpath_var=no |
| 1372 | 1372 | ;; |
| 1373 | 1373 | |
| 1374 | darwin[15]* | rhapsody*) | |
| 1374 | darwin[15].* | rhapsody*) | |
| 1375 | 1375 | allow_undefined_flag='-undefined error' |
| 1376 | archive_cmds='$CC $(test x$module = xyes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs $linkopts -install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != x0.0 && echo $verstring)' | |
| 1376 | archive_cmds='$CC $(test x$module = xyes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs $linkopts $(test x$module != xyes && echo -install_name $rpath/$soname) $(test -n "$verstring" -a x$verstring != x0.0 && echo $verstring)' | |
| 1377 | 1377 | # We need to add '_' to the symbols in $export_symbols first |
| 1378 | 1378 | #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols $lib' |
| 1379 | 1379 | hardcode_direct=yes |
| 1384 | 1384 | # Mac OS X v10.2 uses bash for /bin/sh instead of zsh, and the quoting syntax is incompatible |
| 1385 | 1385 | darwin*) |
| 1386 | 1386 | allow_undefined_flag='-undefined error' |
| 1387 | archive_cmds='$CC $(test x$module = xyes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs $linkopts $(test x$module != xyes && echo -install_name $rpath/$soname $tmp_verstring)' | |
| 1387 | archive_cmds='$CC $(test x$module = xyes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs $linkopts $(test x$module != xyes && echo -install_name $LD_RUN_PATH/$soname $tmp_verstring)' | |
| 1388 | 1388 | # We need to add '_' to the symbols in $export_symbols first |
| 1389 | 1389 | #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols $lib' |
| 1390 | 1390 | hardcode_direct=yes |
| 1949 | 1949 | file_magic_test_file='/usr/lib/libSystem.dylib' |
| 1950 | 1950 | ;; |
| 1951 | 1951 | esac |
| 1952 | library_names_spec='${libname}${release}${versuffix}.$(test x$module = xyes && echo so || echo dylib) ${libname}${release}${major}.$(test x$module = xyes && echo so || echo dylib) ${libname}.$(test x$module = xyes && echo so || echo dylib)' | |
| 1953 | soname_spec='${libname}${release}${major}.$(test x$module = xyes && echo so || echo dylib)' | |
| 1952 | library_names_spec='${libname}.$(test x$module = xyes && echo plugin || echo dylib)' | |
| 1953 | soname_spec='${libname}.$(test x$module = xyes && echo plugin || echo dylib)' | |
| 1954 | 1954 | shlibpath_overrides_runpath=yes |
| 1955 | 1955 | shlibpath_var=DYLD_LIBRARY_PATH |
| 1956 | 1956 | ;; |
| 1774 | 1774 | darwin) |
| 1775 | 1775 | # Like Linux, but with the current version available in |
| 1776 | 1776 | # verstring for coding it into the library header |
| 1777 | major=.`expr $current - $age` | |
| 1778 | versuffix="$major.$age.$revision" | |
| 1777 | major=`expr $current - $age` | |
| 1778 | versuffix=".$major.$age.$revision" | |
| 1779 | 1779 | # Darwin ld doesn't like 0 for these options... |
| 1780 | 1780 | minor_current=`expr $current + 1` |
| 1781 | verstring="-compatibility_version $minor_current -current_version $minor_current.$revision" | |
| 1781 | verstring="-compatibility_version $major -current_version $major.$age.$revision" | |
| 1782 | major=".$major" | |
| 1782 | 1783 | ;; |
| 1783 | 1784 | |
| 1784 | 1785 | *) |
| 143 | 143 | /* Define to 1 if you have the `gss_oid_equal' function. */ |
| 144 | 144 | #undef HAVE_GSS_OID_EQUAL |
| 145 | 145 | |
| 146 | /* Define if your GSSAPI implementation supports SPNEGO */ | |
| 147 | #undef HAVE_GSS_SPNEGO | |
| 148 | ||
| 146 | 149 | /* Define to 1 if you have the `inet_aton' function. */ |
| 147 | 150 | #undef HAVE_INET_ATON |
| 148 | 151 | |
| 382 | 385 | /* The size of `long', as computed by sizeof. */ |
| 383 | 386 | #undef SIZEOF_LONG |
| 384 | 387 | |
| 385 | /* Link ANONYMOUS Staticly */ | |
| 388 | /* Link ANONYMOUS Statically */ | |
| 386 | 389 | #undef STATIC_ANONYMOUS |
| 387 | 390 | |
| 388 | /* Link CRAM-MD5 Staticly */ | |
| 391 | /* Link CRAM-MD5 Statically */ | |
| 389 | 392 | #undef STATIC_CRAMMD5 |
| 390 | 393 | |
| 391 | /* Link DIGEST-MD5 Staticly */ | |
| 394 | /* Link DIGEST-MD5 Statically */ | |
| 392 | 395 | #undef STATIC_DIGESTMD5 |
| 393 | 396 | |
| 394 | /* Link GSSAPI Staticly */ | |
| 397 | /* Link GSSAPI Statically */ | |
| 395 | 398 | #undef STATIC_GSSAPIV2 |
| 396 | 399 | |
| 397 | 400 | /* User KERBEROS_V4 Staticly */ |
| 398 | 401 | #undef STATIC_KERBEROS4 |
| 399 | 402 | |
| 400 | /* Link ldapdb plugin Staticly */ | |
| 403 | /* Link ldapdb plugin Statically */ | |
| 401 | 404 | #undef STATIC_LDAPDB |
| 402 | 405 | |
| 403 | /* Link LOGIN Staticly */ | |
| 406 | /* Link LOGIN Statically */ | |
| 404 | 407 | #undef STATIC_LOGIN |
| 405 | 408 | |
| 406 | /* Link NTLM Staticly */ | |
| 409 | /* Link NTLM Statically */ | |
| 407 | 410 | #undef STATIC_NTLM |
| 408 | 411 | |
| 409 | /* Link OTP Staticly */ | |
| 412 | /* Link OTP Statically */ | |
| 410 | 413 | #undef STATIC_OTP |
| 411 | 414 | |
| 412 | /* Link PASSDSS Staticly */ | |
| 415 | /* Link PASSDSS Statically */ | |
| 413 | 416 | #undef STATIC_PASSDSS |
| 414 | 417 | |
| 415 | 418 | /* Link PLAIN Staticly */ |
| 418 | 421 | /* Link SASLdb Staticly */ |
| 419 | 422 | #undef STATIC_SASLDB |
| 420 | 423 | |
| 421 | /* Link SCRAM Staticly */ | |
| 424 | /* Link SCRAM Statically */ | |
| 422 | 425 | #undef STATIC_SCRAM |
| 423 | 426 | |
| 424 | /* Link SQL plugin staticly */ | |
| 427 | /* Link SQL plugin statically */ | |
| 425 | 428 | #undef STATIC_SQL |
| 426 | 429 | |
| 427 | /* Link SRP Staticly */ | |
| 430 | /* Link SRP Statically */ | |
| 428 | 431 | #undef STATIC_SRP |
| 429 | 432 | |
| 430 | 433 | /* Define to 1 if you have the ANSI C header files. */ |
| 433 | 436 | /* Define to 1 if you can safely include both <sys/time.h> and <time.h>. */ |
| 434 | 437 | #undef TIME_WITH_SYS_TIME |
| 435 | 438 | |
| 436 | /* Should we try to dlopen() plugins while staticly compiled? */ | |
| 439 | /* Should we try to dlopen() plugins while statically compiled? */ | |
| 437 | 440 | #undef TRY_DLOPEN_WHEN_STATIC |
| 438 | 441 | |
| 439 | 442 | /* use the doors IPC API for saslauthd? */ |
| 473 | 476 | |
| 474 | 477 | |
| 475 | 478 | /* Create a struct iovec if we need one */ |
| 476 | #if !defined(_WIN32) && !defined(HAVE_SYS_UIO_H) | |
| 479 | #if !defined(_WIN32) | |
| 480 | #if !defined(HAVE_SYS_UIO_H) | |
| 477 | 481 | /* (win32 is handled in sasl.h) */ |
| 478 | 482 | struct iovec { |
| 479 | 483 | char *iov_base; |
| 483 | 487 | #include <sys/types.h> |
| 484 | 488 | #include <sys/uio.h> |
| 485 | 489 | #endif |
| 490 | #endif | |
| 486 | 491 | |
| 487 | 492 | /* location of the random number generator */ |
| 488 | 493 | #ifdef DEV_RANDOM |
| 520 | 525 | |
| 521 | 526 | #include <stdlib.h> |
| 522 | 527 | #include <sys/types.h> |
| 523 | #include <sys/socket.h> | |
| 524 | 528 | #ifndef WIN32 |
| 529 | # include <sys/socket.h> | |
| 525 | 530 | # include <netdb.h> |
| 531 | # include <netinet/in.h> | |
| 526 | 532 | # ifdef HAVE_SYS_PARAM_H |
| 527 | 533 | # include <sys/param.h> |
| 528 | 534 | # endif |
| 531 | 537 | #endif /* WIN32 */ |
| 532 | 538 | #include <string.h> |
| 533 | 539 | |
| 534 | #include <netinet/in.h> | |
| 535 | ||
| 536 | 540 | #ifndef HAVE_SOCKLEN_T |
| 537 | 541 | typedef unsigned int socklen_t; |
| 538 | 542 | #endif /* HAVE_SOCKLEN_T */ |
| 539 | 543 | |
| 540 | #ifndef HAVE_STRUCT_SOCKADDR_STORAGE | |
| 544 | #if !defined(HAVE_STRUCT_SOCKADDR_STORAGE) && !defined(WIN32) | |
| 541 | 545 | #define _SS_MAXSIZE 128 /* Implementation specific max size */ |
| 542 | 546 | #define _SS_PADSIZE (_SS_MAXSIZE - sizeof (struct sockaddr)) |
| 543 | 547 | |
| 601 | 605 | #define HIER_DELIMITER '/' |
| 602 | 606 | #endif |
| 603 | 607 | |
| 608 | #ifdef WIN32 | |
| 609 | #define SASL_ROOT_KEY "SOFTWARE\\Carnegie Mellon\\Project Cyrus\\SASL Library" | |
| 610 | #define SASL_PLUGIN_PATH_ATTR "SearchPath" | |
| 611 | #define SASL_CONF_PATH_ATTR "ConfFile" | |
| 612 | ||
| 613 | #include <windows.h> | |
| 614 | inline static unsigned int sleep(unsigned int seconds) { | |
| 615 | Sleep(seconds * 1000); | |
| 616 | return 0; | |
| 617 | } | |
| 618 | #endif | |
| 619 | ||
| 604 | 620 | #endif /* CONFIG_H */ |
| 605 | 621 | |
| 2657 | 2657 | |
| 2658 | 2658 | # Define the identity of the package. |
| 2659 | 2659 | PACKAGE=cyrus-sasl |
| 2660 | VERSION=2.1.25 | |
| 2660 | VERSION=2.1.26 | |
| 2661 | 2661 | |
| 2662 | 2662 | |
| 2663 | 2663 | cat >>confdefs.h <<_ACEOF |
| 6421 | 6421 | fi |
| 6422 | 6422 | |
| 6423 | 6423 | saved_LIBS=$LIBS |
| 6424 | for dbname in ${with_bdb} db-4.7 db4.7 db47 db-4.6 db4.6 db46 db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 db-4.2 db4.2 db42 db-4.1 db4.1 db41 db-4.0 db4.0 db-4 db40 db4 db-3.3 db3.3 db33 db-3.2 db3.2 db32 db-3.1 db3.1 db31 db-3 db30 db3 db | |
| 6425 | do | |
| 6424 | for dbname in ${with_bdb} \ | |
| 6425 | db-5.2 db5.2 db52 \ | |
| 6426 | db-5.1 db5.2 db51 \ | |
| 6427 | db-5.0 db5.2 db50 \ | |
| 6428 | db-4.8 db4.8 db48 \ | |
| 6429 | db-4.7 db4.7 db47 \ | |
| 6430 | db-4.6 db4.6 db46 \ | |
| 6431 | db-4.5 db4.5 db45 \ | |
| 6432 | db-4.4 db4.4 db44 \ | |
| 6433 | db-4.3 db4.3 db43 \ | |
| 6434 | db-4.2 db4.2 db42 \ | |
| 6435 | db-4.1 db4.1 db41 \ | |
| 6436 | db-4.0 db4.0 db40 db-4 db4 \ | |
| 6437 | db-3.3 db3.3 db33 \ | |
| 6438 | db-3.2 db3.2 db32 \ | |
| 6439 | db-3.1 db3.1 db31 \ | |
| 6440 | db-3.0 db3.0 db30 db-3 db3 \ | |
| 6441 | db | |
| 6442 | do | |
| 6426 | 6443 | LIBS="$saved_LIBS -l$dbname" |
| 6427 | 6444 | cat >conftest.$ac_ext <<_ACEOF |
| 6428 | 6445 | /* confdefs.h. */ |
| 7231 | 7248 | fi |
| 7232 | 7249 | |
| 7233 | 7250 | saved_LIBS=$LIBS |
| 7234 | for dbname in ${with_bdb} db-4.7 db4.7 db47 db-4.6 db4.6 db46 db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 db-4.2 db4.2 db42 db-4.1 db4.1 db41 db-4.0 db4.0 db-4 db40 db4 db-3.3 db3.3 db33 db-3.2 db3.2 db32 db-3.1 db3.1 db31 db-3 db30 db3 db | |
| 7235 | do | |
| 7251 | for dbname in ${with_bdb} \ | |
| 7252 | db-5.2 db5.2 db52 \ | |
| 7253 | db-5.1 db5.2 db51 \ | |
| 7254 | db-5.0 db5.2 db50 \ | |
| 7255 | db-4.8 db4.8 db48 \ | |
| 7256 | db-4.7 db4.7 db47 \ | |
| 7257 | db-4.6 db4.6 db46 \ | |
| 7258 | db-4.5 db4.5 db45 \ | |
| 7259 | db-4.4 db4.4 db44 \ | |
| 7260 | db-4.3 db4.3 db43 \ | |
| 7261 | db-4.2 db4.2 db42 \ | |
| 7262 | db-4.1 db4.1 db41 \ | |
| 7263 | db-4.0 db4.0 db40 db-4 db4 \ | |
| 7264 | db-3.3 db3.3 db33 \ | |
| 7265 | db-3.2 db3.2 db32 \ | |
| 7266 | db-3.1 db3.1 db31 \ | |
| 7267 | db-3.0 db3.0 db30 db-3 db3 \ | |
| 7268 | db | |
| 7269 | do | |
| 7236 | 7270 | LIBS="$saved_LIBS -l$dbname" |
| 7237 | 7271 | cat >conftest.$ac_ext <<_ACEOF |
| 7238 | 7272 | /* confdefs.h. */ |
| 13842 | 13876 | |
| 13843 | 13877 | LIBS="$cmu_save_LIBS" |
| 13844 | 13878 | |
| 13879 | cmu_save_LIBS="$LIBS" | |
| 13880 | LIBS="$LIBS $GSSAPIBASE_LIBS" | |
| 13881 | { $as_echo "$as_me:$LINENO: checking for SPNEGO support in GSSAPI libraries" >&5 | |
| 13882 | $as_echo_n "checking for SPNEGO support in GSSAPI libraries... " >&6; } | |
| 13883 | if test "$cross_compiling" = yes; then | |
| 13884 | { { $as_echo "$as_me:$LINENO: error: in \`$ac_pwd':" >&5 | |
| 13885 | $as_echo "$as_me: error: in \`$ac_pwd':" >&2;} | |
| 13886 | { { $as_echo "$as_me:$LINENO: error: cannot run test program while cross compiling | |
| 13887 | See \`config.log' for more details." >&5 | |
| 13888 | $as_echo "$as_me: error: cannot run test program while cross compiling | |
| 13889 | See \`config.log' for more details." >&2;} | |
| 13890 | { (exit 1); exit 1; }; }; } | |
| 13891 | else | |
| 13892 | cat >conftest.$ac_ext <<_ACEOF | |
| 13893 | /* confdefs.h. */ | |
| 13894 | _ACEOF | |
| 13895 | cat confdefs.h >>conftest.$ac_ext | |
| 13896 | cat >>conftest.$ac_ext <<_ACEOF | |
| 13897 | /* end confdefs.h. */ | |
| 13898 | ||
| 13899 | #ifdef HAVE_GSSAPI_H | |
| 13900 | #include <gssapi.h> | |
| 13901 | #else | |
| 13902 | #include <gssapi/gssapi.h> | |
| 13903 | #endif | |
| 13904 | ||
| 13905 | int main(void) | |
| 13906 | { | |
| 13907 | gss_OID_desc spnego_oid = { 6, (void *) "\x2b\x06\x01\x05\x05\x02" }; | |
| 13908 | gss_OID_set mech_set; | |
| 13909 | OM_uint32 min_stat; | |
| 13910 | int have_spnego = 0; | |
| 13911 | ||
| 13912 | if (gss_indicate_mechs(&min_stat, &mech_set) == GSS_S_COMPLETE) { | |
| 13913 | gss_test_oid_set_member(&min_stat, &spnego_oid, mech_set, &have_spnego); | |
| 13914 | gss_release_oid_set(&min_stat, &mech_set); | |
| 13915 | } | |
| 13916 | ||
| 13917 | return (!have_spnego); // 0 = success, 1 = failure | |
| 13918 | } | |
| 13919 | ||
| 13920 | _ACEOF | |
| 13921 | rm -f conftest$ac_exeext | |
| 13922 | if { (ac_try="$ac_link" | |
| 13923 | case "(($ac_try" in | |
| 13924 | *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; | |
| 13925 | *) ac_try_echo=$ac_try;; | |
| 13926 | esac | |
| 13927 | eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" | |
| 13928 | $as_echo "$ac_try_echo") >&5 | |
| 13929 | (eval "$ac_link") 2>&5 | |
| 13930 | ac_status=$? | |
| 13931 | $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 | |
| 13932 | (exit $ac_status); } && { ac_try='./conftest$ac_exeext' | |
| 13933 | { (case "(($ac_try" in | |
| 13934 | *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; | |
| 13935 | *) ac_try_echo=$ac_try;; | |
| 13936 | esac | |
| 13937 | eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" | |
| 13938 | $as_echo "$ac_try_echo") >&5 | |
| 13939 | (eval "$ac_try") 2>&5 | |
| 13940 | ac_status=$? | |
| 13941 | $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 | |
| 13942 | (exit $ac_status); }; }; then | |
| 13943 | ||
| 13944 | cat >>confdefs.h <<\_ACEOF | |
| 13945 | #define HAVE_GSS_SPNEGO /**/ | |
| 13946 | _ACEOF | |
| 13947 | ||
| 13948 | { $as_echo "$as_me:$LINENO: result: yes" >&5 | |
| 13949 | $as_echo "yes" >&6; } | |
| 13950 | else | |
| 13951 | $as_echo "$as_me: program exited with status $ac_status" >&5 | |
| 13952 | $as_echo "$as_me: failed program was:" >&5 | |
| 13953 | sed 's/^/| /' conftest.$ac_ext >&5 | |
| 13954 | ||
| 13955 | ( exit $ac_status ) | |
| 13956 | { $as_echo "$as_me:$LINENO: result: no" >&5 | |
| 13957 | $as_echo "no" >&6; } | |
| 13958 | fi | |
| 13959 | rm -rf conftest.dSYM | |
| 13960 | rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext | |
| 13961 | fi | |
| 13962 | ||
| 13963 | ||
| 13964 | LIBS="$cmu_save_LIBS" | |
| 13965 | ||
| 13845 | 13966 | else |
| 13846 | 13967 | { $as_echo "$as_me:$LINENO: result: disabled" >&5 |
| 13847 | 13968 | $as_echo "disabled" >&6; } |
| 18407 | 18528 | ac_config_headers="$ac_config_headers config.h" |
| 18408 | 18529 | |
| 18409 | 18530 | |
| 18410 | ac_config_files="$ac_config_files Makefile include/Makefile sasldb/Makefile plugins/Makefile lib/Makefile utils/Makefile doc/Makefile sample/Makefile java/Makefile java/CyrusSasl/Makefile java/Test/Makefile java/javax/Makefile java/javax/security/Makefile java/javax/security/auth/Makefile java/javax/security/auth/callback/Makefile pwcheck/Makefile man/Makefile" | |
| 18531 | ac_config_files="$ac_config_files Makefile libsasl2.pc include/Makefile sasldb/Makefile plugins/Makefile lib/Makefile utils/Makefile doc/Makefile sample/Makefile java/Makefile java/CyrusSasl/Makefile java/Test/Makefile java/javax/Makefile java/javax/security/Makefile java/javax/security/auth/Makefile java/javax/security/auth/callback/Makefile pwcheck/Makefile man/Makefile" | |
| 18411 | 18532 | |
| 18412 | 18533 | cat >confcache <<\_ACEOF |
| 18413 | 18534 | # This file is a shell script that caches the results of configure |
| 19081 | 19202 | "depfiles") CONFIG_COMMANDS="$CONFIG_COMMANDS depfiles" ;; |
| 19082 | 19203 | "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;; |
| 19083 | 19204 | "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;; |
| 19205 | "libsasl2.pc") CONFIG_FILES="$CONFIG_FILES libsasl2.pc" ;; | |
| 19084 | 19206 | "include/Makefile") CONFIG_FILES="$CONFIG_FILES include/Makefile" ;; |
| 19085 | 19207 | "sasldb/Makefile") CONFIG_FILES="$CONFIG_FILES sasldb/Makefile" ;; |
| 19086 | 19208 | "plugins/Makefile") CONFIG_FILES="$CONFIG_FILES plugins/Makefile" ;; |
| 0 | 0 | dnl configure.in for the SASL library |
| 1 | 1 | dnl Rob Siemborski |
| 2 | 2 | dnl Rob Earhart |
| 3 | dnl $Id: configure.in,v 1.222 2011/09/07 13:19:44 murch Exp $ | |
| 3 | dnl $Id: configure.in,v 1.224 2011/09/22 14:44:15 mel Exp $ | |
| 4 | 4 | dnl |
| 5 | 5 | dnl Copyright (c) 2001 Carnegie Mellon University. All rights reserved. |
| 6 | 6 | dnl |
| 58 | 58 | dnl REMINDER: When changing the version number here, please also update |
| 59 | 59 | dnl the values in win32/include/config.h and include/sasl.h as well. |
| 60 | 60 | dnl |
| 61 | AM_INIT_AUTOMAKE(cyrus-sasl, 2.1.25) | |
| 61 | AM_INIT_AUTOMAKE(cyrus-sasl, 2.1.26) | |
| 62 | 62 | CMU_INIT_AUTOMAKE |
| 63 | 63 | |
| 64 | 64 | # and include our config dir scripts |
| 123 | 123 | enable_staticdlopen=no) |
| 124 | 124 | |
| 125 | 125 | if test "$enable_staticdlopen" = yes; then |
| 126 | AC_DEFINE(TRY_DLOPEN_WHEN_STATIC,[],[Should we try to dlopen() plugins while staticly compiled?]) | |
| 126 | AC_DEFINE(TRY_DLOPEN_WHEN_STATIC,[],[Should we try to dlopen() plugins while statically compiled?]) | |
| 127 | 127 | fi |
| 128 | 128 | |
| 129 | 129 | if test "$ac_cv_prog_gcc" = yes; then |
| 276 | 276 | fi |
| 277 | 277 | AC_CHECK_HEADERS(security/pam_appl.h pam/pam_appl.h) |
| 278 | 278 | cmu_save_LIBS="$LIBS" |
| 279 | AC_CHECK_FUNC(pam_start, :, | |
| 280 | LIBS="-lpam $LIBS" | |
| 279 | AC_CHECK_FUNC(pam_start, :, | |
| 280 | LIBS="-lpam $LIBS" | |
| 281 | 281 | AC_TRY_LINK([[ |
| 282 | 282 | #include <sys/types.h> |
| 283 | 283 | #ifdef HAVE_PAM_PAM_APPL_H |
| 393 | 393 | if test "$enable_static" = yes; then |
| 394 | 394 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS cram.o" |
| 395 | 395 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/cram.c" |
| 396 | AC_DEFINE(STATIC_CRAMMD5, [], [Link CRAM-MD5 Staticly]) | |
| 396 | AC_DEFINE(STATIC_CRAMMD5, [], [Link CRAM-MD5 Statically]) | |
| 397 | 397 | fi |
| 398 | 398 | else |
| 399 | 399 | AC_MSG_RESULT(disabled) |
| 428 | 428 | if test "$enable_static" = yes; then |
| 429 | 429 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/digestmd5.c" |
| 430 | 430 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS digestmd5.o" |
| 431 | AC_DEFINE(STATIC_DIGESTMD5, [], [Link DIGEST-MD5 Staticly]) | |
| 431 | AC_DEFINE(STATIC_DIGESTMD5, [], [Link DIGEST-MD5 Statically]) | |
| 432 | 432 | fi |
| 433 | 433 | else |
| 434 | 434 | AC_MSG_RESULT(disabled) |
| 453 | 453 | if test "$enable_static" = yes; then |
| 454 | 454 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/scram.c" |
| 455 | 455 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS scram.o" |
| 456 | AC_DEFINE(STATIC_SCRAM, [], [Link SCRAM Staticly]) | |
| 456 | AC_DEFINE(STATIC_SCRAM, [], [Link SCRAM Statically]) | |
| 457 | 457 | fi |
| 458 | 458 | |
| 459 | 459 | AC_SUBST(SCRAM_LIBS) |
| 480 | 480 | if test "$enable_static" = yes; then |
| 481 | 481 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/otp.c" |
| 482 | 482 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS otp.o" |
| 483 | AC_DEFINE(STATIC_OTP, [], [Link OTP Staticly]) | |
| 483 | AC_DEFINE(STATIC_OTP, [], [Link OTP Statically]) | |
| 484 | 484 | fi |
| 485 | 485 | |
| 486 | 486 | dnl Test for OPIE |
| 537 | 537 | if test "$enable_static" = yes; then |
| 538 | 538 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/srp.c" |
| 539 | 539 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS srp.o" |
| 540 | AC_DEFINE(STATIC_SRP, [], [Link SRP Staticly]) | |
| 540 | AC_DEFINE(STATIC_SRP, [], [Link SRP Statically]) | |
| 541 | 541 | fi |
| 542 | 542 | |
| 543 | 543 | dnl srp_setpass support |
| 563 | 563 | SASL_GSSAPI_CHK |
| 564 | 564 | |
| 565 | 565 | if test "$gssapi" != "no"; then |
| 566 | AC_DEFINE(STATIC_GSSAPIV2,[],[Link GSSAPI Staticly]) | |
| 566 | AC_DEFINE(STATIC_GSSAPIV2,[],[Link GSSAPI Statically]) | |
| 567 | 567 | mutex_default="no" |
| 568 | 568 | if test "$gss_impl" = "mit"; then |
| 569 | 569 | mutex_default="yes" |
| 593 | 593 | if test "$enable_static" = yes; then |
| 594 | 594 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS anonymous.o" |
| 595 | 595 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/anonymous.c" |
| 596 | AC_DEFINE(STATIC_ANONYMOUS, [], [Link ANONYMOUS Staticly]) | |
| 596 | AC_DEFINE(STATIC_ANONYMOUS, [], [Link ANONYMOUS Statically]) | |
| 597 | 597 | fi |
| 598 | 598 | else |
| 599 | 599 | AC_MSG_RESULT(disabled) |
| 611 | 611 | if test "$enable_static" = yes; then |
| 612 | 612 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/login.c" |
| 613 | 613 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS login.o" |
| 614 | AC_DEFINE(STATIC_LOGIN,[],[Link LOGIN Staticly]) | |
| 614 | AC_DEFINE(STATIC_LOGIN,[],[Link LOGIN Statically]) | |
| 615 | 615 | fi |
| 616 | 616 | else |
| 617 | 617 | AC_MSG_RESULT(disabled) |
| 637 | 637 | if test "$enable_static" = yes; then |
| 638 | 638 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/ntlm.c" |
| 639 | 639 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS ntlm.o" |
| 640 | AC_DEFINE(STATIC_NTLM,[],[Link NTLM Staticly]) | |
| 640 | AC_DEFINE(STATIC_NTLM,[],[Link NTLM Statically]) | |
| 641 | 641 | fi |
| 642 | 642 | else |
| 643 | 643 | AC_MSG_RESULT(disabled) |
| 663 | 663 | if test "$enable_static" = yes; then |
| 664 | 664 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS passdss.o" |
| 665 | 665 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/passdss.c" |
| 666 | AC_DEFINE(STATIC_PASSDSS,[],[Link PASSDSS Staticly]) | |
| 666 | AC_DEFINE(STATIC_PASSDSS,[],[Link PASSDSS Statically]) | |
| 667 | 667 | fi |
| 668 | 668 | else |
| 669 | 669 | AC_MSG_RESULT(disabled) |
| 694 | 694 | if test "$enable_static" = yes; then |
| 695 | 695 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/sql.c" |
| 696 | 696 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS sql.o" |
| 697 | AC_DEFINE(STATIC_SQL,[],[Link SQL plugin staticly]) | |
| 697 | AC_DEFINE(STATIC_SQL,[],[Link SQL plugin statically]) | |
| 698 | 698 | fi |
| 699 | 699 | else |
| 700 | 700 | AC_MSG_RESULT(disabled) |
| 834 | 834 | with_sqlite=$withval, |
| 835 | 835 | with_sqlite=$sql) |
| 836 | 836 | |
| 837 | # find location of library | |
| 837 | # find location of library | |
| 838 | 838 | # presuing if one given then correct |
| 839 | 839 | if test "${with_sqlite}" = "yes"; then |
| 840 | 840 | with_sqlite=notfound |
| 877 | 877 | [Do we have SQLite support?]), |
| 878 | 878 | [AC_WARN([SQLite Library sqlite does not work]) |
| 879 | 879 | with_sqlite=no], $LIB_SQLITE_DIR);; |
| 880 | ||
| 880 | ||
| 881 | 881 | esac |
| 882 | 882 | AC_SUBST(LIB_SQLITE) |
| 883 | 883 | |
| 886 | 886 | with_sqlite3=$withval, |
| 887 | 887 | with_sqlite3=$sql) |
| 888 | 888 | |
| 889 | # find location of library | |
| 889 | # find location of library | |
| 890 | 890 | # we assume that if one given then it is correct |
| 891 | 891 | if test "${with_sqlite3}" = "yes"; then |
| 892 | 892 | with_sqlite3=notfound |
| 929 | 929 | [Do we have SQLite3 support?]), |
| 930 | 930 | [AC_WARN([SQLite3 Library sqlite3 does not work]) |
| 931 | 931 | with_sqlite3=no], $LIB_SQLITE3_DIR);; |
| 932 | ||
| 932 | ||
| 933 | 933 | esac |
| 934 | 934 | AC_SUBST(LIB_SQLITE3) |
| 935 | 935 | |
| 986 | 986 | if test "$enable_static" = yes; then |
| 987 | 987 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/ldapdb.c" |
| 988 | 988 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS ldapdb.o" |
| 989 | AC_DEFINE(STATIC_LDAPDB,[],[Link ldapdb plugin Staticly]) | |
| 989 | AC_DEFINE(STATIC_LDAPDB,[],[Link ldapdb plugin Statically]) | |
| 990 | 990 | fi |
| 991 | 991 | fi |
| 992 | 992 | fi |
| 1267 | 1267 | |
| 1268 | 1268 | |
| 1269 | 1269 | /* Create a struct iovec if we need one */ |
| 1270 | #if !defined(_WIN32) && !defined(HAVE_SYS_UIO_H) | |
| 1270 | #if !defined(_WIN32) | |
| 1271 | #if !defined(HAVE_SYS_UIO_H) | |
| 1271 | 1272 | /* (win32 is handled in sasl.h) */ |
| 1272 | 1273 | struct iovec { |
| 1273 | 1274 | char *iov_base; |
| 1277 | 1278 | #include <sys/types.h> |
| 1278 | 1279 | #include <sys/uio.h> |
| 1279 | 1280 | #endif |
| 1281 | #endif | |
| 1280 | 1282 | |
| 1281 | 1283 | /* location of the random number generator */ |
| 1282 | 1284 | #ifdef DEV_RANDOM |
| 1314 | 1316 | |
| 1315 | 1317 | #include <stdlib.h> |
| 1316 | 1318 | #include <sys/types.h> |
| 1317 | #include <sys/socket.h> | |
| 1318 | 1319 | #ifndef WIN32 |
| 1320 | # include <sys/socket.h> | |
| 1319 | 1321 | # include <netdb.h> |
| 1322 | # include <netinet/in.h> | |
| 1320 | 1323 | # ifdef HAVE_SYS_PARAM_H |
| 1321 | 1324 | # include <sys/param.h> |
| 1322 | 1325 | # endif |
| 1325 | 1328 | #endif /* WIN32 */ |
| 1326 | 1329 | #include <string.h> |
| 1327 | 1330 | |
| 1328 | #include <netinet/in.h> | |
| 1329 | ||
| 1330 | 1331 | #ifndef HAVE_SOCKLEN_T |
| 1331 | 1332 | typedef unsigned int socklen_t; |
| 1332 | 1333 | #endif /* HAVE_SOCKLEN_T */ |
| 1333 | 1334 | |
| 1334 | #ifndef HAVE_STRUCT_SOCKADDR_STORAGE | |
| 1335 | #if !defined(HAVE_STRUCT_SOCKADDR_STORAGE) && !defined(WIN32) | |
| 1335 | 1336 | #define _SS_MAXSIZE 128 /* Implementation specific max size */ |
| 1336 | 1337 | #define _SS_PADSIZE (_SS_MAXSIZE - sizeof (struct sockaddr)) |
| 1337 | 1338 | |
| 1395 | 1396 | #define HIER_DELIMITER '/' |
| 1396 | 1397 | #endif |
| 1397 | 1398 | |
| 1399 | #ifdef WIN32 | |
| 1400 | #define SASL_ROOT_KEY "SOFTWARE\\Carnegie Mellon\\Project Cyrus\\SASL Library" | |
| 1401 | #define SASL_PLUGIN_PATH_ATTR "SearchPath" | |
| 1402 | #define SASL_CONF_PATH_ATTR "ConfFile" | |
| 1403 | ||
| 1404 | #include <windows.h> | |
| 1405 | inline static unsigned int sleep(unsigned int seconds) { | |
| 1406 | Sleep(seconds * 1000); | |
| 1407 | return 0; | |
| 1408 | } | |
| 1409 | #endif | |
| 1410 | ||
| 1398 | 1411 | #endif /* CONFIG_H */ |
| 1399 | 1412 | ]) |
| 1400 | 1413 | |
| 1401 | AC_CONFIG_HEADERS(config.h) | |
| 1414 | AM_CONFIG_HEADER(config.h) | |
| 1402 | 1415 | |
| 1403 | 1416 | AC_OUTPUT(Makefile |
| 1417 | libsasl2.pc | |
| 1404 | 1418 | include/Makefile |
| 1405 | 1419 | sasldb/Makefile |
| 1406 | 1420 | plugins/Makefile |
| 0 | APPLE PUBLIC SOURCE LICENSE | |
| 1 | Version 1.1 - April 19,1999 | |
| 2 | ||
| 3 | Please read this License carefully before downloading this software. | |
| 4 | By downloading and using this software, you are agreeing to be bound | |
| 5 | by the terms of this License. If you do not or cannot agree to the | |
| 6 | terms of this License, please do not download or use the software. | |
| 7 | ||
| 8 | 1. General; Definitions. This License applies to any program or other | |
| 9 | work which Apple Computer, Inc. ("Apple") publicly announces as | |
| 10 | subject to this Apple Public Source License and which contains a | |
| 11 | notice placed by Apple identifying such program or work as "Original | |
| 12 | Code" and stating that it is subject to the terms of this Apple Public | |
| 13 | Source License version 1.1 (or subsequent version thereof), as it may | |
| 14 | be revised from time to time by Apple ("License"). As used in this | |
| 15 | License: | |
| 16 | ||
| 17 | 1.1 "Affected Original Code" means only those specific portions of | |
| 18 | Original Code that allegedly infringe upon any party's intellectual | |
| 19 | property rights or are otherwise the subject of a claim of | |
| 20 | infringement. | |
| 21 | ||
| 22 | 1.2 "Applicable Patent Rights" mean: (a) in the case where Apple is | |
| 23 | the grantor of rights, (i) claims of patents that are now or hereafter | |
| 24 | acquired, owned by or assigned to Apple and (ii) that cover subject | |
| 25 | matter contained in the Original Code, but only to the extent | |
| 26 | necessary to use, reproduce and/or distribute the Original Code | |
| 27 | without infringement; and (b) in the case where You are the grantor of | |
| 28 | rights, (i) claims of patents that are now or hereafter acquired, | |
| 29 | owned by or assigned to You and (ii) that cover subject matter in Your | |
| 30 | Modifications, taken alone or in combination with Original Code. | |
| 31 | ||
| 32 | 1.3 "Covered Code" means the Original Code, Modifications, the | |
| 33 | combination of Original Code and any Modifications, and/or any | |
| 34 | respective portions thereof. | |
| 35 | ||
| 36 | 1.4 "Deploy" means to use, sublicense or distribute Covered Code other | |
| 37 | than for Your internal research and development (R&D), and includes | |
| 38 | without limitation, any and all internal use or distribution of | |
| 39 | Covered Code within Your business or organization except for R&D use, | |
| 40 | as well as direct or indirect sublicensing or distribution of Covered | |
| 41 | Code by You to any third party in any form or manner. | |
| 42 | ||
| 43 | 1.5 "Larger Work" means a work which combines Covered Code or portions | |
| 44 | thereof with code not governed by the terms of this License. | |
| 45 | ||
| 46 | 1.6 "Modifications" mean any addition to, deletion from, and/or change | |
| 47 | to, the substance and/or structure of Covered Code. When code is | |
| 48 | released as a series of files, a Modification is: (a) any addition to | |
| 49 | or deletion from the contents of a file containing Covered Code; | |
| 50 | and/or (b) any new file or other representation of computer program | |
| 51 | statements that contains any part of Covered Code. | |
| 52 | ||
| 53 | 1.7 "Original Code" means (a) the Source Code of a program or other | |
| 54 | work as originally made available by Apple under this License, | |
| 55 | including the Source Code of any updates or upgrades to such programs | |
| 56 | or works made available by Apple under this License, and that has been | |
| 57 | expressly identified by Apple as such in the header file(s) of such | |
| 58 | work; and (b) the object code compiled from such Source Code and | |
| 59 | originally made available by Apple under this License. | |
| 60 | ||
| 61 | 1.8 "Source Code" means the human readable form of a program or other | |
| 62 | work that is suitable for making modifications to it, including all | |
| 63 | modules it contains, plus any associated interface definition files, | |
| 64 | scripts used to control compilation and installation of an executable | |
| 65 | (object code). | |
| 66 | ||
| 67 | 1.9 "You" or "Your" means an individual or a legal entity exercising | |
| 68 | rights under this License. For legal entities, "You" or "Your" | |
| 69 | includes any entity which controls, is controlled by, or is under | |
| 70 | common control with, You, where "control" means (a) the power, direct | |
| 71 | or indirect, to cause the direction or management of such entity, | |
| 72 | whether by contract or otherwise, or (b) ownership of fifty percent | |
| 73 | (50%) or more of the outstanding shares or beneficial ownership of | |
| 74 | such entity. | |
| 75 | ||
| 76 | 2. Permitted Uses; Conditions & Restrictions. Subject to the terms | |
| 77 | and conditions of this License, Apple hereby grants You, effective on | |
| 78 | the date You accept this License and download the Original Code, a | |
| 79 | world-wide, royalty-free, non- exclusive license, to the extent of | |
| 80 | Apple's Applicable Patent Rights and copyrights covering the Original | |
| 81 | Code, to do the following: | |
| 82 | ||
| 83 | 2.1 You may use, copy, modify and distribute Original Code, with or | |
| 84 | without Modifications, solely for Your internal research and | |
| 85 | development, provided that You must in each instance: | |
| 86 | ||
| 87 | (a) retain and reproduce in all copies of Original Code the copyright | |
| 88 | and other proprietary notices and disclaimers of Apple as they appear | |
| 89 | in the Original Code, and keep intact all notices in the Original Code | |
| 90 | that refer to this License; | |
| 91 | ||
| 92 | (b) include a copy of this License with every copy of Source Code of | |
| 93 | Covered Code and documentation You distribute, and You may not offer | |
| 94 | or impose any terms on such Source Code that alter or restrict this | |
| 95 | License or the recipients' rights hereunder, except as permitted under | |
| 96 | Section 6; and | |
| 97 | ||
| 98 | (c) completely and accurately document all Modifications that you have | |
| 99 | made and the date of each such Modification, designate the version of | |
| 100 | the Original Code you used, prominently include a file carrying such | |
| 101 | information with the Modifications, and duplicate the notice in | |
| 102 | Exhibit A in each file of the Source Code of all such Modifications. | |
| 103 | ||
| 104 | 2.2 You may Deploy Covered Code, provided that You must in each | |
| 105 | instance: | |
| 106 | ||
| 107 | (a) satisfy all the conditions of Section 2.1 with respect to the | |
| 108 | Source Code of the Covered Code; | |
| 109 | ||
| 110 | (b) make all Your Deployed Modifications publicly available in Source | |
| 111 | Code form via electronic distribution (e.g. download from a web site) | |
| 112 | under the terms of this License and subject to the license grants set | |
| 113 | forth in Section 3 below, and any additional terms You may choose to | |
| 114 | offer under Section 6. You must continue to make the Source Code of | |
| 115 | Your Deployed Modifications available for as long as you Deploy the | |
| 116 | Covered Code or twelve (12) months from the date of initial | |
| 117 | Deployment, whichever is longer; | |
| 118 | ||
| 119 | (c) if You Deploy Covered Code containing Modifications made by You, | |
| 120 | inform others of how to obtain those Modifications by filling out and | |
| 121 | submitting the information found at | |
| 122 | http://www.apple.com/publicsource/modifications.html, if available; | |
| 123 | and | |
| 124 | ||
| 125 | (d) if You Deploy Covered Code in object code, executable form only, | |
| 126 | include a prominent notice, in the code itself as well as in related | |
| 127 | documentation, stating that Source Code of the Covered Code is | |
| 128 | available under the terms of this License with information on how and | |
| 129 | where to obtain such Source Code. | |
| 130 | ||
| 131 | 3. Your Grants. In consideration of, and as a condition to, the | |
| 132 | licenses granted to You under this License: | |
| 133 | ||
| 134 | (a) You hereby grant to Apple and all third parties a non-exclusive, | |
| 135 | royalty-free license, under Your Applicable Patent Rights and other | |
| 136 | intellectual property rights owned or controlled by You, to use, | |
| 137 | reproduce, modify, distribute and Deploy Your Modifications of the | |
| 138 | same scope and extent as Apple's licenses under Sections 2.1 and 2.2; | |
| 139 | and | |
| 140 | ||
| 141 | (b) You hereby grant to Apple and its subsidiaries a non-exclusive, | |
| 142 | worldwide, royalty-free, perpetual and irrevocable license, under Your | |
| 143 | Applicable Patent Rights and other intellectual property rights owned | |
| 144 | or controlled by You, to use, reproduce, execute, compile, display, | |
| 145 | perform, modify or have modified (for Apple and/or its subsidiaries), | |
| 146 | sublicense and distribute Your Modifications, in any form, through | |
| 147 | multiple tiers of distribution. | |
| 148 | ||
| 149 | 4. Larger Works. You may create a Larger Work by combining Covered | |
| 150 | Code with other code not governed by the terms of this License and | |
| 151 | distribute the Larger Work as a single product. In each such | |
| 152 | instance, You must make sure the requirements of this License are | |
| 153 | fulfilled for the Covered Code or any portion thereof. | |
| 154 | ||
| 155 | 5. Limitations on Patent License. Except as expressly stated in | |
| 156 | Section 2, no other patent rights, express or implied, are granted by | |
| 157 | Apple herein. Modifications and/or Larger Works may require | |
| 158 | additional patent licenses from Apple which Apple may grant in its | |
| 159 | sole discretion. | |
| 160 | ||
| 161 | 6. Additional Terms. You may choose to offer, and to charge a fee | |
| 162 | for, warranty, support, indemnity or liability obligations and/or | |
| 163 | other rights consistent with the scope of the license granted herein | |
| 164 | ("Additional Terms") to one or more recipients of Covered | |
| 165 | Code. However, You may do so only on Your own behalf and as Your sole | |
| 166 | responsibility, and not on behalf of Apple. You must obtain the | |
| 167 | recipient's agreement that any such Additional Terms are offered by | |
| 168 | You alone, and You hereby agree to indemnify, defend and hold Apple | |
| 169 | harmless for any liability incurred by or claims asserted against | |
| 170 | Apple by reason of any such Additional Terms. | |
| 171 | ||
| 172 | 7. Versions of the License. Apple may publish revised and/or new | |
| 173 | versions of this License from time to time. Each version will be | |
| 174 | given a distinguishing version number. Once Original Code has been | |
| 175 | published under a particular version of this License, You may continue | |
| 176 | to use it under the terms of that version. You may also choose to use | |
| 177 | such Original Code under the terms of any subsequent version of this | |
| 178 | License published by Apple. No one other than Apple has the right to | |
| 179 | modify the terms applicable to Covered Code created under this | |
| 180 | License. | |
| 181 | ||
| 182 | 8. NO WARRANTY OR SUPPORT. The Original Code may contain in whole or | |
| 183 | in part pre-release, untested, or not fully tested works. The | |
| 184 | Original Code may contain errors that could cause failures or loss of | |
| 185 | data, and may be incomplete or contain inaccuracies. You expressly | |
| 186 | acknowledge and agree that use of the Original Code, or any portion | |
| 187 | thereof, is at Your sole and entire risk. THE ORIGINAL CODE IS | |
| 188 | PROVIDED "AS IS" AND WITHOUT WARRANTY, UPGRADES OR SUPPORT OF ANY KIND | |
| 189 | AND APPLE AND APPLE'S LICENSOR(S) (FOR THE PURPOSES OF SECTIONS 8 AND | |
| 190 | 9, APPLE AND APPLE'S LICENSOR(S) ARE COLLECTIVELY REFERRED TO AS | |
| 191 | "APPLE") EXPRESSLY DISCLAIM ALL WARRANTIES AND/OR CONDITIONS, EXPRESS | |
| 192 | OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES | |
| 193 | AND/OR CONDITIONS OF MERCHANTABILITY OR SATISFACTORY QUALITY AND | |
| 194 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY | |
| 195 | RIGHTS. APPLE DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE | |
| 196 | ORIGINAL CODE WILL MEET YOUR REQUIREMENTS, OR THAT THE OPERATION OF | |
| 197 | THE ORIGINAL CODE WILL BE UNINTERRUPTED OR ERROR- FREE, OR THAT | |
| 198 | DEFECTS IN THE ORIGINAL CODE WILL BE CORRECTED. NO ORAL OR WRITTEN | |
| 199 | INFORMATION OR ADVICE GIVEN BY APPLE OR AN APPLE AUTHORIZED | |
| 200 | REPRESENTATIVE SHALL CREATE A WARRANTY OR IN ANY WAY INCREASE THE | |
| 201 | SCOPE OF THIS WARRANTY. You acknowledge that the Original Code is not | |
| 202 | intended for use in the operation of nuclear facilities, aircraft | |
| 203 | navigation, communication systems, or air traffic control machines in | |
| 204 | which case the failure of the Original Code could lead to death, | |
| 205 | personal injury, or severe physical or environmental damage. | |
| 206 | ||
| 207 | 9. Liability. | |
| 208 | ||
| 209 | 9.1 Infringement. If any portion of, or functionality implemented by, | |
| 210 | the Original Code becomes the subject of a claim of infringement, | |
| 211 | Apple may, at its option: (a) attempt to procure the rights necessary | |
| 212 | for Apple and You to continue using the Affected Original Code; (b) | |
| 213 | modify the Affected Original Code so that it is no longer infringing; | |
| 214 | or (c) suspend Your rights to use, reproduce, modify, sublicense and | |
| 215 | distribute the Affected Original Code until a final determination of | |
| 216 | the claim is made by a court or governmental administrative agency of | |
| 217 | competent jurisdiction and Apple lifts the suspension as set forth | |
| 218 | below. Such suspension of rights will be effective immediately upon | |
| 219 | Apple's posting of a notice to such effect on the Apple web site that | |
| 220 | is used for implementation of this License. Upon such final | |
| 221 | determination being made, if Apple is legally able, without the | |
| 222 | payment of a fee or royalty, to resume use, reproduction, | |
| 223 | modification, sublicensing and distribution of the Affected Original | |
| 224 | Code, Apple will lift the suspension of rights to the Affected | |
| 225 | Original Code by posting a notice to such effect on the Apple web site | |
| 226 | that is used for implementation of this License. If Apple suspends | |
| 227 | Your rights to Affected Original Code, nothing in this License shall | |
| 228 | be construed to restrict You, at Your option and subject to applicable | |
| 229 | law, from replacing the Affected Original Code with non-infringing | |
| 230 | code or independently negotiating for necessary rights from such third | |
| 231 | party. | |
| 232 | ||
| 233 | 9.2 LIMITATION OF LIABILITY. UNDER NO CIRCUMSTANCES SHALL APPLE BE | |
| 234 | LIABLE FOR ANY INCIDENTAL, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES | |
| 235 | ARISING OUT OF OR RELATING TO THIS LICENSE OR YOUR USE OR INABILITY TO | |
| 236 | USE THE ORIGINAL CODE, OR ANY PORTION THEREOF, WHETHER UNDER A THEORY | |
| 237 | OF CONTRACT, WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCTS LIABILITY | |
| 238 | OR OTHERWISE, EVEN IF APPLE HAS BEEN ADVISED OF THE POSSIBILITY OF | |
| 239 | SUCH DAMAGES AND NOTWITHSTANDING THE FAILURE OF ESSENTIAL PURPOSE OF | |
| 240 | ANY REMEDY. In no event shall Apple's total liability to You for all | |
| 241 | damages under this License exceed the amount of fifty dollars | |
| 242 | ($50.00). | |
| 243 | ||
| 244 | 10. Trademarks. This License does not grant any rights to use the | |
| 245 | trademarks or trade names "Apple", "Apple Computer", "Mac OS X", "Mac | |
| 246 | OS X Server" or any other trademarks or trade names belonging to Apple | |
| 247 | (collectively "Apple Marks") and no Apple Marks may be used to endorse | |
| 248 | or promote products derived from the Original Code other than as | |
| 249 | permitted by and in strict compliance at all times with Apple's third | |
| 250 | party trademark usage guidelines which are posted at | |
| 251 | http://www.apple.com/legal/guidelinesfor3rdparties.html. | |
| 252 | ||
| 253 | 11. Ownership. Apple retains all rights, title and interest in and to | |
| 254 | the Original Code and any Modifications made by or on behalf of Apple | |
| 255 | ("Apple Modifications"), and such Apple Modifications will not be | |
| 256 | automatically subject to this License. Apple may, at its sole | |
| 257 | discretion, choose to license such Apple Modifications under this | |
| 258 | License, or on different terms from those contained in this License or | |
| 259 | may choose not to license them at all. Apple's development, use, | |
| 260 | reproduction, modification, sublicensing and distribution of Covered | |
| 261 | Code will not be subject to this License. | |
| 262 | ||
| 263 | 12. Termination. | |
| 264 | ||
| 265 | 12.1 Termination. This License and the rights granted hereunder will | |
| 266 | terminate: | |
| 267 | ||
| 268 | (a) automatically without notice from Apple if You fail to comply with | |
| 269 | any term(s) of this License and fail to cure such breach within 30 | |
| 270 | days of becoming aware of such breach; (b) immediately in the event of | |
| 271 | the circumstances described in Section 13.5(b); or (c) automatically | |
| 272 | without notice from Apple if You, at any time during the term of this | |
| 273 | License, commence an action for patent infringement against Apple. | |
| 274 | ||
| 275 | 12.2 Effect of Termination. Upon termination, You agree to | |
| 276 | immediately stop any further use, reproduction, modification, | |
| 277 | sublicensing and distribution of the Covered Code and to destroy all | |
| 278 | copies of the Covered Code that are in your possession or control. | |
| 279 | All sublicenses to the Covered Code which have been properly granted | |
| 280 | prior to termination shall survive any termination of this License. | |
| 281 | Provisions which, by their nature, should remain in effect beyond the | |
| 282 | termination of this License shall survive, including but not limited | |
| 283 | to Sections 3, 5, 8, 9, 10, 11, 12.2 and 13. Neither party will be | |
| 284 | liable to the other for compensation, indemnity or damages of any sort | |
| 285 | solely as a result of terminating this License in accordance with its | |
| 286 | terms, and termination of this License will be without prejudice to | |
| 287 | any other right or remedy of either party. | |
| 288 | ||
| 289 | 13. Miscellaneous. | |
| 290 | ||
| 291 | 13.1 Government End Users. The Covered Code is a "commercial item" as | |
| 292 | defined in FAR 2.101. Government software and technical data rights | |
| 293 | in the Covered Code include only those rights customarily provided to | |
| 294 | the public as defined in this License. This customary commercial | |
| 295 | license in technical data and software is provided in accordance with | |
| 296 | FAR 12.211 (Technical Data) and 12.212 (Computer Software) and, for | |
| 297 | Department of Defense purchases, DFAR 252.227-7015 (Technical Data -- | |
| 298 | Commercial Items) and 227.7202-3 (Rights in Commercial Computer | |
| 299 | Software or Computer Software Documentation). Accordingly, all U.S. | |
| 300 | Government End Users acquire Covered Code with only those rights set | |
| 301 | forth herein. | |
| 302 | ||
| 303 | 13.2 Relationship of Parties. This License will not be construed as | |
| 304 | creating an agency, partnership, joint venture or any other form of | |
| 305 | legal association between You and Apple, and You will not represent to | |
| 306 | the contrary, whether expressly, by implication, appearance or | |
| 307 | otherwise. | |
| 308 | ||
| 309 | 13.3 Independent Development. Nothing in this License will impair | |
| 310 | Apple's right to acquire, license, develop, have others develop for | |
| 311 | it, market and/or distribute technology or products that perform the | |
| 312 | same or similar functions as, or otherwise compete with, | |
| 313 | Modifications, Larger Works, technology or products that You may | |
| 314 | develop, produce, market or distribute. | |
| 315 | ||
| 316 | 13.4 Waiver; Construction. Failure by Apple to enforce any provision | |
| 317 | of this License will not be deemed a waiver of future enforcement of | |
| 318 | that or any other provision. Any law or regulation which provides | |
| 319 | that the language of a contract shall be construed against the drafter | |
| 320 | will not apply to this License. | |
| 321 | ||
| 322 | 13.5 Severability. (a) If for any reason a court of competent | |
| 323 | jurisdiction finds any provision of this License, or portion thereof, | |
| 324 | to be unenforceable, that provision of the License will be enforced to | |
| 325 | the maximum extent permissible so as to effect the economic benefits | |
| 326 | and intent of the parties, and the remainder of this License will | |
| 327 | continue in full force and effect. (b) Notwithstanding the foregoing, | |
| 328 | if applicable law prohibits or restricts You from fully and/or | |
| 329 | specifically complying with Sections 2 and/or 3 or prevents the | |
| 330 | enforceability of either of those Sections, this License will | |
| 331 | immediately terminate and You must immediately discontinue any use of | |
| 332 | the Covered Code and destroy all copies of it that are in your | |
| 333 | possession or control. | |
| 334 | ||
| 335 | 13.6 Dispute Resolution. Any litigation or other dispute resolution | |
| 336 | between You and Apple relating to this License shall take place in the | |
| 337 | Northern District of California, and You and Apple hereby consent to | |
| 338 | the personal jurisdiction of, and venue in, the state and federal | |
| 339 | courts within that District with respect to this License. The | |
| 340 | application of the United Nations Convention on Contracts for the | |
| 341 | International Sale of Goods is expressly excluded. | |
| 342 | ||
| 343 | 13.7 Entire Agreement; Governing Law. This License constitutes the | |
| 344 | entire agreement between the parties with respect to the subject | |
| 345 | matter hereof. This License shall be governed by the laws of the | |
| 346 | United States and the State of California, except that body of | |
| 347 | California law concerning conflicts of law. | |
| 348 | ||
| 349 | Where You are located in the province of Quebec, Canada, the following | |
| 350 | clause applies: The parties hereby confirm that they have requested | |
| 351 | that this License and all related documents be drafted in English. Les | |
| 352 | parties ont exige que le present contrat et tous les documents | |
| 353 | connexes soient rediges en anglais. | |
| 354 | ||
| 355 | EXHIBIT A. | |
| 356 | ||
| 357 | "Portions Copyright (c) 1999 Apple Computer, Inc. All Rights | |
| 358 | Reserved. This file contains Original Code and/or Modifications of | |
| 359 | Original Code as defined in and that are subject to the Apple Public | |
| 360 | Source License Version 1.1 (the "License"). You may not use this file | |
| 361 | except in compliance with the License. Please obtain a copy of the | |
| 362 | License at http://www.apple.com/publicsource and read it before using | |
| 363 | this file. | |
| 364 | ||
| 365 | The Original Code and all software distributed under the License are | |
| 366 | distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, EITHER | |
| 367 | EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES, | |
| 368 | INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, | |
| 369 | FITNESS FOR A PARTICULAR PURPOSE OR NON- INFRINGEMENT. Please see the | |
| 370 | License for the specific language governing rights and limitations | |
| 371 | under the License." |
| 0 | 2001-05-05 Christoph Pfisterer <cp@chrisp.de> | |
| 1 | ||
| 2 | * dlfcn.h: Added wrapper for C++. | |
| 3 | ||
| 4 | 2001-01-23 Christoph Pfisterer <cp@chrisp.de> | |
| 5 | ||
| 6 | * dlopen.c: Added optional debugging output. Modules are now | |
| 7 | searched for in various directories when no absolute path is | |
| 8 | specified and the module is not found in the current directory. A | |
| 9 | new function, _dl_search_paths, was added to accomplish the | |
| 10 | search. Added an include for <limits.h>, because PATH_MAX is | |
| 11 | defined there. | |
| 12 | * Makefile: Some rearragements for the optional debugging | |
| 13 | output. (Use "make DEBUG=1" to enable it.) | |
| 14 | ||
| 15 | 2001-01-16 Christoph Pfisterer <cp@chrisp.de> | |
| 16 | ||
| 17 | * dlopen.c: Removed #include for ofi.h - it doesn't seem to be | |
| 18 | needed. | |
| 19 |
| 0 | # | |
| 1 | # Makefile for dlcompat | |
| 2 | # | |
| 3 | # | |
| 4 | # Copyright (c) 2001 Christoph Pfisterer. | |
| 5 | # | |
| 6 | # Portions Copyright (c) 1999-2001 Apple Computer, Inc. All Rights | |
| 7 | # Reserved. | |
| 8 | # | |
| 9 | # This file contains Original Code and/or Modifications of Original | |
| 10 | # Code as defined in and that are subject to the Apple Public Source | |
| 11 | # License Version 1.2 (the "License"). You may not use this file | |
| 12 | # except in compliance with the License. Please obtain a copy of the | |
| 13 | # License at http://www.apple.com/publicsource and read it before | |
| 14 | # using this file. | |
| 15 | # | |
| 16 | # The Original Code and all software distributed under the License are | |
| 17 | # distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, EITHER | |
| 18 | # EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES, | |
| 19 | # INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, | |
| 20 | # FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR | |
| 21 | # NON-INFRINGEMENT. Please see the License for the specific language | |
| 22 | # governing rights and limitations under the License. | |
| 23 | # | |
| 24 | ||
| 25 | ||
| 26 | prefix=/usr/local | |
| 27 | DEBUG=0 | |
| 28 | ||
| 29 | CC=cc | |
| 30 | CFLAGS=-Wall -O2 -DDEBUG=$(DEBUG) | |
| 31 | AR=ar cru | |
| 32 | RANLIB=ranlib | |
| 33 | INSTALL=install | |
| 34 | ||
| 35 | OBJS = dlopen.o | |
| 36 | ||
| 37 | ||
| 38 | all: libdl.a libdl.dylib | |
| 39 | ||
| 40 | install: all | |
| 41 | if test ! -d $(prefix)/lib ; then mkdir $(prefix)/lib ; fi | |
| 42 | $(INSTALL) -m 644 libdl.a $(prefix)/lib | |
| 43 | $(RANLIB) $(prefix)/lib/libdl.a | |
| 44 | chmod 644 $(prefix)/lib/libdl.a | |
| 45 | $(INSTALL) -m 755 libdl.dylib $(prefix)/lib | |
| 46 | if test ! -d $(prefix)/include ; then mkdir $(prefix)/include ; fi | |
| 47 | $(INSTALL) -c -m 644 dlfcn.h $(prefix)/include | |
| 48 | ||
| 49 | .c.o: | |
| 50 | $(CC) $(CFLAGS) -fno-common -o $@ -c $< | |
| 51 | ||
| 52 | libdl.a: $(OBJS) | |
| 53 | $(AR) libdl.a $(OBJS) | |
| 54 | $(RANLIB) libdl.a | |
| 55 | ||
| 56 | libdl.dylib: $(OBJS) | |
| 57 | $(CC) -dynamiclib -undefined error -o libdl.dylib $(OBJS) -install_name $(prefix)/lib/libdl.dylib | |
| 58 | ||
| 59 | clean: | |
| 60 | rm -f $(OBJS) libdl.* | |
| 61 | ||
| 62 | # EOF |
| 0 | dlcompat for Darwin | |
| 1 | ===================== | |
| 2 | ||
| 3 | This is release 20010505 of dlcompat. dlcompat is a small library that | |
| 4 | emulates the dlopen() interface on top of Darwin's dyld API. It is | |
| 5 | based on a CVS snapshot of Apple's Darwin CVS repository, taken on | |
| 6 | Jan 16 2001 (and still current as of May 5 2001). Since it's based on | |
| 7 | Apple code, it is released under the terms of the Apple Public Source | |
| 8 | License; see the file APPLE_LICENSE for the text of the license. | |
| 9 | ||
| 10 | Changes were made to automatically search for the module in several | |
| 11 | directories (taken from the environment variables DYLD_LIBRARY_PATH | |
| 12 | and LD_LIBRARY_PATH, plus /usr/lib and /lib) when no absolute path is | |
| 13 | specified and the module is not found in the current directory. If you | |
| 14 | prefer to run unmodified Apple code, download release 20010116. | |
| 15 | ||
| 16 | ||
| 17 | Installation | |
| 18 | -------------- | |
| 19 | As root, type: | |
| 20 | ||
| 21 | make install | |
| 22 | ||
| 23 | This will compile the source file, generate both a static and shared | |
| 24 | library called libdl and install it into /usr/local/lib. The header | |
| 25 | file dlfcn.h will be installed in /usr/local/include. | |
| 26 | ||
| 27 | If you want to place the files somewhere else, run | |
| 28 | ||
| 29 | make clean | |
| 30 | make install prefix=<prefix> | |
| 31 | ||
| 32 | where <prefix> is the hierarchy you want to install into, e.g. /usr | |
| 33 | for /usr/lib and /usr/include (_NOT_ recommended!). | |
| 34 | ||
| 35 | To enable debugging output, run | |
| 36 | ||
| 37 | make clean | |
| 38 | make DEBUG=1 | |
| 39 | make install | |
| 40 | ||
| 41 | Combinations of those commands are left as an excercise to the | |
| 42 | reader. :-) | |
| 43 | ||
| 44 | ||
| 45 | Usage | |
| 46 | ------- | |
| 47 | Software that uses GNU autoconf will likely check for a library called | |
| 48 | libdl, that's why I named it that way. For software that doesn't find | |
| 49 | the library on its own, you must add a '-ldl' to the appropriate | |
| 50 | Makefile (or environment) variable, usually LIBS. | |
| 51 | ||
| 52 | If you installed dlcompat into a directory other than /usr/local/lib, | |
| 53 | you must tell the compiler where to find it. Add '-L<prefix>/lib' to | |
| 54 | LDFLAGS (or CFLAGS) and '-I<prefix>/include' to CPPFLAGS (or CFLAGS). | |
| 55 | ||
| 56 | ||
| 57 | Genesis | |
| 58 | --------- | |
| 59 | The files dlfcn.h and dlopen.c are taken from the Darwin CVS, | |
| 60 | directory Commands/Apple/cctools/libdyld. For release 20010116, I | |
| 61 | removed an unneccessary include statement from dlopen.c and added the | |
| 62 | Makefile. For release 20010123, I added debugging output and library | |
| 63 | searching. The changes are clearly documented, as required by the | |
| 64 | Apple Public Source License. For release 20010505, I added wrappers to | |
| 65 | disable C++ name mangling. That allows the library to be used by C++ | |
| 66 | code, but be aware that there are issues with C++ and bundles, like | |
| 67 | static initializers not being called. | |
| 68 | ||
| 69 | ||
| 70 | Christoph Pfisterer <cp@chrisp.de> |
| 0 | /* | |
| 1 | * This file was modified by Christoph Pfisterer <cp@chrisp.de> | |
| 2 | * on Sat, May 5 2001. See the file "ChangeLog" for details of what | |
| 3 | * was changed. | |
| 4 | * | |
| 5 | * | |
| 6 | * Copyright (c) 1999 Apple Computer, Inc. All rights reserved. | |
| 7 | * | |
| 8 | * @APPLE_LICENSE_HEADER_START@ | |
| 9 | * | |
| 10 | * Portions Copyright (c) 1999 Apple Computer, Inc. All Rights | |
| 11 | * Reserved. This file contains Original Code and/or Modifications of | |
| 12 | * Original Code as defined in and that are subject to the Apple Public | |
| 13 | * Source License Version 1.1 (the "License"). You may not use this file | |
| 14 | * except in compliance with the License. Please obtain a copy of the | |
| 15 | * License at http://www.apple.com/publicsource and read it before using | |
| 16 | * this file. | |
| 17 | * | |
| 18 | * The Original Code and all software distributed under the License are | |
| 19 | * distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, EITHER | |
| 20 | * EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES, | |
| 21 | * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, | |
| 22 | * FITNESS FOR A PARTICULAR PURPOSE OR NON- INFRINGEMENT. Please see the | |
| 23 | * License for the specific language governing rights and limitations | |
| 24 | * under the License. | |
| 25 | * | |
| 26 | * @APPLE_LICENSE_HEADER_END@ | |
| 27 | */ | |
| 28 | ||
| 29 | #ifdef __cplusplus | |
| 30 | extern "C" { | |
| 31 | #endif | |
| 32 | ||
| 33 | extern void * dlopen( | |
| 34 | const char *path, | |
| 35 | int mode); | |
| 36 | extern void * dlsym( | |
| 37 | void * handle, | |
| 38 | const char *symbol); | |
| 39 | extern const char * dlerror( | |
| 40 | void); | |
| 41 | extern int dlclose( | |
| 42 | void * handle); | |
| 43 | ||
| 44 | #define RTLD_LAZY 0x1 | |
| 45 | #define RTLD_NOW 0x2 | |
| 46 | #define RTLD_LOCAL 0x4 | |
| 47 | #define RTLD_GLOBAL 0x8 | |
| 48 | #define RTLD_NOLOAD 0x10 | |
| 49 | #define RTLD_SHARED 0x20 /* not used, the default */ | |
| 50 | #define RTLD_UNSHARED 0x40 | |
| 51 | #define RTLD_NODELETE 0x80 | |
| 52 | #define RTLD_LAZY_UNDEF 0x100 | |
| 53 | ||
| 54 | #ifdef __cplusplus | |
| 55 | } | |
| 56 | #endif |
| 0 | /* | |
| 1 | * This file was modified by Christoph Pfisterer <cp@chrisp.de> | |
| 2 | * on Tue, Jan 23 2001. See the file "ChangeLog" for details of what | |
| 3 | * was changed. | |
| 4 | * | |
| 5 | * | |
| 6 | * Copyright (c) 1999 Apple Computer, Inc. All rights reserved. | |
| 7 | * | |
| 8 | * @APPLE_LICENSE_HEADER_START@ | |
| 9 | * | |
| 10 | * Portions Copyright (c) 1999 Apple Computer, Inc. All Rights | |
| 11 | * Reserved. This file contains Original Code and/or Modifications of | |
| 12 | * Original Code as defined in and that are subject to the Apple Public | |
| 13 | * Source License Version 1.1 (the "License"). You may not use this file | |
| 14 | * except in compliance with the License. Please obtain a copy of the | |
| 15 | * License at http://www.apple.com/publicsource and read it before using | |
| 16 | * this file. | |
| 17 | * | |
| 18 | * The Original Code and all software distributed under the License are | |
| 19 | * distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, EITHER | |
| 20 | * EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES, | |
| 21 | * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, | |
| 22 | * FITNESS FOR A PARTICULAR PURPOSE OR NON- INFRINGEMENT. Please see the | |
| 23 | * License for the specific language governing rights and limitations | |
| 24 | * under the License. | |
| 25 | * | |
| 26 | * @APPLE_LICENSE_HEADER_END@ | |
| 27 | */ | |
| 28 | #include <stdio.h> | |
| 29 | #include <stdlib.h> | |
| 30 | #include <string.h> | |
| 31 | #include <errno.h> | |
| 32 | #include <sys/types.h> | |
| 33 | #include <sys/stat.h> | |
| 34 | #include <limits.h> | |
| 35 | #include "mach-o/dyld.h" | |
| 36 | #include "dlfcn.h" | |
| 37 | ||
| 38 | /* | |
| 39 | * debugging macros | |
| 40 | */ | |
| 41 | #if DEBUG > 0 | |
| 42 | #define DEBUG_PRINT(format) fprintf(stderr,(format));fflush(stderr) | |
| 43 | #define DEBUG_PRINT1(format,arg1) fprintf(stderr,(format),(arg1));\ | |
| 44 | fflush(stderr) | |
| 45 | #define DEBUG_PRINT2(format,arg1,arg2) fprintf(stderr,(format),\ | |
| 46 | (arg1),(arg2));fflush(stderr) | |
| 47 | #define DEBUG_PRINT3(format,arg1,arg2,arg3) fprintf(stderr,(format),\ | |
| 48 | (arg1),(arg2),(arg3));fflush(stderr) | |
| 49 | #else | |
| 50 | #define DEBUG_PRINT(format) /**/ | |
| 51 | #define DEBUG_PRINT1(format,arg1) /**/ | |
| 52 | #define DEBUG_PRINT2(format,arg1,arg2) /**/ | |
| 53 | #define DEBUG_PRINT3(format,arg1,arg2,arg3) /**/ | |
| 54 | #undef DEBUG | |
| 55 | #endif | |
| 56 | ||
| 57 | /* | |
| 58 | * The structure of a dlopen() handle. | |
| 59 | */ | |
| 60 | struct dlopen_handle { | |
| 61 | dev_t dev; /* the path's device and inode number from stat(2) */ | |
| 62 | ino_t ino; | |
| 63 | int dlopen_mode; /* current dlopen mode for this handle */ | |
| 64 | int dlopen_count; /* number of times dlopen() called on this handle */ | |
| 65 | NSModule module; /* the NSModule returned by NSLinkModule() */ | |
| 66 | struct dlopen_handle *prev; | |
| 67 | struct dlopen_handle *next; | |
| 68 | }; | |
| 69 | static struct dlopen_handle *dlopen_handles = NULL; | |
| 70 | static const struct dlopen_handle main_program_handle = {NULL}; | |
| 71 | static char *dlerror_pointer = NULL; | |
| 72 | ||
| 73 | /* | |
| 74 | * NSMakePrivateModulePublic() is not part of the public dyld API so we define | |
| 75 | * it here. The internal dyld function pointer for | |
| 76 | * __dyld_NSMakePrivateModulePublic is returned so thats all that maters to get | |
| 77 | * the functionality need to implement the dlopen() interfaces. | |
| 78 | */ | |
| 79 | static | |
| 80 | int | |
| 81 | NSMakePrivateModulePublic( | |
| 82 | NSModule module) | |
| 83 | { | |
| 84 | static int (*p)(NSModule module) = NULL; | |
| 85 | ||
| 86 | if(p == NULL) | |
| 87 | _dyld_func_lookup("__dyld_NSMakePrivateModulePublic", | |
| 88 | (unsigned long *)&p); | |
| 89 | if(p == NULL){ | |
| 90 | #ifdef DEBUG | |
| 91 | printf("_dyld_func_lookup of __dyld_NSMakePrivateModulePublic " | |
| 92 | "failed\n"); | |
| 93 | #endif | |
| 94 | return(FALSE); | |
| 95 | } | |
| 96 | return(p(module)); | |
| 97 | } | |
| 98 | ||
| 99 | /* | |
| 100 | * helper routine: search for a named module in various locations | |
| 101 | */ | |
| 102 | static | |
| 103 | int | |
| 104 | _dl_search_paths( | |
| 105 | const char *filename, | |
| 106 | char *pathbuf, | |
| 107 | struct stat *stat_buf) | |
| 108 | { | |
| 109 | const char *pathspec; | |
| 110 | const char *element; | |
| 111 | const char *p; | |
| 112 | char *q; | |
| 113 | char *pathbuf_end; | |
| 114 | const char *envvars[] = { | |
| 115 | "$DYLD_LIBRARY_PATH", | |
| 116 | "$LD_LIBRARY_PATH", | |
| 117 | "/usr/lib:/lib", | |
| 118 | NULL }; | |
| 119 | int envvar_index; | |
| 120 | ||
| 121 | pathbuf_end = pathbuf + PATH_MAX - 8; | |
| 122 | ||
| 123 | for(envvar_index = 0; envvars[envvar_index]; envvar_index++){ | |
| 124 | if(envvars[envvar_index][0] == '$'){ | |
| 125 | pathspec = getenv(envvars[envvar_index]+1); | |
| 126 | } | |
| 127 | else { | |
| 128 | pathspec = envvars[envvar_index]; | |
| 129 | } | |
| 130 | ||
| 131 | if(pathspec != NULL){ | |
| 132 | element = pathspec; | |
| 133 | while(*element){ | |
| 134 | /* extract path list element */ | |
| 135 | p = element; | |
| 136 | q = pathbuf; | |
| 137 | while(*p && *p != ':' && q < pathbuf_end) | |
| 138 | *q++ = *p++; | |
| 139 | if(q == pathbuf){ /* empty element */ | |
| 140 | if(*p){ | |
| 141 | element = p+1; | |
| 142 | continue; | |
| 143 | } | |
| 144 | break; | |
| 145 | } | |
| 146 | if (*p){ | |
| 147 | element = p+1; | |
| 148 | } | |
| 149 | else{ | |
| 150 | element = p; /* this terminates the loop */ | |
| 151 | } | |
| 152 | ||
| 153 | /* add slash if neccessary */ | |
| 154 | if(*(q-1) != '/' && q < pathbuf_end){ | |
| 155 | *q++ = '/'; | |
| 156 | } | |
| 157 | ||
| 158 | /* append module name */ | |
| 159 | p = filename; | |
| 160 | while(*p && q < pathbuf_end) *q++ = *p++; | |
| 161 | *q++ = 0; | |
| 162 | ||
| 163 | if(q >= pathbuf_end){ | |
| 164 | /* maybe add an error message here */ | |
| 165 | break; | |
| 166 | } | |
| 167 | ||
| 168 | if(stat(pathbuf, stat_buf) == 0){ | |
| 169 | return 0; | |
| 170 | } | |
| 171 | } | |
| 172 | } | |
| 173 | } | |
| 174 | ||
| 175 | /* we have searched everywhere, now we give up */ | |
| 176 | return -1; | |
| 177 | } | |
| 178 | ||
| 179 | /* | |
| 180 | * dlopen() the MacOS X version of the FreeBSD dlopen() interface. | |
| 181 | */ | |
| 182 | void * | |
| 183 | dlopen( | |
| 184 | const char *path, | |
| 185 | int mode) | |
| 186 | { | |
| 187 | const char *module_path; | |
| 188 | void *retval; | |
| 189 | struct stat stat_buf; | |
| 190 | NSObjectFileImage objectFileImage; | |
| 191 | NSObjectFileImageReturnCode ofile_result_code; | |
| 192 | NSModule module; | |
| 193 | struct dlopen_handle *p; | |
| 194 | unsigned long options; | |
| 195 | NSSymbol NSSymbol; | |
| 196 | void (*init)(void); | |
| 197 | char pathbuf[PATH_MAX]; | |
| 198 | ||
| 199 | DEBUG_PRINT2("libdl: dlopen(%s,0x%x) -> ", path, (unsigned int)mode); | |
| 200 | ||
| 201 | dlerror_pointer = NULL; | |
| 202 | /* | |
| 203 | * A NULL path is to indicate the caller wants a handle for the | |
| 204 | * main program. | |
| 205 | */ | |
| 206 | if(path == NULL){ | |
| 207 | retval = (void *)&main_program_handle; | |
| 208 | DEBUG_PRINT1("main / %p\n", retval); | |
| 209 | return(retval); | |
| 210 | } | |
| 211 | ||
| 212 | /* see if the path exists and if so get the device and inode number */ | |
| 213 | if(stat(path, &stat_buf) == -1){ | |
| 214 | dlerror_pointer = strerror(errno); | |
| 215 | ||
| 216 | if(path[0] == '/'){ | |
| 217 | DEBUG_PRINT1("ERROR (stat): %s\n", dlerror_pointer); | |
| 218 | return(NULL); | |
| 219 | } | |
| 220 | ||
| 221 | /* search for the module in various places */ | |
| 222 | if(_dl_search_paths(path, pathbuf, &stat_buf)){ | |
| 223 | /* dlerror_pointer is unmodified */ | |
| 224 | DEBUG_PRINT1("ERROR (stat): %s\n", dlerror_pointer); | |
| 225 | return(NULL); | |
| 226 | } | |
| 227 | DEBUG_PRINT1("found %s -> ", pathbuf); | |
| 228 | module_path = pathbuf; | |
| 229 | dlerror_pointer = NULL; | |
| 230 | } | |
| 231 | else{ | |
| 232 | module_path = path; | |
| 233 | } | |
| 234 | ||
| 235 | /* | |
| 236 | * If we don't want an unshared handle see if we already have a handle | |
| 237 | * for this path. | |
| 238 | */ | |
| 239 | if((mode & RTLD_UNSHARED) != RTLD_UNSHARED){ | |
| 240 | p = dlopen_handles; | |
| 241 | while(p != NULL){ | |
| 242 | if(p->dev == stat_buf.st_dev && p->ino == stat_buf.st_ino){ | |
| 243 | /* skip unshared handles */ | |
| 244 | if((p->dlopen_mode & RTLD_UNSHARED) == RTLD_UNSHARED) | |
| 245 | continue; | |
| 246 | /* | |
| 247 | * We have already created a handle for this path. The | |
| 248 | * caller might be trying to promote an RTLD_LOCAL handle | |
| 249 | * to a RTLD_GLOBAL. Or just looking it up with | |
| 250 | * RTLD_NOLOAD. | |
| 251 | */ | |
| 252 | if((p->dlopen_mode & RTLD_LOCAL) == RTLD_LOCAL && | |
| 253 | (mode & RTLD_GLOBAL) == RTLD_GLOBAL){ | |
| 254 | /* promote the handle */ | |
| 255 | if(NSMakePrivateModulePublic(p->module) == TRUE){ | |
| 256 | p->dlopen_mode &= ~RTLD_LOCAL; | |
| 257 | p->dlopen_mode |= RTLD_GLOBAL; | |
| 258 | p->dlopen_count++; | |
| 259 | DEBUG_PRINT1("%p\n", p); | |
| 260 | return(p); | |
| 261 | } | |
| 262 | else{ | |
| 263 | dlerror_pointer = "can't promote handle from " | |
| 264 | "RTLD_LOCAL to RTLD_GLOBAL"; | |
| 265 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 266 | return(NULL); | |
| 267 | } | |
| 268 | } | |
| 269 | p->dlopen_count++; | |
| 270 | DEBUG_PRINT1("%p\n", p); | |
| 271 | return(p); | |
| 272 | } | |
| 273 | p = p->next; | |
| 274 | } | |
| 275 | } | |
| 276 | ||
| 277 | /* | |
| 278 | * We do not have a handle for this path if we were just trying to | |
| 279 | * look it up return NULL to indicate we don't have it. | |
| 280 | */ | |
| 281 | if((mode & RTLD_NOLOAD) == RTLD_NOLOAD){ | |
| 282 | dlerror_pointer = "no existing handle for path RTLD_NOLOAD test"; | |
| 283 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 284 | return(NULL); | |
| 285 | } | |
| 286 | ||
| 287 | /* try to create an object file image from this path */ | |
| 288 | ofile_result_code = NSCreateObjectFileImageFromFile(module_path, | |
| 289 | &objectFileImage); | |
| 290 | if(ofile_result_code != NSObjectFileImageSuccess){ | |
| 291 | switch(ofile_result_code){ | |
| 292 | case NSObjectFileImageFailure: | |
| 293 | dlerror_pointer = "object file setup failure"; | |
| 294 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 295 | return(NULL); | |
| 296 | case NSObjectFileImageInappropriateFile: | |
| 297 | dlerror_pointer = "not a Mach-O MH_BUNDLE file type"; | |
| 298 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 299 | return(NULL); | |
| 300 | case NSObjectFileImageArch: | |
| 301 | dlerror_pointer = "no object for this architecture"; | |
| 302 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 303 | return(NULL); | |
| 304 | case NSObjectFileImageFormat: | |
| 305 | dlerror_pointer = "bad object file format"; | |
| 306 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 307 | return(NULL); | |
| 308 | case NSObjectFileImageAccess: | |
| 309 | dlerror_pointer = "can't read object file"; | |
| 310 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 311 | return(NULL); | |
| 312 | default: | |
| 313 | dlerror_pointer = "unknown error from " | |
| 314 | "NSCreateObjectFileImageFromFile()"; | |
| 315 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 316 | return(NULL); | |
| 317 | } | |
| 318 | } | |
| 319 | ||
| 320 | /* try to link in this object file image */ | |
| 321 | options = NSLINKMODULE_OPTION_PRIVATE; | |
| 322 | if((mode & RTLD_NOW) == RTLD_NOW) | |
| 323 | options |= NSLINKMODULE_OPTION_BINDNOW; | |
| 324 | module = NSLinkModule(objectFileImage, module_path, options); | |
| 325 | NSDestroyObjectFileImage(objectFileImage) ; | |
| 326 | if(module == NULL){ | |
| 327 | dlerror_pointer = "NSLinkModule() failed for dlopen()"; | |
| 328 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 329 | return(NULL); | |
| 330 | } | |
| 331 | ||
| 332 | /* | |
| 333 | * If the handle is to be global promote the handle. It is done this | |
| 334 | * way to avoid multiply defined symbols. | |
| 335 | */ | |
| 336 | if((mode & RTLD_GLOBAL) == RTLD_GLOBAL){ | |
| 337 | if(NSMakePrivateModulePublic(module) == FALSE){ | |
| 338 | dlerror_pointer = "can't promote handle from RTLD_LOCAL to " | |
| 339 | "RTLD_GLOBAL"; | |
| 340 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 341 | return(NULL); | |
| 342 | } | |
| 343 | } | |
| 344 | ||
| 345 | p = malloc(sizeof(struct dlopen_handle)); | |
| 346 | if(p == NULL){ | |
| 347 | dlerror_pointer = "can't allocate memory for the dlopen handle"; | |
| 348 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 349 | return(NULL); | |
| 350 | } | |
| 351 | ||
| 352 | /* fill in the handle */ | |
| 353 | p->dev = stat_buf.st_dev; | |
| 354 | p->ino = stat_buf.st_ino; | |
| 355 | if(mode & RTLD_GLOBAL) | |
| 356 | p->dlopen_mode = RTLD_GLOBAL; | |
| 357 | else | |
| 358 | p->dlopen_mode = RTLD_LOCAL; | |
| 359 | p->dlopen_mode |= (mode & RTLD_UNSHARED) | | |
| 360 | (mode & RTLD_NODELETE) | | |
| 361 | (mode & RTLD_LAZY_UNDEF); | |
| 362 | p->dlopen_count = 1; | |
| 363 | p->module = module; | |
| 364 | p->prev = NULL; | |
| 365 | p->next = dlopen_handles; | |
| 366 | if(dlopen_handles != NULL) | |
| 367 | dlopen_handles->prev = p; | |
| 368 | dlopen_handles = p; | |
| 369 | ||
| 370 | /* call the init function if one exists */ | |
| 371 | NSSymbol = NSLookupSymbolInModule(p->module, "__init"); | |
| 372 | if(NSSymbol != NULL){ | |
| 373 | init = NSAddressOfSymbol(NSSymbol); | |
| 374 | init(); | |
| 375 | } | |
| 376 | ||
| 377 | DEBUG_PRINT1("%p\n", p); | |
| 378 | return(p); | |
| 379 | } | |
| 380 | ||
| 381 | /* | |
| 382 | * dlsym() the MacOS X version of the FreeBSD dlopen() interface. | |
| 383 | */ | |
| 384 | void * | |
| 385 | dlsym( | |
| 386 | void * handle, | |
| 387 | const char *symbol) | |
| 388 | { | |
| 389 | struct dlopen_handle *dlopen_handle, *p; | |
| 390 | NSSymbol NSSymbol; | |
| 391 | void *address; | |
| 392 | ||
| 393 | DEBUG_PRINT2("libdl: dlsym(%p,%s) -> ", handle, symbol); | |
| 394 | ||
| 395 | dlopen_handle = (struct dlopen_handle *)handle; | |
| 396 | ||
| 397 | /* | |
| 398 | * If this is the handle for the main program do a global lookup. | |
| 399 | */ | |
| 400 | if(dlopen_handle == (struct dlopen_handle *)&main_program_handle){ | |
| 401 | if(NSIsSymbolNameDefined(symbol) == TRUE){ | |
| 402 | NSSymbol = NSLookupAndBindSymbol(symbol); | |
| 403 | address = NSAddressOfSymbol(NSSymbol); | |
| 404 | dlerror_pointer = NULL; | |
| 405 | DEBUG_PRINT1("%p\n", address); | |
| 406 | return(address); | |
| 407 | } | |
| 408 | else{ | |
| 409 | dlerror_pointer = "symbol not found"; | |
| 410 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 411 | return(NULL); | |
| 412 | } | |
| 413 | } | |
| 414 | ||
| 415 | /* | |
| 416 | * Find this handle and do a lookup in just this module. | |
| 417 | */ | |
| 418 | p = dlopen_handles; | |
| 419 | while(p != NULL){ | |
| 420 | if(dlopen_handle == p){ | |
| 421 | NSSymbol = NSLookupSymbolInModule(p->module, symbol); | |
| 422 | if(NSSymbol != NULL){ | |
| 423 | address = NSAddressOfSymbol(NSSymbol); | |
| 424 | dlerror_pointer = NULL; | |
| 425 | DEBUG_PRINT1("%p\n", address); | |
| 426 | return(address); | |
| 427 | } | |
| 428 | else{ | |
| 429 | dlerror_pointer = "symbol not found"; | |
| 430 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 431 | return(NULL); | |
| 432 | } | |
| 433 | } | |
| 434 | p = p->next; | |
| 435 | } | |
| 436 | ||
| 437 | dlerror_pointer = "bad handle passed to dlsym()"; | |
| 438 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 439 | return(NULL); | |
| 440 | } | |
| 441 | ||
| 442 | /* | |
| 443 | * dlerror() the MacOS X version of the FreeBSD dlopen() interface. | |
| 444 | */ | |
| 445 | const char * | |
| 446 | dlerror( | |
| 447 | void) | |
| 448 | { | |
| 449 | const char *p; | |
| 450 | ||
| 451 | p = (const char *)dlerror_pointer; | |
| 452 | dlerror_pointer = NULL; | |
| 453 | return(p); | |
| 454 | } | |
| 455 | ||
| 456 | /* | |
| 457 | * dlclose() the MacOS X version of the FreeBSD dlopen() interface. | |
| 458 | */ | |
| 459 | int | |
| 460 | dlclose( | |
| 461 | void * handle) | |
| 462 | { | |
| 463 | struct dlopen_handle *p, *q; | |
| 464 | unsigned long options; | |
| 465 | NSSymbol NSSymbol; | |
| 466 | void (*fini)(void); | |
| 467 | ||
| 468 | DEBUG_PRINT1("libdl: dlclose(%p) -> ", handle); | |
| 469 | ||
| 470 | dlerror_pointer = NULL; | |
| 471 | q = (struct dlopen_handle *)handle; | |
| 472 | p = dlopen_handles; | |
| 473 | while(p != NULL){ | |
| 474 | if(p == q){ | |
| 475 | /* if the dlopen() count is not zero we are done */ | |
| 476 | p->dlopen_count--; | |
| 477 | if(p->dlopen_count != 0){ | |
| 478 | DEBUG_PRINT("OK"); | |
| 479 | return(0); | |
| 480 | } | |
| 481 | ||
| 482 | /* call the fini function if one exists */ | |
| 483 | NSSymbol = NSLookupSymbolInModule(p->module, "__fini"); | |
| 484 | if(NSSymbol != NULL){ | |
| 485 | fini = NSAddressOfSymbol(NSSymbol); | |
| 486 | fini(); | |
| 487 | } | |
| 488 | ||
| 489 | /* unlink the module for this handle */ | |
| 490 | options = 0; | |
| 491 | if(p->dlopen_mode & RTLD_NODELETE) | |
| 492 | options |= NSUNLINKMODULE_OPTION_KEEP_MEMORY_MAPPED; | |
| 493 | if(p->dlopen_mode & RTLD_LAZY_UNDEF) | |
| 494 | options |= NSUNLINKMODULE_OPTION_RESET_LAZY_REFERENCES; | |
| 495 | if(NSUnLinkModule(p->module, options) == FALSE){ | |
| 496 | dlerror_pointer = "NSUnLinkModule() failed for dlclose()"; | |
| 497 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 498 | return(-1); | |
| 499 | } | |
| 500 | if(p->prev != NULL) | |
| 501 | p->prev->next = p->next; | |
| 502 | if(p->next != NULL) | |
| 503 | p->next->prev = p->prev; | |
| 504 | if(dlopen_handles == p) | |
| 505 | dlopen_handles = p->next; | |
| 506 | free(p); | |
| 507 | DEBUG_PRINT("OK"); | |
| 508 | return(0); | |
| 509 | } | |
| 510 | p = p->next; | |
| 511 | } | |
| 512 | dlerror_pointer = "invalid handle passed to dlclose()"; | |
| 513 | DEBUG_PRINT1("ERROR: %s\n", dlerror_pointer); | |
| 514 | return(-1); | |
| 515 | } |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | Network K. Burdis | |
| 4 | Internet-Draft Rhodes University | |
| 5 | Expires: November 28, 2003 R. Naffah | |
| 6 | Forge Research | |
| 7 | May 30, 2003 | |
| 8 | ||
| 9 | ||
| 10 | Secure Remote Password Authentication Mechanism | |
| 11 | draft-burdis-cat-srp-sasl-08 | |
| 12 | ||
| 13 | Status of this Memo | |
| 14 | ||
| 15 | This document is an Internet-Draft and is in full conformance with | |
| 16 | all provisions of Section 10 of RFC2026. | |
| 17 | ||
| 18 | Internet-Drafts are working documents of the Internet Engineering | |
| 19 | Task Force (IETF), its areas, and its working groups. Note that other | |
| 20 | groups may also distribute working documents as Internet-Drafts. | |
| 21 | ||
| 22 | Internet-Drafts are draft documents valid for a maximum of six months | |
| 23 | and may be updated, replaced, or obsoleted by other documents at any | |
| 24 | time. It is inappropriate to use Internet-Drafts as reference | |
| 25 | material or to cite them other than as "work in progress." | |
| 26 | ||
| 27 | The list of current Internet-Drafts can be accessed at http:// | |
| 28 | www.ietf.org/ietf/1id-abstracts.txt. | |
| 29 | ||
| 30 | The list of Internet-Draft Shadow Directories can be accessed at | |
| 31 | http://www.ietf.org/shadow.html. | |
| 32 | ||
| 33 | This Internet-Draft will expire on November 28, 2003. | |
| 34 | ||
| 35 | Copyright Notice | |
| 36 | ||
| 37 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 38 | ||
| 39 | Abstract | |
| 40 | ||
| 41 | This document describes an authentication mechanism based on the | |
| 42 | Secure Remote Password protocol (SRP-6) and how to use it with the | |
| 43 | authentication frameworks Secure Authentication and Security Layer | |
| 44 | (SASL), Generic Security Services Application Programming Interface | |
| 45 | (GSS-API) and Extensible Authentication Protocol (EAP). This | |
| 46 | mechanism performs mutual authentication and can provide a security | |
| 47 | layer with replay detection, integrity protection and/or | |
| 48 | confidentiality protection. | |
| 49 | ||
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | Burdis & Naffah Expires November 28, 2003 [Page 1] | |
| 56 | ||
| 57 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 58 | ||
| 59 | ||
| 60 | Table of Contents | |
| 61 | ||
| 62 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
| 63 | 2. Conventions Used in this Document . . . . . . . . . . . . . 5 | |
| 64 | 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 6 | |
| 65 | 3.1 Scalar Numbers . . . . . . . . . . . . . . . . . . . . . . . 6 | |
| 66 | 3.2 Multi-Precision Integers . . . . . . . . . . . . . . . . . . 6 | |
| 67 | 3.3 Octet Sequences . . . . . . . . . . . . . . . . . . . . . . 7 | |
| 68 | 3.4 Extended Octet Sequences . . . . . . . . . . . . . . . . . . 7 | |
| 69 | 3.5 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |
| 70 | 3.6 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |
| 71 | 3.7 Data Element Size Limits . . . . . . . . . . . . . . . . . . 8 | |
| 72 | 3.8 Unsigned Integers . . . . . . . . . . . . . . . . . . . . . 8 | |
| 73 | 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 9 | |
| 74 | 4.1 Client Sends its Identity . . . . . . . . . . . . . . . . . 11 | |
| 75 | 4.2 Server Agrees to Re-use Parameters of a Previous Session . . 11 | |
| 76 | 4.3 Server Sends Protocol Elements . . . . . . . . . . . . . . . 12 | |
| 77 | 4.4 Client Sends its Ephemeral Public Key and Evidence . . . . . 15 | |
| 78 | 4.5 Server Verifies Client's Evidence and Sends its Evidence . . 17 | |
| 79 | 5. Security Layer . . . . . . . . . . . . . . . . . . . . . . . 19 | |
| 80 | 5.1 Cryptographic Primitives . . . . . . . . . . . . . . . . . . 20 | |
| 81 | 5.1.1 Pseudo Random Number Generator . . . . . . . . . . . . . . . 20 | |
| 82 | 5.1.2 Key Derivation Function . . . . . . . . . . . . . . . . . . 22 | |
| 83 | 5.2 Confidentiality Protection . . . . . . . . . . . . . . . . . 23 | |
| 84 | 5.3 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 24 | |
| 85 | 5.4 Integrity Protection . . . . . . . . . . . . . . . . . . . . 25 | |
| 86 | 5.5 Summary of Security Layer Output . . . . . . . . . . . . . . 25 | |
| 87 | 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |
| 88 | 6.1 Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 27 | |
| 89 | 6.2 Modulus and Generator Values . . . . . . . . . . . . . . . . 27 | |
| 90 | 6.3 Replay Detection Sequence Number Counters . . . . . . . . . 27 | |
| 91 | 6.4 Re-using the Parameters of a Previous Session . . . . . . . 28 | |
| 92 | 7. SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |
| 93 | 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |
| 94 | 7.2 Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . 30 | |
| 95 | 7.3 Security Layer . . . . . . . . . . . . . . . . . . . . . . . 30 | |
| 96 | 7.4 Profile Considerations . . . . . . . . . . . . . . . . . . . 30 | |
| 97 | 7.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |
| 98 | 8. GSS-API . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |
| 99 | 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |
| 100 | 8.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 34 | |
| 101 | 8.3 Initial Token . . . . . . . . . . . . . . . . . . . . . . . 34 | |
| 102 | 8.4 Security Layer . . . . . . . . . . . . . . . . . . . . . . . 35 | |
| 103 | 9. EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |
| 104 | 9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |
| 105 | 9.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 36 | |
| 106 | 9.3 Method Details . . . . . . . . . . . . . . . . . . . . . . . 36 | |
| 107 | 9.4 Security Claims . . . . . . . . . . . . . . . . . . . . . . 37 | |
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | Burdis & Naffah Expires November 28, 2003 [Page 2] | |
| 112 | ||
| 113 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 114 | ||
| 115 | ||
| 116 | 10. Security Considerations . . . . . . . . . . . . . . . . . . 40 | |
| 117 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 | |
| 118 | Normative References . . . . . . . . . . . . . . . . . . . . 42 | |
| 119 | Informative References . . . . . . . . . . . . . . . . . . . 44 | |
| 120 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 | |
| 121 | A. Modulus and Generator Values . . . . . . . . . . . . . . . . 47 | |
| 122 | B. Changes since the previous draft . . . . . . . . . . . . . . 49 | |
| 123 | Intellectual Property and Copyright Statements . . . . . . . 50 | |
| 124 | ||
| 125 | ||
| 126 | ||
| 127 | ||
| 128 | ||
| 129 | ||
| 130 | ||
| 131 | ||
| 132 | ||
| 133 | ||
| 134 | ||
| 135 | ||
| 136 | ||
| 137 | ||
| 138 | ||
| 139 | ||
| 140 | ||
| 141 | ||
| 142 | ||
| 143 | ||
| 144 | ||
| 145 | ||
| 146 | ||
| 147 | ||
| 148 | ||
| 149 | ||
| 150 | ||
| 151 | ||
| 152 | ||
| 153 | ||
| 154 | ||
| 155 | ||
| 156 | ||
| 157 | ||
| 158 | ||
| 159 | ||
| 160 | ||
| 161 | ||
| 162 | ||
| 163 | ||
| 164 | ||
| 165 | ||
| 166 | ||
| 167 | Burdis & Naffah Expires November 28, 2003 [Page 3] | |
| 168 | ||
| 169 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 170 | ||
| 171 | ||
| 172 | 1. Introduction | |
| 173 | ||
| 174 | The Secure Remote Password (SRP) is a password-based, zero-knowledge, | |
| 175 | authentication and key-exchange protocol developed by Thomas Wu. It | |
| 176 | has good performance, is not plaintext-equivalent and maintains | |
| 177 | perfect forward secrecy. It provides authentication (optionally | |
| 178 | mutual authentication) and the negotiation of a shared context key | |
| 179 | [SRP]. | |
| 180 | ||
| 181 | The mechanism described herein is based on the SRP-6 protocol, | |
| 182 | described in [SRP-6] and [SRP-6i]. SRP-6 is an improved version of | |
| 183 | the original SRP protocol (also called SRP-3) described in | |
| 184 | [RFC-2945]. Due to the design of the mechanism, mutual | |
| 185 | authentication is MANDATORY. | |
| 186 | ||
| 187 | ||
| 188 | ||
| 189 | ||
| 190 | ||
| 191 | ||
| 192 | ||
| 193 | ||
| 194 | ||
| 195 | ||
| 196 | ||
| 197 | ||
| 198 | ||
| 199 | ||
| 200 | ||
| 201 | ||
| 202 | ||
| 203 | ||
| 204 | ||
| 205 | ||
| 206 | ||
| 207 | ||
| 208 | ||
| 209 | ||
| 210 | ||
| 211 | ||
| 212 | ||
| 213 | ||
| 214 | ||
| 215 | ||
| 216 | ||
| 217 | ||
| 218 | ||
| 219 | ||
| 220 | ||
| 221 | ||
| 222 | ||
| 223 | Burdis & Naffah Expires November 28, 2003 [Page 4] | |
| 224 | ||
| 225 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 226 | ||
| 227 | ||
| 228 | 2. Conventions Used in this Document | |
| 229 | ||
| 230 | o A hex digit is an element of the set: | |
| 231 | ||
| 232 | {0, 1, 2, 3, 4, 5, 6, 7, 8 , 9, A, B, C, D, E, F} | |
| 233 | ||
| 234 | A hex digit is the representation of a 4-bit string. Examples: | |
| 235 | ||
| 236 | 7 = 0111 | |
| 237 | ||
| 238 | A = 1010 | |
| 239 | ||
| 240 | o An octet is an 8-bit string. In this document an octet may be | |
| 241 | written as a pair of hex digits. Examples: | |
| 242 | ||
| 243 | 7A = 01111010 | |
| 244 | ||
| 245 | 02 = 00000010 | |
| 246 | ||
| 247 | o All data is encoded and sent in network byte order (big-endian). | |
| 248 | ||
| 249 | o The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | |
| 250 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" | |
| 251 | in this document are to be interpreted as described in [RFC-2119]. | |
| 252 | ||
| 253 | ||
| 254 | ||
| 255 | ||
| 256 | ||
| 257 | ||
| 258 | ||
| 259 | ||
| 260 | ||
| 261 | ||
| 262 | ||
| 263 | ||
| 264 | ||
| 265 | ||
| 266 | ||
| 267 | ||
| 268 | ||
| 269 | ||
| 270 | ||
| 271 | ||
| 272 | ||
| 273 | ||
| 274 | ||
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | Burdis & Naffah Expires November 28, 2003 [Page 5] | |
| 280 | ||
| 281 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 282 | ||
| 283 | ||
| 284 | 3. Data Element Formats | |
| 285 | ||
| 286 | This section describes the encoding of the data elements used by the | |
| 287 | mechanism described in this document. | |
| 288 | ||
| 289 | 3.1 Scalar Numbers | |
| 290 | ||
| 291 | Scalar numbers are unsigned quantities. Using b[k] to refer to the | |
| 292 | k-th octet being processed, the value of a two-octet scalar is: | |
| 293 | ||
| 294 | ((b[0] << 8) + b[1]), | |
| 295 | ||
| 296 | where << is the bit left-shift operator. The value of a four-octet | |
| 297 | scalar is: | |
| 298 | ||
| 299 | ((b[0] << 24) + (b[1] << 16) + (b[2] << 8) + b[3]). | |
| 300 | ||
| 301 | ||
| 302 | 3.2 Multi-Precision Integers | |
| 303 | ||
| 304 | Multi-Precision Integers, or MPIs, are positive integers used to hold | |
| 305 | large integers used in cryptographic computations. | |
| 306 | ||
| 307 | MPIs are encoded using a scheme inspired by that used by OpenPGP - | |
| 308 | [RFC-2440] (section 3.2) - for encoding such entities: | |
| 309 | ||
| 310 | The encoded form of an MPI SHALL consist of two pieces: a | |
| 311 | two-octet scalar that represents the length of the entity, in | |
| 312 | octets, followed by a sequence of octets that contain the actual | |
| 313 | integer. | |
| 314 | ||
| 315 | These octets form a big-endian number; A big-endian number can be | |
| 316 | encoded by prefixing it with the appropriate length. | |
| 317 | ||
| 318 | Examples: (all numbers are in hexadecimal) | |
| 319 | ||
| 320 | The sequence of octets [00 01 01] encodes an MPI with the value | |
| 321 | 1, while the sequence [00 02 01 FF] encodes an MPI with the | |
| 322 | value of 511. | |
| 323 | ||
| 324 | Additional rule: | |
| 325 | ||
| 326 | * The length field of an encoded MPI describes the octet count | |
| 327 | starting from the MPI's first non-zero octet, containing the | |
| 328 | most significant non-zero bit. Thus, the encoding [00 02 01] | |
| 329 | is not formed correctly; It should be [00 01 01]. | |
| 330 | ||
| 331 | We shall use the syntax mpi(A) to denote the encoded form of the | |
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | Burdis & Naffah Expires November 28, 2003 [Page 6] | |
| 336 | ||
| 337 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 338 | ||
| 339 | ||
| 340 | multi-precision integer A. Furthermore, we shall use the syntax | |
| 341 | bytes(A) to denote the big-endian sequence of octets forming the | |
| 342 | multi-precision integer with the most significant octet being the | |
| 343 | first non-zero octet containing the most significant bit of A. | |
| 344 | ||
| 345 | 3.3 Octet Sequences | |
| 346 | ||
| 347 | This mechanism generates, uses and exchanges sequences of octets; | |
| 348 | e.g. output values of message digest algorithm functions. When such | |
| 349 | entities travel on the wire, they shall be preceded by a one-octet | |
| 350 | scalar quantity representing the count of following octets. | |
| 351 | ||
| 352 | Note that a zero-length octet sequence is encoded as a single 00 | |
| 353 | octet. | |
| 354 | ||
| 355 | We shall use the syntax os(s) to denote the encoded form of the octet | |
| 356 | sequence. Furthermore, we shall use the syntax bytes(s) to denote | |
| 357 | the sequence of octets s, in big-endian order. | |
| 358 | ||
| 359 | 3.4 Extended Octet Sequences | |
| 360 | ||
| 361 | Extended sequences of octets are exchanged when using the security | |
| 362 | layer. When these sequences travel on the wire, they shall be | |
| 363 | preceded by a four-octet scalar quantity representing the count of | |
| 364 | following octets. | |
| 365 | ||
| 366 | We shall use the syntax eos(s) to denote the encoded form of the | |
| 367 | extended octet sequence. Furthermore, we shall use the syntax | |
| 368 | bytes(s) to denote the sequence of octets s, in big-endian order. | |
| 369 | ||
| 370 | 3.5 Text | |
| 371 | ||
| 372 | The only character set for text is the UTF-8 encoding [RFC-2279] of | |
| 373 | Unicode characters [ISO-10646]. All text MUST be in Unicode | |
| 374 | Normalization Form KC [UNICODE-KC] without NUL characters. | |
| 375 | ||
| 376 | In addition, to avoid non-interoperability due to incompatible | |
| 377 | normalisation techniques, the client MUST prepare strings using the | |
| 378 | [SASLprep] profile of [RFC-3454] | |
| 379 | ||
| 380 | We shall use the syntax utf8(L) to denote the string L in UTF-8 | |
| 381 | encoding, preceded by a two-octet scalar quantity representing the | |
| 382 | count of following octets. Furthermore, we shall use the syntax | |
| 383 | bytes(L) to denote the sequence of octets representing the UTF-8 | |
| 384 | encoding of L, in big-endian order. | |
| 385 | ||
| 386 | Not that the empty string is encoded as the two octet sequence 00 00. | |
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | Burdis & Naffah Expires November 28, 2003 [Page 7] | |
| 392 | ||
| 393 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 394 | ||
| 395 | ||
| 396 | 3.6 Buffers | |
| 397 | ||
| 398 | In this mechanism data is exchanged between the client and server | |
| 399 | using buffers. A buffer acts as an envelope for the sequence of data | |
| 400 | elements sent by one end-point of the exchange, and expected by the | |
| 401 | other. | |
| 402 | ||
| 403 | A buffer MAY NOT contain other buffers. It may only contain zero, | |
| 404 | one or more data elements. | |
| 405 | ||
| 406 | A buffer shall be encoded as two fields: a four-octet scalar quantity | |
| 407 | representing the count of following octets, and the concatenation of | |
| 408 | the octets of the data element(s) contained in the buffer. | |
| 409 | ||
| 410 | We shall use the syntax {A|B|C} to denote a buffer containing A, B | |
| 411 | and C in that order. For example: | |
| 412 | ||
| 413 | { mpi(N) | mpi(g) | utf8(L) } | |
| 414 | ||
| 415 | is a buffer containing, in the designated order, the encoded forms of | |
| 416 | an MPI N, an MPI g and a Text L. | |
| 417 | ||
| 418 | 3.7 Data Element Size Limits | |
| 419 | ||
| 420 | The following table details the size limit, in number of octets, for | |
| 421 | each of the data element encodings described earlier. | |
| 422 | ||
| 423 | Data element type Header Size limit in octets | |
| 424 | (octets) (excluding header) | |
| 425 | ------------------------------------------------------------ | |
| 426 | Octet Sequence 1 255 | |
| 427 | MPI 2 65,535 | |
| 428 | Text 2 65,535 | |
| 429 | Extended Octet Sequence 4 2,147,483,383 | |
| 430 | Buffer 4 2,147,483,643 | |
| 431 | ||
| 432 | An implementation MUST signal an exception if any size constraint is | |
| 433 | violated. | |
| 434 | ||
| 435 | 3.8 Unsigned Integers | |
| 436 | ||
| 437 | This mechanism uses unsigned integer values ranging from zero to | |
| 438 | 4,294,967,296. | |
| 439 | ||
| 440 | When such entities travel on the wire, they shall be encoded as | |
| 441 | 4-octet Scalar Numbers. We shall use the syntax uint(n) to denote | |
| 442 | the encoding of an Unsigned Integer n. | |
| 443 | ||
| 444 | ||
| 445 | ||
| 446 | ||
| 447 | Burdis & Naffah Expires November 28, 2003 [Page 8] | |
| 448 | ||
| 449 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 450 | ||
| 451 | ||
| 452 | 4. Protocol Description | |
| 453 | ||
| 454 | The following sections describe the sequence of data transmitted | |
| 455 | between the client and server for SRP authentication, as well as the | |
| 456 | extra control information exchanged to enable a client to request | |
| 457 | whether or not replay detection, integrity protection and/or | |
| 458 | confidentiality protection should be provided by a security layer. | |
| 459 | There are two possible mechanism data exchanges during the | |
| 460 | authentication phase: | |
| 461 | ||
| 462 | The following exchange occurs when a new session is negotiated | |
| 463 | between the client and the server. It will also occur when the | |
| 464 | client requests re-use of the parameters of a previous session and | |
| 465 | either the server does not support such re-use or no longer considers | |
| 466 | the previous session to be valid: | |
| 467 | ||
| 468 | Client Server | |
| 469 | ||
| 470 | --- { utf8(U) | utf8(I) | utf8(sid) | os(cn) } -------------> | |
| 471 | ||
| 472 | <------ { 00 | mpi(N) | mpi(g) | os(s) | mpi(B) | utf8(L) } --- | |
| 473 | ||
| 474 | --- { mpi(A) | os(M1) | utf8(o) | os(cIV) } ----------------> | |
| 475 | ||
| 476 | <------ { os(M2) | os(sIV) | utf8(sid) | uint(ttl) } --------- | |
| 477 | ||
| 478 | where: | |
| 479 | ||
| 480 | U is the authentication identity (username), | |
| 481 | ||
| 482 | I is the authorisation identity (userid), | |
| 483 | ||
| 484 | sid is the identifier of a previous session whose parameters the | |
| 485 | client wishes to re-use, | |
| 486 | ||
| 487 | cn is the client's nonce used in deriving a new shared context | |
| 488 | key from the shared context key of the previous session, | |
| 489 | ||
| 490 | 00 is an octet indicating that the previous session parameters | |
| 491 | will NOT be re-used, | |
| 492 | ||
| 493 | N is the safe prime modulus, | |
| 494 | ||
| 495 | g is the generator, | |
| 496 | ||
| 497 | s is the user's password salt, | |
| 498 | ||
| 499 | B is the server's ephemeral public key, | |
| 500 | ||
| 501 | ||
| 502 | ||
| 503 | Burdis & Naffah Expires November 28, 2003 [Page 9] | |
| 504 | ||
| 505 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 506 | ||
| 507 | ||
| 508 | L is the options list indicating available security services, | |
| 509 | ||
| 510 | A is the client's ephemeral public key, | |
| 511 | ||
| 512 | M1 is the client's evidence that the shared key K is known, | |
| 513 | ||
| 514 | o is the options list indicating chosen security services, | |
| 515 | ||
| 516 | cIV is the client's initial vector for the chosen encryption | |
| 517 | algorithm, | |
| 518 | ||
| 519 | M2 is the server's evidence that the shared key K is known. | |
| 520 | ||
| 521 | sIV is the server's initial vector for the chosen encryption | |
| 522 | algorithm, | |
| 523 | ||
| 524 | sid is the identifier the server gives to this session for | |
| 525 | possible later re-use of the negotiated parameters, | |
| 526 | ||
| 527 | ttl is the time period for which this session's parameters may be | |
| 528 | re-usable, | |
| 529 | ||
| 530 | The following exchange occurs when the client requests that the | |
| 531 | parameters negotiated in a previous session be re-used in this | |
| 532 | session, but with a newly derived shared context key, and the server | |
| 533 | agrees: | |
| 534 | ||
| 535 | Client Server | |
| 536 | ||
| 537 | --- { utf8(U) | utf8(I) | utf8(sid) | os(cn) } --------------> | |
| 538 | ||
| 539 | <---------------------------------- { FF | os(sn) } ---------- | |
| 540 | ||
| 541 | where: | |
| 542 | ||
| 543 | U is the authentication identity (username), | |
| 544 | ||
| 545 | I is the authorisation identity (userid), | |
| 546 | ||
| 547 | sid is the identifier of a previous session whose parameters the | |
| 548 | client wishes to re-use, | |
| 549 | ||
| 550 | cn is the client's nonce used in deriving a new shared context | |
| 551 | key from the shared context key of the previous session, | |
| 552 | ||
| 553 | FF is an octet indicating that the previous session parameters | |
| 554 | WILL be re-used, | |
| 555 | ||
| 556 | ||
| 557 | ||
| 558 | ||
| 559 | Burdis & Naffah Expires November 28, 2003 [Page 10] | |
| 560 | ||
| 561 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 562 | ||
| 563 | ||
| 564 | sn is the server's nonce used in deriving a new shared context | |
| 565 | key from the shared context key of the previous session, | |
| 566 | ||
| 567 | ||
| 568 | 4.1 Client Sends its Identity | |
| 569 | ||
| 570 | The client determines its authentication identity U and authorisation | |
| 571 | identity I, encodes them and sends them to the server. | |
| 572 | ||
| 573 | The semantics of both U and I are intended to be the same as | |
| 574 | described in [SASL]. Specifically, the authentication identity U is | |
| 575 | derived from the client's authentication credentials, and the | |
| 576 | authorisation identity I is used by the server as the primary | |
| 577 | identity for making access policy decisions. | |
| 578 | ||
| 579 | As a client might not have the same information as the server, | |
| 580 | clients SHOULD NOT themselves try to derive authorisation identities | |
| 581 | from authentication identities. When an authorisation identity is | |
| 582 | not specified by the user the client SHOULD send an empty string | |
| 583 | instead. | |
| 584 | ||
| 585 | If the client does not wish to re-use parameters negotiated in a | |
| 586 | previous session then it sets sid to the empty string and cn to a | |
| 587 | zero-length octet sequence. | |
| 588 | ||
| 589 | However, if the client does wish to attempt to re-use the parameters | |
| 590 | negotiated in a previous session then it sets sid to the session | |
| 591 | identifier for that session, and sets cn as follows: | |
| 592 | ||
| 593 | cn = prng() | |
| 594 | ||
| 595 | where: | |
| 596 | ||
| 597 | prng() is a random number generation function that outputs at | |
| 598 | least 16 octets of data. | |
| 599 | ||
| 600 | See Section 6.4 for more information on re-using negotiated | |
| 601 | parameters of a previous session. | |
| 602 | ||
| 603 | The client sends: | |
| 604 | ||
| 605 | { utf8(U) | utf8(I) | utf8(sid) | os(cn) } | |
| 606 | ||
| 607 | ||
| 608 | 4.2 Server Agrees to Re-use Parameters of a Previous Session | |
| 609 | ||
| 610 | If the server supports re-using the parameters negotiated in a | |
| 611 | previous session and it considers the previous session, identified by | |
| 612 | ||
| 613 | ||
| 614 | ||
| 615 | Burdis & Naffah Expires November 28, 2003 [Page 11] | |
| 616 | ||
| 617 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 618 | ||
| 619 | ||
| 620 | the session identifier (sid) received from the client, to be valid, | |
| 621 | it responds as follows: | |
| 622 | ||
| 623 | The server sends the octet FF as the first element of the message to | |
| 624 | indicate to the client that parameters of the previous session are | |
| 625 | being re-used. It also generates a nonce (sn), which is later used | |
| 626 | in deriving a new shared context key for this session: | |
| 627 | ||
| 628 | sn = prng() | |
| 629 | ||
| 630 | where: | |
| 631 | ||
| 632 | prng() is a random number generation function that outputs at | |
| 633 | least 16 octets of data. | |
| 634 | ||
| 635 | Note that the server nonce (sn) MUST NOT be the same as the client | |
| 636 | nonce (cn). | |
| 637 | ||
| 638 | The server sends: | |
| 639 | ||
| 640 | { FF | os(sn) } | |
| 641 | ||
| 642 | See Section 6.4 for more information on re-using negotiated | |
| 643 | parameters of a previous session and deriving the new shared context | |
| 644 | key. | |
| 645 | ||
| 646 | 4.3 Server Sends Protocol Elements | |
| 647 | ||
| 648 | Otherwise, the server receives U and looks up the safe prime modulus | |
| 649 | N, the generator g, the salt s, and the verifier v, to be used for | |
| 650 | that identity. It uses the this information to generate its | |
| 651 | ephemeral public key B as follows: | |
| 652 | ||
| 653 | b = prng(); | |
| 654 | ||
| 655 | B = ((3 * v) + (g ** b)) % N; | |
| 656 | ||
| 657 | where: | |
| 658 | ||
| 659 | prng() is a random number generation function, | |
| 660 | ||
| 661 | b is the MPI that will act as the server's private key, | |
| 662 | ||
| 663 | v is the stored password verifier value, | |
| 664 | ||
| 665 | g is the generator, | |
| 666 | ||
| 667 | N is the safe prime modulus, | |
| 668 | ||
| 669 | ||
| 670 | ||
| 671 | Burdis & Naffah Expires November 28, 2003 [Page 12] | |
| 672 | ||
| 673 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 674 | ||
| 675 | ||
| 676 | * is the multiplication operator, | |
| 677 | ||
| 678 | + is the addition operator, | |
| 679 | ||
| 680 | ** is the exponentiation operator, | |
| 681 | ||
| 682 | % is the modulus operator, | |
| 683 | ||
| 684 | The server also creates an options list L, which consists of a | |
| 685 | comma-separated list of option strings that specify the options the | |
| 686 | server supports. This options list MUST NOT contain any whitespace | |
| 687 | characters and all alphabetic characters MUST be in lowercase. When | |
| 688 | used in digest calculations by the client the options list MUST be | |
| 689 | used as received. | |
| 690 | ||
| 691 | The following option strings are defined: | |
| 692 | ||
| 693 | o "mda=<MDA-name>" indicates that the server supports the designated | |
| 694 | hash function as the underlying Message Digest Algorithm for the | |
| 695 | designated user to be used for all SRP calculations - to compute | |
| 696 | both client-side and server-side digests. The specified algorithm | |
| 697 | MUST meet the requirements specified in section 3.2 of [RFC-2945]: | |
| 698 | ||
| 699 | "Any hash function used with SRP should produce an output of at | |
| 700 | least 16 bytes and have the property that small changes in the | |
| 701 | input cause significant nonlinear changes in the output." | |
| 702 | ||
| 703 | Note that in the interests of interoperability between client and | |
| 704 | server implementations and with other SRP-based tools, both the | |
| 705 | client and the server MUST support SHA-160 as an underlying | |
| 706 | Message Digest Algorithm. While the server is not required to | |
| 707 | list SHA-160 as an available underlying Message Digest Algorithm, | |
| 708 | it must be able to do so. | |
| 709 | ||
| 710 | o "integrity=hmac-<MDA-name>" indicates that the server supports | |
| 711 | integrity protection using the HMAC algorithm [RFC-2104] with | |
| 712 | <MDA-name> as the underlying Message Digest Algorithm. Acceptable | |
| 713 | MDA names are chosen from [SCAN] under the MessageDigest section. | |
| 714 | A server SHOULD send such an option string for each HMAC algorithm | |
| 715 | it supports. The server MUST advertise at least one integrity | |
| 716 | protection algorithm and in the interest of interoperability the | |
| 717 | server SHOULD advertise support for the HMAC-SHA-160 algorithm. | |
| 718 | ||
| 719 | o "replay_detection" indicates that the server supports replay | |
| 720 | detection using sequence numbers. Replay detection SHALL NOT be | |
| 721 | activated without also activating integrity protection. If the | |
| 722 | replay detection option is offered (by the server) and/or chosen | |
| 723 | (by the client) without explicitly specifying an integrity | |
| 724 | ||
| 725 | ||
| 726 | ||
| 727 | Burdis & Naffah Expires November 28, 2003 [Page 13] | |
| 728 | ||
| 729 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 730 | ||
| 731 | ||
| 732 | protection option, then the default integrity protection option | |
| 733 | "integrity=hmac-sha-160" is implied and SHALL be activated. | |
| 734 | ||
| 735 | o "confidentiality=<cipher-name>" indicates that the server supports | |
| 736 | confidentiality protection using the symmetric key block cipher | |
| 737 | algorithm <cipher-name>. The server SHOULD send such an option | |
| 738 | string for each confidentiality protection algorithm it supports. | |
| 739 | Note that in the interest of interoperability, if the server | |
| 740 | offers confidentiality protection, it MUST send the option string | |
| 741 | "confidentiality=aes" since it is then MANDATORY for it to provide | |
| 742 | support for the [AES] algorithm. | |
| 743 | ||
| 744 | o "mandatory=[integrity|replay_detection|confidentiality]" is an | |
| 745 | option only available to the server that indicates that the | |
| 746 | specified security layer option is MANDATORY and MUST be chosen by | |
| 747 | the client for use in the resulting security layer. If a server | |
| 748 | specifies an option as mandatory in this way, it MUST abort the | |
| 749 | connection if the specified option is not chosen by the client. | |
| 750 | It doesn't make sense for the client to send this option since it | |
| 751 | is only able to choose options that the server advertises. The | |
| 752 | client SHOULD abort the connection if the server does not offer an | |
| 753 | option that it requires. If this option is not specified then | |
| 754 | this implies that no options are mandatory. The server SHOULD | |
| 755 | always send the "mandatory=integrity" option indicating that | |
| 756 | integrity protection is required. | |
| 757 | ||
| 758 | o "maxbuffersize=<number-of-bytes>" indicates to the peer the | |
| 759 | maximum number of raw bytes (excluding the buffer header) to be | |
| 760 | processed by the security layer at a time, if one is negotiated. | |
| 761 | The value of <number-of-bytes> MUST NOT exceed the Buffer size | |
| 762 | limit defined in section 3.7. If this option is not detected by a | |
| 763 | client or server mechanism, then it shall operate its security | |
| 764 | layer on the assumption that the maximum number of bytes that may | |
| 765 | be sent, to the peer server or client mechanism respectively, is | |
| 766 | the Buffer data size limit indicated in section 3.7. On the other | |
| 767 | hand, if a recipient detects this option, it shall break any | |
| 768 | octet-sequence longer than the designated limit into two or more | |
| 769 | fragments, before sending them separately, in sequence, to the | |
| 770 | peer. | |
| 771 | ||
| 772 | For example, if the server supports integrity protection using the | |
| 773 | HMAC-SHA-160 and HMAC-MD5 algorithms, replay detection and no | |
| 774 | confidentiality protection, the options list would be: | |
| 775 | ||
| 776 | mda=sha-1,integrity=hmac-sha-160,integrity=hmac-md5,replay_detection | |
| 777 | ||
| 778 | The server sends the octet 00 as the first element of the message to | |
| 779 | indicate to the client that parameters from a previous session are | |
| 780 | ||
| 781 | ||
| 782 | ||
| 783 | Burdis & Naffah Expires November 28, 2003 [Page 14] | |
| 784 | ||
| 785 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 786 | ||
| 787 | ||
| 788 | NOT being used. | |
| 789 | ||
| 790 | The server sends: | |
| 791 | ||
| 792 | { 00 | mpi(N) | mpi(g) | os(s) | mpi(B) | utf8(L) } | |
| 793 | ||
| 794 | ||
| 795 | 4.4 Client Sends its Ephemeral Public Key and Evidence | |
| 796 | ||
| 797 | The client receives the options list L from the server that specifies | |
| 798 | the Message Digest Algorithm(s) available to be used for all SRP | |
| 799 | calculations, the security service options the server supports, | |
| 800 | including the maximum buffer size the server can handle, and the | |
| 801 | server's ephemeral public key B. The client selects options from | |
| 802 | this list and creates a new options list o that specifies the | |
| 803 | selected Message Digest Algorithm to be used for SRP calculations and | |
| 804 | the security services that will be used in the security layer. At | |
| 805 | most one available Message Digest Algorithm name, one available | |
| 806 | integrity protection algorithm and one available confidentiality | |
| 807 | protection algorithm may be selected. In addition the client may | |
| 808 | specify the maximum buffer size it can handle. The client MUST | |
| 809 | include any option specified by the mandatory option. | |
| 810 | ||
| 811 | The client SHOULD always select an integrity protection algorithm | |
| 812 | even if the server does not make it mandatory to do so. If the | |
| 813 | client selects a confidentiality protection algorithm it SHOULD then | |
| 814 | also select an integrity protection algorithm. | |
| 815 | ||
| 816 | The options list o MUST NOT contain any whitespace characters and all | |
| 817 | alphabetic characters MUST be in lowercase. When used in digest | |
| 818 | calculations by the server the options list MUST be used as received. | |
| 819 | ||
| 820 | The client generates its ephemeral public key A as follows: | |
| 821 | ||
| 822 | a = prng(); | |
| 823 | ||
| 824 | A = (g ** a) % N; | |
| 825 | ||
| 826 | where: | |
| 827 | ||
| 828 | a is the MPI that will act as the client's private key, | |
| 829 | ||
| 830 | The client also calculates the shared context key K, and calculates | |
| 831 | the evidence M1 that proves to the server that it knows the shared | |
| 832 | context key K, as well as the server's ephemeral public key B, the | |
| 833 | user's authorisation identity I and the server's options list L. | |
| 834 | ||
| 835 | K, on the client's side is computed as follows: | |
| 836 | ||
| 837 | ||
| 838 | ||
| 839 | Burdis & Naffah Expires November 28, 2003 [Page 15] | |
| 840 | ||
| 841 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 842 | ||
| 843 | ||
| 844 | x = H(s | H(U | ":" | p)); | |
| 845 | ||
| 846 | u = H(A | B); | |
| 847 | ||
| 848 | S = ((B - (3 * (g ** x))) ** (a + (u * x))) % N; | |
| 849 | ||
| 850 | K = H(S); | |
| 851 | ||
| 852 | where: | |
| 853 | ||
| 854 | s is the user's password salt, | |
| 855 | ||
| 856 | U is the authentication identity (username), | |
| 857 | ||
| 858 | p is the password value. | |
| 859 | ||
| 860 | A is the client's ephemeral public key, | |
| 861 | ||
| 862 | B is the server's ephemeral public key, | |
| 863 | ||
| 864 | g is the generator, | |
| 865 | ||
| 866 | N is the safe prime modulus, | |
| 867 | ||
| 868 | H() is the result of digesting the designated input/data with the | |
| 869 | chosen underlying Message Digest Algorithm function. | |
| 870 | ||
| 871 | - is the subtraction operator, | |
| 872 | ||
| 873 | * is the multiplication operator, | |
| 874 | ||
| 875 | + is the addition operator, | |
| 876 | ||
| 877 | ** is the exponentiation operator, | |
| 878 | ||
| 879 | % is the modulus operator, | |
| 880 | ||
| 881 | M1 is computed as: | |
| 882 | ||
| 883 | H( bytes(H( bytes(N) )) ^ bytes( H( bytes(g) )) | |
| 884 | | bytes(H( bytes(U) )) | |
| 885 | | bytes(s) | |
| 886 | | bytes(A) | |
| 887 | | bytes(B) | |
| 888 | | bytes(K) | |
| 889 | | bytes(H( bytes(I) )) | |
| 890 | | bytes(H( bytes(L) )) | |
| 891 | ) | |
| 892 | ||
| 893 | ||
| 894 | ||
| 895 | Burdis & Naffah Expires November 28, 2003 [Page 16] | |
| 896 | ||
| 897 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 898 | ||
| 899 | ||
| 900 | where: | |
| 901 | ||
| 902 | ^ is the bitwise XOR operator. | |
| 903 | ||
| 904 | All parameters received from the server that are used as input to a | |
| 905 | digest operation MUST be used as received. | |
| 906 | ||
| 907 | If the client chooses to activate the Confidentiality Protection | |
| 908 | service in the Security Layer, it MUST send the Initial Vector cIV | |
| 909 | that the server will use to set up its encryption context. (See | |
| 910 | Section 5.2 for details on the Confidentiality Protection service and | |
| 911 | how cIV is generated.) However, this element MAY be a zero-length | |
| 912 | octet stream if the server does not advertise the Confidentiality | |
| 913 | Protection service or the client decides not to activate it. | |
| 914 | ||
| 915 | The client sends: | |
| 916 | ||
| 917 | { mpi(A) | os(M1) | utf8(o) | os(cIV) } | |
| 918 | ||
| 919 | ||
| 920 | 4.5 Server Verifies Client's Evidence and Sends its Evidence | |
| 921 | ||
| 922 | The server calculates the shared context key K, and verifies the | |
| 923 | client's evidence M1. | |
| 924 | ||
| 925 | K, on the server's side is computed as follows: | |
| 926 | ||
| 927 | u = H(A | B); | |
| 928 | ||
| 929 | S = ((A * (v ** u)) ** b) % N; | |
| 930 | ||
| 931 | K = H(S); | |
| 932 | ||
| 933 | where: | |
| 934 | ||
| 935 | A is the client's ephemeral public key, | |
| 936 | ||
| 937 | B is the server's ephemeral public key, | |
| 938 | ||
| 939 | v is the stored password verifier value, | |
| 940 | ||
| 941 | b is the server's ephemeral private key, | |
| 942 | ||
| 943 | N is the safe prime modulus, | |
| 944 | ||
| 945 | H() is the result of digesting the designated input/data with the | |
| 946 | chosen underlying Message Digest Algorithm function. | |
| 947 | ||
| 948 | ||
| 949 | ||
| 950 | ||
| 951 | Burdis & Naffah Expires November 28, 2003 [Page 17] | |
| 952 | ||
| 953 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 954 | ||
| 955 | ||
| 956 | * is the multiplication operator, | |
| 957 | ||
| 958 | ** is the exponentiation operator, | |
| 959 | ||
| 960 | % is the modulus operator, | |
| 961 | ||
| 962 | If the client chose to activate the Confidentiality Protection | |
| 963 | service in the Security Layer then the server MUST send the Initial | |
| 964 | Vector sIV that the client will use to set up its encryption context. | |
| 965 | (See Section 5.2 for details on the Confidentiality Protection | |
| 966 | service and how sIV is generated.) However, this element MAY be a | |
| 967 | zero-length octet sequence if the client did not choose to activate | |
| 968 | the Confidentiality Protection service. | |
| 969 | ||
| 970 | If the server's policy allows re-using the parameters of this session | |
| 971 | then it sets sid to a unique identifier for this session and sets ttl | |
| 972 | to the number of seconds for which the session MAY be valid. If the | |
| 973 | server does not support re-using the parameters of this session then | |
| 974 | it sets sid to the empty string and ttl to any value. See Section | |
| 975 | 6.4 for more information on re-using negotiated parameters of a | |
| 976 | previous session. | |
| 977 | ||
| 978 | The server computes its evidence M2, which proves to the client that | |
| 979 | it knows the shared context key K, as well as U, I and o, as follows: | |
| 980 | ||
| 981 | H( bytes(A) | |
| 982 | | bytes(M1) | |
| 983 | | bytes(K) | |
| 984 | | bytes(H( bytes(I) )) | |
| 985 | | bytes(H( bytes(o) )) | |
| 986 | | bytes(sid) | |
| 987 | | ttl | |
| 988 | ) | |
| 989 | ||
| 990 | All parameters received from the client that are used as input to a | |
| 991 | digest operation MUST be used as received. | |
| 992 | ||
| 993 | The server sends: | |
| 994 | ||
| 995 | { os(M2) | os(sIV) | sid | ttl } | |
| 996 | ||
| 997 | ||
| 998 | ||
| 999 | ||
| 1000 | ||
| 1001 | ||
| 1002 | ||
| 1003 | ||
| 1004 | ||
| 1005 | ||
| 1006 | ||
| 1007 | Burdis & Naffah Expires November 28, 2003 [Page 18] | |
| 1008 | ||
| 1009 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1010 | ||
| 1011 | ||
| 1012 | 5. Security Layer | |
| 1013 | ||
| 1014 | Depending on the options offered by the server and chosen by the | |
| 1015 | client, the security layer may provide integrity protection, replay | |
| 1016 | detection, and/or confidentiality protection. | |
| 1017 | ||
| 1018 | The security layer can be thought of as a three-stage filter through | |
| 1019 | which the data flows from the output of one stage to the input of the | |
| 1020 | following one. The first input is the original data, while the last | |
| 1021 | output is the data after being subject to the transformations of this | |
| 1022 | filter. | |
| 1023 | ||
| 1024 | The data always passes through this three-stage filter, though any of | |
| 1025 | the stages may be inactive. Only when a stage is active would the | |
| 1026 | output be different from the input. In other words, if a stage is | |
| 1027 | inactive, the octet sequence at the output side is an exact duplicate | |
| 1028 | of the same sequence at the input side. | |
| 1029 | ||
| 1030 | Schematically, the three-stage filter security layer appears as | |
| 1031 | follows: | |
| 1032 | ||
| 1033 | +----------------------------+ | |
| 1034 | | | I/ p1 | |
| 1035 | p1 --->| Confidentiality protection |---+ | |
| 1036 | | | | A/ c | |
| 1037 | +----------------------------+ | | |
| 1038 | | | |
| 1039 | +------------------------------------+ | |
| 1040 | | | |
| 1041 | | +----------------------------+ | |
| 1042 | | | | I/ p2 | |
| 1043 | p2 +-->| Replay detection |---+ | |
| 1044 | | | | A/ p2 | q | |
| 1045 | +----------------------------+ | | |
| 1046 | | | |
| 1047 | +------------------------------------+ | |
| 1048 | | | |
| 1049 | | +----------------------------+ | |
| 1050 | | | | I/ p3 | |
| 1051 | p3 +-->| Integrity protection |---> | |
| 1052 | | | A/ p3 | C | |
| 1053 | +----------------------------+ | |
| 1054 | ||
| 1055 | where: | |
| 1056 | ||
| 1057 | p1, p2 and p3 are the input octet sequences at each stage, | |
| 1058 | ||
| 1059 | I/ denotes the output at the end of one stage if/when the stage is | |
| 1060 | ||
| 1061 | ||
| 1062 | ||
| 1063 | Burdis & Naffah Expires November 28, 2003 [Page 19] | |
| 1064 | ||
| 1065 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1066 | ||
| 1067 | ||
| 1068 | inactive or disabled, | |
| 1069 | ||
| 1070 | A/ denotes the output at the end of one stage if/when the stage is | |
| 1071 | active or enabled, | |
| 1072 | ||
| 1073 | c is the encrypted (sender-side) or decrypted (receiver-side) | |
| 1074 | octet sequence. c1 shall denote the value computed by the sender, | |
| 1075 | while c2 shall denote the value computed by the receiver. | |
| 1076 | ||
| 1077 | q is a four-octet scalar quantity representing a sequence number, | |
| 1078 | ||
| 1079 | C is the Message Authentication Code. C1 shall denote the value | |
| 1080 | of the MAC as computed by the sender, while C2 shall denote the | |
| 1081 | value computed by the receiver. | |
| 1082 | ||
| 1083 | It is worth noting here that both client and server have their own | |
| 1084 | distinct security contexts, including distinct encryption and | |
| 1085 | decryption sub-contexts. In principal, nothing in this specification | |
| 1086 | should prevent an implementation from supporting asynchronous | |
| 1087 | connections. | |
| 1088 | ||
| 1089 | 5.1 Cryptographic Primitives | |
| 1090 | ||
| 1091 | 5.1.1 Pseudo Random Number Generator | |
| 1092 | ||
| 1093 | This mechanism requires random data to be generated for use in: | |
| 1094 | ||
| 1095 | 1. The CALG key material for both the client and server when the | |
| 1096 | Confidentiality Protection service is enabled. | |
| 1097 | ||
| 1098 | 2. The IALG key material for both the client and server when the | |
| 1099 | Integrity Protection service is enabled. | |
| 1100 | ||
| 1101 | The PRNG used in this specification is based on the pseudo-random | |
| 1102 | function described in section 5 of [UMAC]. It uses the [AES] | |
| 1103 | algorithm, in its 128-bit key size variant, as the underlying | |
| 1104 | symmetric key block cipher for its operations. | |
| 1105 | ||
| 1106 | A formal description of this PRNG follows: | |
| 1107 | ||
| 1108 | o Initialisation | |
| 1109 | ||
| 1110 | * SK: a 16-octet sequence (seeding key to AES) | |
| 1111 | ||
| 1112 | o Input | |
| 1113 | ||
| 1114 | * n: a positive integer | |
| 1115 | ||
| 1116 | ||
| 1117 | ||
| 1118 | ||
| 1119 | Burdis & Naffah Expires November 28, 2003 [Page 20] | |
| 1120 | ||
| 1121 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1122 | ||
| 1123 | ||
| 1124 | o Output | |
| 1125 | ||
| 1126 | * Y: an n-octet sequence | |
| 1127 | ||
| 1128 | o Algorithm | |
| 1129 | ||
| 1130 | * (initialisation) | |
| 1131 | ||
| 1132 | 1. Initialise an AES instance for encryption with the first 16 | |
| 1133 | octets of SK as its user-supplied key material. Let "aes" | |
| 1134 | be that instance; i.e. aes = AES(SK, ENCRYPTION); | |
| 1135 | ||
| 1136 | 2. Initialise T to be an all-zero 16-octet long sequence; | |
| 1137 | ||
| 1138 | * (for every input) | |
| 1139 | ||
| 1140 | 1. Initialise "remaining" to n; | |
| 1141 | ||
| 1142 | 2. Initialise Y to be a 0-length octet sequence; | |
| 1143 | ||
| 1144 | 3. while (remaining > 0) do | |
| 1145 | ||
| 1146 | 1. T = aes(T); | |
| 1147 | ||
| 1148 | 2. Append m octets from T to Y, where m is the minimum of | |
| 1149 | 16 and remaining; | |
| 1150 | ||
| 1151 | 3. Subtract 16 from remaining; | |
| 1152 | ||
| 1153 | 4. return Y; | |
| 1154 | ||
| 1155 | In this document, "PRNG(key,n)" will refer to this algorithm, with | |
| 1156 | the initialisation parameter SK set to be the octets of the specified | |
| 1157 | key, returning n bits of pseudo-random data. For example, | |
| 1158 | "PRNG(K,n)" will refer to this algorithm, with the initialisation | |
| 1159 | parameters SK set to the shared context key K computed by the SRP | |
| 1160 | calculations (see Section 4.4 and Section 4.5), returning n bits of | |
| 1161 | pseudo-random data. | |
| 1162 | ||
| 1163 | This algorithm MAY also be used as part of the SRP calculations to | |
| 1164 | generate the required "a" and "b" parameters used in creating the | |
| 1165 | client and server ephemeral private keys ("A" and "B"), or to | |
| 1166 | generate the cn and sn parameters used in session re-use, or to | |
| 1167 | generate the initial vectors sIV and cIV used to set up the | |
| 1168 | encryption contexts. In this case the initialisation parameter SK can | |
| 1169 | be any 16-octet sequence (e.g. multiple representations of the | |
| 1170 | time-of-day). | |
| 1171 | ||
| 1172 | ||
| 1173 | ||
| 1174 | ||
| 1175 | Burdis & Naffah Expires November 28, 2003 [Page 21] | |
| 1176 | ||
| 1177 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1178 | ||
| 1179 | ||
| 1180 | If the same PRNG instance is used for both these calculations and the | |
| 1181 | calculations in this specification, it MUST be re-initialised with | |
| 1182 | the shared context key K before any of the latter calculations are | |
| 1183 | performed. | |
| 1184 | ||
| 1185 | 5.1.2 Key Derivation Function | |
| 1186 | ||
| 1187 | During the authentication phase, both parties compute the shared | |
| 1188 | context key K (see Section 4.4 for the client, and Section 4.5 for | |
| 1189 | the server sides respectively). The length of K is s bits, where "s" | |
| 1190 | is the output length of the chosen underlying Message Digest | |
| 1191 | Algorithm used in the SRP calculations (see "mda" option in Section | |
| 1192 | 4.3). | |
| 1193 | ||
| 1194 | When Confidentiality Protection is required, and the length of K is | |
| 1195 | not equal to the length of the user-supplied key material needed to | |
| 1196 | initialise the chosen Confidentiality Algorithm (CALG), the peers | |
| 1197 | MUST apply the Key Derivation Function (KDF) in order to obtain | |
| 1198 | enough data for this purpose. | |
| 1199 | ||
| 1200 | Similarly, when Integrity Protection is required, and the length of K | |
| 1201 | is not equal to the required length of the key material needed to | |
| 1202 | initialise the chosen Integrity Algorithm (IALG), the peers MUST | |
| 1203 | apply the Key Derivation Function (KDF) in order to obtain enough | |
| 1204 | data for this purpose too. | |
| 1205 | ||
| 1206 | If the KDF is required for both the key used with the CALG and the | |
| 1207 | key used with the IALG then it is first applied for the CALG key and | |
| 1208 | thereafter for the IALG key. | |
| 1209 | ||
| 1210 | We define this KDF as: | |
| 1211 | ||
| 1212 | Km = KDF(n) | |
| 1213 | ||
| 1214 | where: | |
| 1215 | ||
| 1216 | Km is the required key material, | |
| 1217 | ||
| 1218 | K is the shared context key, and | |
| 1219 | ||
| 1220 | n is the required length of Km. | |
| 1221 | ||
| 1222 | The following steps describe the KDF algorithm: | |
| 1223 | ||
| 1224 | If length of K is greater than or equal to n, then | |
| 1225 | ||
| 1226 | Let Km be the first n bytes of K; | |
| 1227 | ||
| 1228 | ||
| 1229 | ||
| 1230 | ||
| 1231 | Burdis & Naffah Expires November 28, 2003 [Page 22] | |
| 1232 | ||
| 1233 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1234 | ||
| 1235 | ||
| 1236 | Else | |
| 1237 | ||
| 1238 | Let Km = PRNG(K, n); | |
| 1239 | ||
| 1240 | return Km | |
| 1241 | ||
| 1242 | ||
| 1243 | 5.2 Confidentiality Protection | |
| 1244 | ||
| 1245 | The plaintext data octet sequence p1 is encrypted using the chosen | |
| 1246 | confidentiality algorithm (CALG) with key size m, initialised for | |
| 1247 | encryption with the key material Kc obtained as follows: | |
| 1248 | ||
| 1249 | Kc = KDF(m) | |
| 1250 | ||
| 1251 | c1 = CALG(Kc, ENCRYPTION)( bytes(p1) ) | |
| 1252 | ||
| 1253 | On the receiving side, the ciphertext data octet sequence p1 is | |
| 1254 | decrypted using the chosen confidentiality algorithm (CALG) | |
| 1255 | initialised for decryption, with the key Kc obtained by a similar | |
| 1256 | process: | |
| 1257 | ||
| 1258 | Kc = KDF(m) | |
| 1259 | ||
| 1260 | c2 = CALG(Kc, DECRYPTION)( bytes(p1) ) | |
| 1261 | ||
| 1262 | The designated CALG symmetric-key block cipher MUST be used in OFB | |
| 1263 | (Output Feedback Block) mode in the ISO variant, as described in | |
| 1264 | [HAC], algorithm 7.20. | |
| 1265 | ||
| 1266 | Let k be the block size of the chosen symmetric key block cipher | |
| 1267 | algorithm; e.g. for AES this is 128 bits or 16 octets. The OFB mode | |
| 1268 | used shall have a block size of k. | |
| 1269 | ||
| 1270 | It is recommended that block ciphers operating in OFB mode be used | |
| 1271 | with an Initial Vector (the mode's IV). In such a mode of operation | |
| 1272 | - OFB with key re-use - the IV need not be secret. For the mechanism | |
| 1273 | described in this document, the server MUST use cIV received from the | |
| 1274 | client as the Initial Vector when initialising its encryption | |
| 1275 | context, and the client MUST use sIV received from the server as the | |
| 1276 | Initial Vector when initialising its encryption context. These | |
| 1277 | Initial Vectors are generated as: | |
| 1278 | ||
| 1279 | cIV = prng(k); | |
| 1280 | ||
| 1281 | sIV = prng(k); | |
| 1282 | ||
| 1283 | where: | |
| 1284 | ||
| 1285 | ||
| 1286 | ||
| 1287 | Burdis & Naffah Expires November 28, 2003 [Page 23] | |
| 1288 | ||
| 1289 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1290 | ||
| 1291 | ||
| 1292 | prng() is a random number generation function that outputs k | |
| 1293 | octets of data, | |
| 1294 | ||
| 1295 | k is the block size of the chosen symmetric key block cipher | |
| 1296 | algorithm | |
| 1297 | ||
| 1298 | The input data to the confidentiality protection algorithm shall be a | |
| 1299 | multiple of the symmetric key block cipher block size k. When the | |
| 1300 | input length is not a multiple of k octets, the data shall be padded | |
| 1301 | according to the following scheme (described in [PKCS7] which itself | |
| 1302 | is based on [RFC-1423]): | |
| 1303 | ||
| 1304 | Assuming the length of the input is l octets, (k - (l mod k)) | |
| 1305 | octets, all having the value (k - (l mod k)), shall be appended to | |
| 1306 | the original data. In other words, the input is padded at the | |
| 1307 | trailing end with one of the following sequences: | |
| 1308 | ||
| 1309 | ||
| 1310 | ||
| 1311 | 01 -- if l mod k = k-1 | |
| 1312 | 02 02 -- if l mod k = k-2 | |
| 1313 | ... | |
| 1314 | ... | |
| 1315 | ... | |
| 1316 | k k ... k k -- if l mod k = 0 | |
| 1317 | ||
| 1318 | The padding can be removed unambiguously since all input is padded | |
| 1319 | and no padding sequence is a suffix of another. This padding | |
| 1320 | method is well-defined if and only if k < 256 octets, which is the | |
| 1321 | case with symmetric block ciphers today, and in the forseeable | |
| 1322 | future. | |
| 1323 | ||
| 1324 | The output of this stage, when it is active, is: | |
| 1325 | ||
| 1326 | at the sending side: CALG(Kc, ENCRYPT)( bytes(p1) ) | |
| 1327 | ||
| 1328 | at the receiving side: CALG(Kc, DECRYPT)( bytes(p1) ) | |
| 1329 | ||
| 1330 | ||
| 1331 | 5.3 Replay Detection | |
| 1332 | ||
| 1333 | A sequence number q is incremented every time a message is sent to | |
| 1334 | the peer. | |
| 1335 | ||
| 1336 | The output of this stage, when it is active, is: | |
| 1337 | ||
| 1338 | p2 | q | |
| 1339 | ||
| 1340 | ||
| 1341 | ||
| 1342 | ||
| 1343 | Burdis & Naffah Expires November 28, 2003 [Page 24] | |
| 1344 | ||
| 1345 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1346 | ||
| 1347 | ||
| 1348 | At the other end, the receiver increments its instance of the | |
| 1349 | sequence number. This new value of the sequence number is then used | |
| 1350 | in the integrity protection transformation, which must also be active | |
| 1351 | as described in Section 4.3. See Section 6.3 for more details. | |
| 1352 | ||
| 1353 | 5.4 Integrity Protection | |
| 1354 | ||
| 1355 | When the Integrity Protection stage is active, a message | |
| 1356 | authentication code C is computed using the chosen integrity | |
| 1357 | protection algorithm (IALG) as follows: | |
| 1358 | ||
| 1359 | o the IALG is initialised (once) with the key material Ki of size n | |
| 1360 | (the required key size of the chosen IALG); i.e. Ki = KDF(n), | |
| 1361 | ||
| 1362 | o the IALG is updated with every exchange of the sequence p3, | |
| 1363 | yielding the value C and a new IALG context for use in the | |
| 1364 | following exchange. | |
| 1365 | ||
| 1366 | At the other end, the receiver computes its version of C, using the | |
| 1367 | same transformation, and checks that its value is equal to that | |
| 1368 | received. If the two values do not agree, the receiver MUST signal an | |
| 1369 | exception and abort. | |
| 1370 | ||
| 1371 | The output of this stage, when it is active, is then: | |
| 1372 | ||
| 1373 | IALG(Ki)( bytes(p3) ) | |
| 1374 | ||
| 1375 | ||
| 1376 | 5.5 Summary of Security Layer Output | |
| 1377 | ||
| 1378 | The following table shows the data exchanged by the security layer | |
| 1379 | peers, depending on the possible legal combinations of the three | |
| 1380 | security services in operation: | |
| 1381 | ||
| 1382 | CP IP RD Peer sends/receives | |
| 1383 | ||
| 1384 | I I I { eos(p) } | |
| 1385 | I A I { eos(p) | os( IALG(Ki)( bytes(p) ) ) } | |
| 1386 | I A A { eos(p) | os( IALG(Ki)( bytes(p) | bytes(q)) ) } | |
| 1387 | A I I { eos(c) } | |
| 1388 | A A I { eos(c) | os( IALG(Ki)( bytes(c) ) ) } | |
| 1389 | A A A { eos(c) | os( IALG(Ki)((bytes(c) | bytes(q)) )} | |
| 1390 | ||
| 1391 | where | |
| 1392 | ||
| 1393 | CP Confidentiality protection, | |
| 1394 | ||
| 1395 | IP Integrity protection, | |
| 1396 | ||
| 1397 | ||
| 1398 | ||
| 1399 | Burdis & Naffah Expires November 28, 2003 [Page 25] | |
| 1400 | ||
| 1401 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1402 | ||
| 1403 | ||
| 1404 | RD Replay detection, | |
| 1405 | ||
| 1406 | I Security service is Inactive/disabled, | |
| 1407 | ||
| 1408 | A Security service is Active/enabled, | |
| 1409 | ||
| 1410 | p The original plaintext, | |
| 1411 | ||
| 1412 | q The sequence number. | |
| 1413 | ||
| 1414 | c The enciphered input obtained by either: | |
| 1415 | ||
| 1416 | CALG(Kc, ENCRYPT)( bytes(p) ) at the sender's side, or | |
| 1417 | ||
| 1418 | CALG(Kc, DECRYPT)( bytes(p) ) at the receiver's side | |
| 1419 | ||
| 1420 | ||
| 1421 | ||
| 1422 | ||
| 1423 | ||
| 1424 | ||
| 1425 | ||
| 1426 | ||
| 1427 | ||
| 1428 | ||
| 1429 | ||
| 1430 | ||
| 1431 | ||
| 1432 | ||
| 1433 | ||
| 1434 | ||
| 1435 | ||
| 1436 | ||
| 1437 | ||
| 1438 | ||
| 1439 | ||
| 1440 | ||
| 1441 | ||
| 1442 | ||
| 1443 | ||
| 1444 | ||
| 1445 | ||
| 1446 | ||
| 1447 | ||
| 1448 | ||
| 1449 | ||
| 1450 | ||
| 1451 | ||
| 1452 | ||
| 1453 | ||
| 1454 | ||
| 1455 | Burdis & Naffah Expires November 28, 2003 [Page 26] | |
| 1456 | ||
| 1457 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1458 | ||
| 1459 | ||
| 1460 | 6. Discussion | |
| 1461 | ||
| 1462 | 6.1 Mandatory Algorithms | |
| 1463 | ||
| 1464 | The algorithms specified as mandatory were chosen for utility and | |
| 1465 | availablity. We felt that a mandatory confidentiality and integrity | |
| 1466 | protection algorithm for the security layer and a mandatory Message | |
| 1467 | Digest Algorithm for SRP calculations should be specified to ensure | |
| 1468 | interoperability between implementations of this mechanism: | |
| 1469 | ||
| 1470 | o The SHA-160 Message Digest Algorithm was chosen as an underlying | |
| 1471 | algorithm for SRP calculations because this allows for easy | |
| 1472 | interoperability with other SRP-based tools that use the SRP-SHA1 | |
| 1473 | protocol described in section 3 of [RFC-2945] and create their | |
| 1474 | password files using this algorithm. | |
| 1475 | ||
| 1476 | o The HMAC algorithm was chosen as an integrity algorithm because it | |
| 1477 | is faster than MAC algorithms based on secret key encryption | |
| 1478 | algorithms [RFC-2847]. | |
| 1479 | ||
| 1480 | o AES was chosen as a symmetric-key block cipher because it has | |
| 1481 | undergone thorough scrutiny by the best cryptographers in the | |
| 1482 | world. | |
| 1483 | ||
| 1484 | Since confidentiality protection is optional, this mechanism should | |
| 1485 | be usable in countries that have strict controls on the use of | |
| 1486 | cryptography. | |
| 1487 | ||
| 1488 | 6.2 Modulus and Generator Values | |
| 1489 | ||
| 1490 | It is RECOMMENDED that the server use values for the modulus N and | |
| 1491 | generator g chosen from those listed in Appendix A so that the client | |
| 1492 | can avoid expensive constraint checks, since these predefined values | |
| 1493 | already meet the constraints described in [RFC-2945]: | |
| 1494 | ||
| 1495 | "For maximum security, N should be a safe prime (i.e. a number of | |
| 1496 | the form N = 2q + 1, where q is also prime). Also, g should be a | |
| 1497 | generator modulo N (see [SRP] for details), which means that for | |
| 1498 | any X where 0 < X < N, there exists a value x for which g**x == X | |
| 1499 | (mod N). | |
| 1500 | ||
| 1501 | If other values are used for N and g then these values SHOULD undergo | |
| 1502 | the specified constraint checks. | |
| 1503 | ||
| 1504 | 6.3 Replay Detection Sequence Number Counters | |
| 1505 | ||
| 1506 | The mechanism described in this document allows the use of a Replay | |
| 1507 | Detection security service that works by including sequence number | |
| 1508 | ||
| 1509 | ||
| 1510 | ||
| 1511 | Burdis & Naffah Expires November 28, 2003 [Page 27] | |
| 1512 | ||
| 1513 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1514 | ||
| 1515 | ||
| 1516 | counters in the message authentication code (MAC) created by the | |
| 1517 | Integrity Protection service. As noted in Section 4.3 integrity | |
| 1518 | protection is always activated when the Replay Detection service is | |
| 1519 | activated. | |
| 1520 | ||
| 1521 | Both the client and the server keep two sequence number counters. | |
| 1522 | Each of these counters is a 32-bit unsigned integer initialised with | |
| 1523 | a Starting Value and incremented by an Increment Value with every | |
| 1524 | successful transmission of a data buffer through the security layer. | |
| 1525 | The Sent counter is incremented for each buffer sent through the | |
| 1526 | security layer. The Received counter is incremented for each buffer | |
| 1527 | received through the security layer. If the value of a sequence | |
| 1528 | number counter exceeds 2**32-1 it wraps around and starts from zero | |
| 1529 | again. | |
| 1530 | ||
| 1531 | When a sender sends a buffer it includes the value of its Sent | |
| 1532 | counter in the computation of the MAC accompanying each integrity | |
| 1533 | protected message. When a recipient receives a buffer it uses the | |
| 1534 | value of it's Received counter in its computation of the integrity | |
| 1535 | protection MAC for the received message. The recipient's Received | |
| 1536 | counter must be the same as the sender's Sent counter in order for | |
| 1537 | the received and computed MACs to match. | |
| 1538 | ||
| 1539 | This specification assumes that for each sequence number counter the | |
| 1540 | Starting Value is ZERO, and that the Increment Value is ONE. These | |
| 1541 | values do not affect the security or the intended objective of the | |
| 1542 | replay detection service, since they never travel on the wire. | |
| 1543 | ||
| 1544 | 6.4 Re-using the Parameters of a Previous Session | |
| 1545 | ||
| 1546 | Re-using the parameters of a previous session enables the client and | |
| 1547 | server to avoid the overhead of the full authentication exchange | |
| 1548 | where the client and server communicate more than once during a | |
| 1549 | server-specified time period. | |
| 1550 | ||
| 1551 | Servers are not required to support re-using the parameters of the | |
| 1552 | current session in future sessions. If they do not wish to support | |
| 1553 | this then they send an empty string for the session identifier (sid). | |
| 1554 | However, if the server's policy allows for the parameters of the | |
| 1555 | current session to be re-used later, it generates a session | |
| 1556 | identifier (sid) that will uniquely identify the session within the | |
| 1557 | specified time period (ttl). The time period (ttl) is specified in | |
| 1558 | seconds and only gives an indication to the client how long the | |
| 1559 | session may be valid. The server is not required to ensure that the | |
| 1560 | session is valid for this time period. Note that a ttl of 0 indicates | |
| 1561 | an indeterminate time period. | |
| 1562 | ||
| 1563 | To avoid session hijacking, servers SHOULD NOT indicate that a | |
| 1564 | ||
| 1565 | ||
| 1566 | ||
| 1567 | Burdis & Naffah Expires November 28, 2003 [Page 28] | |
| 1568 | ||
| 1569 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1570 | ||
| 1571 | ||
| 1572 | session may be re-used unless a security layer with integrity | |
| 1573 | protection and/or confidentiality protection has been negotiated. | |
| 1574 | ||
| 1575 | Clients are not required to support re-using the parameters of | |
| 1576 | previous sessions. If they do not wish to support it or they do not | |
| 1577 | wish to re-use the parameters of a previous session then they send | |
| 1578 | the empty string as the value for the session identifier (sid) and | |
| 1579 | send a zero-length octet sequence for the nonce (cn). If they do | |
| 1580 | support it and wish to use the parameters of a previous session then | |
| 1581 | they send the session identifier for this session that they | |
| 1582 | previously received from the server and calculate cn as described in | |
| 1583 | Section 4.1. | |
| 1584 | ||
| 1585 | If a client specifies a session id (sid) for a session that the | |
| 1586 | server still considers valid then the server sends the octet FF, to | |
| 1587 | indicate to the client that parameters of a previous session are | |
| 1588 | being re-used, and the nonce (sn) calculated as described in Section | |
| 1589 | 4.2. The client and server then calculate the new shared context key | |
| 1590 | Kn for this session as follows: | |
| 1591 | ||
| 1592 | Kn = H(K | cn | sn) | |
| 1593 | ||
| 1594 | where: | |
| 1595 | ||
| 1596 | K is the shared context key for the previous session identified | |
| 1597 | by sid. | |
| 1598 | ||
| 1599 | H() is the result of digesting the designated input/data with the | |
| 1600 | Message Digest Algorithm function negotiated in the previous | |
| 1601 | session identified by sid. | |
| 1602 | ||
| 1603 | Then, if the confidentiality and/or integrity protection services | |
| 1604 | were negotiated for the previous session, new keys for these services | |
| 1605 | are derived using the KDF for use in this session. (See Section | |
| 1606 | 5.1.2.) | |
| 1607 | ||
| 1608 | If the server does not support re-using parameters of previous | |
| 1609 | sessions or no longer considers the specified previous session to be | |
| 1610 | valid, it ignores the session id specified by the client and | |
| 1611 | continues the full authentication exchange. However, the first | |
| 1612 | element of the next buffer it sends is the octet 00, which indicates | |
| 1613 | to the client that no parameters of a previous session will be | |
| 1614 | re-used. | |
| 1615 | ||
| 1616 | ||
| 1617 | ||
| 1618 | ||
| 1619 | ||
| 1620 | ||
| 1621 | ||
| 1622 | ||
| 1623 | Burdis & Naffah Expires November 28, 2003 [Page 29] | |
| 1624 | ||
| 1625 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1626 | ||
| 1627 | ||
| 1628 | 7. SASL | |
| 1629 | ||
| 1630 | 7.1 Overview | |
| 1631 | ||
| 1632 | SASL is described as follows [RFC-2222]: | |
| 1633 | ||
| 1634 | The Simple Authentication and Security Layer (SASL) is a method | |
| 1635 | for adding authentication support to connection-based protocols. | |
| 1636 | ||
| 1637 | This document describes a mechanism that can be used within the SASL | |
| 1638 | authentication framework. | |
| 1639 | ||
| 1640 | 7.2 Mechanism Name | |
| 1641 | ||
| 1642 | The SASL mechanism name associated with this protocol is "SRP". | |
| 1643 | ||
| 1644 | 7.3 Security Layer | |
| 1645 | ||
| 1646 | Section 3 of [RFC-2222] describes the operation of the security layer | |
| 1647 | as follows: | |
| 1648 | ||
| 1649 | "The security layer takes effect immediately following the last | |
| 1650 | response of the authentication exchange for data sent by the | |
| 1651 | client and the completion indication for data sent by the server. | |
| 1652 | Once the security layer is in effect, the protocol stream is | |
| 1653 | processed by the security layer into buffers of cipher-text. Each | |
| 1654 | buffer is transferred over the connection as a stream of octets | |
| 1655 | prepended with a four octet field in network byte order that | |
| 1656 | represents the length of the following buffer. The length of the | |
| 1657 | cipher-text buffer must be no larger than the maximum size that | |
| 1658 | was defined or negotiated by the other side." | |
| 1659 | ||
| 1660 | ||
| 1661 | 7.4 Profile Considerations | |
| 1662 | ||
| 1663 | As mentioned briefly in [RFC-2222], and detailed in [SASL] a SASL | |
| 1664 | specification has three layers: (a) a protocol definition using SASL | |
| 1665 | known as the "Profile", (b) a SASL mechanism definition, and (c) the | |
| 1666 | SASL framework. | |
| 1667 | ||
| 1668 | Point (3) in section 5 of [SASL] ("Protocol profile requirements") | |
| 1669 | clearly states that it is the responsibility of the Profile to define | |
| 1670 | "...how the challenges and responses are encoded, how the server | |
| 1671 | indicates completion or failure of the exchange, how the client | |
| 1672 | aborts an exchange, and how the exchange method interacts with any | |
| 1673 | line length limits in the protocol." | |
| 1674 | ||
| 1675 | The username entity, referenced as U throughout this document, and | |
| 1676 | ||
| 1677 | ||
| 1678 | ||
| 1679 | Burdis & Naffah Expires November 28, 2003 [Page 30] | |
| 1680 | ||
| 1681 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1682 | ||
| 1683 | ||
| 1684 | used by the server to locate the password data, is assumed to travel | |
| 1685 | "in the clear," meaning that no transformation is applied to its | |
| 1686 | contents. This assumption was made to allow the same SRP password | |
| 1687 | files to be used in this mechanism, as those used with other SRP | |
| 1688 | applications and tools. | |
| 1689 | ||
| 1690 | A Profile may decide, for privacy or other reason, to disallow such | |
| 1691 | information to travel in the clear, and instead use a hashed version | |
| 1692 | of U, or more generally a transformation function applied to U; i.e. | |
| 1693 | f(U). Such a Profile would require additional tools to add the | |
| 1694 | required entries to the SRP password files for the new value(s) of | |
| 1695 | f(U). It is worth noting too that if this is the case, and the same | |
| 1696 | user shall access the server through this mechanism as well as | |
| 1697 | through other SRP tools, then at least two entries, one with U and | |
| 1698 | the other with f(U) need to be present in the SRP password files if | |
| 1699 | those same files are to be used for both types of access. | |
| 1700 | ||
| 1701 | 7.5 Example | |
| 1702 | ||
| 1703 | The example below uses SMTP authentication [RFC-2554]. The base64 | |
| 1704 | encoding of challenges and responses, as well as the reply codes | |
| 1705 | preceding the responses are part of the SMTP authentication | |
| 1706 | specification, not part of this SASL mechanism itself. | |
| 1707 | ||
| 1708 | "C:" and "S:" indicate lines sent by the client and server | |
| 1709 | respectively. | |
| 1710 | ||
| 1711 | S: 220 smtp.example.com ESMTP server ready | |
| 1712 | ||
| 1713 | C: EHLO zaau.example.com | |
| 1714 | ||
| 1715 | S: 250-smtp.example.com | |
| 1716 | S: 250 AUTH SRP CRAM-MD5 DIGEST-MD5 | |
| 1717 | ||
| 1718 | C: AUTH SRP AAAADAAEdGVzdAAEdGVzdA== | |
| 1719 | ||
| 1720 | with: | |
| 1721 | ||
| 1722 | U = "test" | |
| 1723 | ||
| 1724 | I = "test" | |
| 1725 | ||
| 1726 | S: 334 AAABygEArGvbQTJKmpvxZt5eE4lYL69ytmUZh+4H/DGSlD21YFCjcynLtKCZ | |
| 1727 | 7YGT4HV3Z6E91SMSq0sDMQ3Nf0ip2gT9UOgIOWntt2ewz2CVF5oWOrNmGgX71fqq6Ck | |
| 1728 | YqZYvC5O4Vfl5k+yXXuqoDXQK2/T/dHNZ0EHVwz6nHSgeRGsUdzvKl7Q6I/uAFna9IH | |
| 1729 | pDbGSB8dK5B4cXRhpbnTLmiPh3SFRFI7UksNV9Xqd6J3XS7PoDLPvb9S+zeGFgJ5AE5 | |
| 1730 | Xrmr4dOcwPOUymczAQce8MI2CpWmPOo0MOCca41+Onb+7aUtcgD2J965DXeI21SX1R1 | |
| 1731 | m2XjcvzWjvIPpxEfnkr/cwABAgqsi3AvmIqdEbREALhtZGE9U0hBLTEsbWFuZGF0b3J | |
| 1732 | ||
| 1733 | ||
| 1734 | ||
| 1735 | Burdis & Naffah Expires November 28, 2003 [Page 31] | |
| 1736 | ||
| 1737 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1738 | ||
| 1739 | ||
| 1740 | 5PXJlcGxheSBkZXRlY3Rpb24scmVwbGF5IGRldGVjdGlvbixpbnRlZ3JpdHk9aG1hYy | |
| 1741 | 1zaGExLGludGVncml0eT1obWFjLW1kNSxjb25maWRlbnRpYWxpdHk9YWVzLGNvbmZpZ | |
| 1742 | GVudGlhbGl0eT1jYXN0NSxjb25maWRlbnRpYWxpdHk9Ymxvd2Zpc2gsbWF4YnVmZmVy | |
| 1743 | c2l6ZT0yMTQ3NDgzNjQz | |
| 1744 | ||
| 1745 | with: | |
| 1746 | ||
| 1747 | N = "21766174458617435773191008891802753781907668374255538511144 | |
| 1748 | 6432246898862353838409572109090130860564015713997172358072665816 | |
| 1749 | 4960647214841029141336415219736447718088739565548373811507267740 | |
| 1750 | 2235101762521901569820740293149529620419333266262073471054548368 | |
| 1751 | 7360395197024862265062488610602569718029849535611214426801576680 | |
| 1752 | 0076142998822245709041387397397017192709399211475176516806361476 | |
| 1753 | 1119615476233422096442783117971236371647333871414335895773474667 | |
| 1754 | 3089670508070055093204247996784170368679283167612722742303140675 | |
| 1755 | 4829113358247958306143957755934710196177140617368437852270348349 | |
| 1756 | 5337037655006751328447510550299250924469288819" | |
| 1757 | ||
| 1758 | g = "2" | |
| 1759 | ||
| 1760 | s = "814819216327401865851972" | |
| 1761 | ||
| 1762 | L = "mda=sha-1,mandatory=replay_detection,replay_detection,integ | |
| 1763 | rity=hmac-sha1,integrity=hmac-md5,confidentiality=aes,confidenti | |
| 1764 | ality=cast5,confidentiality=blowfish,maxbuffersize=2147483643" | |
| 1765 | ||
| 1766 | C: AAABYwEAAp5q/4zhXoTUzXBscozN97SWgfDcAImIk3lNHNvd0b+Dr7jEm6upXblZ | |
| 1767 | T5sL9mPgFsejlIh+B/eCu/HvzWCrXj6ylPZv8dy3LCH3LIORqQ45S7Lsbmrrg/dukDh | |
| 1768 | 4tZCJMLD4r3evzaY8KVhtJeLMVbeXuh4JljKP42Ll59Lzwf8jfPh4+4Lae1rpWUCL9D | |
| 1769 | ueKcY+nN+xNHTit/ynLATxwL93P6+GoGY4TkUbUBfjiI1+rAMvyMDMw5XozGy07FOEc | |
| 1770 | ++U0iPeXCQP4MT5FipOUoz8CYX7J1LbaXp2WJuFHlkyVXF7oCoyHbhld/5CfR3o6q/B | |
| 1771 | /x9+yZRqaHH+JfllOgBfbWRhPVNIQS0xLHJlcGxheSBkZXRlY3Rpb24saW50ZWdyaXR | |
| 1772 | 5PWhtYWMtbWQ1LGNvbmZpZGVudGlhbGl0eT1ibG93ZmlzaCxtYXhidWZmZXJzaXplPT | |
| 1773 | IxNDc0ODM2NDM= | |
| 1774 | ||
| 1775 | with: | |
| 1776 | ||
| 1777 | A = "33059541846712102497463123211304342021934496372587869281515 | |
| 1778 | 9695658237779884462777478850394977744553746930451895815615888405 | |
| 1779 | 0562780707370878253753979367019077142882237029766166623275718227 | |
| 1780 | 6555389834190840322081091599089081947324537907613924707058150037 | |
| 1781 | 7802790776231793962143786411792516760030102436603621046541729396 | |
| 1782 | 6890613394379900527412007068242559299422872893332111365840536495 | |
| 1783 | 1858834742328835373387573188369956379881606380890675411966073665 | |
| 1784 | 1106922002294035533470301541999274557200666703389531481794516625 | |
| 1785 | 4757418442215980634933876533189969562613241499465295849832999091 | |
| 1786 | 40398081321840949606581251320320995783959866" | |
| 1787 | ||
| 1788 | ||
| 1789 | ||
| 1790 | ||
| 1791 | Burdis & Naffah Expires November 28, 2003 [Page 32] | |
| 1792 | ||
| 1793 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1794 | ||
| 1795 | ||
| 1796 | o = mda=sha-1,replay_detection,integrity=hmac-md5,confidentialit | |
| 1797 | y=blowfish,maxbuffersize=2147483643" | |
| 1798 | ||
| 1799 | S: 334 AAABAgEAOUKbXpnzMhziivGgMwm+FS8sKGSvjh5M3D+80RF/5z9rm0oPoi4+ | |
| 1800 | pF83fueWn4Hz9M+muF/22PHHZkHtlutDrtapj4OtirdxC21fS9bMtEh3F0whTX+3mPv | |
| 1801 | thw5sk11turandHiLvcUZOgcrAGIoDKcBPoGyBud+8bMgpkf/uGfyBM2nEX/hV+oGgg | |
| 1802 | X+LiHjmkxAJ3kewfQPH0eV9ffEuuyu8BUcBXkJsS6l7eWkuERSCttVOi/jS031c+CD/ | |
| 1803 | nuecUXYiF8IYzW03rbcwYhZzifmTi3VK9C8zG2K1WmGU+cDKlZMkyCPMmtCsxlbgE8z | |
| 1804 | SHCuCiOgQ35XhcA0Qa0C3Q== | |
| 1805 | ||
| 1806 | with: | |
| 1807 | ||
| 1808 | B: "722842847565031844205403087285424428589273458129750231766015 | |
| 1809 | 4465607827529853239240118185263492617243523916106658696965596526 | |
| 1810 | 8585300845435562962039149169549800169184521786717633959469278439 | |
| 1811 | 8771344445002432579509292115598435685062882631760796416554562980 | |
| 1812 | 8475896198325835507901319556929511421472132184990365213059654962 | |
| 1813 | 7218189966140113906545856088040473723048909402258929560823932725 | |
| 1814 | 2022154114087913895411927676707073040281136096806681758265221209 | |
| 1815 | 8822374723416364340410020172215773934302794679034424699999611678 | |
| 1816 | 9730443114919539575466941344964841591072763617954717789621871251 | |
| 1817 | 71089179399349194452686682517183909017223901" | |
| 1818 | ||
| 1819 | C: AAAAFRTkoju6xGP+zH89iaDWIFjfIKt5Kg== | |
| 1820 | ||
| 1821 | S: 235 Authentication successful. | |
| 1822 | ||
| 1823 | ||
| 1824 | ||
| 1825 | ||
| 1826 | ||
| 1827 | ||
| 1828 | ||
| 1829 | ||
| 1830 | ||
| 1831 | ||
| 1832 | ||
| 1833 | ||
| 1834 | ||
| 1835 | ||
| 1836 | ||
| 1837 | ||
| 1838 | ||
| 1839 | ||
| 1840 | ||
| 1841 | ||
| 1842 | ||
| 1843 | ||
| 1844 | ||
| 1845 | ||
| 1846 | ||
| 1847 | Burdis & Naffah Expires November 28, 2003 [Page 33] | |
| 1848 | ||
| 1849 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1850 | ||
| 1851 | ||
| 1852 | 8. GSS-API | |
| 1853 | ||
| 1854 | 8.1 Overview | |
| 1855 | ||
| 1856 | The GSS-API is described as follows: | |
| 1857 | ||
| 1858 | The Generic Security Service Application Program Interface | |
| 1859 | (GSS-API), Version 2, as defined in [RFC-2078], provides security | |
| 1860 | services to callers in a generic fashion, supportable with a range | |
| 1861 | of underlying mechanisms and technologies and hence allowing | |
| 1862 | source-level portability of applications to different | |
| 1863 | environments. | |
| 1864 | ||
| 1865 | According to [RFC-2078] there are certain specifications related to | |
| 1866 | the GSS-API that are: | |
| 1867 | ||
| 1868 | "documents defining token formats, protocols, and procedures to be | |
| 1869 | implemented in order to realize GSS-API services atop particular | |
| 1870 | security mechanisms" | |
| 1871 | ||
| 1872 | This specification is such a document - it defines a security | |
| 1873 | mechanism that can be used with the GSS-API authentication framework. | |
| 1874 | ||
| 1875 | 8.2 Terminology | |
| 1876 | ||
| 1877 | The tokens referred to in the GSS-API specification [RFC-2078] are | |
| 1878 | the same as the buffers referred to in this document. | |
| 1879 | ||
| 1880 | 8.3 Initial Token | |
| 1881 | ||
| 1882 | [RFC-2078] states that: | |
| 1883 | ||
| 1884 | The first context-level token obtained from GSS_Init_sec_context() | |
| 1885 | is required to indicate at its very beginning a | |
| 1886 | globally-interpretable mechanism identifier, i.e., an Object | |
| 1887 | Identifier (OID) of the security mechanism. The remaining part of | |
| 1888 | this token as well as the whole content of all other tokens are | |
| 1889 | specific to the particular underlying mechanism used to support | |
| 1890 | the GSS-API. | |
| 1891 | ||
| 1892 | To satisfy this requirement and make use of the mechanism described | |
| 1893 | in this document as a GSS-API mechanism, the following octets must be | |
| 1894 | prefixed to the first buffer sent as part of the protocol described | |
| 1895 | in Section 4: | |
| 1896 | ||
| 1897 | [ 60 08 06 06 2B 06 01 05 05 08 ] | |
| 1898 | ||
| 1899 | Each octet is written as a pair of hex digits - see Section 2. | |
| 1900 | ||
| 1901 | ||
| 1902 | ||
| 1903 | Burdis & Naffah Expires November 28, 2003 [Page 34] | |
| 1904 | ||
| 1905 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1906 | ||
| 1907 | ||
| 1908 | These octets represent the encoding of the GSS-API mechanism | |
| 1909 | identifier as per section 3.1 of [RFC-2078]. The OID for this | |
| 1910 | mechanism is iso.org.dod.internet.security.mechanisms.srp | |
| 1911 | (1.3.6.1.5.5.8). | |
| 1912 | ||
| 1913 | Note that it is not possible to make this requirement part of the | |
| 1914 | security protocol itself, because other authentication frameworks | |
| 1915 | have different requirements for the initial octets in a mechanism | |
| 1916 | buffer. | |
| 1917 | ||
| 1918 | 8.4 Security Layer | |
| 1919 | ||
| 1920 | This mechanism does not provide distinct replay detection and | |
| 1921 | sequencing services as part of the security layer. Both of these | |
| 1922 | services are provided through the use of sequence numbers in | |
| 1923 | integrity protected messages. If a GSS-API caller sets either the | |
| 1924 | replay_det_req_flag or the sequence_req_flag (section 1.2.3 of | |
| 1925 | [RFC-2078]) then this selects the "replay_detection" security | |
| 1926 | service. | |
| 1927 | ||
| 1928 | This mechanism does not make use of any channel binding data (section | |
| 1929 | 1.1.6 of [RFC-2078]). | |
| 1930 | ||
| 1931 | ||
| 1932 | ||
| 1933 | ||
| 1934 | ||
| 1935 | ||
| 1936 | ||
| 1937 | ||
| 1938 | ||
| 1939 | ||
| 1940 | ||
| 1941 | ||
| 1942 | ||
| 1943 | ||
| 1944 | ||
| 1945 | ||
| 1946 | ||
| 1947 | ||
| 1948 | ||
| 1949 | ||
| 1950 | ||
| 1951 | ||
| 1952 | ||
| 1953 | ||
| 1954 | ||
| 1955 | ||
| 1956 | ||
| 1957 | ||
| 1958 | ||
| 1959 | Burdis & Naffah Expires November 28, 2003 [Page 35] | |
| 1960 | ||
| 1961 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 1962 | ||
| 1963 | ||
| 1964 | 9. EAP | |
| 1965 | ||
| 1966 | 9.1 Overview | |
| 1967 | ||
| 1968 | The Extensible Authentication Protocol (EAP) [RFC-2284] is an | |
| 1969 | authentication framework that supports multiple authentication | |
| 1970 | mechanisms. It is used with link layer protocols such as PPP and the | |
| 1971 | IEEE-802 wired and wireless protocols. | |
| 1972 | ||
| 1973 | 9.2 Terminology | |
| 1974 | ||
| 1975 | EAP uses the following terms to describe the entities involved in the | |
| 1976 | authentication exchange [rfc2284bis]: | |
| 1977 | ||
| 1978 | Authenticator: The entity that initiates EAP authentication in order | |
| 1979 | to authenticate a Peer. | |
| 1980 | ||
| 1981 | Peer: The entity that responds to requests from the Authenticator. | |
| 1982 | ||
| 1983 | In this document, the Server corresponds to the Authenticator and the | |
| 1984 | Client corresponds to the Peer. | |
| 1985 | ||
| 1986 | 9.3 Method Details | |
| 1987 | ||
| 1988 | The EAP authentication method described in this document has the | |
| 1989 | following properties: | |
| 1990 | ||
| 1991 | Method Name: SRP | |
| 1992 | ||
| 1993 | Method Type: 7 | |
| 1994 | ||
| 1995 | As described in section 2 of [rfc2284bis] the EAP authentication | |
| 1996 | exchange is initiated by the Authenticator sending a Request packet | |
| 1997 | to the peer with a Type field indicating the type of request. The | |
| 1998 | Peer responds with a corresponding Reply packet, and the | |
| 1999 | Authenticator and Peer exchange additional corresponding Request and | |
| 2000 | Reply packets until the Authenticator deems that the authentication | |
| 2001 | exchange is successful and complete, whereafter the Authenticator | |
| 2002 | sends a Success packet. However, if at any time the Authenticator | |
| 2003 | deems the authentication exchange to be unsuccessful it sends a | |
| 2004 | Failure packet to indicate this. | |
| 2005 | ||
| 2006 | When using this authentication method, the Type field in all Request | |
| 2007 | and Reply packets is set to 7 and the Type Data is as described in | |
| 2008 | Section 4 and the rest of this document. The diagrams below | |
| 2009 | illustrate the EAP packet exchanges for this authentication method. | |
| 2010 | ||
| 2011 | The following exchange occurs when a new session is negotiated | |
| 2012 | ||
| 2013 | ||
| 2014 | ||
| 2015 | Burdis & Naffah Expires November 28, 2003 [Page 36] | |
| 2016 | ||
| 2017 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2018 | ||
| 2019 | ||
| 2020 | between the client and the server. It will also occur when the | |
| 2021 | client requests re-use of the parameters of a previous session and | |
| 2022 | either the server does not support such re-use or no longer considers | |
| 2023 | the previous session to be valid: | |
| 2024 | ||
| 2025 | Peer (client) Authenticator (server) | |
| 2026 | ||
| 2027 | <------------ Request [ 7, { } ] ---------------------------- | |
| 2028 | ||
| 2029 | ---- Reply [ 7, { U, I, sid, cn } ] -------------------------> | |
| 2030 | ||
| 2031 | <------------ Request [ 7, { 00, N, g, s, B, L } ] ---------- | |
| 2032 | ||
| 2033 | ---- Reply [ 7, { A, M1, o, cIV } ] ------------------------> | |
| 2034 | ||
| 2035 | <------------ Request [ 7, { M2, sIV, sid, ttl } ] ---------- | |
| 2036 | ||
| 2037 | ---- Reply [ 7, { } ] --------------------------------------> | |
| 2038 | ||
| 2039 | The following exchange occurs when the client requests that the | |
| 2040 | parameters negotiated in a previous session be re-used in this | |
| 2041 | session, but with a newly derived shared context key, and the server | |
| 2042 | agrees: | |
| 2043 | ||
| 2044 | Peer (client) Authenticator (server) | |
| 2045 | ||
| 2046 | <----------------------------- Request [ 7, { } ] ----------- | |
| 2047 | ||
| 2048 | --------- Reply [ 7, { U, I, sid, cn } ] -------------------> | |
| 2049 | ||
| 2050 | <----------------------------- Request [ 7, { FF, sn } ] ---- | |
| 2051 | ||
| 2052 | --------- Reply [ 7, { } ] ---------------------------------> | |
| 2053 | ||
| 2054 | If a security layer is negotiated then the payloads of all subsequent | |
| 2055 | lower layer packets sent over the link are protected using the | |
| 2056 | negotiated security services. | |
| 2057 | ||
| 2058 | 9.4 Security Claims | |
| 2059 | ||
| 2060 | As required by section 7.2 of [rfc2284bis], these are the security | |
| 2061 | claims made by this authentication method indicating the level of | |
| 2062 | security provided: | |
| 2063 | ||
| 2064 | Intended Use: Wired networks, including PPP, PPPOE, and IEEE-802 | |
| 2065 | wired media. Use over the Internet or with wireless media only | |
| 2066 | when the recommended security layer has been negotiated. | |
| 2067 | ||
| 2068 | ||
| 2069 | ||
| 2070 | ||
| 2071 | Burdis & Naffah Expires November 28, 2003 [Page 37] | |
| 2072 | ||
| 2073 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2074 | ||
| 2075 | ||
| 2076 | Mechanism: Passphrase | |
| 2077 | ||
| 2078 | Mutual authentication: Yes. This mechanism requires mutual | |
| 2079 | authentication. | |
| 2080 | ||
| 2081 | Integrity protection: Yes. The calculations of evidence that the | |
| 2082 | shared context key is known - M1 sent by the client and M2 sent by | |
| 2083 | the server - include the protocol elements received from the | |
| 2084 | other party, so any modification by a third party will be | |
| 2085 | detected. SRP itself is resistent to known active and passive | |
| 2086 | attacks - see [SRP]. | |
| 2087 | ||
| 2088 | Replay protection: Yes. Both the client and the server randomly | |
| 2089 | generate ephemeral private keys (a and b) that are used in the SRP | |
| 2090 | calculations, but are not publicly revealed. New ephemeral | |
| 2091 | private keys are generated for each session making replay attacks | |
| 2092 | infeasible. | |
| 2093 | ||
| 2094 | Confidentiality: No. | |
| 2095 | ||
| 2096 | Key Derivation: No. | |
| 2097 | ||
| 2098 | Dictionary attack protection: Yes. From [SRP]: "An attacker with | |
| 2099 | neither the user's password nor the host's password file cannot | |
| 2100 | mount a dictionary attack on the password". | |
| 2101 | ||
| 2102 | Fast reconnect: Yes. An optional, optimised alternate authentication | |
| 2103 | exchange is available where the parameters of a previously | |
| 2104 | negotiated session are re-used, but with a newly derived shared | |
| 2105 | context key - see Section 6.4. | |
| 2106 | ||
| 2107 | Man-in-the-Middle resistance: Yes. The calculations of evidence - M1 | |
| 2108 | sent by the client and M2 sent by the server - include the | |
| 2109 | protocol elements received from the other party, so any | |
| 2110 | modification by a third party will be detected. SRP itself is | |
| 2111 | resistent to known active attacks, including man-in-the-middle | |
| 2112 | attacks - see [SRP]. | |
| 2113 | ||
| 2114 | Acknowledged result indications: Yes. When the client receives M2 | |
| 2115 | from the server it knows that the server has verified that the | |
| 2116 | evidence (M1) it presented to prove its knowledge of the shared | |
| 2117 | context key is correct, so it knows that it is authenticated to | |
| 2118 | the server. When the server receives the empty response from the | |
| 2119 | client at the end of the authentication exchange, it knows that | |
| 2120 | the client has verified that the evidence (M2) it presented to | |
| 2121 | prove its knowledge of the shared context key is correct, so it | |
| 2122 | knows that it is authenticated to the client. Similarly for | |
| 2123 | session re-use where the client receives the server nonce (sn) | |
| 2124 | ||
| 2125 | ||
| 2126 | ||
| 2127 | Burdis & Naffah Expires November 28, 2003 [Page 38] | |
| 2128 | ||
| 2129 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2130 | ||
| 2131 | ||
| 2132 | from the server, and the server receives the final empty response | |
| 2133 | from the client. | |
| 2134 | ||
| 2135 | Key hierarchy: N/A | |
| 2136 | ||
| 2137 | Key strength: The shared context key (K) negotiated between the | |
| 2138 | client and server has a length of s, where "s" is the output | |
| 2139 | length of the chosen underlying Message Digest Algorithm used in | |
| 2140 | the SRP calculations (see "mda" option in Section 4.3). For | |
| 2141 | example, the recommended Message Digest Algorithm SHA-160 has an | |
| 2142 | output length of 160 bits, so in this case the length of K would | |
| 2143 | be 160 bits. Keys for the confidentiality and integrity | |
| 2144 | protection services are derived from K - see Section 5.1.2 - and | |
| 2145 | have sizes appropriate for the algorithms being used. Note that | |
| 2146 | all Message Digest Algorithms used with this mechanism MUST have | |
| 2147 | an output of at least 16 bytes (see "mda" option in Section 4.3), | |
| 2148 | which means that the shared context key will always have a length | |
| 2149 | of at least 128 bits. | |
| 2150 | ||
| 2151 | ||
| 2152 | ||
| 2153 | ||
| 2154 | ||
| 2155 | ||
| 2156 | ||
| 2157 | ||
| 2158 | ||
| 2159 | ||
| 2160 | ||
| 2161 | ||
| 2162 | ||
| 2163 | ||
| 2164 | ||
| 2165 | ||
| 2166 | ||
| 2167 | ||
| 2168 | ||
| 2169 | ||
| 2170 | ||
| 2171 | ||
| 2172 | ||
| 2173 | ||
| 2174 | ||
| 2175 | ||
| 2176 | ||
| 2177 | ||
| 2178 | ||
| 2179 | ||
| 2180 | ||
| 2181 | ||
| 2182 | ||
| 2183 | Burdis & Naffah Expires November 28, 2003 [Page 39] | |
| 2184 | ||
| 2185 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2186 | ||
| 2187 | ||
| 2188 | 10. Security Considerations | |
| 2189 | ||
| 2190 | This mechanism relies on the security of SRP, which bases its | |
| 2191 | security on the difficulty of solving the Diffie-Hellman problem in | |
| 2192 | the multiplicative field modulo a large safe prime. See section 4 | |
| 2193 | "Security Considerations" of [RFC-2945], section 4 "Security | |
| 2194 | analysis" of [SRP], and [SRP-6i]. | |
| 2195 | ||
| 2196 | This mechanism also relies on the security of the HMAC algorithm and | |
| 2197 | the underlying hash function when integrity protection is used. | |
| 2198 | Section 6 "Security" of [RFC-2104] discusses these security issues in | |
| 2199 | detail. Weaknesses found in MD5 do not impact HMAC-MD5 [DOBBERTIN]. | |
| 2200 | ||
| 2201 | U, I, A and o, sent from the client to the server, and N, g, s, B and | |
| 2202 | L, sent from the server to the client, could be modified by an | |
| 2203 | attacker before reaching the other party. For this reason, these | |
| 2204 | values are included in the respective calculations of evidence (M1 | |
| 2205 | and M2) to prove that each party knows the shared context key K. | |
| 2206 | This allows each party to verify that these values were received | |
| 2207 | unmodified. | |
| 2208 | ||
| 2209 | The use of integrity protection is RECOMMENDED to detect message | |
| 2210 | tampering and to avoid session hijacking after authentication has | |
| 2211 | taken place. | |
| 2212 | ||
| 2213 | Replay attacks may be avoided through the use of sequence numbers, | |
| 2214 | because sequence numbers make each integrity protected message | |
| 2215 | exchanged during a session different, and each session uses a | |
| 2216 | different key. | |
| 2217 | ||
| 2218 | Research [KRAWCZYK] shows that the order and way of combining message | |
| 2219 | encryption (Confidentiality Protection) and message authentication | |
| 2220 | (Integrity Protection) are important. This mechanism follows the EtA | |
| 2221 | (encrypt-then-authenticate) method and is "generically secure". | |
| 2222 | ||
| 2223 | This mechanism uses a Pseudo-Random Number Generator (PRNG) for | |
| 2224 | generating some of its parameters. Section 5.1.1 describes a | |
| 2225 | securely seeded, cryptographically strong PRNG implementation for | |
| 2226 | this purpose. | |
| 2227 | ||
| 2228 | ||
| 2229 | ||
| 2230 | ||
| 2231 | ||
| 2232 | ||
| 2233 | ||
| 2234 | ||
| 2235 | ||
| 2236 | ||
| 2237 | ||
| 2238 | ||
| 2239 | Burdis & Naffah Expires November 28, 2003 [Page 40] | |
| 2240 | ||
| 2241 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2242 | ||
| 2243 | ||
| 2244 | 11. Acknowledgements | |
| 2245 | ||
| 2246 | The following people provided valuable feedback in the preparation of | |
| 2247 | this document: | |
| 2248 | ||
| 2249 | Stephen Farrell <stephen.farrell@baltimore.ie> | |
| 2250 | ||
| 2251 | Sam Hartman <hartmans@mit.edu> | |
| 2252 | ||
| 2253 | Timothy Martin <tmartin@andrew.cmu.edu> | |
| 2254 | ||
| 2255 | Alexey Melnikov <mel@messagingdirect.com> | |
| 2256 | ||
| 2257 | Ken Murchison <ken@oceana.com> | |
| 2258 | ||
| 2259 | Magnus Nystrom <magnus@rsasecurity.com> | |
| 2260 | ||
| 2261 | David Taylor <DavidTaylor@forge.com.au> | |
| 2262 | ||
| 2263 | Thomas Wu <tom@arcot.com> | |
| 2264 | ||
| 2265 | ||
| 2266 | ||
| 2267 | ||
| 2268 | ||
| 2269 | ||
| 2270 | ||
| 2271 | ||
| 2272 | ||
| 2273 | ||
| 2274 | ||
| 2275 | ||
| 2276 | ||
| 2277 | ||
| 2278 | ||
| 2279 | ||
| 2280 | ||
| 2281 | ||
| 2282 | ||
| 2283 | ||
| 2284 | ||
| 2285 | ||
| 2286 | ||
| 2287 | ||
| 2288 | ||
| 2289 | ||
| 2290 | ||
| 2291 | ||
| 2292 | ||
| 2293 | ||
| 2294 | ||
| 2295 | Burdis & Naffah Expires November 28, 2003 [Page 41] | |
| 2296 | ||
| 2297 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2298 | ||
| 2299 | ||
| 2300 | Normative References | |
| 2301 | ||
| 2302 | [RFC-2078] | |
| 2303 | Linn, J., "Generic Security Service Application Program | |
| 2304 | Interface, Version 2", RFC 2078, January 1997, <http:// | |
| 2305 | www.ietf.org/rfc/rfc2078.txt>. | |
| 2306 | ||
| 2307 | [RFC-2104] | |
| 2308 | Krawczyk, H., "HMAC: Keyed-Hashing for Message | |
| 2309 | Authentication", RFC 2104, February 1997, <http:// | |
| 2310 | www.ietf.org/rfc/rfc2104.txt>. | |
| 2311 | ||
| 2312 | [RFC-2119] | |
| 2313 | Bradner, S., "Key words for use in RFCs to Indicate | |
| 2314 | Requirement Levels", BCP 0014, RFC 2119, March 1997, | |
| 2315 | <http://www.ietf.org/rfc/rfc2119.txt>. | |
| 2316 | ||
| 2317 | [RFC-2222] | |
| 2318 | Myers, J., "Simple Authentication and Security Layer | |
| 2319 | (SASL)", RFC 2222, October 1997, <http://www.ietf.org/rfc/ | |
| 2320 | rfc2222.txt>. | |
| 2321 | ||
| 2322 | [RFC-2284] | |
| 2323 | Blunk, L. and J. Vollbrecht, "PPP Extensible | |
| 2324 | Authentication Protocol (EAP)", RFC 2284, March 1998, | |
| 2325 | <http://www.ietf.org/rfc/rfc2284.txt>. | |
| 2326 | ||
| 2327 | [rfc2284bis] | |
| 2328 | Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. | |
| 2329 | Levkowetz, "Extensible Authentication Protocol (EAP), work | |
| 2330 | in progress", May 2003, <http://www.ietf.org/ | |
| 2331 | internet-drafts/draft-ietf-eap-rfc2284bis-03.txt>. | |
| 2332 | ||
| 2333 | [RFC-2945] | |
| 2334 | Wu, T., "The SRP Authentication and Key Exchange System", | |
| 2335 | RFC 2945, September 2000, <http://www.ietf.org/rfc/ | |
| 2336 | rfc2945.txt>. | |
| 2337 | ||
| 2338 | [RFC-3454] | |
| 2339 | Hoffman, P. and M. Blanchet, "Preparation of | |
| 2340 | Internationalized Strings ("stringprep")", RFC 3454, | |
| 2341 | December 2002, <http://www.ietf.org/rfc/rfc3454.txt>. | |
| 2342 | ||
| 2343 | [SASL] Myers, J., "Simple Authentication and Security Layer | |
| 2344 | (SASL)", April 2002, <http://www.ietf.org/internet-drafts/ | |
| 2345 | draft-myers-saslrev-02.txt>. | |
| 2346 | ||
| 2347 | [SASLprep] | |
| 2348 | ||
| 2349 | ||
| 2350 | ||
| 2351 | Burdis & Naffah Expires November 28, 2003 [Page 42] | |
| 2352 | ||
| 2353 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2354 | ||
| 2355 | ||
| 2356 | Zeilenga, K., "SASLprep: Stringprep profile for user names | |
| 2357 | and passwords, work in progress", May 2003, <http:// | |
| 2358 | www.ietf.org/internet-drafts/ | |
| 2359 | draft-ietf-sasl-saslprep-01.txt>. | |
| 2360 | ||
| 2361 | [SRP] Wu, T., "The Secure Remote Password Protocol, Proceedings | |
| 2362 | of the 1998 Internet Society Network and Distributed | |
| 2363 | System Security Symposium, San Diego, CA, Mar 1998, pp. | |
| 2364 | 97-111", March 1998, <http://srp.stanford.edu/ndss.html>. | |
| 2365 | ||
| 2366 | [SRP-6i] Wu, T., "SRP-6: Improvements and Refinements to the Secure | |
| 2367 | Remote Password Protocol", October 2002, <http:// | |
| 2368 | srp.stanford.edu/srp6.ps>. | |
| 2369 | ||
| 2370 | ||
| 2371 | ||
| 2372 | ||
| 2373 | ||
| 2374 | ||
| 2375 | ||
| 2376 | ||
| 2377 | ||
| 2378 | ||
| 2379 | ||
| 2380 | ||
| 2381 | ||
| 2382 | ||
| 2383 | ||
| 2384 | ||
| 2385 | ||
| 2386 | ||
| 2387 | ||
| 2388 | ||
| 2389 | ||
| 2390 | ||
| 2391 | ||
| 2392 | ||
| 2393 | ||
| 2394 | ||
| 2395 | ||
| 2396 | ||
| 2397 | ||
| 2398 | ||
| 2399 | ||
| 2400 | ||
| 2401 | ||
| 2402 | ||
| 2403 | ||
| 2404 | ||
| 2405 | ||
| 2406 | ||
| 2407 | Burdis & Naffah Expires November 28, 2003 [Page 43] | |
| 2408 | ||
| 2409 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2410 | ||
| 2411 | ||
| 2412 | Informative References | |
| 2413 | ||
| 2414 | [AES] National Institute of Standards and Technology, "Rijndael: | |
| 2415 | NIST's Selection for the AES", December 2000, <http:// | |
| 2416 | csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf>. | |
| 2417 | ||
| 2418 | [DOBBERTIN] | |
| 2419 | Dobbertin, H., "The Status of MD5 After a Recent Attack", | |
| 2420 | December 1996, <ftp://ftp.rsasecurity.com/pub/cryptobytes/ | |
| 2421 | crypto2n2.pdf>. | |
| 2422 | ||
| 2423 | [HAC] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook | |
| 2424 | of Applied Cryptography", CRC Press, Inc., ISBN | |
| 2425 | 0-8493-8523-7, 1997, <http://www.cacr.math.uwaterloo.ca/ | |
| 2426 | hac/about/chap7.ps>. | |
| 2427 | ||
| 2428 | [ISO-10646] | |
| 2429 | International Standards Organization, "International | |
| 2430 | Standard --Information technology-- Universal | |
| 2431 | Multiple-Octet Coded Character Set (UCS) -- Part 1 | |
| 2432 | Architecture and Basic Multilingual Plane. UTF-8 is | |
| 2433 | described in Annex R, adopted but not yet published. | |
| 2434 | UTF-16 is described in Annex Q, adopted but not yet | |
| 2435 | published.", ISO/IEC 10646-1, 1993. | |
| 2436 | ||
| 2437 | [KRAWCZYK] | |
| 2438 | Krawczyk, H., "The order of encryption and authentication | |
| 2439 | for protecting communications (Or: how secure is SSL?)", | |
| 2440 | June 2001, <http://eprint.iacr.org/2001/045/>. | |
| 2441 | ||
| 2442 | [PKCS7] RSA Data Security, Inc., "PKCS #7: Cryptographic Message | |
| 2443 | Syntax Standard", Version 1.5, November 1993, <ftp:// | |
| 2444 | ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-7.asc>. | |
| 2445 | ||
| 2446 | [RFC-1423] | |
| 2447 | Balenson, D., "Privacy Enhancement for Internet Electronic | |
| 2448 | Mail: Part III: Algorithms, Modes, and Identifiers", RFC | |
| 2449 | 1423, February 1993, <http://www.ietf.org/rfc/ | |
| 2450 | rfc1423.txt>. | |
| 2451 | ||
| 2452 | [RFC-2279] | |
| 2453 | Yergeau, F., "UTF-8, a transformation format of Unicode | |
| 2454 | and ISO 10646", RFC 2279, January 1998, <http:// | |
| 2455 | www.ietf.org/rfc/rfc2279.txt>. | |
| 2456 | ||
| 2457 | [RFC-2440] | |
| 2458 | Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, | |
| 2459 | "OpenPGP Message Format", RFC 2440, November 1998, <http:/ | |
| 2460 | ||
| 2461 | ||
| 2462 | ||
| 2463 | Burdis & Naffah Expires November 28, 2003 [Page 44] | |
| 2464 | ||
| 2465 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2466 | ||
| 2467 | ||
| 2468 | /www.ietf.org/rfc/rfc2440.txt>. | |
| 2469 | ||
| 2470 | [RFC-2554] | |
| 2471 | Myers, J., "SMTP Service Extension for Authentication", | |
| 2472 | RFC 2554, March 1999. | |
| 2473 | ||
| 2474 | [RFC-2629] | |
| 2475 | Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, | |
| 2476 | June 1999, <http://www.ietf.org/rfc/rfc2629.txt>. | |
| 2477 | ||
| 2478 | [RFC-2847] | |
| 2479 | Eisler, M., "LIPKEY - A Low Infrastructure Public Key | |
| 2480 | Mechanism Using SPKM", RFC 2847, June 2000, <http:// | |
| 2481 | www.ietf.org/rfc/rfc2847.txt>. | |
| 2482 | ||
| 2483 | [SCAN] Hopwood, D., "Standard Cryptographic Algorithm Naming", | |
| 2484 | June 2000, <http://www.eskimo.com/~weidai/scan-mirror/>. | |
| 2485 | ||
| 2486 | [SRP-6] Wu, T., "SRP Protocol Design", October 2002, <http:// | |
| 2487 | srp.stanford.edu/design.html>. | |
| 2488 | ||
| 2489 | [SRPimpl] Wu, T., "SRP: The Open Source Password Authentication | |
| 2490 | Standard", March 1998, <http://srp.stanford.edu/srp/>. | |
| 2491 | ||
| 2492 | [UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T. and P. | |
| 2493 | Rogaway, "UMAC: Fast and Secure Message Authentication, | |
| 2494 | Advances in Cryptology - CRYPTO '99. Lecture Notes in | |
| 2495 | Computer Science, vol. 1666, Springer-Verlag, 1999, pp. | |
| 2496 | 216-233", October 2000, <http://www.cs.ucdavis.edu/ | |
| 2497 | ~rogaway/umac/umac_proc.pdf>. | |
| 2498 | ||
| 2499 | [UNICODE] The Unicode Consortium, "The Unicode Standard, Version | |
| 2500 | 3.2.0, is defined by The Unicode Standard, Version 3.0, as | |
| 2501 | amended by the Unicode Standard Annex #27: Unicode 3.1 and | |
| 2502 | by the Unicode Standard Annex #28: Unicode 3.2.", March | |
| 2503 | 2002, <http://www.unicode.org/reports/tr28/tr28-3.html>. | |
| 2504 | ||
| 2505 | [UNICODE-KC] | |
| 2506 | Durst, D., "Unicode Standard Annex #15: Unicode | |
| 2507 | Normalization Forms.", March 2001, <http:// | |
| 2508 | www.unicode.org/unicode/reports/tr15>. | |
| 2509 | ||
| 2510 | ||
| 2511 | ||
| 2512 | ||
| 2513 | ||
| 2514 | ||
| 2515 | ||
| 2516 | ||
| 2517 | ||
| 2518 | ||
| 2519 | Burdis & Naffah Expires November 28, 2003 [Page 45] | |
| 2520 | ||
| 2521 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2522 | ||
| 2523 | ||
| 2524 | Authors' Addresses | |
| 2525 | ||
| 2526 | Keith Burdis | |
| 2527 | Rhodes University | |
| 2528 | Computer Science Department | |
| 2529 | Grahamstown 6139 | |
| 2530 | ZA | |
| 2531 | ||
| 2532 | EMail: keith@rucus.ru.ac.za | |
| 2533 | ||
| 2534 | ||
| 2535 | Raif S. Naffah | |
| 2536 | Forge Research Pty. Limited | |
| 2537 | Suite 116, Bay 9 | |
| 2538 | Locomotive Workshop, | |
| 2539 | Australian Technology Park | |
| 2540 | Cornwallis Street | |
| 2541 | Eveleigh, NSW 1430 | |
| 2542 | AU | |
| 2543 | ||
| 2544 | EMail: raif@forge.com.au | |
| 2545 | ||
| 2546 | ||
| 2547 | ||
| 2548 | ||
| 2549 | ||
| 2550 | ||
| 2551 | ||
| 2552 | ||
| 2553 | ||
| 2554 | ||
| 2555 | ||
| 2556 | ||
| 2557 | ||
| 2558 | ||
| 2559 | ||
| 2560 | ||
| 2561 | ||
| 2562 | ||
| 2563 | ||
| 2564 | ||
| 2565 | ||
| 2566 | ||
| 2567 | ||
| 2568 | ||
| 2569 | ||
| 2570 | ||
| 2571 | ||
| 2572 | ||
| 2573 | ||
| 2574 | ||
| 2575 | Burdis & Naffah Expires November 28, 2003 [Page 46] | |
| 2576 | ||
| 2577 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2578 | ||
| 2579 | ||
| 2580 | Appendix A. Modulus and Generator Values | |
| 2581 | ||
| 2582 | Modulus N and generator g values for various modulus lengths are | |
| 2583 | given below. In each case the modulus is a large safe prime and the | |
| 2584 | generator is a primitve root of GF(n) [RFC-2945]. These values are | |
| 2585 | taken from software developed by Tom Wu and Eugene Jhong for the | |
| 2586 | Stanford SRP distribution [SRPimpl]. | |
| 2587 | ||
| 2588 | [264 bits] | |
| 2589 | Modulus (base 16) = | |
| 2590 | 115B8B692E0E045692CF280B436735C77A5A9E8A9E7ED56C965F87DB5B2A2 | |
| 2591 | ECE3 | |
| 2592 | Generator = 2 | |
| 2593 | ||
| 2594 | [384 bits] | |
| 2595 | Modulus (base 16) = | |
| 2596 | 8025363296FB943FCE54BE717E0E2958A02A9672EF561953B2BAA3BAACC3E | |
| 2597 | D5754EB764C7AB7184578C57D5949CCB41B | |
| 2598 | Generator = 2 | |
| 2599 | ||
| 2600 | [512 bits] | |
| 2601 | Modulus (base 16) = | |
| 2602 | D4C7F8A2B32C11B8FBA9581EC4BA4F1B04215642EF7355E37C0FC0443EF75 | |
| 2603 | 6EA2C6B8EEB755A1C723027663CAA265EF785B8FF6A9B35227A52D86633DB | |
| 2604 | DFCA43 | |
| 2605 | Generator = 2 | |
| 2606 | ||
| 2607 | [640 bits] | |
| 2608 | Modulus (base 16) = | |
| 2609 | C94D67EB5B1A2346E8AB422FC6A0EDAEDA8C7F894C9EEEC42F9ED250FD7F0 | |
| 2610 | 046E5AF2CF73D6B2FA26BB08033DA4DE322E144E7A8E9B12A0E4637F6371F | |
| 2611 | 34A2071C4B3836CBEEAB15034460FAA7ADF483 | |
| 2612 | Generator = 2 | |
| 2613 | ||
| 2614 | [768 bits] | |
| 2615 | Modulus (base 16) = | |
| 2616 | B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9 | |
| 2617 | F402653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE | |
| 2618 | 694AFF737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867 | |
| 2619 | C60C3262B | |
| 2620 | Generator = 2 | |
| 2621 | ||
| 2622 | [1024 bits] | |
| 2623 | Modulus (base 16) = | |
| 2624 | EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256 | |
| 2625 | 576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D60 | |
| 2626 | 89DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F56 | |
| 2627 | 6660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC6 | |
| 2628 | ||
| 2629 | ||
| 2630 | ||
| 2631 | Burdis & Naffah Expires November 28, 2003 [Page 47] | |
| 2632 | ||
| 2633 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2634 | ||
| 2635 | ||
| 2636 | 1D2FC0EB06E3 | |
| 2637 | Generator = 2 | |
| 2638 | ||
| 2639 | [1280 bits] | |
| 2640 | Modulus (base 16) = | |
| 2641 | D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690 | |
| 2642 | DC43872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E | |
| 2643 | 004B786C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744 | |
| 2644 | B1CDE1891690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB | |
| 2645 | 14BB2049B163EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5 | |
| 2646 | 003686161F0605B | |
| 2647 | Generator = 2 | |
| 2648 | ||
| 2649 | [1536 bits] | |
| 2650 | Modulus (base 16) = | |
| 2651 | 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19C | |
| 2652 | C4D5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A | |
| 2653 | 22E8DCDF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D4754838 | |
| 2654 | 1DBC5B1FC764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2F | |
| 2655 | D53D24B7C48665772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87 | |
| 2656 | F8A2FE9B8B5292E5A021FFF5E91479E8CE7A28C2442C6F315180F93499A23 | |
| 2657 | 4DCF76E3FED135F9BB | |
| 2658 | Generator = 2 | |
| 2659 | ||
| 2660 | [2048 bits] | |
| 2661 | Modulus (base 16) = | |
| 2662 | AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56 | |
| 2663 | 050A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA | |
| 2664 | 04FD50E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A99 | |
| 2665 | 62F0B93B855F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D28 | |
| 2666 | 1E446B14773BCA97B43A23FB801676BD207A436C6481F1D2B9078717461A5 | |
| 2667 | B9D32E688F87748544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3 | |
| 2668 | 786160279004E57AE6AF874E7303CE53299CCC041C7BC308D82A5698F3A8D | |
| 2669 | 0C38271AE35F8E9DBFBB694B5C803D89F7AE435DE236D525F54759B65E372 | |
| 2670 | FCD68EF20FA7111F9E4AFF73 | |
| 2671 | Generator = 2 | |
| 2672 | ||
| 2673 | ||
| 2674 | ||
| 2675 | ||
| 2676 | ||
| 2677 | ||
| 2678 | ||
| 2679 | ||
| 2680 | ||
| 2681 | ||
| 2682 | ||
| 2683 | ||
| 2684 | ||
| 2685 | ||
| 2686 | ||
| 2687 | Burdis & Naffah Expires November 28, 2003 [Page 48] | |
| 2688 | ||
| 2689 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2690 | ||
| 2691 | ||
| 2692 | Appendix B. Changes since the previous draft | |
| 2693 | ||
| 2694 | Removed specific references to SASL in the main document, instead | |
| 2695 | isolating them to their own section. | |
| 2696 | ||
| 2697 | Added sections describing how the mechanism can be used with the | |
| 2698 | GSS-API and EAP authentication frameworks. | |
| 2699 | ||
| 2700 | Adopted SRP-6 exchange for the base protocol. | |
| 2701 | ||
| 2702 | Mandated the use of SASLprep profile for text based information. | |
| 2703 | ||
| 2704 | Added an optional, optimised alternate authentication exchange where | |
| 2705 | the parameters of a previously negotiated session are re-used, but | |
| 2706 | with a newly derived shared context key. | |
| 2707 | ||
| 2708 | TODO: Regenerate SASL example. | |
| 2709 | ||
| 2710 | ||
| 2711 | ||
| 2712 | ||
| 2713 | ||
| 2714 | ||
| 2715 | ||
| 2716 | ||
| 2717 | ||
| 2718 | ||
| 2719 | ||
| 2720 | ||
| 2721 | ||
| 2722 | ||
| 2723 | ||
| 2724 | ||
| 2725 | ||
| 2726 | ||
| 2727 | ||
| 2728 | ||
| 2729 | ||
| 2730 | ||
| 2731 | ||
| 2732 | ||
| 2733 | ||
| 2734 | ||
| 2735 | ||
| 2736 | ||
| 2737 | ||
| 2738 | ||
| 2739 | ||
| 2740 | ||
| 2741 | ||
| 2742 | ||
| 2743 | Burdis & Naffah Expires November 28, 2003 [Page 49] | |
| 2744 | ||
| 2745 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2746 | ||
| 2747 | ||
| 2748 | Intellectual Property Statement | |
| 2749 | ||
| 2750 | The IETF takes no position regarding the validity or scope of any | |
| 2751 | intellectual property or other rights that might be claimed to | |
| 2752 | pertain to the implementation or use of the technology described in | |
| 2753 | this document or the extent to which any license under such rights | |
| 2754 | might or might not be available; neither does it represent that it | |
| 2755 | has made any effort to identify any such rights. Information on the | |
| 2756 | IETF's procedures with respect to rights in standards-track and | |
| 2757 | standards-related documentation can be found in BCP-11. Copies of | |
| 2758 | claims of rights made available for publication and any assurances of | |
| 2759 | licenses to be made available, or the result of an attempt made to | |
| 2760 | obtain a general license or permission for the use of such | |
| 2761 | proprietary rights by implementors or users of this specification can | |
| 2762 | be obtained from the IETF Secretariat. | |
| 2763 | ||
| 2764 | The IETF invites any interested party to bring to its attention any | |
| 2765 | copyrights, patents or patent applications, or other proprietary | |
| 2766 | rights which may cover technology that may be required to practice | |
| 2767 | this standard. Please address the information to the IETF Executive | |
| 2768 | Director. | |
| 2769 | ||
| 2770 | ||
| 2771 | Full Copyright Statement | |
| 2772 | ||
| 2773 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 2774 | ||
| 2775 | This document and translations of it may be copied and furnished to | |
| 2776 | others, and derivative works that comment on or otherwise explain it | |
| 2777 | or assist in its implementation may be prepared, copied, published | |
| 2778 | and distributed, in whole or in part, without restriction of any | |
| 2779 | kind, provided that the above copyright notice and this paragraph are | |
| 2780 | included on all such copies and derivative works. However, this | |
| 2781 | document itself may not be modified in any way, such as by removing | |
| 2782 | the copyright notice or references to the Internet Society or other | |
| 2783 | Internet organizations, except as needed for the purpose of | |
| 2784 | developing Internet standards in which case the procedures for | |
| 2785 | copyrights defined in the Internet Standards process must be | |
| 2786 | followed, or as required to translate it into languages other than | |
| 2787 | English. | |
| 2788 | ||
| 2789 | The limited permissions granted above are perpetual and will not be | |
| 2790 | revoked by the Internet Society or its successors or assignees. | |
| 2791 | ||
| 2792 | This document and the information contained herein is provided on an | |
| 2793 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 2794 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 2795 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 2796 | ||
| 2797 | ||
| 2798 | ||
| 2799 | Burdis & Naffah Expires November 28, 2003 [Page 50] | |
| 2800 | ||
| 2801 | Internet-Draft SRP Authentication Mechanism May 2003 | |
| 2802 | ||
| 2803 | ||
| 2804 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 2805 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 2806 | ||
| 2807 | ||
| 2808 | Acknowledgement | |
| 2809 | ||
| 2810 | Funding for the RFC Editor function is currently provided by the | |
| 2811 | Internet Society. | |
| 2812 | ||
| 2813 | ||
| 2814 | ||
| 2815 | ||
| 2816 | ||
| 2817 | ||
| 2818 | ||
| 2819 | ||
| 2820 | ||
| 2821 | ||
| 2822 | ||
| 2823 | ||
| 2824 | ||
| 2825 | ||
| 2826 | ||
| 2827 | ||
| 2828 | ||
| 2829 | ||
| 2830 | ||
| 2831 | ||
| 2832 | ||
| 2833 | ||
| 2834 | ||
| 2835 | ||
| 2836 | ||
| 2837 | ||
| 2838 | ||
| 2839 | ||
| 2840 | ||
| 2841 | ||
| 2842 | ||
| 2843 | ||
| 2844 | ||
| 2845 | ||
| 2846 | ||
| 2847 | ||
| 2848 | ||
| 2849 | ||
| 2850 | ||
| 2851 | ||
| 2852 | ||
| 2853 | ||
| 2854 | ||
| 2855 | Burdis & Naffah Expires November 28, 2003 [Page 51] | |
| 2856 | ||
| 2857 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | INTERNET-DRAFT Editor: Kurt D. Zeilenga | |
| 7 | Intended Category: Standards Track OpenLDAP Foundation | |
| 8 | Expires in six months 30 June 2003 | |
| 9 | Obsoletes: RFC 2245 | |
| 10 | ||
| 11 | ||
| 12 | The Anonymous SASL Mechanism | |
| 13 | <draft-ietf-sasl-anon-02.txt> | |
| 14 | ||
| 15 | ||
| 16 | Status of Memo | |
| 17 | ||
| 18 | This document is an Internet-Draft and is in full conformance with all | |
| 19 | provisions of Section 10 of RFC2026. | |
| 20 | ||
| 21 | This document is intended to be, after appropriate review and | |
| 22 | revision, submitted to the RFC Editor as a Standards Track document. | |
| 23 | Distribution of this memo is unlimited. Technical discussion of this | |
| 24 | document will take place on the IETF SASL mailing list | |
| 25 | <ietf-sasl@imc.org>. Please send editorial comments directly to the | |
| 26 | document editor <Kurt@OpenLDAP.org>. | |
| 27 | ||
| 28 | Internet-Drafts are working documents of the Internet Engineering Task | |
| 29 | Force (IETF), its areas, and its working groups. Note that other | |
| 30 | groups may also distribute working documents as Internet-Drafts. | |
| 31 | Internet-Drafts are draft documents valid for a maximum of six months | |
| 32 | and may be updated, replaced, or obsoleted by other documents at any | |
| 33 | time. It is inappropriate to use Internet-Drafts as reference | |
| 34 | material or to cite them other than as ``work in progress.'' | |
| 35 | ||
| 36 | The list of current Internet-Drafts can be accessed at | |
| 37 | <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of | |
| 38 | Internet-Draft Shadow Directories can be accessed at | |
| 39 | <http://www.ietf.org/shadow.html>. | |
| 40 | ||
| 41 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 42 | ||
| 43 | Please see the Full Copyright section near the end of this document | |
| 44 | for more information. | |
| 45 | ||
| 46 | ||
| 47 | Abstract | |
| 48 | ||
| 49 | It is common practice on the Internet to permit anonymous access to | |
| 50 | various services. Traditionally, this has been done with a plain text | |
| 51 | password mechanism using "anonymous" as the user name and optional | |
| 52 | trace information, such as an email address, as the password. As | |
| 53 | plain text login commands are not permitted in new IETF protocols, a | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Zeilenga Anonymous SASL Mechanism [Page 1] | |
| 58 | ||
| 59 | INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 | |
| 60 | ||
| 61 | ||
| 62 | new way to provide anonymous login is needed within the context of the | |
| 63 | Simple Authentication and Security Layer (SASL) framework. | |
| 64 | ||
| 65 | ||
| 66 | Conventions | |
| 67 | ||
| 68 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
| 69 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
| 70 | document are to be interpreted as described in [Keywords]. | |
| 71 | ||
| 72 | ||
| 73 | 1. Anonymous SASL mechanism | |
| 74 | ||
| 75 | This document defines an anonymous mechanism for the Simple | |
| 76 | Authentication and Security Layer ([SASL]) framework. The name | |
| 77 | associated with this mechanism is "ANONYMOUS". | |
| 78 | ||
| 79 | This document replaces RFC 2245. Changes since RFC 2245 are detailed | |
| 80 | in Appendix A. | |
| 81 | ||
| 82 | The mechanism consists of a single message from the client to the | |
| 83 | server. The client sends optional trace information in the form of a | |
| 84 | string of [UTF-8] encoded [Unicode] characters prepared in accordance | |
| 85 | with [StringPrep] and the "trace" stringprep profile defined in | |
| 86 | Section 2 of this document. The trace information, which has no | |
| 87 | semantical value, should take one of three forms: an Internet email | |
| 88 | address, an opaque string which does not contain the '@' (U+0040) | |
| 89 | character and can be interpreted by the system administrator of the | |
| 90 | client's domain, or nothing. For privacy reasons, an Internet email | |
| 91 | address or other information identifying the user should only be used | |
| 92 | with permission from the user. | |
| 93 | ||
| 94 | A server which permits anonymous access will announce support for the | |
| 95 | ANONYMOUS mechanism, and allow anyone to log in using that mechanism, | |
| 96 | usually with restricted access. | |
| 97 | ||
| 98 | This mechanism does not provide a security layer. | |
| 99 | ||
| 100 | A formal grammar for the client message using Augmented BNF [ABNF] is | |
| 101 | provide below as a tool for understanding this technical | |
| 102 | specification. | |
| 103 | ||
| 104 | message = [ email / token ] | |
| 105 | ;; MUST be prepared in accordance with Section 2 | |
| 106 | ||
| 107 | UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) | |
| 108 | UTF2 = %xC2-DF UTF0 | |
| 109 | UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / | |
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Zeilenga Anonymous SASL Mechanism [Page 2] | |
| 114 | ||
| 115 | INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 | |
| 116 | ||
| 117 | ||
| 118 | %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) | |
| 119 | UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / | |
| 120 | %xF4 %x80-8F 2(UTF0) | |
| 121 | UTF0 = %x80-BF | |
| 122 | ||
| 123 | TCHAR = UTF1 / UTF2 / UTF3 / UTF4 | |
| 124 | ;; any UTF-8 encoded Unicode character | |
| 125 | ;; except '@' (U+0040) | |
| 126 | ||
| 127 | email = addr-spec | |
| 128 | ;; as defined in [IMAIL], except with no free | |
| 129 | ;; insertion of linear-white-space, and the | |
| 130 | ;; local-part MUST either be entirely enclosed in | |
| 131 | ;; quotes or entirely unquoted | |
| 132 | ||
| 133 | token = 1*255TCHAR | |
| 134 | ||
| 135 | Note to implementors: | |
| 136 | The <token> production is restricted to 255 UTF-8 encoded Unicode | |
| 137 | characters. As the encoding of a characters uses a sequence of 1 | |
| 138 | to 4 octets, a token may be long as 1020 octets. | |
| 139 | ||
| 140 | ||
| 141 | 2. The "trace" profile of "Stringprep" | |
| 142 | ||
| 143 | This section defines the "trace" profile of [StringPrep]. This | |
| 144 | profile is designed for use with the SASL ANONYMOUS Mechanism. | |
| 145 | Specifically, the client MUST prepare the <message> production in | |
| 146 | accordance with this profile. | |
| 147 | ||
| 148 | The character repertoire of this profile is Unicode 3.2 [Unicode]. | |
| 149 | ||
| 150 | No mapping is required by this profile. | |
| 151 | ||
| 152 | No Unicode normalization is required by this profile. | |
| 153 | ||
| 154 | The list of unassigned code points for this profile is that provided | |
| 155 | in appendix A of [RFC 3454]. Unassigned code points are not | |
| 156 | prohibited. | |
| 157 | ||
| 158 | Characters from the following tables of [StringPrep] are prohibited: | |
| 159 | - C.2.1 (ASCII control characters) | |
| 160 | - C.2.2 (Non-ASCII control characters) | |
| 161 | - C.3 (Private use characters) | |
| 162 | - C.4 (Non-character code points) | |
| 163 | - C.5 (Surrogate codes) | |
| 164 | - C.6 (Inappropriate for plain text) | |
| 165 | - C.8 (Change display properties are deprecated) | |
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Zeilenga Anonymous SASL Mechanism [Page 3] | |
| 170 | ||
| 171 | INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 | |
| 172 | ||
| 173 | ||
| 174 | - C.9 (Tagging characters) | |
| 175 | ||
| 176 | No additional characters are prohibited. | |
| 177 | ||
| 178 | This profile requires bidirectional character checking per Section 6 | |
| 179 | of [StringPrep]. | |
| 180 | ||
| 181 | ||
| 182 | 3. Example | |
| 183 | ||
| 184 | Here is a sample ANONYMOUS login between an IMAP client and server. | |
| 185 | In this example, "C:" and "S:" indicate lines sent by the client and | |
| 186 | server respectively. If such lines are wrapped without a new "C:" or | |
| 187 | "S:" label, then the wrapping is for editorial clarity and is not part | |
| 188 | of the command. | |
| 189 | ||
| 190 | Note that this example uses the IMAP profile [IMAP4] of SASL. The | |
| 191 | base64 encoding of challenges and responses, as well as the "+ " | |
| 192 | preceding the responses are part of the IMAP4 profile, not part of | |
| 193 | SASL itself. Newer profiles of SASL will include the client message | |
| 194 | with the AUTHENTICATE command itself so the extra round trip below | |
| 195 | (the server response with an empty "+ ") can be eliminated. | |
| 196 | ||
| 197 | In this example, the user's opaque identification token is "sirhc". | |
| 198 | ||
| 199 | S: * OK IMAP4 server ready | |
| 200 | C: A001 CAPABILITY | |
| 201 | S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS | |
| 202 | S: A001 OK done | |
| 203 | C: A002 AUTHENTICATE ANONYMOUS | |
| 204 | S: + | |
| 205 | C: c2lyaGM= | |
| 206 | S: A003 OK Welcome, trace information has been logged. | |
| 207 | ||
| 208 | ||
| 209 | 4. Security Considerations | |
| 210 | ||
| 211 | The ANONYMOUS mechanism grants access to information by anyone. For | |
| 212 | this reason it should be disabled by default so the administrator can | |
| 213 | make an explicit decision to enable it. | |
| 214 | ||
| 215 | If the anonymous user has any write privileges, a denial of service | |
| 216 | attack is possible by filling up all available space. This can be | |
| 217 | prevented by disabling all write access by anonymous users. | |
| 218 | ||
| 219 | If anonymous users have read and write access to the same area, the | |
| 220 | server can be used as a communication mechanism to anonymously | |
| 221 | exchange information. Servers which accept anonymous submissions | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Zeilenga Anonymous SASL Mechanism [Page 4] | |
| 226 | ||
| 227 | INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 | |
| 228 | ||
| 229 | ||
| 230 | should implement the common "drop box" model which forbids anonymous | |
| 231 | read access to the area where anonymous submissions are accepted. | |
| 232 | ||
| 233 | If the anonymous user can run many expensive operations (e.g., an IMAP | |
| 234 | SEARCH BODY command), this could enable a denial of service attack. | |
| 235 | Servers are encouraged to reduce the priority of anonymous users or | |
| 236 | limit their resource usage. | |
| 237 | ||
| 238 | While servers may impose a limit on the number of anonymous users, it | |
| 239 | is noted that such limits enable denial of service attacks and should | |
| 240 | be used with caution. | |
| 241 | ||
| 242 | The trace information is not authenticated so it can be falsified. | |
| 243 | This can be used as an attempt to get someone else in trouble for | |
| 244 | access to questionable information. Administrators trying to trace | |
| 245 | abuse need to realize this information may be falsified. | |
| 246 | ||
| 247 | A client which uses the user's correct email address as trace | |
| 248 | information without explicit permission may violate that user's | |
| 249 | privacy. Information about who accesses an anonymous archive on a | |
| 250 | sensitive subject (e.g., sexual abuse) has strong privacy needs. | |
| 251 | Clients should not send the email address without explicit permission | |
| 252 | of the user and should offer the option of supplying no trace token -- | |
| 253 | thus only exposing the source IP address and time. Anonymous proxy | |
| 254 | servers could enhance this privacy, but would have to consider the | |
| 255 | resulting potential denial of service attacks. | |
| 256 | ||
| 257 | Anonymous connections are susceptible to man in the middle attacks | |
| 258 | which view or alter the data transferred. Clients and servers are | |
| 259 | encouraged to support external integrity and encryption mechanisms. | |
| 260 | ||
| 261 | Protocols which fail to require an explicit anonymous login are more | |
| 262 | susceptible to break-ins given certain common implementation | |
| 263 | techniques. Specifically, Unix servers which offer user login may | |
| 264 | initially start up as root and switch to the appropriate user id after | |
| 265 | an explicit login command. Normally such servers refuse all data | |
| 266 | access commands prior to explicit login and may enter a restricted | |
| 267 | security environment (e.g., the Unix chroot(2) function) for anonymous | |
| 268 | users. If anonymous access is not explicitly requested, the entire | |
| 269 | data access machinery is exposed to external security attacks without | |
| 270 | the chance for explicit protective measures. Protocols which offer | |
| 271 | restricted data access should not allow anonymous data access without | |
| 272 | an explicit login step. | |
| 273 | ||
| 274 | General [SASL] security considerations apply to this mechanism. | |
| 275 | ||
| 276 | [StringPrep] security considerations as well as [Unicode] security | |
| 277 | considerations discussed in [StringPrep] apply to this mechanism. | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Zeilenga Anonymous SASL Mechanism [Page 5] | |
| 282 | ||
| 283 | INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 | |
| 284 | ||
| 285 | ||
| 286 | [UTF-8] security considerations also apply. | |
| 287 | ||
| 288 | ||
| 289 | 5. IANA Considerations | |
| 290 | ||
| 291 | It is requested that the SASL Mechanism registry [IANA-SASL] entry for | |
| 292 | the ANONYMOUS mechanism be updated to reflect that this document now | |
| 293 | provides its technical specification. | |
| 294 | ||
| 295 | To: iana@iana.org | |
| 296 | Subject: Updated Registration of SASL mechanism ANONYMOUS | |
| 297 | ||
| 298 | SASL mechanism name: ANONYMOUS | |
| 299 | Security considerations: See RFC XXXX. | |
| 300 | Published specification (optional, recommended): RFC XXXX | |
| 301 | Person & email address to contact for further information: | |
| 302 | Kurt Zeilenga <kurt@openldap.org> | |
| 303 | Chris Neuman <chris.newman@innosoft.com> | |
| 304 | Intended usage: COMMON | |
| 305 | Author/Change controller: IESG <iesg@ietf.org> | |
| 306 | Note: Updates existing entry for ANONYMOUS | |
| 307 | ||
| 308 | ||
| 309 | It is requested that the [Stringprep] profile "trace", first defined | |
| 310 | in this RFC, be registered: | |
| 311 | ||
| 312 | To: iana@iana.org | |
| 313 | Subject: Initial Registration of Stringprep "trace" profile | |
| 314 | ||
| 315 | Stringprep profile: trace | |
| 316 | Published specification: RFC XXXX | |
| 317 | Person & email address to contact for further information: | |
| 318 | Kurt Zeilenga <kurt@openldap.org> | |
| 319 | ||
| 320 | ||
| 321 | 6. Acknowledgment | |
| 322 | ||
| 323 | This document is a revision of RFC 2245 by Chris Newman. Portions of | |
| 324 | the grammar defined in Section 1 were borrowed from [UTF-8] by | |
| 325 | Francois Yergeau. | |
| 326 | ||
| 327 | This document is a product of the IETF SASL WG. | |
| 328 | ||
| 329 | ||
| 330 | 7. Normative References | |
| 331 | ||
| 332 | [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
| 333 | Specifications: ABNF", RFC 2234, November 1997. | |
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Zeilenga Anonymous SASL Mechanism [Page 6] | |
| 338 | ||
| 339 | INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 | |
| 340 | ||
| 341 | ||
| 342 | [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet | |
| 343 | Text Messages", STD 11, RFC 822, August 1982. | |
| 344 | ||
| 345 | [Keywords] Bradner, S., "Key words for use in RFCs to Indicate | |
| 346 | Requirement Levels", BCP 14, RFC 2119, March 1997 | |
| 347 | ||
| 348 | [SASL] Myers, J., "Simple Authentication and Security Layer | |
| 349 | (SASL)", draft-myers-saslrev-xx.txt, a work in progress. | |
| 350 | ||
| 351 | [StringPrep] Hoffman P. and M. Blanchet, "Preparation of | |
| 352 | Internationalized Strings ('stringprep')", RFC 3454, | |
| 353 | December 2002. | |
| 354 | ||
| 355 | [Unicode] The Unicode Consortium, "The Unicode Standard, Version | |
| 356 | 3.2.0" is defined by "The Unicode Standard, Version 3.0" | |
| 357 | (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), | |
| 358 | as amended by the "Unicode Standard Annex #27: Unicode | |
| 359 | 3.1" (http://www.unicode.org/reports/tr27/) and by the | |
| 360 | "Unicode Standard Annex #28: Unicode 3.2" | |
| 361 | (http://www.unicode.org/reports/tr28/). | |
| 362 | ||
| 363 | [UTF-8] Yergeau, F., "UTF-8, a transformation | |
| 364 | format of ISO 10646", draft-yergeau-rfc2279bis, a work | |
| 365 | in progress. | |
| 366 | ||
| 367 | ||
| 368 | 8. Informative References | |
| 369 | ||
| 370 | [IMAP4] Crispin, M., "Internet Message Access Protocol - Version | |
| 371 | 4rev1", RFC 2060, December 1996. | |
| 372 | ||
| 373 | [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) | |
| 374 | MECHANISMS", http://www.iana.org/assignments/sasl- | |
| 375 | mechanisms. | |
| 376 | ||
| 377 | ||
| 378 | 9. Editor's Address | |
| 379 | ||
| 380 | Kurt Zeilenga | |
| 381 | OpenLDAP Foundation | |
| 382 | ||
| 383 | Email: kurt@OpenLDAP.org | |
| 384 | ||
| 385 | ||
| 386 | Appendix A. Changes since RFC 2245 | |
| 387 | ||
| 388 | This appendix is non-normative. | |
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Zeilenga Anonymous SASL Mechanism [Page 7] | |
| 394 | ||
| 395 | INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 | |
| 396 | ||
| 397 | ||
| 398 | RFC 2245 allows the client to send optional trace information in the | |
| 399 | form of a human readable string. RFC 2245 restricted this string to | |
| 400 | US-ASCII. As the Internet is international, this document uses a | |
| 401 | string restricted to UTF-8 encoded Unicode characters. A "stringprep" | |
| 402 | profile is defined to precisely define which Unicode characters are | |
| 403 | allowed in this string. While the string remains restricted to 255 | |
| 404 | characters, the encoded length of each character may now range from 1 | |
| 405 | to 4 octets. | |
| 406 | ||
| 407 | Additionally, a number of editorial changes were made. | |
| 408 | ||
| 409 | ||
| 410 | ||
| 411 | Intellectual Property Rights | |
| 412 | ||
| 413 | The IETF takes no position regarding the validity or scope of any | |
| 414 | intellectual property or other rights that might be claimed to pertain | |
| 415 | to the implementation or use of the technology described in this | |
| 416 | document or the extent to which any license under such rights might or | |
| 417 | might not be available; neither does it represent that it has made any | |
| 418 | effort to identify any such rights. Information on the IETF's | |
| 419 | procedures with respect to rights in standards-track and | |
| 420 | standards-related documentation can be found in BCP-11. Copies of | |
| 421 | claims of rights made available for publication and any assurances of | |
| 422 | licenses to be made available, or the result of an attempt made to | |
| 423 | obtain a general license or permission for the use of such proprietary | |
| 424 | rights by implementors or users of this specification can be obtained | |
| 425 | from the IETF Secretariat. | |
| 426 | ||
| 427 | The IETF invites any interested party to bring to its attention any | |
| 428 | copyrights, patents or patent applications, or other proprietary | |
| 429 | rights which may cover technology that may be required to practice | |
| 430 | this standard. Please address the information to the IETF Executive | |
| 431 | Director. | |
| 432 | ||
| 433 | ||
| 434 | ||
| 435 | Full Copyright | |
| 436 | ||
| 437 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 438 | ||
| 439 | This document and translations of it may be copied and furnished to | |
| 440 | others, and derivative works that comment on or otherwise explain it | |
| 441 | or assist in its implmentation may be prepared, copied, published and | |
| 442 | distributed, in whole or in part, without restriction of any kind, | |
| 443 | provided that the above copyright notice and this paragraph are | |
| 444 | included on all such copies and derivative works. However, this | |
| 445 | document itself may not be modified in any way, such as by removing | |
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Zeilenga Anonymous SASL Mechanism [Page 8] | |
| 450 | ||
| 451 | INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 | |
| 452 | ||
| 453 | ||
| 454 | the copyright notice or references to the Internet Society or other | |
| 455 | Internet organizations, except as needed for the purpose of | |
| 456 | developing Internet standards in which case the procedures for | |
| 457 | copyrights defined in the Internet Standards process must be followed, | |
| 458 | or as required to translate it into languages other than English. | |
| 459 | ||
| 460 | ||
| 461 | ||
| 462 | ||
| 463 | ||
| 464 | ||
| 465 | ||
| 466 | ||
| 467 | ||
| 468 | ||
| 469 | ||
| 470 | ||
| 471 | ||
| 472 | ||
| 473 | ||
| 474 | ||
| 475 | ||
| 476 | ||
| 477 | ||
| 478 | ||
| 479 | ||
| 480 | ||
| 481 | ||
| 482 | ||
| 483 | ||
| 484 | ||
| 485 | ||
| 486 | ||
| 487 | ||
| 488 | ||
| 489 | ||
| 490 | ||
| 491 | ||
| 492 | ||
| 493 | ||
| 494 | ||
| 495 | ||
| 496 | ||
| 497 | ||
| 498 | ||
| 499 | ||
| 500 | ||
| 501 | ||
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Zeilenga Anonymous SASL Mechanism [Page 9] | |
| 506 |
| 0 | ||
| 1 | ||
| 2 | Network Working Group L. Nerenberg, Editor | |
| 3 | Internet Draft: The CRAM-MD5 SASL Mechanism Orthanc Systems | |
| 4 | Document: draft-ietf-sasl-crammd5-01.txt November 2003 | |
| 5 | ||
| 6 | ||
| 7 | ||
| 8 | The CRAM-MD5 SASL Mechanism | |
| 9 | ||
| 10 | ||
| 11 | Status of this Memo | |
| 12 | ||
| 13 | This document is an Internet Draft and is in full conformance with | |
| 14 | all provisions of Section 10 of RFC 2026. | |
| 15 | ||
| 16 | Internet Drafts are working documents of the Internet Engineering | |
| 17 | Task Force (IETF), its areas, and its working groups. Note that | |
| 18 | other groups may also distribute working documents as Internet | |
| 19 | Drafts. | |
| 20 | ||
| 21 | Internet Drafts are draft documents valid for a maximum of six | |
| 22 | months and may be updated, replaced, or obsoleted by other docu- | |
| 23 | ments at any time. It is inappropriate to use Internet Drafts as | |
| 24 | reference material or to cite them other than as "work in | |
| 25 | progress." | |
| 26 | ||
| 27 | The list of current Internet Drafts can be accessed at | |
| 28 | http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet | |
| 29 | Draft Shadow Directories can be accessed at | |
| 30 | http://www.ietf.org/shadow.html. | |
| 31 | ||
| 32 | Copyright 2003, The Internet Society. All Rights Reserved. | |
| 33 | ||
| 34 | Please see the Copyright section near the end of this document for | |
| 35 | more information. | |
| 36 | ||
| 37 | Abstract | |
| 38 | ||
| 39 | This document defines a simple challenge-response authentication | |
| 40 | mechanism, using a keyed-hash digest, for use with the Simple | |
| 41 | Authentication and Security Layer (SASL). | |
| 42 | ||
| 43 | 1. Conventions Used in this Document | |
| 44 | ||
| 45 | The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" | |
| 46 | in this document are to be interpreted as defined in [KEYWORD]. | |
| 47 | ||
| 48 | ||
| 49 | 2. CRAM-MD5 Authentication Mechanism | |
| 50 | ||
| 51 | This document defines a simple challenge-response [SASL] authenti- | |
| 52 | cation mechanism, using a [KEYED-MD5] digest, for use with [SASL]. | |
| 53 | The mechanism name associated with CRAM-MD5 is 'CRAM-MD5'. | |
| 54 | ||
| 55 | This mechanism does not provide a security layer. | |
| 56 | ||
| 57 | ||
| 58 | ||
| 59 | Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 1] | |
| 60 | ||
| 61 | Internet Draft CRAM-MD5 SASL Mechanism November 2003 | |
| 62 | ||
| 63 | ||
| 64 | The data encoded in the challenge contains a presumptively arbi- | |
| 65 | trary string of random digits, a time-stamp, and the fully-quali- | |
| 66 | fied primary host name of the server. | |
| 67 | ||
| 68 | The client makes note of the data and then responds with a string | |
| 69 | consisting of the user name, a space, and a "digest." The latter | |
| 70 | is computed by applying the keyed MD5 algorithm from [KEYED-MD5] | |
| 71 | where the key is a shared secret and the digested text is the chal- | |
| 72 | lenge (including angle-brackets). The client MUST NOT interpret or | |
| 73 | attempt to validate the contents of the challenge in any way. | |
| 74 | ||
| 75 | This shared secret is a string known only to the client and server. | |
| 76 | The "digest" parameter itself is a 16-octet value which is sent in | |
| 77 | hexadecimal format, using lower-case US-ASCII characters. | |
| 78 | ||
| 79 | When the server receives this client response, it verifies the | |
| 80 | digest provided. Since the user name may contain the space charac- | |
| 81 | ter, the server MUST scan the client response from right to left; | |
| 82 | the first space character encountered separates the digest from the | |
| 83 | user name. If the digest is correct, the server should consider | |
| 84 | the client authenticated and respond appropriately. | |
| 85 | ||
| 86 | The client MUST prepare the user name and shared secret strings | |
| 87 | using the [SASLPrep] profile of the [StringPrep] algorithm. The | |
| 88 | resulting values MUST be encoded as UTF-8 [UTF8]. | |
| 89 | ||
| 90 | ||
| 91 | 2.1. Formal Syntax | |
| 92 | ||
| 93 | The following syntax specification uses the augmented Backus-Naur | |
| 94 | Form (ABNF) as specified in [ABNF], and incorporates by reference | |
| 95 | the Core Rules defined in that document. | |
| 96 | ||
| 97 | challenge = "<" 1*DIGIT "." 1*DIGIT "@" hostname ">" | |
| 98 | ||
| 99 | digest = 32(DIGIT / %x61-66) | |
| 100 | ; A hexadecimal string using only lower-case | |
| 101 | ; letters | |
| 102 | ||
| 103 | hostname = 1*(ALPHA / DIGIT) *("." / "-" / ALPHA / DIGIT) | |
| 104 | ||
| 105 | response = user SP digest | |
| 106 | ||
| 107 | user = 1*OCTET | |
| 108 | ||
| 109 | ||
| 110 | 2.2. Examples | |
| 111 | ||
| 112 | The examples in this section do NOT form part of the specification. | |
| 113 | Where conflicts exist between the examples and the formal grammar | |
| 114 | or specification text, the latter are authoritative. | |
| 115 | ||
| 116 | These examples show the use of the CRAM-MD5 mechanism with the | |
| 117 | IMAP4 AUTHENTICATE command [IMAP4]. The base64 encoding of the | |
| 118 | ||
| 119 | ||
| 120 | ||
| 121 | Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 2] | |
| 122 | ||
| 123 | Internet Draft CRAM-MD5 SASL Mechanism November 2003 | |
| 124 | ||
| 125 | ||
| 126 | challenges and responses is part of the IMAP4 AUTHENTICATE command, | |
| 127 | not part of the CRAM-MD5 specification itself. | |
| 128 | ||
| 129 | S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] | |
| 130 | C: A0001 AUTHENTICATE CRAM-MD5 | |
| 131 | S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ | |
| 132 | C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw | |
| 133 | S: A0001 OK CRAM-MD5 authentication successful | |
| 134 | ||
| 135 | In this example, the shared secret is the string | |
| 136 | ||
| 137 | tanstaaftanstaaf | |
| 138 | ||
| 139 | Hence, the Keyed MD5 digest is produced by calculating | |
| 140 | ||
| 141 | MD5((tanstaaftanstaaf XOR opad), | |
| 142 | MD5((tanstaaftanstaaf XOR ipad), | |
| 143 | <1896.697170952@postoffice.example.net>)) | |
| 144 | ||
| 145 | where ipad and opad are as defined in [KEYED-MD5] and the string | |
| 146 | shown in the challenge is the base64 encoding of | |
| 147 | <1896.697170952@postoffice.reston.mci.net>. The shared secret is | |
| 148 | null-padded to a length of 64 bytes. If the shared secret is longer | |
| 149 | than 64 bytes, the MD5 digest of the shared secret is used as a 16 | |
| 150 | byte input to the keyed MD5 calculation. | |
| 151 | ||
| 152 | This produces a digest value (in hexadecimal) of | |
| 153 | ||
| 154 | b913a602c7eda7a495b4e6e7334d3890 | |
| 155 | ||
| 156 | The user name is then prepended to it, forming | |
| 157 | ||
| 158 | tim b913a602c7eda7a495b4e6e7334d3890 | |
| 159 | ||
| 160 | Which is then base64 encoded to meet the requirements of the IMAP4 | |
| 161 | AUTHENTICATE command (or the similar POP3 AUTH command), yielding | |
| 162 | ||
| 163 | dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw | |
| 164 | ||
| 165 | ||
| 166 | ||
| 167 | 3. References | |
| 168 | ||
| 169 | 3.1. Normative References | |
| 170 | ||
| 171 | [ABNF] | |
| 172 | Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications: | |
| 173 | ABNF", RFC2234, Internet Mail Consortium and Demon Internet Ltd., | |
| 174 | November 1997. | |
| 175 | ||
| 176 | [KEYED-MD5] | |
| 177 | Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message | |
| 178 | Authentication", RFC 2104, IBM and UCSD, February 1997. | |
| 179 | ||
| 180 | ||
| 181 | ||
| 182 | ||
| 183 | Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 3] | |
| 184 | ||
| 185 | Internet Draft CRAM-MD5 SASL Mechanism November 2003 | |
| 186 | ||
| 187 | ||
| 188 | [KEYWORD] | |
| 189 | Bradner, S., "Key words for use in RFCs to Indicate Requirement | |
| 190 | Levels", BCP 14, RFC2119, Harvard University, March 1997. | |
| 191 | ||
| 192 | [MD5] | |
| 193 | Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT Labo- | |
| 194 | ratory for Computer Science and RSA Data Security, Inc., April | |
| 195 | 1992. | |
| 196 | ||
| 197 | [SASL] | |
| 198 | Myers, J., "Simple Authentication and Security Layer (SASL)," RFC | |
| 199 | 2222, Netscape Communications, October 1997. | |
| 200 | ||
| 201 | [SASLPrep] | |
| 202 | Zeilenga, K., "SASL String Preparation Profiles", draft-ietf-sasl- | |
| 203 | saslprep (work in progress) | |
| 204 | ||
| 205 | [StringPrep] | |
| 206 | Hoffman, P., M. Blanchet, "Preparation of Internationalized Strings | |
| 207 | (stringprep)", RFC 3454, IMC and Viagenie, December 2002. | |
| 208 | ||
| 209 | [UTF8] | |
| 210 | Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC | |
| 211 | 2279, Alis Technologies, January 1998. | |
| 212 | ||
| 213 | 3.2. Informative References | |
| 214 | ||
| 215 | [IMAP4] | |
| 216 | Crispin, M., "Internet Message Access Protocol - Version 4rev1," | |
| 217 | RFC 3501, University of Washington, March 2003. | |
| 218 | ||
| 219 | ||
| 220 | 4. Security Considerations | |
| 221 | ||
| 222 | It is conjectured that use of the CRAM-MD5 authentication mechanism | |
| 223 | provides replay protection for a session. | |
| 224 | ||
| 225 | This mechanism does not obscure the user name in any way. Accord- | |
| 226 | ingly, a server that implements both a clear-text password command | |
| 227 | and this authentication type should not allow both methods of | |
| 228 | access for a given user name. | |
| 229 | ||
| 230 | Keyed MD5 is chosen for this application because of the greater | |
| 231 | security imparted to authentication of short messages. In addition, | |
| 232 | the use of the techniques described in [KEYED-MD5] for pre-computa- | |
| 233 | tion of intermediate results make it possible to avoid explicit | |
| 234 | clear-text storage of the shared secret on the server system by | |
| 235 | instead storing the intermediate results which are known as "con- | |
| 236 | texts." While the saving, on the server, of the MD5 "context" is | |
| 237 | marginally better than saving the shared secrets in clear-text, it | |
| 238 | is not sufficient to protect the secrets if the server itself is | |
| 239 | compromised. Consequently, servers that store the secrets or con- | |
| 240 | texts must both be protected to a level appropriate to the poten- | |
| 241 | tial information value in the data and services protected by this | |
| 242 | ||
| 243 | ||
| 244 | ||
| 245 | Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 4] | |
| 246 | ||
| 247 | Internet Draft CRAM-MD5 SASL Mechanism November 2003 | |
| 248 | ||
| 249 | ||
| 250 | mechanism. In other words, techniques like this one involve a | |
| 251 | trade-off between vulnerability to network sniffing and I/O buffer | |
| 252 | snooping and vulnerability of the server host's databases. If one | |
| 253 | believes that the host and its databases are subject to compromise, | |
| 254 | and the network is not, this technique (and all others like it) is | |
| 255 | unattractive. It is perhaps even less attractive than clear-text | |
| 256 | passwords, which are typically stored on hosts in one-way hash | |
| 257 | form. On the other hand, if the server databases are perceived as | |
| 258 | reasonably secure, and one is concerned about client-side or net- | |
| 259 | work interception of the passwords (secrets), then this (and simi- | |
| 260 | lar) techniques are preferable to clear-text passwords by a wide | |
| 261 | margin. | |
| 262 | ||
| 263 | As the length of the shared secret increases, so does the diffi- | |
| 264 | culty of deriving it. | |
| 265 | ||
| 266 | While there are now suggestions in the literature that the use of | |
| 267 | MD5 and keyed MD5 in authentication procedures probably has a lim- | |
| 268 | ited effective lifetime, the technique is now widely deployed and | |
| 269 | widely understood. It is believed that this general understanding | |
| 270 | may assist with the rapid replacement, by CRAM-MD5, of the current | |
| 271 | uses of permanent clear-text passwords in many protocols. This | |
| 272 | document has been deliberately written to permit easy upgrading to | |
| 273 | use SHA (or whatever alternatives emerge) when they are considered | |
| 274 | to be widely available and adequately safe. | |
| 275 | ||
| 276 | Even with the use of CRAM-MD5, users are still vulnerable to active | |
| 277 | attacks. An example of an increasingly common active attack is | |
| 278 | 'TCP Session Hijacking' as described in CERT Advisory CA-95:01. | |
| 279 | ||
| 280 | CRAM-MD5 does not authenticate the server and does not include a | |
| 281 | client-supplied nonce. As a result, it is possible to construct a | |
| 282 | server with a fixed challenge string that has pre-computed the | |
| 283 | hashes for all possible passwords up to a certain length (or from a | |
| 284 | dictionary). Such a server could then immediately determine the | |
| 285 | user's password if it is sufficiently short. | |
| 286 | ||
| 287 | ||
| 288 | 5. IANA Considerations | |
| 289 | ||
| 290 | The SASL Mechanism Registry entry for CRAM-MD5 must be updated to | |
| 291 | reference this specification. | |
| 292 | ||
| 293 | ||
| 294 | 6. Contributors | |
| 295 | ||
| 296 | The CRAM-MD5 mechanism was originally specified in RFC 2095, | |
| 297 | IMAP/POP AUTHorize Extension for Simple Challenge/Response. The | |
| 298 | authors of that document -- John C. Klensin, Paul Krumviede, and | |
| 299 | Randy Catoe -- are to be credited with the design and specification | |
| 300 | of CRAM-MD5. This memo serves only to re-state CRAM-MD5 within the | |
| 301 | formal context of SASL, which specification it preceded by several | |
| 302 | months. | |
| 303 | ||
| 304 | ||
| 305 | ||
| 306 | ||
| 307 | Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 5] | |
| 308 | ||
| 309 | Internet Draft CRAM-MD5 SASL Mechanism November 2003 | |
| 310 | ||
| 311 | ||
| 312 | 7. Intellectual Property | |
| 313 | ||
| 314 | The IETF takes no position regarding the validity or scope of any | |
| 315 | intellectual property or other rights that might be claimed to per- | |
| 316 | tain to the implementation or use of the technology described in | |
| 317 | this document or the extent to which any license under such rights | |
| 318 | might or might not be available; neither does it represent that it | |
| 319 | has made any effort to identify any such rights. Information on | |
| 320 | the IETF's procedures with respect to rights in standards-track and | |
| 321 | standards-related documentation can be found in BCP-11. Copies of | |
| 322 | claims of rights made available for publication and any assurances | |
| 323 | of licenses to be made available, or the result of an attempt made | |
| 324 | to obtain a general license or permission for the use of such pro- | |
| 325 | prietary rights by implementers or users of this specification can | |
| 326 | be obtained from the IETF Secretariat. | |
| 327 | ||
| 328 | The IETF invites any interested party to bring to its attention any | |
| 329 | copyrights, patents or patent applications, or other proprietary | |
| 330 | rights which may cover technology that may be required to practice | |
| 331 | this standard. Please address the information to the IETF Execu- | |
| 332 | tive Director. | |
| 333 | ||
| 334 | ||
| 335 | 8. Editors' Address | |
| 336 | ||
| 337 | Lyndon Nerenberg | |
| 338 | Orthanc Systems | |
| 339 | 1606 - 10770 Winterburn Road | |
| 340 | Edmonton, Alberta | |
| 341 | Canada T5S 1T6 | |
| 342 | Email: lyndon+rfc-crammd5@orthanc.ca | |
| 343 | ||
| 344 | ||
| 345 | ||
| 346 | ||
| 347 | ||
| 348 | ||
| 349 | ||
| 350 | ||
| 351 | ||
| 352 | ||
| 353 | ||
| 354 | ||
| 355 | ||
| 356 | ||
| 357 | ||
| 358 | ||
| 359 | ||
| 360 | ||
| 361 | ||
| 362 | ||
| 363 | ||
| 364 | ||
| 365 | ||
| 366 | ||
| 367 | ||
| 368 | ||
| 369 | Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 6] | |
| 370 | ||
| 371 | Internet Draft CRAM-MD5 SASL Mechanism November 2003 | |
| 372 | ||
| 373 | ||
| 374 | 9. Full Copyright Statement | |
| 375 | ||
| 376 | Copyright 2003, The Internet Society. All Rights Reserved. | |
| 377 | ||
| 378 | This document and translations of it may be copied and furnished to | |
| 379 | others, and derivative works that comment on or otherwise explain | |
| 380 | it or assist in its implementation may be prepared, copied, pub- | |
| 381 | lished and distributed, in whole or in part, without restriction of | |
| 382 | any kind, provided that the above copyright notice and this para- | |
| 383 | graph are included on all such copies and derivative works. How- | |
| 384 | ever, this document itself may not be modified in any way, such as | |
| 385 | by removing the copyright notice or references to the Internet | |
| 386 | Society or other Internet organizations, except as needed for the | |
| 387 | purpose of developing Internet standards in which case the proce- | |
| 388 | dures for copyrights defined in the Internet Standards process must | |
| 389 | be followed, or as required to translate it into languages other | |
| 390 | than English. The limited permissions granted above are perpetual | |
| 391 | and will not be revoked by the Internet Society or its successors | |
| 392 | or assigns. | |
| 393 | ||
| 394 | This document and the information contained herein is provided on | |
| 395 | an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI- | |
| 396 | NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, | |
| 397 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |
| 398 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR- | |
| 399 | RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 400 | ||
| 401 | ||
| 402 | ||
| 403 | ||
| 404 | ||
| 405 | ||
| 406 | ||
| 407 | ||
| 408 | ||
| 409 | ||
| 410 | ||
| 411 | ||
| 412 | ||
| 413 | ||
| 414 | ||
| 415 | ||
| 416 | ||
| 417 | ||
| 418 | ||
| 419 | ||
| 420 | ||
| 421 | ||
| 422 | ||
| 423 | ||
| 424 | ||
| 425 | ||
| 426 | ||
| 427 | ||
| 428 | ||
| 429 | ||
| 430 | ||
| 431 | Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 7] | |
| 432 | ||
| 433 |
| 0 | ||
| 1 | ||
| 2 | SASL Working Group A. Melnikov | |
| 3 | Internet-Draft Isode | |
| 4 | Expires: May 22, 2004 November 22, 2003 | |
| 5 | ||
| 6 | ||
| 7 | SASL GSSAPI mechanisms | |
| 8 | draft-ietf-sasl-gssapi-00 | |
| 9 | ||
| 10 | Status of this Memo | |
| 11 | ||
| 12 | This document is an Internet-Draft and is in full conformance with | |
| 13 | all provisions of Section 10 of RFC2026. | |
| 14 | ||
| 15 | Internet-Drafts are working documents of the Internet Engineering | |
| 16 | Task Force (IETF), its areas, and its working groups. Note that | |
| 17 | other groups may also distribute working documents as Internet- | |
| 18 | Drafts. | |
| 19 | ||
| 20 | Internet-Drafts are draft documents valid for a maximum of six months | |
| 21 | and may be updated, replaced, or obsoleted by other documents at any | |
| 22 | time. It is inappropriate to use Internet-Drafts as reference | |
| 23 | material or to cite them other than as "work in progress." | |
| 24 | ||
| 25 | The list of current Internet-Drafts can be accessed at http:// | |
| 26 | www.ietf.org/ietf/1id-abstracts.txt. | |
| 27 | ||
| 28 | The list of Internet-Draft Shadow Directories can be accessed at | |
| 29 | http://www.ietf.org/shadow.html. | |
| 30 | ||
| 31 | This Internet-Draft will expire on May 22, 2004. | |
| 32 | ||
| 33 | Copyright Notice | |
| 34 | ||
| 35 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 36 | ||
| 37 | Abstract | |
| 38 | ||
| 39 | The Simple Authentication and Security Layer [SASL] is a method for | |
| 40 | adding authentication support to connection-based protocols. This | |
| 41 | document describes the method for using the Generic Security Service | |
| 42 | Application Program Interface [GSSAPI] in the Simple Authentication | |
| 43 | and Security Layer [SASL]. | |
| 44 | ||
| 45 | This document replaces section 7.2 of RFC 2222 [SASL], the definition | |
| 46 | of the "GSSAPI" SASL mechanism. | |
| 47 | ||
| 48 | ||
| 49 | ||
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | Melnikov Expires May 22, 2004 [Page 1] | |
| 55 | ||
| 56 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 57 | ||
| 58 | ||
| 59 | Table of Contents | |
| 60 | ||
| 61 | 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 | |
| 62 | 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 | |
| 63 | 2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
| 64 | 3. SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |
| 65 | 4. Specification common to all GSSAPI mechanisms . . . . . . . . 6 | |
| 66 | 4.1 Client side of authentication protocol exchange . . . . . . . 6 | |
| 67 | 4.2 Server side of authentication protocol exchange . . . . . . . 7 | |
| 68 | 4.3 Security layer . . . . . . . . . . . . . . . . . . . . . . . . 8 | |
| 69 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |
| 70 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |
| 71 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | |
| 72 | Normative References . . . . . . . . . . . . . . . . . . . . . 13 | |
| 73 | Informative References . . . . . . . . . . . . . . . . . . . . 14 | |
| 74 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 | |
| 75 | Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 | |
| 76 | ||
| 77 | ||
| 78 | ||
| 79 | ||
| 80 | ||
| 81 | ||
| 82 | ||
| 83 | ||
| 84 | ||
| 85 | ||
| 86 | ||
| 87 | ||
| 88 | ||
| 89 | ||
| 90 | ||
| 91 | ||
| 92 | ||
| 93 | ||
| 94 | ||
| 95 | ||
| 96 | ||
| 97 | ||
| 98 | ||
| 99 | ||
| 100 | ||
| 101 | ||
| 102 | ||
| 103 | ||
| 104 | ||
| 105 | ||
| 106 | ||
| 107 | ||
| 108 | ||
| 109 | ||
| 110 | Melnikov Expires May 22, 2004 [Page 2] | |
| 111 | ||
| 112 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 113 | ||
| 114 | ||
| 115 | 1. Conventions Used in this Document | |
| 116 | ||
| 117 | The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" | |
| 118 | in this document are to be interpreted as defined in "Key words for | |
| 119 | use in RFCs to Indicate Requirement Levels" [KEYWORDS]. | |
| 120 | ||
| 121 | ||
| 122 | ||
| 123 | ||
| 124 | ||
| 125 | ||
| 126 | ||
| 127 | ||
| 128 | ||
| 129 | ||
| 130 | ||
| 131 | ||
| 132 | ||
| 133 | ||
| 134 | ||
| 135 | ||
| 136 | ||
| 137 | ||
| 138 | ||
| 139 | ||
| 140 | ||
| 141 | ||
| 142 | ||
| 143 | ||
| 144 | ||
| 145 | ||
| 146 | ||
| 147 | ||
| 148 | ||
| 149 | ||
| 150 | ||
| 151 | ||
| 152 | ||
| 153 | ||
| 154 | ||
| 155 | ||
| 156 | ||
| 157 | ||
| 158 | ||
| 159 | ||
| 160 | ||
| 161 | ||
| 162 | ||
| 163 | ||
| 164 | ||
| 165 | ||
| 166 | Melnikov Expires May 22, 2004 [Page 3] | |
| 167 | ||
| 168 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 169 | ||
| 170 | ||
| 171 | 2. Introduction and Overview | |
| 172 | ||
| 173 | Each and every GSSAPI mechanism used within SASL is implicitly | |
| 174 | registered by this specification. | |
| 175 | ||
| 176 | For backwards compatibility with existing implementations of Kerberos | |
| 177 | V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5 | |
| 178 | GSSAPI mechanism [KRB5GSS] is "GSSAPI" and the SASL mechanism for the | |
| 179 | SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO". The SASL mechanism | |
| 180 | name for any other GSSAPI mechanism is the concatenation of "GSS-" | |
| 181 | and the Base32 [BASE-ENCODING] encoding of the first ten bytes of the | |
| 182 | MD5 hash [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI | |
| 183 | mechanism's OID. The Base32 rules on padding characters and | |
| 184 | characters outside of the base32 alphabet are not relevant to this | |
| 185 | use of Base32. | |
| 186 | ||
| 187 | SASL mechanism names starting with "GSS-" are reserved for SASL | |
| 188 | mechanisms which conform to this document. | |
| 189 | ||
| 190 | The specification of all SASL mechanisms conforming to this document | |
| 191 | is in the "Specification common to all GSSAPI mechanisms" section of | |
| 192 | this document. | |
| 193 | ||
| 194 | The IESG is considered to be the owner of all SASL mechanisms which | |
| 195 | conform to this document. This does NOT necessarily imply that the | |
| 196 | IESG is considered to be the owner of the underlying GSSAPI | |
| 197 | mechanism. | |
| 198 | ||
| 199 | 2.1 Example | |
| 200 | ||
| 201 | The OID for the SPKM-1 mechanism [SPKM1] is 1.3.6.1.5.5.1. The ASN.1 | |
| 202 | DER encoding of this OID is 06 06 2b 06 01 05 05 01. The MD5 hash of | |
| 203 | the ASN.1 DER encoding is 57 ee 81 82 4e ac 4d b0 e6 50 9f 60 1f 46 | |
| 204 | 8a 30. The Base32 encoding of the first ten bytes of this is | |
| 205 | "K7XIDASOVRG3BZSQ". Thus the SASL mechanism name for the SPKM-1 | |
| 206 | GSSAPI mechanism is "GSS-K7XIDASOVRG3BZSQ". | |
| 207 | ||
| 208 | ||
| 209 | ||
| 210 | ||
| 211 | ||
| 212 | ||
| 213 | ||
| 214 | ||
| 215 | ||
| 216 | ||
| 217 | ||
| 218 | ||
| 219 | ||
| 220 | ||
| 221 | ||
| 222 | Melnikov Expires May 22, 2004 [Page 4] | |
| 223 | ||
| 224 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 225 | ||
| 226 | ||
| 227 | 3. SPNEGO | |
| 228 | ||
| 229 | Use of the Simple and Protected GSS-API Negotiation Mechanism | |
| 230 | [SPNEGO] underneath SASL introduces subtle interoperability problems | |
| 231 | and security considerations. To address these, this section places | |
| 232 | additional requirements on implementations which support SPNEGO | |
| 233 | underneath SASL. | |
| 234 | ||
| 235 | A client which supports, for example, the Kerberos V5 GSSAPI | |
| 236 | mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL | |
| 237 | mechanism will not interoperate with a server which supports the | |
| 238 | Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL | |
| 239 | mechanism. | |
| 240 | ||
| 241 | Since SASL is capable of negotiating amongst GSSAPI mechanisms, the | |
| 242 | only reason for a server or client to support the "GSS-SPNEGO" | |
| 243 | mechanism is to allow a policy of only using mechanisms below a | |
| 244 | certain strength if those mechanism's negotiation is protected. In | |
| 245 | such a case, a client or server would only want to negotiate those | |
| 246 | weaker mechanisms through SPNEGO. In any case, there is no down- | |
| 247 | negotiation security consideration with using the strongest mechanism | |
| 248 | and set of options the implementation supports, so for | |
| 249 | interoperability that mechanism and set of options MUST be negotiable | |
| 250 | without using the "GSS-SPNEGO" mechanism. | |
| 251 | ||
| 252 | If a client's policy is to first prefer GSSAPI mechanism X, then non- | |
| 253 | GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports | |
| 254 | mechanisms Y and Z but not X, then if the client attempts to | |
| 255 | negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it | |
| 256 | may end up using mechanism Z when it should have used mechanism Y. | |
| 257 | For this reason, implementations MUST exclude from SPNEGO those | |
| 258 | GSSAPI mechanisms which are weaker than the strongest non-GSSAPI SASL | |
| 259 | mechanism advertised by the server. | |
| 260 | ||
| 261 | ||
| 262 | ||
| 263 | ||
| 264 | ||
| 265 | ||
| 266 | ||
| 267 | ||
| 268 | ||
| 269 | ||
| 270 | ||
| 271 | ||
| 272 | ||
| 273 | ||
| 274 | ||
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | Melnikov Expires May 22, 2004 [Page 5] | |
| 279 | ||
| 280 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 281 | ||
| 282 | ||
| 283 | 4. Specification common to all GSSAPI mechanisms | |
| 284 | ||
| 285 | Each SASL mechanism which uses a GSSAPI mechanism uses the following | |
| 286 | specification. | |
| 287 | ||
| 288 | The implementation MAY set any GSSAPI flags or arguments not | |
| 289 | mentioned in this specification as is necessary for the | |
| 290 | implementation to enforce its security policy. | |
| 291 | ||
| 292 | 4.1 Client side of authentication protocol exchange | |
| 293 | ||
| 294 | The client calls GSS_Init_sec_context, passing in | |
| 295 | input_context_handle of 0 (initially), mech_type of the GSSAPI | |
| 296 | mechanism for which this SASL mechanism is registered, chan_binding | |
| 297 | of NULL, and targ_name equal to output_name from GSS_Import_Name | |
| 298 | called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and | |
| 299 | input_name_string of "service@hostname" where "service" is the | |
| 300 | service name specified in the protocol's profile, and "hostname" is | |
| 301 | the fully qualified host name of the server. If the client will be | |
| 302 | requesting a security layer, it MUST also supply to the | |
| 303 | GSS_Init_sec_context a mutual_req_flag of TRUE, a sequence_req_flag | |
| 304 | of TRUE, and an integ_req_flag of TRUE. If the client will be | |
| 305 | requesting a security layer providing confidentiality protection, it | |
| 306 | MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE. | |
| 307 | The client then responds with the resulting output_token. If | |
| 308 | GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client | |
| 309 | should expect the server to issue a token in a subsequent challenge. | |
| 310 | The client must pass the token to another call to | |
| 311 | GSS_Init_sec_context, repeating the actions in this paragraph. | |
| 312 | ||
| 313 | When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines | |
| 314 | the context to ensure that it provides a level of protection | |
| 315 | permitted by the client's security policy. If the context is | |
| 316 | acceptable, the client takes the following actions: If the last call | |
| 317 | to GSS_Init_sec_context returned an output_token, then the client | |
| 318 | responds with the output_token, otherwise the client responds with no | |
| 319 | data. The client should then expect the server to issue a token in a | |
| 320 | subsequent challenge. The client passes this token to GSS_Unwrap and | |
| 321 | interprets the first octet of resulting cleartext as a bit-mask | |
| 322 | specifying the security layers supported by the server and the second | |
| 323 | through fourth octets as the network byte order maximum size | |
| 324 | output_message to send to the server (if the resulting cleartext is | |
| 325 | not 4 octets long, the client fails the negotiation). The client | |
| 326 | then constructs data, with the first octet containing the bit-mask | |
| 327 | specifying the selected security layer, the second through fourth | |
| 328 | octets containing in network byte order the maximum size | |
| 329 | output_message the client is able to receive, and the remaining | |
| 330 | octets containing the authorization identity, encoded according to | |
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | Melnikov Expires May 22, 2004 [Page 6] | |
| 335 | ||
| 336 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 337 | ||
| 338 | ||
| 339 | the application profile specification. The authorization identity is | |
| 340 | not NUL-terminated. The client passes the data to GSS_Wrap with | |
| 341 | conf_flag set to FALSE, and responds with the generated | |
| 342 | output_message. The client can then consider the server | |
| 343 | authenticated. | |
| 344 | ||
| 345 | 4.2 Server side of authentication protocol exchange | |
| 346 | ||
| 347 | The server passes the initial client response to | |
| 348 | GSS_Accept_sec_context as input_token, setting input_context_handle | |
| 349 | to 0 (initially), mech_type of the GSSAPI mechanism for which this | |
| 350 | SASL mechanism is registered, chan_binding of NULL, and | |
| 351 | acceptor_cred_handle equal to output_cred_handle from | |
| 352 | GSS_Acquire_cred called with desired_name equal to output_name from | |
| 353 | GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE | |
| 354 | and input_name_string of "service@hostname" where "service" is the | |
| 355 | service name specified in the protocol's profile, and "hostname" is | |
| 356 | the fully qualified host name of the server. If | |
| 357 | GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server | |
| 358 | returns the generated output_token to the client in challenge and | |
| 359 | passes the resulting response to another call to | |
| 360 | GSS_Accept_sec_context, repeating the actions in this paragraph. | |
| 361 | ||
| 362 | When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server | |
| 363 | examines the context to ensure that it provides a level of protection | |
| 364 | permitted by the server's security policy. If the context is | |
| 365 | acceptable, the server takes the following actions: If the last call | |
| 366 | to GSS_Accept_sec_context returned an output_token, the server | |
| 367 | returns it to the client in a challenge and expects a reply from the | |
| 368 | client with no data. Whether or not an output_token was returned | |
| 369 | (and after receipt of any response from the client to such an | |
| 370 | output_token), the server then constructs 4 octets of data, with the | |
| 371 | first octet containing a bit-mask specifying the security layers | |
| 372 | supported by the server and the second through fourth octets | |
| 373 | containing in network byte order the maximum size output_token the | |
| 374 | server is able to receive. The server must then pass the plaintext | |
| 375 | to GSS_Wrap with conf_flag set to FALSE and issue the generated | |
| 376 | output_message to the client in a challenge. The server must then | |
| 377 | pass the resulting response to GSS_Unwrap and interpret the first | |
| 378 | octet of resulting cleartext as the bit-mask for the selected | |
| 379 | security layer, the second through fourth octets as the network byte | |
| 380 | order maximum size output_message to send to the client, and the | |
| 381 | remaining octets as the authorization identity. The server must | |
| 382 | verify that the src_name is authorized to authenticate as the | |
| 383 | authorization identity. After these verifications, the | |
| 384 | authentication process is complete. | |
| 385 | ||
| 386 | ||
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | Melnikov Expires May 22, 2004 [Page 7] | |
| 391 | ||
| 392 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 393 | ||
| 394 | ||
| 395 | 4.3 Security layer | |
| 396 | ||
| 397 | The security layers and their corresponding bit-masks are as follows: | |
| 398 | ||
| 399 | 1 No security layer | |
| 400 | 2 Integrity protection. | |
| 401 | Sender calls GSS_Wrap with conf_flag set to FALSE | |
| 402 | 4 Confidentiality protection. | |
| 403 | Sender calls GSS_Wrap with conf_flag set to TRUE | |
| 404 | ||
| 405 | Other bit-masks may be defined in the future; bits which are not | |
| 406 | understood must be negotiated off. | |
| 407 | ||
| 408 | Note that SASL negotiates the maximum size of the output_message to | |
| 409 | send. Implementations can use the GSS_Wrap_size_limit call to | |
| 410 | determine the corresponding maximum size input_message. | |
| 411 | ||
| 412 | ||
| 413 | ||
| 414 | ||
| 415 | ||
| 416 | ||
| 417 | ||
| 418 | ||
| 419 | ||
| 420 | ||
| 421 | ||
| 422 | ||
| 423 | ||
| 424 | ||
| 425 | ||
| 426 | ||
| 427 | ||
| 428 | ||
| 429 | ||
| 430 | ||
| 431 | ||
| 432 | ||
| 433 | ||
| 434 | ||
| 435 | ||
| 436 | ||
| 437 | ||
| 438 | ||
| 439 | ||
| 440 | ||
| 441 | ||
| 442 | ||
| 443 | ||
| 444 | ||
| 445 | ||
| 446 | Melnikov Expires May 22, 2004 [Page 8] | |
| 447 | ||
| 448 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 449 | ||
| 450 | ||
| 451 | 5. IANA Considerations | |
| 452 | ||
| 453 | The IANA is advised that SASL mechanism names starting with "GSS-" | |
| 454 | are reserved for SASL mechanisms which conform to this document. The | |
| 455 | IANA is directed to place a statement to that effect in the sasl- | |
| 456 | mechanisms registry. | |
| 457 | ||
| 458 | Family of SASL mechanisms: YES | |
| 459 | ||
| 460 | Prefix: GSS- | |
| 461 | ||
| 462 | Security considerations: RFC [THIS-DOC] | |
| 463 | ||
| 464 | Published Specification: RFC [THIS-DOC] | |
| 465 | ||
| 466 | Person & email address to contact for further information: Alexey | |
| 467 | Melnikov <Alexey.Melnikov@isode.com> | |
| 468 | ||
| 469 | Intended usage: COMMON | |
| 470 | ||
| 471 | Author/Change controller: iesg@ietf.org | |
| 472 | ||
| 473 | The IANA is directed to modify the existing registration for "GSSAPI" | |
| 474 | as follows. | |
| 475 | ||
| 476 | Family of SASL mechanisms: NO | |
| 477 | ||
| 478 | SASL mechanism name: GSSAPI | |
| 479 | ||
| 480 | Security considerations: ? | |
| 481 | ||
| 482 | Published Specification: RFC [THIS-DOC] | |
| 483 | ||
| 484 | Person & email address to contact for further information: Alexey | |
| 485 | Melnikov <Alexey.Melnikov@isode.com> | |
| 486 | ||
| 487 | Intended usage: COMMON | |
| 488 | ||
| 489 | Author/Change controller: iesg@ietf.org | |
| 490 | ||
| 491 | Additional Information: This mechanism is for the Kerberos V5 | |
| 492 | mechanism of GSSAPI. Other GSSAPI mechanisms use other SASL | |
| 493 | mechanism names, as described in this mechanism's published | |
| 494 | specification. | |
| 495 | ||
| 496 | The IANA is directed to modify the existing registration for "GSS- | |
| 497 | SPNEGO" as follows. | |
| 498 | ||
| 499 | ||
| 500 | ||
| 501 | ||
| 502 | Melnikov Expires May 22, 2004 [Page 9] | |
| 503 | ||
| 504 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 505 | ||
| 506 | ||
| 507 | Family of SASL mechanisms: NO | |
| 508 | ||
| 509 | SASL mechanism name: GSS-SPNEGO | |
| 510 | ||
| 511 | Security considerations: See the "SPNEGO" section of RFC [THIS-DOC]. | |
| 512 | ||
| 513 | Published Specification: RFC [THIS-DOC] | |
| 514 | ||
| 515 | Person & email address to contact for further information: Alexey | |
| 516 | Melnikov <Alexey.Melnikov@isode.com> | |
| 517 | ||
| 518 | Intended usage: LIMITED USE | |
| 519 | ||
| 520 | Author/Change controller: iesg@ietf.org | |
| 521 | ||
| 522 | ||
| 523 | ||
| 524 | ||
| 525 | ||
| 526 | ||
| 527 | ||
| 528 | ||
| 529 | ||
| 530 | ||
| 531 | ||
| 532 | ||
| 533 | ||
| 534 | ||
| 535 | ||
| 536 | ||
| 537 | ||
| 538 | ||
| 539 | ||
| 540 | ||
| 541 | ||
| 542 | ||
| 543 | ||
| 544 | ||
| 545 | ||
| 546 | ||
| 547 | ||
| 548 | ||
| 549 | ||
| 550 | ||
| 551 | ||
| 552 | ||
| 553 | ||
| 554 | ||
| 555 | ||
| 556 | ||
| 557 | ||
| 558 | Melnikov Expires May 22, 2004 [Page 10] | |
| 559 | ||
| 560 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 561 | ||
| 562 | ||
| 563 | 6. Security Considerations | |
| 564 | ||
| 565 | Security issues are discussed throughout this memo. | |
| 566 | ||
| 567 | When a server or client supports multiple authentication mechanisms, | |
| 568 | each of which has a different security strength, it is possible for | |
| 569 | an active attacker to cause a party to use the least secure mechanism | |
| 570 | supported. To protect against this sort of attack, a client or | |
| 571 | server which supports mechanisms of different strengths should have a | |
| 572 | configurable minimum strength that it will use. It is not sufficient | |
| 573 | for this minimum strength check to only be on the server, since an | |
| 574 | active attacker can change which mechanisms the client sees as being | |
| 575 | supported, causing the client to send authentication credentials for | |
| 576 | its weakest supported mechanism. | |
| 577 | ||
| 578 | The client's selection of a SASL mechanism is done in the clear and | |
| 579 | may be modified by an active attacker. It is important for any new | |
| 580 | SASL mechanisms to be designed such that an active attacker cannot | |
| 581 | obtain an authentication with weaker security properties by modifying | |
| 582 | the SASL mechanism name and/or the challenges and responses. | |
| 583 | ||
| 584 | [SPNEGO] has protection against many of these down-negotiation | |
| 585 | attacks, SASL does not itself have such protection. The section | |
| 586 | titled "SPNEGO" mentions considerations of choosing negotiation | |
| 587 | through SASL versus SPNEGO. | |
| 588 | ||
| 589 | The integrity protection provided by the security layer is useless to | |
| 590 | the client unless the client also requests mutual authentication. | |
| 591 | Therefore, a client wishing to benefit from the integrity protection | |
| 592 | of a security layer MUST pass to the GSS_Init_sec_context call a | |
| 593 | mutual_req_flag of TRUE. | |
| 594 | ||
| 595 | When constructing the input_name_string, the client should not | |
| 596 | canonicalize the server's fully qualified domain name using an | |
| 597 | insecure or untrusted directory service. | |
| 598 | ||
| 599 | Additional security considerations are in the [SASL] and [GSSAPI] | |
| 600 | specifications. | |
| 601 | ||
| 602 | ||
| 603 | ||
| 604 | ||
| 605 | ||
| 606 | ||
| 607 | ||
| 608 | ||
| 609 | ||
| 610 | ||
| 611 | ||
| 612 | ||
| 613 | ||
| 614 | Melnikov Expires May 22, 2004 [Page 11] | |
| 615 | ||
| 616 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 617 | ||
| 618 | ||
| 619 | 7. Acknowledgements | |
| 620 | ||
| 621 | This document is a revision of RFC 2222 written by John G. Myers. | |
| 622 | He also contributed significantly to this revision. | |
| 623 | ||
| 624 | Thank you to Lawrence Greenfield for converting text of this draft to | |
| 625 | XML format. | |
| 626 | ||
| 627 | Contributions of many members of the SASL mailing list are gratefully | |
| 628 | acknowledged. | |
| 629 | ||
| 630 | ||
| 631 | ||
| 632 | ||
| 633 | ||
| 634 | ||
| 635 | ||
| 636 | ||
| 637 | ||
| 638 | ||
| 639 | ||
| 640 | ||
| 641 | ||
| 642 | ||
| 643 | ||
| 644 | ||
| 645 | ||
| 646 | ||
| 647 | ||
| 648 | ||
| 649 | ||
| 650 | ||
| 651 | ||
| 652 | ||
| 653 | ||
| 654 | ||
| 655 | ||
| 656 | ||
| 657 | ||
| 658 | ||
| 659 | ||
| 660 | ||
| 661 | ||
| 662 | ||
| 663 | ||
| 664 | ||
| 665 | ||
| 666 | ||
| 667 | ||
| 668 | ||
| 669 | ||
| 670 | Melnikov Expires May 22, 2004 [Page 12] | |
| 671 | ||
| 672 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 673 | ||
| 674 | ||
| 675 | Normative References | |
| 676 | ||
| 677 | [ASN1] International Organization for Standardization, | |
| 678 | "Information Processing Systems - Open Systems | |
| 679 | Interconnection - Specification of Abstract Syntax | |
| 680 | Notation One (ASN.1)", ISO Standard 8824, December | |
| 681 | 1990. | |
| 682 | ||
| 683 | [BASE-ENCODING] Josefsson, S., "The Base16, Base32, and Base64 Data | |
| 684 | Encodings", RFC 3548, July 2003. | |
| 685 | ||
| 686 | [GSSAPI] Linn, J., "Generic Security Service Application | |
| 687 | Program Interface Version 2, Update 1", RFC 2743, | |
| 688 | January 2000. | |
| 689 | ||
| 690 | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |
| 691 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
| 692 | ||
| 693 | [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API | |
| 694 | Mechanism", RFC 1964, June 1996. | |
| 695 | ||
| 696 | [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC | |
| 697 | 1321, April 1992. | |
| 698 | ||
| 699 | [SASL] Myers, J., "Simple Authentication and Security Layer | |
| 700 | (SASL)", RFC 2222, October 1997. | |
| 701 | ||
| 702 | [SASL(rev)] Melnikov, A., "Simple Authentication and Security | |
| 703 | Layer (SASL)", draft-ietf-sasl-rfc2222bis (work in | |
| 704 | progress), October 2003. | |
| 705 | ||
| 706 | [SPNEGO] Baize, E. and D. Pinkas, "The Simple and Protected | |
| 707 | GSS-API Negotiation Mechanism", RFC 2478, December | |
| 708 | 1998. | |
| 709 | ||
| 710 | ||
| 711 | ||
| 712 | ||
| 713 | ||
| 714 | ||
| 715 | ||
| 716 | ||
| 717 | ||
| 718 | ||
| 719 | ||
| 720 | ||
| 721 | ||
| 722 | ||
| 723 | ||
| 724 | ||
| 725 | ||
| 726 | Melnikov Expires May 22, 2004 [Page 13] | |
| 727 | ||
| 728 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 729 | ||
| 730 | ||
| 731 | Informative References | |
| 732 | ||
| 733 | [SPKM1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", | |
| 734 | RFC 2025, October 1996. | |
| 735 | ||
| 736 | [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", | |
| 737 | RFC 2279, January 1998. | |
| 738 | ||
| 739 | ||
| 740 | Author's Address | |
| 741 | ||
| 742 | Alexey Melnikov (Ed.) | |
| 743 | Isode Limited | |
| 744 | 5 Castle Business Village | |
| 745 | 36 Station Road | |
| 746 | Hampton, Middlesex TW12 2BX | |
| 747 | UK | |
| 748 | ||
| 749 | EMail: Alexey.Melnikov@isode.com | |
| 750 | URI: http://www.melnikov.ca/ | |
| 751 | ||
| 752 | ||
| 753 | ||
| 754 | ||
| 755 | ||
| 756 | ||
| 757 | ||
| 758 | ||
| 759 | ||
| 760 | ||
| 761 | ||
| 762 | ||
| 763 | ||
| 764 | ||
| 765 | ||
| 766 | ||
| 767 | ||
| 768 | ||
| 769 | ||
| 770 | ||
| 771 | ||
| 772 | ||
| 773 | ||
| 774 | ||
| 775 | ||
| 776 | ||
| 777 | ||
| 778 | ||
| 779 | ||
| 780 | ||
| 781 | ||
| 782 | Melnikov Expires May 22, 2004 [Page 14] | |
| 783 | ||
| 784 | Internet-Draft SASL GSSAPI mechanisms November 2003 | |
| 785 | ||
| 786 | ||
| 787 | Full Copyright Statement | |
| 788 | ||
| 789 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 790 | ||
| 791 | This document and translations of it may be copied and furnished to | |
| 792 | others, and derivative works that comment on or otherwise explain it | |
| 793 | or assist in its implementation may be prepared, copied, published | |
| 794 | and distributed, in whole or in part, without restriction of any | |
| 795 | kind, provided that the above copyright notice and this paragraph are | |
| 796 | included on all such copies and derivative works. However, this | |
| 797 | document itself may not be modified in any way, such as by removing | |
| 798 | the copyright notice or references to the Internet Society or other | |
| 799 | Internet organizations, except as needed for the purpose of | |
| 800 | developing Internet standards in which case the procedures for | |
| 801 | copyrights defined in the Internet Standards process must be | |
| 802 | followed, or as required to translate it into languages other than | |
| 803 | English. | |
| 804 | ||
| 805 | The limited permissions granted above are perpetual and will not be | |
| 806 | revoked by the Internet Society or its successors or assigns. | |
| 807 | ||
| 808 | This document and the information contained herein is provided on an | |
| 809 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 810 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 811 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 812 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 813 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 814 | ||
| 815 | Acknowledgement | |
| 816 | ||
| 817 | Funding for the RFC Editor function is currently provided by the | |
| 818 | Internet Society. | |
| 819 | ||
| 820 | ||
| 821 | ||
| 822 | ||
| 823 | ||
| 824 | ||
| 825 | ||
| 826 | ||
| 827 | ||
| 828 | ||
| 829 | ||
| 830 | ||
| 831 | ||
| 832 | ||
| 833 | ||
| 834 | ||
| 835 | ||
| 836 | ||
| 837 | ||
| 838 | Melnikov Expires May 22, 2004 [Page 15] | |
| 839 | ||
| 840 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | INTERNET-DRAFT Editor: Kurt D. Zeilenga | |
| 7 | Intended Category: Standards Track OpenLDAP Foundation | |
| 8 | Expires in six months 27 October 2003 | |
| 9 | Updates: RFC 2595 | |
| 10 | ||
| 11 | ||
| 12 | The Plain SASL Mechanism | |
| 13 | <draft-ietf-sasl-plain-03.txt> | |
| 14 | ||
| 15 | ||
| 16 | Status of Memo | |
| 17 | ||
| 18 | This document is an Internet-Draft and is in full conformance with all | |
| 19 | provisions of Section 10 of RFC2026. | |
| 20 | ||
| 21 | This document is intended to be, after appropriate review and | |
| 22 | revision, submitted to the RFC Editor as a Standards Track document. | |
| 23 | Distribution of this memo is unlimited. Technical discussion of this | |
| 24 | document will take place on the IETF SASL mailing list | |
| 25 | <ietf-sasl@imc.org>. Please send editorial comments directly to the | |
| 26 | document editor <Kurt@OpenLDAP.org>. | |
| 27 | ||
| 28 | Internet-Drafts are working documents of the Internet Engineering Task | |
| 29 | Force (IETF), its areas, and its working groups. Note that other | |
| 30 | groups may also distribute working documents as Internet-Drafts. | |
| 31 | Internet-Drafts are draft documents valid for a maximum of six months | |
| 32 | and may be updated, replaced, or obsoleted by other documents at any | |
| 33 | time. It is inappropriate to use Internet-Drafts as reference | |
| 34 | material or to cite them other than as ``work in progress.'' | |
| 35 | ||
| 36 | The list of current Internet-Drafts can be accessed at | |
| 37 | <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of | |
| 38 | Internet-Draft Shadow Directories can be accessed at | |
| 39 | <http://www.ietf.org/shadow.html>. | |
| 40 | ||
| 41 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 42 | ||
| 43 | Please see the Full Copyright section near the end of this document | |
| 44 | for more information. | |
| 45 | ||
| 46 | ||
| 47 | Abstract | |
| 48 | ||
| 49 | This document defines a simple clear-text user/password Simple | |
| 50 | Authentication and Security Layer (SASL) mechanism called the PLAIN | |
| 51 | mechanism. The PLAIN mechanism is intended to be used, in combination | |
| 52 | with data confidentiality services provided by a lower layer, in | |
| 53 | protocols which lack a simple password authentication command. | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Zeilenga Plain SASL Mechanism [Page 1] | |
| 58 | ||
| 59 | INTERNET-DRAFT draft-ietf-sasl-plain-03.txt 27 October 2003 | |
| 60 | ||
| 61 | ||
| 62 | Conventions | |
| 63 | ||
| 64 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
| 65 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
| 66 | document are to be interpreted as described in [Keywords]. | |
| 67 | ||
| 68 | ||
| 69 | 1. Background and Intended Usage | |
| 70 | ||
| 71 | Clear-text passwords are simple, interoperate with almost all existing | |
| 72 | operating system authentication databases, and are useful for a smooth | |
| 73 | transition to a more secure password-based authentication mechanism. | |
| 74 | The drawback is that they are unacceptable for use over an unencrypted | |
| 75 | network connection. | |
| 76 | ||
| 77 | This document defines the PLAIN Simple Authentication and Security | |
| 78 | Layer ([SASL]) mechanism for use in protocols with no clear-text login | |
| 79 | command (e.g., [ACAP] or [SMTP-AUTH]). | |
| 80 | ||
| 81 | The name associated with this mechanism is "PLAIN". | |
| 82 | ||
| 83 | The PLAIN SASL mechanism does not provide a security layer. This | |
| 84 | mechanism MUST NOT be used without adequate security protection as the | |
| 85 | mechanism affords no integrity nor confidentiality protection itself. | |
| 86 | The PLAIN SASL mechanism MUST NOT be advertised unless a strong | |
| 87 | encryption layer, such as provided by Transport Layer Security | |
| 88 | ([TLS]), is active or backwards compatibility dictates otherwise. | |
| 89 | ||
| 90 | This document updates RFC 2595, replacing Section 6. Changes since | |
| 91 | RFC 2595 are detailed in Appendix A. | |
| 92 | ||
| 93 | ||
| 94 | 2. PLAIN SASL mechanism | |
| 95 | ||
| 96 | The mechanism consists of a single message from the client to the | |
| 97 | server. The client sends the authorization identity (identity to | |
| 98 | login as), followed by a NUL (U+0000) character, followed by the | |
| 99 | authentication identity (identity whose password will be used), | |
| 100 | followed by a NUL (U+0000) character, followed by the clear-text | |
| 101 | password. The client leaves the authorization identity empty if it | |
| 102 | wishes the server to derive the authorization identity from the | |
| 103 | authentication identity. | |
| 104 | ||
| 105 | The formal grammar for the client message using Augmented BNF [ABNF] | |
| 106 | follows. | |
| 107 | ||
| 108 | message = [authzid] NUL authcid NUL passwd | |
| 109 | authcid = 1*SAFE ; MUST accept up to 255 octets | |
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Zeilenga Plain SASL Mechanism [Page 2] | |
| 114 | ||
| 115 | INTERNET-DRAFT draft-ietf-sasl-plain-03.txt 27 October 2003 | |
| 116 | ||
| 117 | ||
| 118 | authzid = 1*SAFE ; MUST accept up to 255 octets | |
| 119 | passwd = 1*SAFE ; MUST accept up to 255 octets | |
| 120 | NUL = %x00 | |
| 121 | ||
| 122 | SAFE = UTF1 / UTF2 / UTF3 / UTF4 | |
| 123 | ;; any UTF-8 encoded Unicode character except NUL | |
| 124 | ||
| 125 | UTF1 = %x01-7F ;; except NULL | |
| 126 | UTF2 = %xC2-DF UTF0 | |
| 127 | UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / | |
| 128 | %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) | |
| 129 | UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / | |
| 130 | %xF4 %x80-8F 2(UTF0) | |
| 131 | UTF0 = %x80-BF | |
| 132 | ||
| 133 | The authorization identity (authzid), authentication identity | |
| 134 | (authcid) and password (passwd) SHALL be transferred as [UTF-8] | |
| 135 | encoded strings of [Unicode] characters. As NUL (U+0000) is used as a | |
| 136 | deliminator, the NUL (U+0000) MUST NOT appear in authzid, authcid, or | |
| 137 | passwd productions. | |
| 138 | ||
| 139 | The form of the authzid production is specific to the | |
| 140 | application-level protocol's SASL profile [SASL]. The authcid and | |
| 141 | passwd productions are form-free. Use of non-visible characters or | |
| 142 | characters which a user may be unable to enter on some keyboards is | |
| 143 | discouraged. | |
| 144 | ||
| 145 | Servers MUST be capable of accepting authzid, authcid, and passwd | |
| 146 | productions up to and including 255 octets. It is noted that the | |
| 147 | UTF-8 encoding of a Unicode character may be as long as 4 octets. | |
| 148 | ||
| 149 | Upon receipt of the message, the server will verify the presented | |
| 150 | authentication identity (authcid) and password (passwd) with the | |
| 151 | system authentication database and verify the authentication | |
| 152 | credentials permit the client to login as the (presented or derived) | |
| 153 | authorization identity. If both steps succeed, the user is | |
| 154 | authenticated. | |
| 155 | ||
| 156 | The presented authentication identity and password strings are not to | |
| 157 | be compared directly with stored strings. The server SHALL first | |
| 158 | prepare authentication identity and password strings using the | |
| 159 | [SASLPrep] profile of the [StringPrep] algorithm. If preparation | |
| 160 | fails or results in an empty string, verification SHALL fail. If the | |
| 161 | server stores only the hash of expected string, that string MUST be | |
| 162 | prepared before generation of the hash. | |
| 163 | ||
| 164 | When the no authorization identity is provided, the server SHALL | |
| 165 | derive the authorization identity from the prepared representation of | |
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Zeilenga Plain SASL Mechanism [Page 3] | |
| 170 | ||
| 171 | INTERNET-DRAFT draft-ietf-sasl-plain-03.txt 27 October 2003 | |
| 172 | ||
| 173 | ||
| 174 | the provided authentication identity string. This ensures that the | |
| 175 | derivation of different representations of the authentication identity | |
| 176 | produce the same authorization identity. | |
| 177 | ||
| 178 | The verification function (using hashed password) can be written (in | |
| 179 | pseudo-code): | |
| 180 | ||
| 181 | boolean Verify(string authzid, string authcid, string passwd) { | |
| 182 | string pAuthcid = SASLprep(authcid); # prepare authcid | |
| 183 | string pPasswd = SASLprep(passwd); # prepare passwd | |
| 184 | if (pAuthcid == NULL || pPasswd == NULL) { | |
| 185 | return false; # preparation failed | |
| 186 | } | |
| 187 | if (pAuthcid == "" || pPasswd == "") { | |
| 188 | return false; # empty prepared string | |
| 189 | } | |
| 190 | ||
| 191 | storedHash = FetchPasswordHash(pAuthcid); | |
| 192 | if (storedHash == NULL || storedHash == "") { | |
| 193 | return false; # error or unknown authcid | |
| 194 | } | |
| 195 | ||
| 196 | if (!Compare(storedHash, Hash(pPassword))) { | |
| 197 | return false; # incorrect password | |
| 198 | } | |
| 199 | ||
| 200 | if (authzid == NULL) { | |
| 201 | authzid = DeriveAuthzid(pAuthcid); | |
| 202 | if (authzid == NULL || authzid == "") { | |
| 203 | return false; # could not derive authzid | |
| 204 | } | |
| 205 | } | |
| 206 | ||
| 207 | if (!Authorize(pAuthcid, authzid)) { | |
| 208 | return false; # not authorized | |
| 209 | } | |
| 210 | ||
| 211 | return true; | |
| 212 | } | |
| 213 | ||
| 214 | Also note that the second parameter provided to the Authorize function | |
| 215 | is not prepared by this code. The application-level SASL profile | |
| 216 | should be consulted to determine what, if any, preparation is | |
| 217 | necessary. | |
| 218 | ||
| 219 | The server MAY also use the credentials to initialize any new | |
| 220 | authentication database, such as one suitable for [CRAM-MD5] or | |
| 221 | [DIGEST-MD5]. | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Zeilenga Plain SASL Mechanism [Page 4] | |
| 226 | ||
| 227 | INTERNET-DRAFT draft-ietf-sasl-plain-03.txt 27 October 2003 | |
| 228 | ||
| 229 | ||
| 230 | 4. Example | |
| 231 | ||
| 232 | Here is an example of how this might be used to initialize a CRAM-MD5 | |
| 233 | authentication database using the Application Configuration Access | |
| 234 | Protocol ([ACAP]). "C:" and "S:" indicate lines sent by the client | |
| 235 | and server respectively and <NUL> represents a single NUL (U+0000) | |
| 236 | character. | |
| 237 | ||
| 238 | S: * ACAP (SASL "CRAM-MD5") (STARTTLS) | |
| 239 | C: a001 AUTHENTICATE "CRAM-MD5" | |
| 240 | S: + "<1896.697170952@postoffice.reston.mci.net>" | |
| 241 | C: "tim b913a602c7eda7a495b4e6e7334d3890" | |
| 242 | S: a001 NO (TRANSITION-NEEDED) | |
| 243 | "Please change your password, or use TLS to login" | |
| 244 | C: a002 STARTTLS | |
| 245 | S: a002 OK "Begin TLS negotiation now" | |
| 246 | <TLS negotiation, further commands are under TLS layer> | |
| 247 | S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") | |
| 248 | C: a003 AUTHENTICATE "PLAIN" {21+} | |
| 249 | C: <NUL>tim<NUL>tanstaaftanstaaf | |
| 250 | S: a003 OK CRAM-MD5 password initialized | |
| 251 | ||
| 252 | ||
| 253 | ||
| 254 | 5. Security Considerations | |
| 255 | ||
| 256 | The PLAIN mechanism relies on the TLS encryption layer for security. | |
| 257 | When used without TLS, it is vulnerable to a common network | |
| 258 | eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used | |
| 259 | unless a suitable TLS encryption layer is active or backwards | |
| 260 | compatibility dictates otherwise. | |
| 261 | ||
| 262 | When the PLAIN mechanism is used, the server gains the ability to | |
| 263 | impersonate the user to all services with the same password regardless | |
| 264 | of any encryption provided by TLS or other network privacy mechanisms. | |
| 265 | While many other authentication mechanisms have similar weaknesses, | |
| 266 | stronger SASL mechanisms address this issue. Clients are encouraged | |
| 267 | to have an operational mode where all mechanisms which are likely to | |
| 268 | reveal the user's password to the server are disabled. | |
| 269 | ||
| 270 | General SASL security considerations apply to this mechanism. | |
| 271 | "stringprep" and Unicode [StringPrep] security considerations also | |
| 272 | apply, as do [UTF-8] security considerations. | |
| 273 | ||
| 274 | ||
| 275 | 6. IANA Considerations | |
| 276 | ||
| 277 | It is requested that the SASL Mechanism registry [IANA-SASL] entry for | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Zeilenga Plain SASL Mechanism [Page 5] | |
| 282 | ||
| 283 | INTERNET-DRAFT draft-ietf-sasl-plain-03.txt 27 October 2003 | |
| 284 | ||
| 285 | ||
| 286 | the PLAIN mechanism be updated to reflect that this document now | |
| 287 | provides its technical specification. | |
| 288 | ||
| 289 | To: iana@iana.org | |
| 290 | Subject: Updated Registration of SASL mechanism PLAIN | |
| 291 | ||
| 292 | SASL mechanism name: PLAIN | |
| 293 | Security considerations: See RFC XXXX. | |
| 294 | Published specification (optional, recommended): RFC XXXX | |
| 295 | Person & email address to contact for further information: | |
| 296 | Kurt Zeilenga <kurt@openldap.org> | |
| 297 | IETF SASL WG <ietf-sasl@imc.org> | |
| 298 | Intended usage: COMMON | |
| 299 | Author/Change controller: IESG <iesg@ietf.org> | |
| 300 | Note: Updates existing entry for PLAIN | |
| 301 | ||
| 302 | ||
| 303 | 7. Acknowledgment | |
| 304 | ||
| 305 | This document is a revision of RFC 2595 by Chris Newman. Portions of | |
| 306 | the grammar defined in Section 2 were borrowed from [UTF-8] by | |
| 307 | Francois Yergeau. | |
| 308 | ||
| 309 | This document is a product of the IETF SASL WG. | |
| 310 | ||
| 311 | ||
| 312 | 8. Normative References | |
| 313 | ||
| 314 | [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
| 315 | Specifications: ABNF", RFC 2234, November 1997. | |
| 316 | ||
| 317 | [Keywords] Bradner, S., "Key words for use in RFCs to Indicate | |
| 318 | Requirement Levels", BCP 14, RFC 2119, March 1997 | |
| 319 | ||
| 320 | [SASL] Melnikov, A. (Editor), "Simple Authentication and | |
| 321 | Security Layer (SASL)", | |
| 322 | draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. | |
| 323 | ||
| 324 | [StringPrep] Hoffman P. and M. Blanchet, "Preparation of | |
| 325 | Internationalized Strings ('stringprep')", | |
| 326 | draft-hoffman-rfc3454bis-xx.txt, a work in progress. | |
| 327 | ||
| 328 | [Unicode] The Unicode Consortium, "The Unicode Standard, Version | |
| 329 | 3.2.0" is defined by "The Unicode Standard, Version 3.0" | |
| 330 | (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), | |
| 331 | as amended by the "Unicode Standard Annex #27: Unicode | |
| 332 | 3.1" (http://www.unicode.org/reports/tr27/) and by the | |
| 333 | "Unicode Standard Annex #28: Unicode 3.2" | |
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Zeilenga Plain SASL Mechanism [Page 6] | |
| 338 | ||
| 339 | INTERNET-DRAFT draft-ietf-sasl-plain-03.txt 27 October 2003 | |
| 340 | ||
| 341 | ||
| 342 | (http://www.unicode.org/reports/tr28/). | |
| 343 | ||
| 344 | [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO | |
| 345 | 10646", draft-yergeau-rfc2279bis-xx.txt, a work in | |
| 346 | progress. | |
| 347 | ||
| 348 | [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version | |
| 349 | 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in | |
| 350 | progress. | |
| 351 | ||
| 352 | ||
| 353 | 9. Informative References | |
| 354 | ||
| 355 | [ACAP] Newman, C. and J. Myers, "ACAP -- Application | |
| 356 | Configuration Access Protocol", RFC 2244, November 1997. | |
| 357 | [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", | |
| 358 | draft-ietf-sasl-crammd5-xx.txt, a work in progress. | |
| 359 | ||
| 360 | [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest | |
| 361 | Authentication as a SASL Mechanism", | |
| 362 | draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress. | |
| 363 | ||
| 364 | [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) | |
| 365 | MECHANISMS", http://www.iana.org/assignments/sasl- | |
| 366 | mechanisms. | |
| 367 | ||
| 368 | [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", | |
| 369 | RFC 2554, March 1999. | |
| 370 | ||
| 371 | ||
| 372 | ||
| 373 | 10. Editor's Address | |
| 374 | ||
| 375 | Kurt Zeilenga | |
| 376 | OpenLDAP Foundation | |
| 377 | ||
| 378 | Email: kurt@OpenLDAP.org | |
| 379 | ||
| 380 | ||
| 381 | Appendix A. Changes since RFC 2595 | |
| 382 | ||
| 383 | This appendix is non-normative. | |
| 384 | ||
| 385 | This document replaces Section 6 of RFC 2595. | |
| 386 | ||
| 387 | The specification details how the server is to compare client-provided | |
| 388 | character strings with stored character strings. | |
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Zeilenga Plain SASL Mechanism [Page 7] | |
| 394 | ||
| 395 | INTERNET-DRAFT draft-ietf-sasl-plain-03.txt 27 October 2003 | |
| 396 | ||
| 397 | ||
| 398 | The ABNF grammar was updated. In particular, the grammar now allows | |
| 399 | LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the | |
| 400 | authzid, authcid, passwd productions. However, whether these control | |
| 401 | characters may be used depends on the string preparation rules | |
| 402 | applicable to the production. For passwd and authcid productions, | |
| 403 | control characters are prohibited. For authzid, one must consult the | |
| 404 | application-level SASL profile. | |
| 405 | ||
| 406 | ||
| 407 | ||
| 408 | Intellectual Property Rights | |
| 409 | ||
| 410 | The IETF takes no position regarding the validity or scope of any | |
| 411 | intellectual property or other rights that might be claimed to pertain | |
| 412 | to the implementation or use of the technology described in this | |
| 413 | document or the extent to which any license under such rights might or | |
| 414 | might not be available; neither does it represent that it has made any | |
| 415 | effort to identify any such rights. Information on the IETF's | |
| 416 | procedures with respect to rights in standards-track and | |
| 417 | standards-related documentation can be found in BCP-11. Copies of | |
| 418 | claims of rights made available for publication and any assurances of | |
| 419 | licenses to be made available, or the result of an attempt made to | |
| 420 | obtain a general license or permission for the use of such proprietary | |
| 421 | rights by implementors or users of this specification can be obtained | |
| 422 | from the IETF Secretariat. | |
| 423 | ||
| 424 | The IETF invites any interested party to bring to its attention any | |
| 425 | copyrights, patents or patent applications, or other proprietary | |
| 426 | rights which may cover technology that may be required to practice | |
| 427 | this standard. Please address the information to the IETF Executive | |
| 428 | Director. | |
| 429 | ||
| 430 | ||
| 431 | ||
| 432 | Full Copyright | |
| 433 | ||
| 434 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 435 | ||
| 436 | This document and translations of it may be copied and furnished to | |
| 437 | others, and derivative works that comment on or otherwise explain it | |
| 438 | or assist in its implmentation may be prepared, copied, published and | |
| 439 | distributed, in whole or in part, without restriction of any kind, | |
| 440 | provided that the above copyright notice and this paragraph are | |
| 441 | included on all such copies and derivative works. However, this | |
| 442 | document itself may not be modified in any way, such as by removing | |
| 443 | the copyright notice or references to the Internet Society or other | |
| 444 | Internet organizations, except as needed for the purpose of | |
| 445 | developing Internet standards in which case the procedures for | |
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Zeilenga Plain SASL Mechanism [Page 8] | |
| 450 | ||
| 451 | INTERNET-DRAFT draft-ietf-sasl-plain-03.txt 27 October 2003 | |
| 452 | ||
| 453 | ||
| 454 | copyrights defined in the Internet Standards process must be followed, | |
| 455 | or as required to translate it into languages other than English. | |
| 456 | ||
| 457 | ||
| 458 | ||
| 459 | ||
| 460 | ||
| 461 | ||
| 462 | ||
| 463 | ||
| 464 | ||
| 465 | ||
| 466 | ||
| 467 | ||
| 468 | ||
| 469 | ||
| 470 | ||
| 471 | ||
| 472 | ||
| 473 | ||
| 474 | ||
| 475 | ||
| 476 | ||
| 477 | ||
| 478 | ||
| 479 | ||
| 480 | ||
| 481 | ||
| 482 | ||
| 483 | ||
| 484 | ||
| 485 | ||
| 486 | ||
| 487 | ||
| 488 | ||
| 489 | ||
| 490 | ||
| 491 | ||
| 492 | ||
| 493 | ||
| 494 | ||
| 495 | ||
| 496 | ||
| 497 | ||
| 498 | ||
| 499 | ||
| 500 | ||
| 501 | ||
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Zeilenga Plain SASL Mechanism [Page 9] | |
| 506 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group A. Melnikov | |
| 7 | Internet Draft Editor | |
| 8 | Document: draft-ietf-sasl-rfc2222bis-03.txt October 2003 | |
| 9 | Expires in six months | |
| 10 | ||
| 11 | ||
| 12 | Simple Authentication and Security Layer (SASL) | |
| 13 | ||
| 14 | Status of this Memo | |
| 15 | ||
| 16 | This document is an Internet Draft and is in full conformance with | |
| 17 | all provisions of Section 10 of RFC 2026. | |
| 18 | ||
| 19 | Internet Drafts are working documents of the Internet Engineering | |
| 20 | Task Force (IETF), its Areas, and its Working Groups. Note that | |
| 21 | other groups may also distribute working documents as Internet | |
| 22 | Drafts. Internet Drafts are draft documents valid for a maximum of | |
| 23 | six months. Internet Drafts may be updated, replaced, or obsoleted | |
| 24 | by other documents at any time. It is not appropriate to use | |
| 25 | Internet Drafts as reference material or to cite them other than as | |
| 26 | ``work in progress''. | |
| 27 | ||
| 28 | The list of current Internet-Drafts can be accessed at | |
| 29 | http://www.ietf.org/ietf/1id-abstracts.txt | |
| 30 | ||
| 31 | The list of Internet-Draft Shadow Directories can be accessed at | |
| 32 | http://www.ietf.org/shadow.html. | |
| 33 | ||
| 34 | A revised version of this draft document will be submitted to the RFC | |
| 35 | editor as a Draft Standard for the Internet Community. Discussion | |
| 36 | and suggestions for improvement are requested. Distribution of this | |
| 37 | draft is unlimited. | |
| 38 | ||
| 39 | When published as an RFC this document will obsolete RFC 2222. | |
| 40 | ||
| 41 | ||
| 42 | ||
| 43 | ||
| 44 | ||
| 45 | ||
| 46 | ||
| 47 | ||
| 48 | ||
| 49 | ||
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | A. Melnikov FORMFEED[Page i] | |
| 58 | ||
| 59 | ||
| 60 | ||
| 61 | ||
| 62 | ||
| 63 | Internet DRAFT SASL 18 October 2003 | |
| 64 | ||
| 65 | ||
| 66 | 1. Abstract | |
| 67 | ||
| 68 | The Simple Authentication and Security Layer (SASL) provides a method | |
| 69 | for adding authentication support with an optional security layer to | |
| 70 | connection-based protocols. It also describes a structure for | |
| 71 | authentication mechanisms. The result is an abstraction layer | |
| 72 | between protocols and authentication mechanisms such that any SASL- | |
| 73 | compatible authentication mechanism can be used with any SASL- | |
| 74 | compatible protocol. | |
| 75 | ||
| 76 | This document describes how a SASL authentication mechanism is | |
| 77 | structured, describes how a protocol adds support for SASL, defines | |
| 78 | the protocol for carrying a security layer over a connection, and | |
| 79 | defines the EXTERNAL SASL authentication mechanism. | |
| 80 | ||
| 81 | 2. Organization of this document | |
| 82 | ||
| 83 | 2.1. How to read this document | |
| 84 | ||
| 85 | This document is written to serve two different audiences, protocol | |
| 86 | designers using this specification to support authentication in their | |
| 87 | protocol, and implementors of clients or servers for those protocols | |
| 88 | using this specification. | |
| 89 | ||
| 90 | The sections "Overview", "Authentication Mechanisms", "Protocol | |
| 91 | Profile Requirements", "Specific Issues", and "Security | |
| 92 | Considerations" cover issues that protocol designers need to | |
| 93 | understand and address in profiling this specification for use in a | |
| 94 | specific protocol. | |
| 95 | ||
| 96 | Implementors of a protocol using this specification need the | |
| 97 | protocol-specific profiling information in addition to the | |
| 98 | information in this document. | |
| 99 | ||
| 100 | 2.2. Conventions used in this document | |
| 101 | ||
| 102 | In examples, "C:" and "S:" indicate lines sent by the client and | |
| 103 | server respectively. | |
| 104 | ||
| 105 | The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" | |
| 106 | in this document are to be interpreted as defined in "Key words for | |
| 107 | use in RFCs to Indicate Requirement Levels" [KEYWORDS]. | |
| 108 | ||
| 109 | Character names in this document use the notation for code points and | |
| 110 | names from the Unicode Standard [Unicode]. For example, the letter | |
| 111 | "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. | |
| 112 | ||
| 113 | ||
| 114 | ||
| 115 | ||
| 116 | ||
| 117 | A. Melnikov FORMFEED[Page 2] | |
| 118 | ||
| 119 | ||
| 120 | ||
| 121 | ||
| 122 | ||
| 123 | Internet DRAFT SASL 18 October 2003 | |
| 124 | ||
| 125 | ||
| 126 | 3. Overview | |
| 127 | ||
| 128 | The Simple Authentication and Security Layer (SASL) is a method for | |
| 129 | adding authentication support to connection-based protocols. | |
| 130 | ||
| 131 | The SASL specification has three layers, as indicated in the diagram | |
| 132 | below. At the top, a protocol definition using SASL specifies a | |
| 133 | profile, including a command for identifying and authenticating a | |
| 134 | user to a server and for optionally negotiating a security layer for | |
| 135 | subsequent protocol interactions. At the bottom, a SASL mechanism | |
| 136 | definition specifies an authentication mechanism. The SASL | |
| 137 | framework, specified by this document, constrains the behavior of | |
| 138 | protocol profiles and mechanisms, separating protocol from mechanism | |
| 139 | and defining how they interact. | |
| 140 | ||
| 141 | SMTP Protocol LDAP Protocol Etc | |
| 142 | Profile Profile . . . | |
| 143 | ----- | -----// | |
| 144 | | // | |
| 145 | SASL framework | |
| 146 | / | \ | |
| 147 | /----- | -----\ | |
| 148 | EXTERNAL DIGEST-MD5 Etc | |
| 149 | SASL mechanism SASL mechanism . . . | |
| 150 | ||
| 151 | This separation between the definition of protocols and the | |
| 152 | definition of authentication mechanisms is crucial. It permits an | |
| 153 | authentication mechanism to be defined once, making it usable by any | |
| 154 | SASL protocol profile. In many implementations, the same SASL | |
| 155 | mechanism code is used for multiple protocols. | |
| 156 | ||
| 157 | 4. Authentication mechanisms | |
| 158 | ||
| 159 | SASL mechanisms are named by strings, from 1 to 20 characters in | |
| 160 | length, consisting of upper-case ASCII [ASCII] letters, digits, | |
| 161 | hyphens, and/or underscores. SASL mechanism names must be registered | |
| 162 | with the Internet Assigned Numbers Authority (IANA). IETF standards | |
| 163 | track documents may direct the IANA to reserve a portion of the SASL | |
| 164 | mechanism namespace and may specify different registration criteria | |
| 165 | for the reserved portion; the GSSAPI mechanism specification [SASL- | |
| 166 | GSSAPI] does this. Procedures for registering new SASL mechanisms are | |
| 167 | given in the section 8. | |
| 168 | ||
| 169 | The "sasl-mech" rule below defines the syntax of a SASL mechanism | |
| 170 | name. This uses the Augmented Backus-Naur Form (ABNF) notation as | |
| 171 | specified in [ABNF] and the ABNF core rules as specified in Appendix | |
| 172 | A of the ABNF specification [ABNF]. | |
| 173 | ||
| 174 | ||
| 175 | ||
| 176 | ||
| 177 | A. Melnikov FORMFEED[Page 3] | |
| 178 | ||
| 179 | ||
| 180 | ||
| 181 | ||
| 182 | ||
| 183 | Internet DRAFT SASL 18 October 2003 | |
| 184 | ||
| 185 | ||
| 186 | sasl-mech = 1*20mech-char | |
| 187 | mech-char = %x41-5A / DIGIT / "-" / "_" | |
| 188 | ; mech names restricted to uppercase ASCII letters, | |
| 189 | ; digits, "-" and "_" | |
| 190 | ||
| 191 | ||
| 192 | 4.1. Authentication protocol exchange | |
| 193 | ||
| 194 | A SASL mechanism is responsible for conducting an authentication | |
| 195 | protocol exchange. This consists of a series of server challenges | |
| 196 | and client responses, the contents of which are specific to and | |
| 197 | defined by the mechanism. To the protocol, the challenges and | |
| 198 | responses are opaque binary tokens of arbitrary length. The | |
| 199 | protocol's profile then specifies how these binary tokens are then | |
| 200 | encoded for transfer over the connection. | |
| 201 | ||
| 202 | After receiving an authentication command or any client response, a | |
| 203 | server mechanism may issue a challenge, indicate failure, or indicate | |
| 204 | completion. The server mechanism may return additional data with a | |
| 205 | completion indication. The protocol's profile specifies how each of | |
| 206 | these is then represented over the connection. | |
| 207 | ||
| 208 | After receiving a challenge, a client mechanism may issue a response | |
| 209 | or abort the exchange. The protocol's profile specifies how each of | |
| 210 | these is then represented over the connection. | |
| 211 | ||
| 212 | During the authentication protocol exchange, the mechanism performs | |
| 213 | authentication, transmits an authorization identity (frequently known | |
| 214 | as a userid) from the client to server, and negotiates the use of a | |
| 215 | mechanism-specific security layer. If the use of a security layer is | |
| 216 | agreed upon, then the mechanism must also define or negotiate the | |
| 217 | maximum security layer buffer size that each side is able to receive. | |
| 218 | ||
| 219 | 4.2. Authorization identities and proxy authentication | |
| 220 | ||
| 221 | An authorization identity is a string of zero or more ISO 10646 | |
| 222 | [ISO-10646] coded characters. The NUL <U+0000> character is not | |
| 223 | permitted in authorization identities. The meaning of an | |
| 224 | authorization identity of the empty string (zero length) is defined | |
| 225 | below in this section. The authorization identity is used by the | |
| 226 | server as the primary identity for making access policy decisions. | |
| 227 | ||
| 228 | The character encoding scheme used (see [CHARSET-POLICY] for IETF | |
| 229 | policy regarding character sets in IETF protocols) for transmitting | |
| 230 | an authorization identity over protocol is specified in each | |
| 231 | authentication mechanism (with the authentication mechanism's data | |
| 232 | being further restricted/encoded by the protocol profile). | |
| 233 | Authentication mechanisms SHOULD encode these and other strings in | |
| 234 | ||
| 235 | ||
| 236 | ||
| 237 | A. Melnikov FORMFEED[Page 4] | |
| 238 | ||
| 239 | ||
| 240 | ||
| 241 | ||
| 242 | ||
| 243 | Internet DRAFT SASL 18 October 2003 | |
| 244 | ||
| 245 | ||
| 246 | UTF-8 [UTF-8]. While some legacy mechanisms are incapable of | |
| 247 | transmitting an authorization identity other than the empty string, | |
| 248 | newly defined mechanisms are expected to be capable of carrying the | |
| 249 | entire Unicode repertoire (with the exception of the NUL character). | |
| 250 | An authorization identity of the empty string and an absent | |
| 251 | authorization identity MUST be treated as equivalent. However, | |
| 252 | mechanisms SHOULD NOT allow both. That is, a mechanism which provides | |
| 253 | an optional field for an authorization identity, SHOULD NOT allow | |
| 254 | that field, when present, to be empty. | |
| 255 | ||
| 256 | The identity derived from the client's authentication credentials is | |
| 257 | known as the "authentication identity". With any mechanism, | |
| 258 | transmitting an authorization identity of the empty string directs | |
| 259 | the server to derive an authorization identity from the client's | |
| 260 | authentication identity. | |
| 261 | ||
| 262 | If the authorization identity transmitted during the authentication | |
| 263 | protocol exchange is not the empty string, this is typically referred | |
| 264 | to as "proxy authentication". This feature permits agents such as | |
| 265 | proxy servers to authenticate using their own credentials, yet | |
| 266 | request the access privileges of the identity for which they are | |
| 267 | proxying. | |
| 268 | ||
| 269 | The server makes an implementation defined policy decision as to | |
| 270 | whether the authentication identity is permitted to have the access | |
| 271 | privileges of the authorization identity and whether the | |
| 272 | authorization identity is permitted to receive service. If it is | |
| 273 | not, the server indicates failure of the authentication protocol | |
| 274 | exchange. | |
| 275 | ||
| 276 | As a client might not have the same information as the server, | |
| 277 | clients SHOULD NOT derive authorization identities from | |
| 278 | authentication identities. Instead, clients SHOULD provide no (or | |
| 279 | empty) authorization identity when the user has not provided an | |
| 280 | authorization identity. | |
| 281 | ||
| 282 | The server MUST verify that a received authorization identity is in | |
| 283 | the correct form. Profiles whose authorization identities are simple | |
| 284 | user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLPrep" profile | |
| 285 | [SASLPrep] of the "stringprep" algorithm [StringPrep] to prepare | |
| 286 | these names for matching. The profiles MAY use a stringprep profile | |
| 287 | that is more strict than "SASLPrep". If the preparation of the | |
| 288 | authorization identity fails or results in an empty string, the | |
| 289 | server MUST fail the authentication exchange. The only exception to | |
| 290 | this rule is when the received authorization identity is already the | |
| 291 | empty string. | |
| 292 | ||
| 293 | ||
| 294 | ||
| 295 | ||
| 296 | ||
| 297 | A. Melnikov FORMFEED[Page 5] | |
| 298 | ||
| 299 | ||
| 300 | ||
| 301 | ||
| 302 | ||
| 303 | Internet DRAFT SASL 18 October 2003 | |
| 304 | ||
| 305 | ||
| 306 | 4.3. Security layers | |
| 307 | ||
| 308 | If use of a security layer is negotiated by the authentication | |
| 309 | protocol exchange, the security layer is applied to all subsequent | |
| 310 | data sent over the connection (until another security layer or no | |
| 311 | security layer is negotiated; see also section 6.3). The security | |
| 312 | layer takes effect immediately following the last response of the | |
| 313 | authentication exchange for data sent by the client and the | |
| 314 | completion indication for data sent by the server. | |
| 315 | ||
| 316 | Once the security layer is in effect, the protocol stream is | |
| 317 | processed by the security layer into buffers of security encoded | |
| 318 | data. Each buffer of security encoded data is transferred over the | |
| 319 | connection as a stream of octets prepended with a four octet field in | |
| 320 | network byte order that represents the length of the following | |
| 321 | buffer. The length of the security encoded data buffer MUST be no | |
| 322 | larger than the maximum size that was either defined in the mechanism | |
| 323 | specification or negotiated by the other side during the | |
| 324 | authentication protocol exchange. Upon the receipt of a data buffer | |
| 325 | which is larger than the defined/negotiated maximal buffer size, the | |
| 326 | receiver SHOULD close the connection. This might be a sign of an | |
| 327 | attack or a buggy implementation. | |
| 328 | ||
| 329 | 4.4. Character string issues | |
| 330 | ||
| 331 | Authentication mechanisms SHOULD encode character strings in UTF-8 | |
| 332 | [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character | |
| 333 | sets in IETF protocols). In order to avoid noninteroperability due | |
| 334 | to differing normalizations, when a mechanism specifies that a string | |
| 335 | authentication identity or password used as input to a cryptographic | |
| 336 | function (or used for comparison) it SHOULD specify that the string | |
| 337 | first be prepared using the "SASLPrep" profile [SASLPrep] of the | |
| 338 | "stringprep" algorithm [StringPrep]. There are three entities that | |
| 339 | has to deal with this issue: a client (upon getting user input or | |
| 340 | retrieving a value from configuration), a server (upon receiving the | |
| 341 | value from the client) and a utility that is able to store | |
| 342 | passwords/hashes in a database that can be later used by the server. | |
| 343 | The preparation must be done by the client and the utility and may be | |
| 344 | done by the server. If preparation fails or results in an empty | |
| 345 | string, the entity doing the preparation SHALL fail the | |
| 346 | authentication exchange. | |
| 347 | ||
| 348 | ||
| 349 | 5. Protocol profile requirements | |
| 350 | ||
| 351 | In order to use this specification, a protocol definition MUST supply | |
| 352 | the following information: | |
| 353 | ||
| 354 | ||
| 355 | ||
| 356 | ||
| 357 | A. Melnikov FORMFEED[Page 6] | |
| 358 | ||
| 359 | ||
| 360 | ||
| 361 | ||
| 362 | ||
| 363 | Internet DRAFT SASL 18 October 2003 | |
| 364 | ||
| 365 | ||
| 366 | A service name, to be selected from the IANA registry of "service" | |
| 367 | elements for the GSSAPI host-based service name form [GSSAPI]. This | |
| 368 | service name is made available to the authentication mechanism. | |
| 369 | ||
| 370 | The registry is available at the URL | |
| 371 | <http://www.iana.org/assignments/gssapi-service-names>. | |
| 372 | ||
| 373 | A definition of the command to initiate the authentication protocol | |
| 374 | exchange. This command must have as a parameter the name of the | |
| 375 | mechanism being selected by the client. | |
| 376 | ||
| 377 | The command SHOULD have an optional parameter giving an initial | |
| 378 | response. This optional parameter allows the client to avoid a round | |
| 379 | trip when using a mechanism which is defined to have the client send | |
| 380 | data first. When this initial response is sent by the client and the | |
| 381 | selected mechanism is defined to have the server start with an | |
| 382 | initial challenge, the command fails. See section 6.1 of this | |
| 383 | document for further information. | |
| 384 | ||
| 385 | A definition of the method by which the authentication protocol | |
| 386 | exchange is carried out, including how the challenges and responses | |
| 387 | are encoded, how the server indicates completion or failure of the | |
| 388 | exchange, how the client aborts an exchange, and how the exchange | |
| 389 | method interacts with any line length limits in the protocol. | |
| 390 | ||
| 391 | The exchange method SHOULD allow the server to include an optional | |
| 392 | data ("optional challenge") with a success notification. This allows | |
| 393 | the server to avoid a round trip when using a mechanism which is | |
| 394 | defined to have the server send additional data along with the | |
| 395 | indication of successful completion. See section 6.2 of this | |
| 396 | document for further information. | |
| 397 | ||
| 398 | In addition, a protocol profile SHOULD specify a mechanism through | |
| 399 | which a client may obtain the names of the SASL mechanisms available | |
| 400 | to it. This is typically done through the protocol's extensions or | |
| 401 | capabilities mechanism. | |
| 402 | ||
| 403 | Identification of the octet where any negotiated security layer | |
| 404 | starts to take effect, in both directions. | |
| 405 | ||
| 406 | Specify if the protocol supports "multiple authentications" (see | |
| 407 | section 6.3). | |
| 408 | ||
| 409 | If both TLS and SASL security layer are allowed to be negotiated by | |
| 410 | the protocol, the protocol profile MUST define in which order they | |
| 411 | are applied to a cleartext data sent over the connection. | |
| 412 | ||
| 413 | A protocol profile MAY further refine the definition of an | |
| 414 | ||
| 415 | ||
| 416 | ||
| 417 | A. Melnikov FORMFEED[Page 7] | |
| 418 | ||
| 419 | ||
| 420 | ||
| 421 | ||
| 422 | ||
| 423 | Internet DRAFT SASL 18 October 2003 | |
| 424 | ||
| 425 | ||
| 426 | authorization identity by adding additional syntactic restrictions | |
| 427 | and protocol-specific semantics. A protocol profile MUST specify the | |
| 428 | form of the authorization identity (since it is protocol specific, as | |
| 429 | opposed to the authentication identity, which is mechanism specific) | |
| 430 | and how authorization identities are to be compared. Profiles whose | |
| 431 | authorization identities are simple user names (e.g. IMAP [RFC 3501]) | |
| 432 | SHOULD use "SASLPrep" profile [SASLPrep] of the "stringprep" | |
| 433 | algorithm [StringPrep] to prepare these names for matching. The | |
| 434 | profiles MAY use a stringprep profile that is more strict than | |
| 435 | SASLPrep. | |
| 436 | ||
| 437 | A protocol profile SHOULD NOT attempt to amend the definition of | |
| 438 | mechanisms or make mechanism-specific encodings. This breaks the | |
| 439 | separation between protocol and mechanism that is fundamental to the | |
| 440 | design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. | |
| 441 | ||
| 442 | 6. Specific issues | |
| 443 | ||
| 444 | 6.1. Client sends data first | |
| 445 | ||
| 446 | Some mechanisms specify that the first data sent in the | |
| 447 | authentication protocol exchange is from the client to the server. | |
| 448 | ||
| 449 | If a protocol's profile permits the command which initiates an | |
| 450 | authentication protocol exchange to contain an initial client | |
| 451 | response, this parameter SHOULD be used with such mechanisms. | |
| 452 | ||
| 453 | If the initial client response parameter is not given, or if a | |
| 454 | protocol's profile does not permit the command which initiates an | |
| 455 | authentication protocol exchange to contain an initial client | |
| 456 | response, then the server issues a challenge with no data. The | |
| 457 | client's response to this challenge is then used as the initial | |
| 458 | client response. (The server then proceeds to send the next | |
| 459 | challenge, indicates completion, or indicates failure.) | |
| 460 | ||
| 461 | 6.2. Server returns success with additional data | |
| 462 | ||
| 463 | Some mechanisms may specify that additional data be sent to the | |
| 464 | client along with an indication of successful completion of the | |
| 465 | exchange. This data would, for example, authenticate the server to | |
| 466 | the client. | |
| 467 | ||
| 468 | If a protocol's profile does not permit this additional data to be | |
| 469 | returned with a success indication, then the server issues the data | |
| 470 | as a server challenge, without an indication of successful | |
| 471 | completion. The client then responds with no data. After receiving | |
| 472 | this empty response, the server then indicates successful completion | |
| 473 | (with no additional data). | |
| 474 | ||
| 475 | ||
| 476 | ||
| 477 | A. Melnikov FORMFEED[Page 8] | |
| 478 | ||
| 479 | ||
| 480 | ||
| 481 | ||
| 482 | ||
| 483 | Internet DRAFT SASL 18 October 2003 | |
| 484 | ||
| 485 | ||
| 486 | Client implementors should be aware of an additional failure case | |
| 487 | that might occur when the profile supports sending the additional | |
| 488 | data with success. Imagine that an active attacker is trying to | |
| 489 | impersonate the server and sends faked data, which should be used to | |
| 490 | authenticate the server to the client, with success. (A similar | |
| 491 | situation can happen when either the server and/or the client has a | |
| 492 | bug and they calculate different responses.) After checking the data, | |
| 493 | the client will think that the authentication exchange has failed, | |
| 494 | however the server will think that the authentication exchange has | |
| 495 | completed successfully. At this point the client can not abort the | |
| 496 | authentication exchange, it SHOULD close the connection instead. | |
| 497 | However, if the profile did not support sending of additional data | |
| 498 | with success, the client could have aborted the exchange at the very | |
| 499 | last step of the authentication exchange. | |
| 500 | ||
| 501 | 6.3. Multiple authentications | |
| 502 | ||
| 503 | Unless otherwise stated by the protocol's profile, only one | |
| 504 | successful SASL negotiation may occur in a protocol session. In this | |
| 505 | case, once an authentication protocol exchange has successfully | |
| 506 | completed, further attempts to initiate an authentication protocol | |
| 507 | exchange fail. | |
| 508 | ||
| 509 | If a profile explicitly permits multiple successful SASL negotiations | |
| 510 | to occur, then in no case may multiple security layers be | |
| 511 | simultaneously in effect. If a security layer is in effect and a | |
| 512 | subsequent SASL negotiation selects a second security layer, then the | |
| 513 | second security layer replaces the first. If a security layer is in | |
| 514 | effect and a subsequent SASL negotiation selects no security layer, | |
| 515 | the original security layer MUST be removed. The next paragraphs | |
| 516 | explain why this is important. | |
| 517 | ||
| 518 | Let's assume that the protected resources on a server are partitioned | |
| 519 | into a set of protection spaces, each with its own authentication | |
| 520 | mechanisms and/or authorization database. Let's use the term "realm" | |
| 521 | to reference any such protected space. Conceptually, realm is a named | |
| 522 | collection of user's accounts. For example, a proxy/frontend can use | |
| 523 | different realms for different servers/backends it represents. | |
| 524 | ||
| 525 | Now consider the following scenario. A client has already | |
| 526 | authenticated and established a security layer with "Realm A" which | |
| 527 | is managed by the server AA. Now the same client authenticates to | |
| 528 | "Realm B" (managed by the server BB) without negotiating a new | |
| 529 | security layer, while the security layer negotiated with "Realm A" | |
| 530 | remains in effect. The server BB is now able observe how known | |
| 531 | cleartext is encrypted. This scenario enables the server BB to make | |
| 532 | guesses about previously observed ciphertext between the client and | |
| 533 | the server AA using the server's SASL engine as an oracle. This | |
| 534 | ||
| 535 | ||
| 536 | ||
| 537 | A. Melnikov FORMFEED[Page 9] | |
| 538 | ||
| 539 | ||
| 540 | ||
| 541 | ||
| 542 | ||
| 543 | Internet DRAFT SASL 18 October 2003 | |
| 544 | ||
| 545 | ||
| 546 | scenario is illustrated below: | |
| 547 | ||
| 548 | ||
| 549 | ||
| 550 | ||
| 551 | ||
| 552 | ||
| 553 | ||
| 554 | ||
| 555 | ||
| 556 | ||
| 557 | ||
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | ||
| 562 | ||
| 563 | ||
| 564 | ||
| 565 | ||
| 566 | ||
| 567 | ||
| 568 | ||
| 569 | ||
| 570 | ||
| 571 | ||
| 572 | ||
| 573 | ||
| 574 | ||
| 575 | ||
| 576 | ||
| 577 | ||
| 578 | ||
| 579 | ||
| 580 | ||
| 581 | ||
| 582 | ||
| 583 | ||
| 584 | ||
| 585 | ||
| 586 | ||
| 587 | ||
| 588 | ||
| 589 | ||
| 590 | ||
| 591 | ||
| 592 | ||
| 593 | ||
| 594 | ||
| 595 | ||
| 596 | ||
| 597 | A. Melnikov FORMFEED[Page 10] | |
| 598 | ||
| 599 | ||
| 600 | ||
| 601 | ||
| 602 | ||
| 603 | Internet DRAFT SASL 18 October 2003 | |
| 604 | ||
| 605 | ||
| 606 | +---------+ +---------+ | |
| 607 | | | | | | |
| 608 | | Realm B | | Realm A | | |
| 609 | | | | | | |
| 610 | +---------+ +---------+ | |
| 611 | | ^ | | |
| 612 | | : +-----------+ | | |
| 613 | Traffic from | : | Encryption| | Traffic from A | |
| 614 | B to client +-------->| end point |<-------+ to client | |
| 615 | : | (SSL/SASL)| | |
| 616 | : +-----------+ | |
| 617 | : | | |
| 618 | : | | |
| 619 | : +---+ | |
| 620 | : | | | |
| 621 | : | | | |
| 622 | : | | Encryption tunnel, e.g. SASL or SSL, | |
| 623 | : | | between the server | |
| 624 | (1) Recording +---------:| | and a single client only. | |
| 625 | encrypted | | Separate tunnels to different | |
| 626 | traffic between | | clients. | |
| 627 | Realm A and client +---+ | |
| 628 | | | |
| 629 | | | |
| 630 | +-----------> Traffic to clients | |
| 631 | ||
| 632 | 7. The EXTERNAL mechanism | |
| 633 | ||
| 634 | The mechanism name associated with external authentication is | |
| 635 | "EXTERNAL". | |
| 636 | ||
| 637 | The client sends an initial response with the UTF-8 encoding of the | |
| 638 | authorization identity. The form of the authorization identity is | |
| 639 | further restricted by the application-level protocol's SASL profile. | |
| 640 | ||
| 641 | The server uses information, external to SASL, to determine whether | |
| 642 | the client is authorized to authenticate as the authorization | |
| 643 | identity. If the client is so authorized, the server indicates | |
| 644 | successful completion of the authentication exchange; otherwise the | |
| 645 | server indicates failure. | |
| 646 | ||
| 647 | The system providing this external information may be, for example, | |
| 648 | IPSec or TLS. However, the client can make no assumptions as to what | |
| 649 | information the server can use in determining client authorization. | |
| 650 | E.g., just because TLS was established, doesn't mean that the server | |
| 651 | will use the information provided by TLS. | |
| 652 | ||
| 653 | If the client sends the empty string as the authorization identity | |
| 654 | ||
| 655 | ||
| 656 | ||
| 657 | A. Melnikov FORMFEED[Page 11] | |
| 658 | ||
| 659 | ||
| 660 | ||
| 661 | ||
| 662 | ||
| 663 | Internet DRAFT SASL 18 October 2003 | |
| 664 | ||
| 665 | ||
| 666 | (thus requesting that the authorization identity be derived from the | |
| 667 | client's authentication credentials), the authorization identity is | |
| 668 | to be derived from authentication credentials which exist in the | |
| 669 | system that is providing the external authentication. | |
| 670 | ||
| 671 | 7.1. Formal syntax | |
| 672 | ||
| 673 | The following syntax specification uses the augmented Backus-Naur | |
| 674 | Form (BNF) notation as specified in [ABNF]. This uses the ABNF core | |
| 675 | rules as specified in Appendix A of the ABNF specification [ABNF]. | |
| 676 | Non-terminals referenced but not defined below are as defined by | |
| 677 | [UTF-8]. | |
| 678 | ||
| 679 | The "extern-init-resp" rule below defines the initial response sent | |
| 680 | from client to server. | |
| 681 | ||
| 682 | extern-init-resp = *( UTF8-char-no-nul ) | |
| 683 | ||
| 684 | UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 | |
| 685 | ||
| 686 | UTF8-1-no-nul = %x01-7F | |
| 687 | ||
| 688 | ||
| 689 | 7.2. Example | |
| 690 | ||
| 691 | The following is an example of an EXTERNAL authentication in the SMTP | |
| 692 | protocol [SMTP]. In this example, the client is proxy | |
| 693 | authenticating, sending the authorization id "fred". The server has | |
| 694 | determined the client's identity through IPsec and has a security | |
| 695 | policy that permits that identity to proxy authenticate as any other | |
| 696 | identity. | |
| 697 | ||
| 698 | To the protocol profile, the four octet sequence "fred" is an opaque | |
| 699 | binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies | |
| 700 | that server challenges and client responses are encoded in BASE64 | |
| 701 | [BASE64]; the BASE64 encoding of "fred" is "ZnJlZA==". | |
| 702 | ||
| 703 | S: 220 smtp.example.com ESMTP server ready | |
| 704 | C: EHLO jgm.example.com | |
| 705 | S: 250-smtp.example.com | |
| 706 | S: 250 AUTH DIGEST-MD5 EXTERNAL | |
| 707 | C: AUTH EXTERNAL ZnJlZA== | |
| 708 | S: 235 Authentication successful. | |
| 709 | ||
| 710 | 8. IANA Considerations | |
| 711 | ||
| 712 | ||
| 713 | ||
| 714 | ||
| 715 | ||
| 716 | ||
| 717 | A. Melnikov FORMFEED[Page 12] | |
| 718 | ||
| 719 | ||
| 720 | ||
| 721 | ||
| 722 | ||
| 723 | Internet DRAFT SASL 18 October 2003 | |
| 724 | ||
| 725 | ||
| 726 | 8.1. Guidelines for IANA | |
| 727 | ||
| 728 | ||
| 729 | It is requested that IANA updates the SASL mechanisms registry as | |
| 730 | follows: | |
| 731 | ||
| 732 | ||
| 733 | Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism | |
| 734 | registrations to OBSOLETE. Change the "Published specification" | |
| 735 | of the EXTERNAL mechanism to this document. Updated registration | |
| 736 | is provided in Section 8.6. | |
| 737 | ||
| 738 | 8.2. Registration procedure | |
| 739 | ||
| 740 | ||
| 741 | Registration of a SASL mechanism is done by filling in the template | |
| 742 | in section 8.5 and sending it via electronic mail to <iana@iana.org>. | |
| 743 | IANA has the right to reject obviously bogus registrations, but will | |
| 744 | perform no review of claims made in the registration form. SASL | |
| 745 | mechanism registrations are currently available at the URL | |
| 746 | <http://www.iana.org/assignments/sasl-mechanisms>. | |
| 747 | ||
| 748 | There is no naming convention for SASL mechanisms; any name that | |
| 749 | conforms to the syntax of a SASL mechanism name can be registered. | |
| 750 | An IETF Standards Track document may reserve a portion of the SASL | |
| 751 | mechanism namespace ("family of SASL mechanisms") for its own use, | |
| 752 | amending the registration rules for that portion of the namespace. | |
| 753 | Each family of SASL mechanisms MUST be identified by a prefix. | |
| 754 | ||
| 755 | While the registration procedures do not require it, authors of SASL | |
| 756 | mechanisms are encouraged to seek community review and comment | |
| 757 | whenever that is feasible. Authors may seek community review by | |
| 758 | posting a specification of their proposed mechanism as an Internet- | |
| 759 | Draft. SASL mechanisms intended for widespread use should be | |
| 760 | standardized through the normal IETF process, when appropriate. | |
| 761 | ||
| 762 | 8.3. Comments on SASL mechanism registrations | |
| 763 | ||
| 764 | Comments on registered SASL mechanisms should first be sent to the | |
| 765 | "owner" of the mechanism and/or to the SASL WG mailing list. | |
| 766 | Submitters of comments may, after a reasonable attempt to contact the | |
| 767 | owner, request IANA to attach their comment to the SASL mechanism | |
| 768 | registration itself. If IANA approves of this, the comment will be | |
| 769 | made accessible in conjunction with the SASL mechanism registration | |
| 770 | itself. | |
| 771 | ||
| 772 | ||
| 773 | ||
| 774 | ||
| 775 | ||
| 776 | ||
| 777 | A. Melnikov FORMFEED[Page 13] | |
| 778 | ||
| 779 | ||
| 780 | ||
| 781 | ||
| 782 | ||
| 783 | Internet DRAFT SASL 18 October 2003 | |
| 784 | ||
| 785 | ||
| 786 | 8.4. Change control | |
| 787 | ||
| 788 | Once a SASL mechanism registration has been published by IANA, the | |
| 789 | author may request a change to its definition. The change request | |
| 790 | follows the same procedure as the registration request. | |
| 791 | ||
| 792 | The owner of a SASL mechanism may pass responsibility for the SASL | |
| 793 | mechanism to another person or agency by informing IANA; this can be | |
| 794 | done without discussion or review. | |
| 795 | ||
| 796 | The IESG may reassign responsibility for a SASL mechanism. The most | |
| 797 | common case of this will be to enable changes to be made to | |
| 798 | mechanisms where the author of the registration has died, moved out | |
| 799 | of contact or is otherwise unable to make changes that are important | |
| 800 | to the community. | |
| 801 | ||
| 802 | SASL mechanism registrations may not be deleted; mechanisms which are | |
| 803 | no longer believed appropriate for use can be declared OBSOLETE by a | |
| 804 | change to their "intended use" field; such SASL mechanisms will be | |
| 805 | clearly marked in the lists published by IANA. | |
| 806 | ||
| 807 | The IESG is considered to be the owner of all SASL mechanisms which | |
| 808 | are on the IETF standards track. | |
| 809 | ||
| 810 | 8.5. Registration template | |
| 811 | ||
| 812 | ||
| 813 | Subject: Registration of SASL mechanism X | |
| 814 | ||
| 815 | Family of SASL mechanisms: (YES or NO) | |
| 816 | ||
| 817 | SASL mechanism name (or prefix for the family): | |
| 818 | ||
| 819 | Security considerations: | |
| 820 | ||
| 821 | Published specification (optional, recommended): | |
| 822 | ||
| 823 | Person & email address to contact for further information: | |
| 824 | ||
| 825 | Intended usage: | |
| 826 | ||
| 827 | (One of COMMON, LIMITED USE or OBSOLETE) | |
| 828 | ||
| 829 | Owner/Change controller: | |
| 830 | ||
| 831 | (Any other information that the author deems interesting may be | |
| 832 | added below this line.) | |
| 833 | ||
| 834 | ||
| 835 | ||
| 836 | ||
| 837 | A. Melnikov FORMFEED[Page 14] | |
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | ||
| 842 | ||
| 843 | Internet DRAFT SASL 18 October 2003 | |
| 844 | ||
| 845 | ||
| 846 | 8.6. The EXTERNAL mechanism registration | |
| 847 | ||
| 848 | It is requested that the SASL Mechanism registry [IANA-SASL] entry | |
| 849 | for the EXTERNAL mechanism be updated to reflect that this document | |
| 850 | now provides its technical specification. | |
| 851 | ||
| 852 | ||
| 853 | Subject: Updated Registration of SASL mechanism EXTERNAL | |
| 854 | ||
| 855 | Family of SASL mechanisms: NO | |
| 856 | ||
| 857 | SASL mechanism name: EXTERNAL | |
| 858 | ||
| 859 | Security considerations: See RFC XXXX, section 9. | |
| 860 | ||
| 861 | Published specification (optional, recommended): RFC XXXX | |
| 862 | ||
| 863 | Person & email address to contact for further information: | |
| 864 | Alexey Melnikov <Alexey.Melnikov@isode.com> | |
| 865 | ||
| 866 | Intended usage: COMMON | |
| 867 | ||
| 868 | Owner/Change controller: IESG <iesg@ietf.org> | |
| 869 | ||
| 870 | Note: Updates existing entry for EXTERNAL | |
| 871 | ||
| 872 | 9. Security considerations | |
| 873 | ||
| 874 | Security issues are discussed throughout this memo. | |
| 875 | ||
| 876 | The mechanisms that support integrity protection are designed such | |
| 877 | that the negotiation of the security layer and authorization identity | |
| 878 | is integrity protected. When the client selects a security layer | |
| 879 | with at least integrity protection, this protects against an active | |
| 880 | attacker hijacking the connection and modifying the authentication | |
| 881 | exchange to negotiate a plaintext connection. | |
| 882 | ||
| 883 | When a server or client supports multiple authentication mechanisms, | |
| 884 | each of which has a different security strength, it is possible for | |
| 885 | an active attacker to cause a party to use the least secure mechanism | |
| 886 | supported. To protect against this sort of attack, a client or | |
| 887 | server which supports mechanisms of different strengths should have a | |
| 888 | configurable minimum strength that it will use. It is not sufficient | |
| 889 | for this minimum strength check to only be on the server, since an | |
| 890 | active attacker can change which mechanisms the client sees as being | |
| 891 | supported, causing the client to send authentication credentials for | |
| 892 | its weakest supported mechanism. | |
| 893 | ||
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | A. Melnikov FORMFEED[Page 15] | |
| 898 | ||
| 899 | ||
| 900 | ||
| 901 | ||
| 902 | ||
| 903 | Internet DRAFT SASL 18 October 2003 | |
| 904 | ||
| 905 | ||
| 906 | The client's selection of a SASL mechanism is done in the clear and | |
| 907 | may be modified by an active attacker. It is important for any new | |
| 908 | SASL mechanisms to be designed such that an active attacker cannot | |
| 909 | obtain an authentication with weaker security properties by modifying | |
| 910 | the SASL mechanism name and/or the challenges and responses. | |
| 911 | ||
| 912 | Any protocol interactions prior to authentication are performed in | |
| 913 | the clear and may be modified by an active attacker. In the case | |
| 914 | where a client selects integrity protection, it is important that any | |
| 915 | security-sensitive protocol negotiations be performed after | |
| 916 | authentication is complete. Protocols should be designed such that | |
| 917 | negotiations performed prior to authentication should be either | |
| 918 | ignored or revalidated once authentication is complete. | |
| 919 | ||
| 920 | When use of a security layer is negotiated by the authentication | |
| 921 | protocol exchange, the receiver should handle gracefully any security | |
| 922 | encoded data buffer larger than the defined/negotiated maximal size. | |
| 923 | In particular, it must not blindly allocate the amount of memory | |
| 924 | specified in the buffer size field, as this might cause the "out of | |
| 925 | memory" condition. If the receiver detects a large block, it SHOULD | |
| 926 | close the connection. | |
| 927 | ||
| 928 | "stringprep" and Unicode security considerations apply to | |
| 929 | authentication identities, authorization identities and passwords. | |
| 930 | ||
| 931 | The EXTERNAL mechanism provides no security protection; it is | |
| 932 | vulnerable to spoofing by either client or server, active attack, and | |
| 933 | eavesdropping. It should only be used when external security | |
| 934 | mechanisms are present and have sufficient strength. | |
| 935 | ||
| 936 | 10. References | |
| 937 | ||
| 938 | 10.1. Normative References | |
| 939 | ||
| 940 | [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: | |
| 941 | ABNF", RFC 2234, November 1997 | |
| 942 | ||
| 943 | [ASCII] American National Standards Institute, "Code Extension | |
| 944 | Techniques for Use with the 7-bit Coded Character Set of American | |
| 945 | National Standard Code (ASCII) for Information Interchange", FIPS PUB | |
| 946 | 35, 1974 | |
| 947 | ||
| 948 | [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and | |
| 949 | Languages", RFC 2277, January 1998 | |
| 950 | ||
| 951 | [GSSAPI] Linn, "Generic Security Service Application Program | |
| 952 | Interface, Version 2, Update 1", RFC 2743, January 2000 | |
| 953 | ||
| 954 | ||
| 955 | ||
| 956 | ||
| 957 | A. Melnikov FORMFEED[Page 16] | |
| 958 | ||
| 959 | ||
| 960 | ||
| 961 | ||
| 962 | ||
| 963 | Internet DRAFT SASL 18 October 2003 | |
| 964 | ||
| 965 | ||
| 966 | [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - | |
| 967 | Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. | |
| 968 | ||
| 969 | [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate | |
| 970 | Requirement Levels", RFC 2119, March 1997 | |
| 971 | ||
| 972 | [Unicode] The Unicode Consortium, "The Unicode Standard, Version | |
| 973 | 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, | |
| 974 | MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the | |
| 975 | "Unicode Standard Annex #27: Unicode 3.1" | |
| 976 | (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard | |
| 977 | Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). | |
| 978 | ||
| 979 | [Stringprep] P. Hoffman, M. Blanchet, "Preparation of | |
| 980 | Internationalized Strings ("stringprep")", RFC 3454, December 2002. | |
| 981 | ||
| 982 | [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names | |
| 983 | and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. | |
| 984 | ||
| 985 | [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work | |
| 986 | in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279, | |
| 987 | Janyary 1998 | |
| 988 | ||
| 989 | 10.2. Informative References | |
| 990 | ||
| 991 | <<Update the reference below>> [SASL-GSSAPI] Myers, J., "SASL GSSAPI | |
| 992 | mechanisms", work in progress, draft-ietf-cat-sasl-gssapi-XX.txt, | |
| 993 | September 2000 | |
| 994 | ||
| 995 | [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest | |
| 996 | Authentication as a SASL Mechanism", work in progress, draft-ietf- | |
| 997 | sasl-rfc2831bis-XX.txt, replaces RFC 2831 | |
| 998 | ||
| 999 | [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC | |
| 1000 | 2444, October 1998 | |
| 1001 | ||
| 1002 | [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April | |
| 1003 | 2001 | |
| 1004 | ||
| 1005 | [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", | |
| 1006 | RFC 2554, March 1999 | |
| 1007 | ||
| 1008 | [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data | |
| 1009 | Encodings", RFC 3548, July 2003 | |
| 1010 | ||
| 1011 | [RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC Authors", | |
| 1012 | RFC 2223, October 1997 | |
| 1013 | ||
| 1014 | ||
| 1015 | ||
| 1016 | ||
| 1017 | A. Melnikov FORMFEED[Page 17] | |
| 1018 | ||
| 1019 | ||
| 1020 | ||
| 1021 | ||
| 1022 | ||
| 1023 | Internet DRAFT SASL 18 October 2003 | |
| 1024 | ||
| 1025 | ||
| 1026 | [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) | |
| 1027 | MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. | |
| 1028 | ||
| 1029 | 11. Editor's Address | |
| 1030 | ||
| 1031 | Alexey Melnikov | |
| 1032 | Isode | |
| 1033 | ||
| 1034 | Email: Alexey.Melnikov@isode.com | |
| 1035 | ||
| 1036 | 12. Acknowledgments | |
| 1037 | ||
| 1038 | This document is a revision of RFC 2222 written by John G. Myers. He | |
| 1039 | also contributed significantly to this revision. | |
| 1040 | ||
| 1041 | Magnus Nystrom provided the ASCII art used in Section 6.3. | |
| 1042 | ||
| 1043 | Definition of realm was extracted from RFC 2617 ("HTTP | |
| 1044 | Authentication: Basic and Digest Access Authentication"). | |
| 1045 | ||
| 1046 | Contributions of many members of the SASL mailing list are gratefully | |
| 1047 | acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob | |
| 1048 | Siemborski, Jeffrey Hutzelman and Hallvard B Furuseth for | |
| 1049 | proofreading the document and various editorial suggestions. | |
| 1050 | ||
| 1051 | ||
| 1052 | 13. Full Copyright Statement | |
| 1053 | ||
| 1054 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 1055 | ||
| 1056 | This document and translations of it may be copied and furnished to | |
| 1057 | others, and derivative works that comment on or otherwise explain it | |
| 1058 | or assist in its implementation may be prepared, copied, published | |
| 1059 | and distributed, in whole or in part, without restriction of any | |
| 1060 | kind, provided that the above copyright notice and this paragraph are | |
| 1061 | included on all such copies and derivative works. However, this | |
| 1062 | document itself may not be modified in any way, such as by removing | |
| 1063 | the copyright notice or references to the Internet Society or other | |
| 1064 | Internet organizations, except as needed for the purpose of | |
| 1065 | developing Internet standards in which case the procedures for | |
| 1066 | copyrights defined in the Internet Standards process must be | |
| 1067 | followed, or as required to translate it into languages other than | |
| 1068 | English. | |
| 1069 | ||
| 1070 | The limited permissions granted above are perpetual and will not be | |
| 1071 | revoked by the Internet Society or its successors or assigns. | |
| 1072 | ||
| 1073 | This document and the information contained herein is provided on an | |
| 1074 | ||
| 1075 | ||
| 1076 | ||
| 1077 | A. Melnikov FORMFEED[Page 18] | |
| 1078 | ||
| 1079 | ||
| 1080 | ||
| 1081 | ||
| 1082 | ||
| 1083 | Internet DRAFT SASL 18 October 2003 | |
| 1084 | ||
| 1085 | ||
| 1086 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 1087 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 1088 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 1089 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 1090 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 1091 | ||
| 1092 | Acknowledgement | |
| 1093 | ||
| 1094 | Funding for the RFC Editor function is currently provided by the | |
| 1095 | Internet Society. | |
| 1096 | ||
| 1097 | Appendix A. Relation of SASL to transport security | |
| 1098 | ||
| 1099 | Questions have been raised about the relationship between SASL and | |
| 1100 | various services (such as IPsec and TLS) which provide a secured | |
| 1101 | connection. | |
| 1102 | ||
| 1103 | Two of the key features of SASL are: | |
| 1104 | ||
| 1105 | The separation of the authorization identity from the identity in | |
| 1106 | the client's credentials. This permits agents such as proxy | |
| 1107 | servers to authenticate using their own credentials, yet request | |
| 1108 | the access privileges of the identity for which they are proxying. | |
| 1109 | ||
| 1110 | Upon successful completion of an authentication exchange, the | |
| 1111 | server knows the authorization identity the client wishes to use. | |
| 1112 | This allows servers to move to a "user is authenticated" state in | |
| 1113 | the protocol. | |
| 1114 | ||
| 1115 | These features are extremely important to some application protocols, | |
| 1116 | yet Transport Security services do not always provide them. To | |
| 1117 | define SASL mechanisms based on these services would be a very messy | |
| 1118 | task, as the framing of these services would be redundant with the | |
| 1119 | framing of SASL and some method of providing these important SASL | |
| 1120 | features would have to be devised. | |
| 1121 | ||
| 1122 | Sometimes it is desired to enable within an existing connection the | |
| 1123 | use of a security service which does not fit the SASL model. (TLS is | |
| 1124 | an example of such a service.) This can be done by adding a command, | |
| 1125 | for example "STARTTLS", to the protocol. Such a command is outside | |
| 1126 | the scope of SASL, and should be different from the command which | |
| 1127 | starts a SASL authentication protocol exchange. | |
| 1128 | ||
| 1129 | In certain situations, it is reasonable to use SASL underneath one of | |
| 1130 | these Transport Security services. The transport service would | |
| 1131 | secure the connection, either service would authenticate the client, | |
| 1132 | and SASL would negotiate the authorization identity. The SASL | |
| 1133 | negotiation would be what moves the protocol from "unauthenticated" | |
| 1134 | ||
| 1135 | ||
| 1136 | ||
| 1137 | A. Melnikov FORMFEED[Page 19] | |
| 1138 | ||
| 1139 | ||
| 1140 | ||
| 1141 | ||
| 1142 | ||
| 1143 | Internet DRAFT SASL 18 October 2003 | |
| 1144 | ||
| 1145 | ||
| 1146 | to "authenticated" state. The "EXTERNAL" SASL mechanism is | |
| 1147 | explicitly intended to handle the case where the transport service | |
| 1148 | secures the connection and authenticates the client and SASL | |
| 1149 | negotiates the authorization identity. | |
| 1150 | ||
| 1151 | Appendix B. Changes since RFC 2222 | |
| 1152 | ||
| 1153 | The GSSAPI mechanism was removed. It is now specified in a separate | |
| 1154 | document [SASL-GSSAPI]. | |
| 1155 | ||
| 1156 | The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has | |
| 1157 | been removed. | |
| 1158 | ||
| 1159 | The "SKEY" mechanism described in RFC 2222 is obsolete and has been | |
| 1160 | removed. It has been replaced by the OTP mechanism [SASL-OTP]. | |
| 1161 | ||
| 1162 | The overview has been substantially reorganized and clarified. | |
| 1163 | ||
| 1164 | Clarified the definition and semantics of the authorization identity. | |
| 1165 | ||
| 1166 | Prohibited the NUL character in authorization identities. | |
| 1167 | ||
| 1168 | Added a section on character string issues. | |
| 1169 | ||
| 1170 | The word "must" in the first paragraph of the "Protocol profile | |
| 1171 | requirements" section was changed to "MUST". | |
| 1172 | ||
| 1173 | Specified that protocol profiles SHOULD provide a way for clients to | |
| 1174 | discover available SASL mechanisms. | |
| 1175 | ||
| 1176 | Made the requirement that protocol profiles specify the semantics of | |
| 1177 | the authorization identity optional to the protocol profile. | |
| 1178 | Clarified that such a specification is a refinement of the definition | |
| 1179 | in the base SASL spec. | |
| 1180 | ||
| 1181 | Added a requirement discouraging protocol profiles from breaking the | |
| 1182 | separation between protocol and mechanism. | |
| 1183 | ||
| 1184 | Mentioned that standards track documents may carve out their own | |
| 1185 | portions of the SASL mechanism namespace and may amend registration | |
| 1186 | rules for the portion. However registration of individual SASL | |
| 1187 | mechanisms is still required. | |
| 1188 | ||
| 1189 | Specified that the authorization identity in the EXTERNAL mechanism | |
| 1190 | is encoded in UTF-8. | |
| 1191 | ||
| 1192 | Added a statement that a protocol profile SHOULD allow challenge data | |
| 1193 | to be sent with a success indication. | |
| 1194 | ||
| 1195 | ||
| 1196 | ||
| 1197 | A. Melnikov FORMFEED[Page 20] | |
| 1198 | ||
| 1199 | ||
| 1200 | ||
| 1201 | ||
| 1202 | ||
| 1203 | Internet DRAFT SASL 18 October 2003 | |
| 1204 | ||
| 1205 | ||
| 1206 | Added a security consideration for the EXTERNAL mechansim. | |
| 1207 | ||
| 1208 | Clarified sections concerning success with additional data. | |
| 1209 | ||
| 1210 | Cleaned up IANA considerations/registrations and assembled them in | |
| 1211 | one place. | |
| 1212 | ||
| 1213 | Updated references and split them into Informative and Normative. | |
| 1214 | ||
| 1215 | Added text to the Security Considerations section regarding handling | |
| 1216 | of extremely large SASL blocks. | |
| 1217 | ||
| 1218 | Replaced UTF-8 ABNF with the reference to the UTF-8 document. | |
| 1219 | ||
| 1220 | Added text about SASLPrep for authentication identities and | |
| 1221 | passwords. Described where SASLPrep preparation should take place. | |
| 1222 | ||
| 1223 | Added paragraph about verifying authorization identities. | |
| 1224 | ||
| 1225 | This document requires to drop a security layer on reauthentication | |
| 1226 | when no security layer is negotiated. This differs from RFC 2222, | |
| 1227 | which required to keep the last security layer in this case. | |
| 1228 | ||
| 1229 | Added a protocol profile requirement to specify interaction between | |
| 1230 | SASL and TLS security layers. | |
| 1231 | ||
| 1232 | Added a protocol profile requirement to specify if it supports | |
| 1233 | reauthentication. | |
| 1234 | ||
| 1235 | Removed the text that seemed to suggest that SASL security layer must | |
| 1236 | not be used when TLS is available. | |
| 1237 | ||
| 1238 | ||
| 1239 | ||
| 1240 | ||
| 1241 | ||
| 1242 | ||
| 1243 | ||
| 1244 | ||
| 1245 | ||
| 1246 | ||
| 1247 | ||
| 1248 | ||
| 1249 | ||
| 1250 | ||
| 1251 | ||
| 1252 | ||
| 1253 | ||
| 1254 | ||
| 1255 | ||
| 1256 | ||
| 1257 | A. Melnikov FORMFEED[Page 21] | |
| 1258 | ||
| 1259 | ||
| 1260 | ||
| 1261 | ||
| 1262 | ||
| 1263 | Internet DRAFT SASL 18 October 2003 | |
| 1264 | ||
| 1265 | ||
| 1266 | Status of this Memo .......................................... i | |
| 1267 | 1. Abstract ............................................... 2 | |
| 1268 | 2. Organization of this document .......................... 2 | |
| 1269 | 2.1. How to read this document .............................. 2 | |
| 1270 | 2.2. Conventions used in this document ...................... 2 | |
| 1271 | 3. Overview ............................................... 3 | |
| 1272 | 4. Authentication mechanisms .............................. 3 | |
| 1273 | 4.1. Authentication protocol exchange ....................... 4 | |
| 1274 | 4.2. Authorization identities and proxy authentication ...... 4 | |
| 1275 | 4.3. Security layers ........................................ 6 | |
| 1276 | 4.4. Character string issues ................................ 6 | |
| 1277 | 5. Protocol profile requirements .......................... 6 | |
| 1278 | 6. Specific issues ........................................ 8 | |
| 1279 | 6.1. Client sends data first ................................ 8 | |
| 1280 | 6.2. Server returns success with additional data ............ 8 | |
| 1281 | 6.3. Multiple authentications ............................... 9 | |
| 1282 | 7. The EXTERNAL mechanism ................................ 11 | |
| 1283 | 7.1. Formal syntax ......................................... 12 | |
| 1284 | 7.2. Example ............................................... 12 | |
| 1285 | 8. IANA Considerations ................................... 12 | |
| 1286 | 8.1. Guidelines for IANA ................................... 13 | |
| 1287 | 8.2. Registration procedure ................................ 13 | |
| 1288 | 8.3. Comments on SASL mechanism registrations .............. 13 | |
| 1289 | 8.4. Change control ........................................ 14 | |
| 1290 | 8.5. Registration template ................................. 14 | |
| 1291 | 8.6. The EXTERNAL mechanism registration ................... 15 | |
| 1292 | 9. Security considerations ................................ 15 | |
| 1293 | 10. References ........................................... 16 | |
| 1294 | 10.1. Normative References ................................. 16 | |
| 1295 | 10.2. Informative References ............................... 17 | |
| 1296 | 11. Editor's Address ...................................... 18 | |
| 1297 | 12. Acknowledgments ....................................... 18 | |
| 1298 | 13. Full Copyright Statement .............................. 18 | |
| 1299 | Appendix A. Relation of SASL to transport security .......... 19 | |
| 1300 | Appendix B. Changes since RFC 2222 .......................... 20 | |
| 1301 | ||
| 1302 | ||
| 1303 | ||
| 1304 | ||
| 1305 | ||
| 1306 | ||
| 1307 | ||
| 1308 | ||
| 1309 | ||
| 1310 | ||
| 1311 | ||
| 1312 | ||
| 1313 | ||
| 1314 | ||
| 1315 | ||
| 1316 | ||
| 1317 | A. Melnikov FORMFEED[Page ii] | |
| 1318 | ||
| 1319 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | INTERNET-DRAFT P. Leach | |
| 7 | Obsoletes: 2831 Microsoft | |
| 8 | Intended category: Standards track C. Newman | |
| 9 | Sun Microsystems | |
| 10 | A. Melnikov | |
| 11 | Isode | |
| 12 | June 2003 | |
| 13 | ||
| 14 | Using Digest Authentication as a SASL Mechanism | |
| 15 | draft-ietf-sasl-rfc2831bis-02.txt | |
| 16 | ||
| 17 | Status of this Memo | |
| 18 | ||
| 19 | This document is an Internet-Draft and is in full conformance with | |
| 20 | all provisions of Section 10 of RFC 2026. | |
| 21 | ||
| 22 | Internet-Drafts are working documents of the Internet Engineering | |
| 23 | Task Force (IETF), its areas, and its working groups. Note that other | |
| 24 | groups may also distribute working documents as Internet-Drafts. | |
| 25 | ||
| 26 | Internet-Drafts are draft documents valid for a maximum of six months | |
| 27 | and may be updated, replaced, or obsoleted by other documents at any | |
| 28 | time. It is inappropriate to use Internet-Drafts as reference | |
| 29 | material or to cite them other than as "work in progress." | |
| 30 | ||
| 31 | The list of current Internet-Drafts can be accessed at | |
| 32 | http://www.ietf.org/ietf/1id-abstracts.txt | |
| 33 | ||
| 34 | The list of Internet-Draft Shadow Directories can be accessed at | |
| 35 | http://www.ietf.org/shadow.html. | |
| 36 | ||
| 37 | Copyright Notice | |
| 38 | ||
| 39 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 40 | ||
| 41 | Abstract | |
| 42 | ||
| 43 | This specification defines how HTTP Digest Authentication [Digest] | |
| 44 | can be used as a SASL [RFC 2222] mechanism for any protocol that has | |
| 45 | a SASL profile. It is intended both as an improvement over CRAM-MD5 | |
| 46 | [RFC 2195] and as a convenient way to support a single authentication | |
| 47 | mechanism for web, mail, LDAP, and other protocols. | |
| 48 | ||
| 49 | ||
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Leach & Newman Expires: December 2003 [Page 1] | |
| 58 | ||
| 59 | ||
| 60 | ||
| 61 | ||
| 62 | ||
| 63 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 64 | ||
| 65 | ||
| 66 | Table of Contents | |
| 67 | ||
| 68 | 1 INTRODUCTION.....................................................3 | |
| 69 | 1.1 CONVENTIONS AND NOTATION......................................3 | |
| 70 | 1.2 REQUIREMENTS..................................................4 | |
| 71 | 2 AUTHENTICATION...................................................5 | |
| 72 | 2.1 INITIAL AUTHENTICATION........................................5 | |
| 73 | 2.1.1 Step One...................................................5 | |
| 74 | 2.1.2 Step Two...................................................9 | |
| 75 | 2.1.3 Step Three................................................16 | |
| 76 | 2.2 SUBSEQUENT AUTHENTICATION....................................17 | |
| 77 | 2.2.1 Step one..................................................17 | |
| 78 | 2.2.2 Step Two..................................................17 | |
| 79 | 2.3 INTEGRITY PROTECTION.........................................18 | |
| 80 | 2.4 CONFIDENTIALITY PROTECTION...................................18 | |
| 81 | 3 SECURITY CONSIDERATIONS.........................................21 | |
| 82 | 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........21 | |
| 83 | 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................21 | |
| 84 | 3.3 REPLAY ATTACKS...............................................21 | |
| 85 | 3.4 ONLINE DICTIONARY ATTACKS....................................22 | |
| 86 | 3.5 OFFLINE DICTIONARY ATTACKS...................................22 | |
| 87 | 3.6 MAN IN THE MIDDLE............................................22 | |
| 88 | 3.7 CHOSEN PLAINTEXT ATTACKS.....................................22 | |
| 89 | 3.8 CBC MODE ATTACKS............................................. | |
| 90 | 3.9 SPOOFING BY COUNTERFEIT SERVERS..............................23 | |
| 91 | 3.10 STORING PASSWORDS...........................................23 | |
| 92 | 3.11 MULTIPLE REALMS.............................................24 | |
| 93 | 3.12 SUMMARY.....................................................24 | |
| 94 | 4 EXAMPLE.........................................................24 | |
| 95 | 5 REFERENCES......................................................26 | |
| 96 | 5.1 NORMATIVE REFERENCES.........................................26 | |
| 97 | 5.2 INFORMATIVE REFERENCES.......................................27 | |
| 98 | 6 AUTHORS' ADDRESSES..............................................28 | |
| 99 | 7 ABNF............................................................29 | |
| 100 | 7.1 AUGMENTED BNF................................................29 | |
| 101 | 7.2 BASIC RULES..................................................31 | |
| 102 | 8 SAMPLE CODE.....................................................33 | |
| 103 | 9 INTEROPERABILITY CONSIDERATIONS.................................34 | |
| 104 | 9.1 Implementing DES cipher in CBC mode..........................34 | |
| 105 | 10 ACKNOWLEDGEMENTS..............................................34 | |
| 106 | 11 FULL COPYRIGHT STATEMENT.......................................35 | |
| 107 | Appendix A: Changes from 2831.....................................36 | |
| 108 | Appendix B: Open Issues...........................................37 | |
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | ||
| 114 | ||
| 115 | ||
| 116 | ||
| 117 | Leach & Newman Expires: December 2003 [Page 2] | |
| 118 | ||
| 119 | ||
| 120 | ||
| 121 | ||
| 122 | ||
| 123 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 124 | ||
| 125 | ||
| 126 | 1 Introduction | |
| 127 | ||
| 128 | This specification describes the use of HTTP Digest Access | |
| 129 | Authentication as a SASL mechanism. The authentication type | |
| 130 | associated with the Digest SASL mechanism is "DIGEST-MD5". | |
| 131 | ||
| 132 | This specification is intended to be upward compatible with the | |
| 133 | "md5-sess" algorithm of HTTP/1.1 Digest Access Authentication | |
| 134 | specified in [Digest]. The only difference in the "md5-sess" | |
| 135 | algorithm is that some directives not needed in a SASL mechanism have | |
| 136 | had their values defaulted. | |
| 137 | ||
| 138 | There is one new feature for use as a SASL mechanism: integrity | |
| 139 | protection on application protocol messages after an authentication | |
| 140 | exchange. | |
| 141 | ||
| 142 | Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext | |
| 143 | attacks, and permits the use of third party authentication servers, | |
| 144 | mutual authentication, and optimized reauthentication if a client has | |
| 145 | recently authenticated to a server. | |
| 146 | ||
| 147 | 1.1 Conventions and Notation | |
| 148 | ||
| 149 | This specification uses the same ABNF notation and lexical | |
| 150 | conventions as HTTP/1.1 specification; see section 7. | |
| 151 | ||
| 152 | Let { a, b, ... } be the concatenation of the octet strings a, b, ... | |
| 153 | ||
| 154 | Let ** denote the power operation. | |
| 155 | ||
| 156 | Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s. | |
| 157 | ||
| 158 | Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string | |
| 159 | k, a colon and the string s. | |
| 160 | ||
| 161 | Let HEX(n) be the representation of the 16 octet MD5 hash n as a | |
| 162 | string of 32 hex digits (with alphabetic characters always in lower | |
| 163 | case, since MD5 is case sensitive). | |
| 164 | ||
| 165 | Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet | |
| 166 | string s using the octet string k as a key. | |
| 167 | ||
| 168 | ||
| 169 | ||
| 170 | ||
| 171 | ||
| 172 | ||
| 173 | ||
| 174 | ||
| 175 | ||
| 176 | ||
| 177 | Leach & Newman Expires: December 2003 [Page 3] | |
| 178 | ||
| 179 | ||
| 180 | ||
| 181 | ||
| 182 | ||
| 183 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 184 | ||
| 185 | ||
| 186 | Let unq(X) be the value of the quoted-string X without the | |
| 187 | surrounding quotes and with all escape characters "\\" removed. For | |
| 188 | example for the quoted-string "Babylon" the value of unq("Babylon") | |
| 189 | is Babylon; for the quoted string "ABC\"123\\" the value of | |
| 190 | unq("ABC\"123\\") is ABC"123\. | |
| 191 | ||
| 192 | The value of a quoted string constant as an octet string does not | |
| 193 | include any terminating null character. | |
| 194 | ||
| 195 | 1.2 Requirements | |
| 196 | ||
| 197 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
| 198 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
| 199 | document are to be interpreted as described in RFC 2119 [RFC 2119]. | |
| 200 | ||
| 201 | An implementation is not compliant if it fails to satisfy one or more | |
| 202 | of the MUST level requirements for the protocols it implements. An | |
| 203 | implementation that satisfies all the MUST level and all the SHOULD | |
| 204 | level requirements for its protocols is said to be "unconditionally | |
| 205 | compliant"; one that satisfies all the MUST level requirements but | |
| 206 | not all the SHOULD level requirements for its protocols is said to be | |
| 207 | "conditionally compliant." | |
| 208 | ||
| 209 | ||
| 210 | ||
| 211 | ||
| 212 | ||
| 213 | ||
| 214 | ||
| 215 | ||
| 216 | ||
| 217 | ||
| 218 | ||
| 219 | ||
| 220 | ||
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | ||
| 226 | ||
| 227 | ||
| 228 | ||
| 229 | ||
| 230 | ||
| 231 | ||
| 232 | ||
| 233 | ||
| 234 | ||
| 235 | ||
| 236 | ||
| 237 | Leach & Newman Expires: December 2003 [Page 4] | |
| 238 | ||
| 239 | ||
| 240 | ||
| 241 | ||
| 242 | ||
| 243 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 244 | ||
| 245 | ||
| 246 | 2 Authentication | |
| 247 | ||
| 248 | The following sections describe how to use Digest as a SASL | |
| 249 | authentication mechanism. | |
| 250 | ||
| 251 | 2.1 Initial Authentication | |
| 252 | ||
| 253 | If the client has not recently authenticated to the server, then it | |
| 254 | must perform "initial authentication", as defined in this section. If | |
| 255 | it has recently authenticated, then a more efficient form is | |
| 256 | available, defined in the next section. | |
| 257 | ||
| 258 | 2.1.1 Step One | |
| 259 | ||
| 260 | The server starts by sending a challenge. The data encoded in the | |
| 261 | challenge contains a string formatted according to the rules for a | |
| 262 | "digest-challenge" defined as follows: | |
| 263 | ||
| 264 | ||
| 265 | ||
| 266 | ||
| 267 | ||
| 268 | ||
| 269 | ||
| 270 | ||
| 271 | ||
| 272 | ||
| 273 | ||
| 274 | ||
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | ||
| 282 | ||
| 283 | ||
| 284 | ||
| 285 | ||
| 286 | ||
| 287 | ||
| 288 | ||
| 289 | ||
| 290 | ||
| 291 | ||
| 292 | ||
| 293 | ||
| 294 | ||
| 295 | ||
| 296 | ||
| 297 | Leach & Newman Expires: December 2003 [Page 5] | |
| 298 | ||
| 299 | ||
| 300 | ||
| 301 | ||
| 302 | ||
| 303 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 304 | ||
| 305 | ||
| 306 | digest-challenge = | |
| 307 | 1#( realm | nonce | qop-options | stale | server_maxbuf | charset | |
| 308 | algorithm | cipher-opts | auth-param ) | |
| 309 | ||
| 310 | realm = "realm" "=" <"> realm-value <"> | |
| 311 | realm-value = qdstr-val | |
| 312 | nonce = "nonce" "=" <"> nonce-value <"> | |
| 313 | nonce-value = *qdtext | |
| 314 | qop-options = "qop" "=" <"> qop-list <"> | |
| 315 | qop-list = 1#qop-value | |
| 316 | qop-value = "auth" | "auth-int" | "auth-conf" | | |
| 317 | token | |
| 318 | stale = "stale" "=" "true" | |
| 319 | server_maxbuf = "maxbuf" "=" maxbuf-value | |
| 320 | maxbuf-value = 1*DIGIT | |
| 321 | charset = "charset" "=" "utf-8" | |
| 322 | algorithm = "algorithm" "=" "md5-sess" | |
| 323 | cipher-opts = "cipher" "=" <"> 1#cipher-value <"> | |
| 324 | cipher-value = "3des" | "des" | "rc4-40" | "rc4" | | |
| 325 | "rc4-56" | "aes" | token | |
| 326 | auth-param = token "=" ( token | quoted-string ) | |
| 327 | ||
| 328 | The meanings of the values of the directives used above are as | |
| 329 | follows: | |
| 330 | ||
| 331 | realm | |
| 332 | Mechanistically, a string which can enable users to know which | |
| 333 | username and password to use, in case they might have different | |
| 334 | ones for different servers. Conceptually, it is the name of a | |
| 335 | collection of accounts that might include the user's account. This | |
| 336 | string should contain at least the name of the host performing the | |
| 337 | authentication and might additionally indicate the collection of | |
| 338 | users who might have access. An example might be | |
| 339 | "registered_users@gotham.news.example.com". This directive is | |
| 340 | optional; if not present, the client SHOULD solicit it from the | |
| 341 | user or be able to compute a default; a plausible default might be | |
| 342 | the realm supplied by the user when they logged in to the client | |
| 343 | system. Multiple realm directives are allowed, in which case the | |
| 344 | user or client must choose one as the realm for which to supply to | |
| 345 | username and password. | |
| 346 | ||
| 347 | If at least one realm is present and the charset directive is also | |
| 348 | specified (which means that realm(s) are encoded as UTF-8), the | |
| 349 | client should prepare each instance of realm using the "SASLPrep" | |
| 350 | profile [SASLPrep] of the "stringprep" algorithm [StringPrep]. If | |
| 351 | preparation of a realm instance fails or results in an empty | |
| 352 | string, the client should abort the authentication exchange. | |
| 353 | ||
| 354 | ||
| 355 | ||
| 356 | ||
| 357 | Leach & Newman Expires: December 2003 [Page 6] | |
| 358 | ||
| 359 | ||
| 360 | ||
| 361 | ||
| 362 | ||
| 363 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 364 | ||
| 365 | ||
| 366 | nonce | |
| 367 | A server-specified data string which MUST be different each time a | |
| 368 | digest-challenge is sent as part of initial authentication. It is | |
| 369 | recommended that this string be base64 or hexadecimal data. Note | |
| 370 | that since the string is passed as a quoted string, the | |
| 371 | double-quote character is not allowed unless escaped (see section | |
| 372 | 7.2). The contents of the nonce are implementation dependent. The | |
| 373 | security of the implementation depends on a good choice. It is | |
| 374 | RECOMMENDED that it contain at least 64 bits of entropy. The nonce | |
| 375 | is opaque to the client. This directive is required and MUST | |
| 376 | appear exactly once; if not present, or if multiple instances are | |
| 377 | present, the client should abort the authentication exchange. | |
| 378 | ||
| 379 | qop-options | |
| 380 | A quoted string of one or more tokens indicating the "quality of | |
| 381 | protection" values supported by the server. The value "auth" | |
| 382 | indicates authentication; the value "auth-int" indicates | |
| 383 | authentication with integrity protection; the value "auth-conf" | |
| 384 | indicates authentication with integrity protection and encryption. | |
| 385 | This directive is optional; if not present it defaults to "auth". | |
| 386 | The client MUST ignore unrecognized options; if the client | |
| 387 | recognizes no option, it should abort the authentication exchange. | |
| 388 | ||
| 389 | stale | |
| 390 | The "stale" directive is not used in initial authentication. See | |
| 391 | the next section for its use in subsequent authentications. This | |
| 392 | directive may appear at most once; if multiple instances are | |
| 393 | present, the client should abort the authentication exchange. | |
| 394 | ||
| 395 | server_maxbuf ("maximal ciphertext buffer size") | |
| 396 | A number indicating the size of the largest buffer the server is | |
| 397 | able to receive when using "auth-int" or "auth-conf". The value | |
| 398 | MUST be bigger than 16 and smaller or equal to 16777215 (i.e. | |
| 399 | 2**24-1). If this directive is missing, the default value is | |
| 400 | 65536. This directive may appear at most once; if multiple | |
| 401 | instances are present, the client MUST abort the authentication | |
| 402 | exchange. | |
| 403 | ||
| 404 | Let call "maximal cleartext buffer size" (or "maximal sender | |
| 405 | size") the maximal size of a cleartext buffer that, after being | |
| 406 | transformed by integrity (section 2.3) or confidentiality (section | |
| 407 | 2.4) protection function, will produce a SASL block of the maxbuf | |
| 408 | size. As it should be clear from the name, the sender MUST never | |
| 409 | pass a block of data bigger than the "maximal sender size" through | |
| 410 | the selected protection function. This will guaranty that the | |
| 411 | receiver will never get a block bigger than the maxbuf. | |
| 412 | ||
| 413 | ||
| 414 | ||
| 415 | ||
| 416 | ||
| 417 | Leach & Newman Expires: December 2003 [Page 7] | |
| 418 | ||
| 419 | ||
| 420 | ||
| 421 | ||
| 422 | ||
| 423 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 424 | ||
| 425 | ||
| 426 | charset | |
| 427 | This directive, if present, specifies that the server supports | |
| 428 | UTF-8 [UTF-8] encoding for the username, realm and password. If | |
| 429 | present, the username, realm and password are in Unicode, prepared | |
| 430 | using the "SASLPrep" profile [SASLPrep] of the "stringprep" | |
| 431 | algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not | |
| 432 | present, the username, realm and password MUST be encoded in ISO | |
| 433 | 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset). The | |
| 434 | directive is needed for backwards compatibility with HTTP Digest, | |
| 435 | which only supports ISO 8859-1. This directive may appear at most | |
| 436 | once; if multiple instances are present, the client should abort | |
| 437 | the authentication exchange. | |
| 438 | ||
| 439 | Note, that this directive doesn't affect authorization id | |
| 440 | ("authzid"). | |
| 441 | ||
| 442 | algorithm | |
| 443 | This directive is required for backwards compatibility with HTTP | |
| 444 | Digest, which supports other algorithms. This directive is | |
| 445 | required and MUST appear exactly once; if not present, or if | |
| 446 | multiple instances are present, the client should abort the | |
| 447 | authentication exchange. | |
| 448 | ||
| 449 | cipher-opts | |
| 450 | A list of ciphers that the server supports. This directive must be | |
| 451 | present exactly once if "auth-conf" is offered in the | |
| 452 | "qop-options" directive, in which case the "3des" cipher is | |
| 453 | mandatory-to-implement. The client MUST ignore unrecognized | |
| 454 | options; if the client recognizes no option, it should abort the | |
| 455 | authentication exchange. See section 2.4 for more detailed | |
| 456 | description of the ciphers. | |
| 457 | ||
| 458 | des | |
| 459 | the Data Encryption Standard (DES) cipher [FIPS] in cipher | |
| 460 | block chaining (CBC) mode with a 56 bit key. | |
| 461 | ||
| 462 | 3des | |
| 463 | the "triple DES" cipher in CBC mode with EDE | |
| 464 | (Encrypt,Decrypt,Encrypt) with the same key for each E stage | |
| 465 | (aka "two keys mode") for a total key length of 112 bits. | |
| 466 | ||
| 467 | rc4, rc4-40, rc4-56 | |
| 468 | the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, | |
| 469 | respectively. | |
| 470 | ||
| 471 | aes | |
| 472 | the Advanced Encryption Standard (AES) cipher [AES] in cipher | |
| 473 | block chaining (CBC) mode with a 128 bit key. This mode | |
| 474 | ||
| 475 | ||
| 476 | ||
| 477 | Leach & Newman Expires: December 2003 [Page 8] | |
| 478 | ||
| 479 | ||
| 480 | ||
| 481 | ||
| 482 | ||
| 483 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 484 | ||
| 485 | ||
| 486 | requires an Initialization Vector (IV) that has the same size | |
| 487 | as the block size. | |
| 488 | ||
| 489 | auth-param | |
| 490 | This construct allows for future extensions; it may appear more | |
| 491 | than once. The client MUST ignore any unrecognized directives. | |
| 492 | ||
| 493 | For use as a SASL mechanism, note that the following changes are made | |
| 494 | to "digest-challenge" from HTTP: the following Digest options (called | |
| 495 | "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent, | |
| 496 | and MUST be ignored if received): | |
| 497 | ||
| 498 | opaque | |
| 499 | domain | |
| 500 | ||
| 501 | The size of a digest-challenge MUST be less than 2048 bytes. | |
| 502 | ||
| 503 | 2.1.2 Step Two | |
| 504 | ||
| 505 | The client makes note of the "digest-challenge" and then responds | |
| 506 | with a string formatted and computed according to the rules for a | |
| 507 | "digest-response" defined as follows: | |
| 508 | ||
| 509 | digest-response = 1#( username | realm | nonce | cnonce | | |
| 510 | nonce-count | qop | digest-uri | response | | |
| 511 | client_maxbuf | charset | cipher | authzid | | |
| 512 | auth-param ) | |
| 513 | ||
| 514 | username = "username" "=" <"> username-value <"> | |
| 515 | username-value = qdstr-val | |
| 516 | cnonce = "cnonce" "=" <"> cnonce-value <"> | |
| 517 | cnonce-value = *qdtext | |
| 518 | nonce-count = "nc" "=" nc-value | |
| 519 | nc-value = 8LHEX | |
| 520 | client_maxbuf = "maxbuf" "=" maxbuf-value | |
| 521 | qop = "qop" "=" qop-value | |
| 522 | digest-uri = "digest-uri" "=" <"> digest-uri-value <"> | |
| 523 | digest-uri-value = serv-type "/" host [ "/" serv-name ] | |
| 524 | serv-type = 1*ALPHA | |
| 525 | serv-name = host | |
| 526 | response = "response" "=" response-value | |
| 527 | response-value = 32LHEX | |
| 528 | LHEX = "0" | "1" | "2" | "3" | | |
| 529 | "4" | "5" | "6" | "7" | | |
| 530 | "8" | "9" | "a" | "b" | | |
| 531 | "c" | "d" | "e" | "f" | |
| 532 | cipher = "cipher" "=" cipher-value | |
| 533 | authzid = "authzid" "=" <"> authzid-value <"> | |
| 534 | ||
| 535 | ||
| 536 | ||
| 537 | Leach & Newman Expires: December 2003 [Page 9] | |
| 538 | ||
| 539 | ||
| 540 | ||
| 541 | ||
| 542 | ||
| 543 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 544 | ||
| 545 | ||
| 546 | authzid-value = qdstr-val | |
| 547 | ||
| 548 | The 'host' non-terminal is defined in [RFC 2732] as | |
| 549 | ||
| 550 | host = hostname | IPv4address | IPv6reference | |
| 551 | ipv6reference = "[" IPv6address "]" | |
| 552 | ||
| 553 | where IPv6address and IPv4address are defined in [RFC 2373] | |
| 554 | and 'hostname' is defined in [RFC 2396]. | |
| 555 | ||
| 556 | username | |
| 557 | The user's name in the specified realm, encoded according to the | |
| 558 | value of the "charset" directive. This directive is required and | |
| 559 | MUST be present exactly once; otherwise, authentication fails. | |
| 560 | ||
| 561 | Upon the receipt of this value and if the charset directive is | |
| 562 | also specified (which means that the username is encoded as | |
| 563 | UTF-8), the server MUST prepare the username using the "SASLPrep" | |
| 564 | profile [SASLPrep] of the "stringprep" algorithm [StringPrep]. If | |
| 565 | preparation of the username fails or results in an empty string, | |
| 566 | the server MUST fail the authentication exchange. | |
| 567 | ||
| 568 | realm | |
| 569 | The realm containing the user's account, encoded according to the | |
| 570 | value of the "charset" directive. This directive is required if | |
| 571 | the server provided any realms in the | |
| 572 | "digest-challenge", in which case it may appear exactly once and | |
| 573 | its value SHOULD be one of those realms. If the directive is | |
| 574 | missing, "realm-value" will set to the empty string when computing | |
| 575 | A1 (see below for details). | |
| 576 | ||
| 577 | If realm was provided by the client and if the charset directive | |
| 578 | was also specified (which means that the realm is encoded as | |
| 579 | UTF-8), the server MUST prepare the realm using the "SASLPrep" | |
| 580 | profile [SASLPrep] of the "stringprep" algorithm [StringPrep]. If | |
| 581 | preparation of the realm fails or results in an empty string, the | |
| 582 | server MUST fail the authentication exchange. | |
| 583 | ||
| 584 | nonce | |
| 585 | The server-specified data string received in the preceding digest- | |
| 586 | challenge. This directive is required and MUST be present exactly | |
| 587 | once; otherwise, authentication fails. | |
| 588 | ||
| 589 | ||
| 590 | ||
| 591 | ||
| 592 | ||
| 593 | ||
| 594 | ||
| 595 | ||
| 596 | ||
| 597 | Leach & Newman Expires: December 2003 [Page 10] | |
| 598 | ||
| 599 | ||
| 600 | ||
| 601 | ||
| 602 | ||
| 603 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 604 | ||
| 605 | ||
| 606 | cnonce | |
| 607 | A client-specified data string which MUST be different each time a | |
| 608 | digest-response is sent as part of initial authentication. The | |
| 609 | cnonce-value is an opaque quoted string value provided by the | |
| 610 | client and used by both client and server to avoid chosen | |
| 611 | plaintext attacks, and to provide mutual authentication. The | |
| 612 | security of the implementation depends on a good choice. It is | |
| 613 | RECOMMENDED that it contain at least 64 bits of entropy. This | |
| 614 | directive is required and MUST be present exactly once; otherwise, | |
| 615 | authentication fails. | |
| 616 | ||
| 617 | nonce-count | |
| 618 | The nc-value is the hexadecimal count of the number of requests | |
| 619 | (including the current request) that the client has sent with the | |
| 620 | nonce value in this request. For example, in the first request | |
| 621 | sent in response to a given nonce value, the client sends | |
| 622 | "nc=00000001". The purpose of this directive is to allow the | |
| 623 | server to detect request replays by maintaining its own copy of | |
| 624 | this count - if the same nc-value is seen twice, then the request | |
| 625 | is a replay. See the description below of the construction of the | |
| 626 | response value. This directive is required and MUST be present | |
| 627 | exactly once; otherwise, authentication fails. | |
| 628 | ||
| 629 | qop | |
| 630 | Indicates what "quality of protection" the client accepted. If | |
| 631 | present, it may appear exactly once and its value MUST be one of | |
| 632 | the alternatives in qop-options. If not present, it defaults to | |
| 633 | "auth". These values affect the computation of the response. Note | |
| 634 | that this is a single token, not a quoted list of alternatives. | |
| 635 | ||
| 636 | serv-type | |
| 637 | Indicates the type of service, such as "http" for web service, | |
| 638 | "ftp" for FTP service, "smtp" for mail delivery service, etc. The | |
| 639 | service name as defined in the SASL profile for the protocol see | |
| 640 | section 4 of [RFC 2222], registered in the IANA registry of | |
| 641 | "service" elements for the GSSAPI host-based service name form | |
| 642 | [RFC 2078]. | |
| 643 | ||
| 644 | host | |
| 645 | The DNS host name or IP (IPv4 or IPv6) address for the service | |
| 646 | requested. The DNS host name must be the fully-qualified | |
| 647 | canonical name of the host. The DNS host name is the preferred | |
| 648 | form; see notes on server processing of the digest-uri. | |
| 649 | ||
| 650 | ||
| 651 | ||
| 652 | ||
| 653 | ||
| 654 | ||
| 655 | ||
| 656 | ||
| 657 | Leach & Newman Expires: December 2003 [Page 11] | |
| 658 | ||
| 659 | ||
| 660 | ||
| 661 | ||
| 662 | ||
| 663 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 664 | ||
| 665 | ||
| 666 | serv-name | |
| 667 | Indicates the name of the service if it is replicated. The service | |
| 668 | is considered to be replicated if the client's service-location | |
| 669 | process involves resolution using standard DNS lookup operations, | |
| 670 | and if these operations involve DNS records (such as SRV [RFC | |
| 671 | 2052], or MX) which resolve one DNS name into a set of other DNS | |
| 672 | names. In this case, the initial name used by the client is the | |
| 673 | "serv-name", and the final name is the "host" component. For | |
| 674 | example, the incoming mail service for "example.com" may be | |
| 675 | replicated through the use of MX records stored in the DNS, one of | |
| 676 | which points at an SMTP server called "mail3.example.com"; it's | |
| 677 | "serv-name" would be "example.com", it's "host" would be | |
| 678 | "mail3.example.com". If the service is not replicated, or the | |
| 679 | serv-name is identical to the host, then the serv-name component | |
| 680 | MUST be omitted. | |
| 681 | ||
| 682 | digest-uri | |
| 683 | Indicates the principal name of the service with which the client | |
| 684 | wishes to connect, formed from the serv-type, host, and serv-name. | |
| 685 | For example, the FTP service on "ftp.example.com" would have a | |
| 686 | "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from | |
| 687 | the example above would have a "digest-uri" value of | |
| 688 | "SMTP/mail3.example.com/example.com". | |
| 689 | ||
| 690 | Servers SHOULD check that the supplied value is correct. This will | |
| 691 | detect accidental connection to the incorrect server, as well as some | |
| 692 | redirection attacks. It is also so that clients will be trained to | |
| 693 | provide values that will work with implementations that use a shared | |
| 694 | back-end authentication service that can provide server | |
| 695 | authentication. | |
| 696 | ||
| 697 | The serv-type component should match the service being offered. The | |
| 698 | host component should match one of the host names of the host on | |
| 699 | which the service is running, or it's IP address. Servers SHOULD NOT | |
| 700 | normally support the IP address form, because server authentication | |
| 701 | by IP address is not very useful; they should only do so if the DNS | |
| 702 | is unavailable or unreliable. The serv-name component should match | |
| 703 | one of the service's configured service names. | |
| 704 | ||
| 705 | This directive may appear at most once; if multiple instances are | |
| 706 | present, the client should abort the authentication exchange. | |
| 707 | ||
| 708 | Note: In the HTTP use of Digest authentication, the digest-uri is the | |
| 709 | URI (usually a URL) of the resource requested -- hence the name of | |
| 710 | the directive. | |
| 711 | ||
| 712 | ||
| 713 | ||
| 714 | ||
| 715 | ||
| 716 | ||
| 717 | Leach & Newman Expires: December 2003 [Page 12] | |
| 718 | ||
| 719 | ||
| 720 | ||
| 721 | ||
| 722 | ||
| 723 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 724 | ||
| 725 | ||
| 726 | response | |
| 727 | A string of 32 hex digits computed as defined below, which proves | |
| 728 | that the user knows a password. This directive is required and | |
| 729 | MUST be present exactly once; otherwise, authentication fails. | |
| 730 | ||
| 731 | client_maxbuf | |
| 732 | A number indicating the size of the largest ciphertext buffer the | |
| 733 | client is able to receive when using "auth-int" or "auth-conf". If | |
| 734 | this directive is missing, the default value is 65536. This | |
| 735 | directive may appear at most once; if multiple instances are | |
| 736 | present, the server MUST abort the authentication exchange. If the | |
| 737 | value is less or equal to 16 or bigger than 16777215 (i.e. | |
| 738 | 2**24-1), the server MUST abort the authentication exchange. | |
| 739 | ||
| 740 | Upon processing/sending of the client_maxbuf value both the server | |
| 741 | and the client calculate their "maximal ciphertext buffer size" as | |
| 742 | the minimum of the server_maxbuf (Step One) and the client_maxbuf | |
| 743 | (Step Two). The "maximal sender size" can be calculated by | |
| 744 | subtracting 16 from the calculated "maximal ciphertext buffer | |
| 745 | size". | |
| 746 | ||
| 747 | When sending a block of data the client/server MUST NOT pass more | |
| 748 | than the "maximal sender size" bytes of data to the selected | |
| 749 | protection function (2.3 or 2.4). | |
| 750 | ||
| 751 | charset | |
| 752 | This directive, if present, specifies that the client has used | |
| 753 | UTF-8 [UTF-8] encoding for the username, realm and password. If | |
| 754 | present, the username, realm and password are in Unicode, prepared | |
| 755 | using the "SASLPrep" profile [SASLPrep] of the "stringprep" | |
| 756 | algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not | |
| 757 | present, the username and password must be encoded in ISO 8859-1 | |
| 758 | [ISO-8859] (of which | |
| 759 | US-ASCII [USASCII] is a subset). The client should send this | |
| 760 | directive only if the server has indicated it supports UTF-8 | |
| 761 | [UTF-8]. The directive is needed for backwards compatibility with | |
| 762 | HTTP Digest, which only supports ISO 8859-1. | |
| 763 | ||
| 764 | Note, that this directive doesn't affect authorization id | |
| 765 | ("authzid"). | |
| 766 | ||
| 767 | LHEX | |
| 768 | 32 hex digits, where the alphabetic characters MUST be lower case, | |
| 769 | because MD5 is not case insensitive. | |
| 770 | ||
| 771 | cipher | |
| 772 | The cipher chosen by the client. This directive MUST appear | |
| 773 | exactly once if "auth-conf" is negotiated; if required and not | |
| 774 | ||
| 775 | ||
| 776 | ||
| 777 | Leach & Newman Expires: December 2003 [Page 13] | |
| 778 | ||
| 779 | ||
| 780 | ||
| 781 | ||
| 782 | ||
| 783 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 784 | ||
| 785 | ||
| 786 | present, authentication fails. | |
| 787 | ||
| 788 | authzid | |
| 789 | The "authorization ID" directive is optional. If present, and the | |
| 790 | authenticating user has sufficient privilege, and the server | |
| 791 | supports it, then after authentication the server will use this | |
| 792 | identity for making all accesses and access checks. If the client | |
| 793 | specifies it, and the server does not support it, then the | |
| 794 | response-value calculated on the server will not match the one | |
| 795 | calculated on the client and authentication will fail. | |
| 796 | ||
| 797 | The authzid MUST NOT be an empty string. | |
| 798 | ||
| 799 | The authorization identifier MUST NOT be converted to ISO 8859-1 | |
| 800 | even if the authentication identifier ("username") is converted | |
| 801 | for compatibility as directed by "charset" directive. | |
| 802 | ||
| 803 | The server SHOULD verify the correctness of an authzid as | |
| 804 | specified by the corresponding SASL protocol profile. | |
| 805 | ||
| 806 | The size of a digest-response MUST be less than 4096 bytes. | |
| 807 | ||
| 808 | 2.1.2.1 Response-value | |
| 809 | ||
| 810 | The definition of "response-value" above indicates the encoding for | |
| 811 | its value -- 32 lower case hex characters. The following definitions | |
| 812 | show how the value is computed. | |
| 813 | ||
| 814 | Although qop-value and components of digest-uri-value may be | |
| 815 | case-insensitive, the case which the client supplies in step two is | |
| 816 | preserved for the purpose of computing and verifying the | |
| 817 | response-value. | |
| 818 | ||
| 819 | response-value = | |
| 820 | HEX( KD ( HEX(H(A1)), | |
| 821 | { nonce-value, ":" nc-value, ":", | |
| 822 | cnonce-value, ":", qop-value, ":", HEX(H(A2)) })) | |
| 823 | ||
| 824 | If authzid is specified, then A1 is | |
| 825 | ||
| 826 | ||
| 827 | A1 = { H( { unq(username-value), ":", unq(realm-value), ":", passwd } ), | |
| 828 | ":", nonce-value, ":", cnonce-value, ":", unq(authzid-value) } | |
| 829 | ||
| 830 | If authzid is not specified, then A1 is | |
| 831 | ||
| 832 | ||
| 833 | A1 = { H( { unq(username-value), ":", unq(realm-value), ":", passwd } ), | |
| 834 | ||
| 835 | ||
| 836 | ||
| 837 | Leach & Newman Expires: December 2003 [Page 14] | |
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | ||
| 842 | ||
| 843 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 844 | ||
| 845 | ||
| 846 | ":", nonce-value, ":", cnonce-value } | |
| 847 | ||
| 848 | where | |
| 849 | ||
| 850 | passwd = *OCTET | |
| 851 | ||
| 852 | The "username-value", "realm-value" and "passwd" are encoded | |
| 853 | according to the value of the "charset" directive. If "charset=UTF-8" | |
| 854 | is present, and all the characters of "username-value" are, after | |
| 855 | preparing using the "SASLPrep" profile [SASLPrep] of the "stringprep" | |
| 856 | algorithm [StringPrep], in the ISO 8859-1 character set, then it must | |
| 857 | be converted to ISO 8859-1 before being hashed. The same | |
| 858 | transformation has to be done for "realm-value" and "passwd". This is | |
| 859 | so that authentication databases that store the hashed username, | |
| 860 | realm and password (which is common) can be shared compatibly with | |
| 861 | HTTP, which specifies ISO 8859-1. A sample implementation of this | |
| 862 | conversion is in section 8. | |
| 863 | ||
| 864 | If the "qop" directive's value is "auth", then A2 is: | |
| 865 | ||
| 866 | A2 = { "AUTHENTICATE:", digest-uri-value } | |
| 867 | ||
| 868 | ||
| 869 | ||
| 870 | ||
| 871 | ||
| 872 | ||
| 873 | ||
| 874 | ||
| 875 | ||
| 876 | ||
| 877 | ||
| 878 | ||
| 879 | ||
| 880 | ||
| 881 | ||
| 882 | ||
| 883 | ||
| 884 | ||
| 885 | ||
| 886 | ||
| 887 | ||
| 888 | ||
| 889 | ||
| 890 | ||
| 891 | ||
| 892 | ||
| 893 | ||
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | Leach & Newman Expires: December 2003 [Page 15] | |
| 898 | ||
| 899 | ||
| 900 | ||
| 901 | ||
| 902 | ||
| 903 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 904 | ||
| 905 | ||
| 906 | If the "qop" value is "auth-int" or "auth-conf" then A2 is: | |
| 907 | ||
| 908 | A2 = { "AUTHENTICATE:", digest-uri-value, | |
| 909 | ":00000000000000000000000000000000" } | |
| 910 | ||
| 911 | Note that "AUTHENTICATE:" must be in upper case, and the second | |
| 912 | string constant is a string with a colon followed by 32 zeros. | |
| 913 | ||
| 914 | These apparently strange values of A2 are for compatibility with | |
| 915 | HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and | |
| 916 | the hash of the entity body to zero in the HTTP digest calculation of | |
| 917 | A2. | |
| 918 | ||
| 919 | Also, in the HTTP usage of Digest, several directives in the | |
| 920 | "digest-challenge" sent by the server have to be returned by the | |
| 921 | client in the "digest-response". These are: | |
| 922 | ||
| 923 | opaque | |
| 924 | algorithm | |
| 925 | ||
| 926 | These directives are not needed when Digest is used as a SASL | |
| 927 | mechanism (i.e., MUST NOT be sent, and MUST be ignored if received). | |
| 928 | ||
| 929 | 2.1.3 Step Three | |
| 930 | ||
| 931 | The server receives and validates the "digest-response". The server | |
| 932 | checks that the nonce-count is "00000001". If it supports subsequent | |
| 933 | authentication (see section 2.2), it saves the value of the nonce and | |
| 934 | the nonce-count. It sends a message formatted as follows: | |
| 935 | ||
| 936 | response-auth = "rspauth" "=" response-value | |
| 937 | ||
| 938 | where response-value is calculated as above, using the values sent in | |
| 939 | step two, except that if qop is "auth", then A2 is | |
| 940 | ||
| 941 | A2 = { ":", digest-uri-value } | |
| 942 | ||
| 943 | And if qop is "auth-int" or "auth-conf" then A2 is | |
| 944 | ||
| 945 | A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" } | |
| 946 | ||
| 947 | Compared to its use in HTTP, the following Digest directives in the | |
| 948 | "digest-response" are unused: | |
| 949 | ||
| 950 | nextnonce | |
| 951 | qop | |
| 952 | cnonce | |
| 953 | nonce-count | |
| 954 | ||
| 955 | ||
| 956 | ||
| 957 | Leach & Newman Expires: December 2003 [Page 16] | |
| 958 | ||
| 959 | ||
| 960 | ||
| 961 | ||
| 962 | ||
| 963 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 964 | ||
| 965 | ||
| 966 | 2.2 Subsequent Authentication | |
| 967 | ||
| 968 | If the client has previously authenticated to the server, and | |
| 969 | remembers the values of username, realm, nonce, nonce-count, cnonce, | |
| 970 | and qop that it used in that authentication, and the SASL profile for | |
| 971 | a protocol permits an initial client response, then it MAY perform | |
| 972 | "subsequent authentication", as defined in this section. | |
| 973 | ||
| 974 | 2.2.1 Step one | |
| 975 | ||
| 976 | The client uses the values from the previous authentication and sends | |
| 977 | an initial response with a string formatted and computed according to | |
| 978 | the rules for a "digest-response", as defined above, but with a | |
| 979 | nonce-count one greater than used in the last "digest-response". | |
| 980 | ||
| 981 | 2.2.2 Step Two | |
| 982 | ||
| 983 | The server receives the "digest-response". If the server does not | |
| 984 | support subsequent authentication, then it sends a | |
| 985 | "digest-challenge", and authentication proceeds as in initial | |
| 986 | authentication. If the server has no saved nonce and nonce-count from | |
| 987 | a previous authentication, then it sends a "digest-challenge", and | |
| 988 | authentication proceeds as in initial authentication. Otherwise, the | |
| 989 | server validates the "digest-response", checks that the nonce-count | |
| 990 | is one greater than that used in the previous authentication using | |
| 991 | that nonce, and saves the new value of nonce-count. | |
| 992 | ||
| 993 | If the response is invalid, then the server sends a | |
| 994 | "digest-challenge", and authentication proceeds as in initial | |
| 995 | authentication (and should be configurable to log an authentication | |
| 996 | failure in some sort of security audit log, since the failure may be | |
| 997 | a symptom of an attack). The nonce-count MUST NOT be incremented in | |
| 998 | this case: to do so would allow a denial of service attack by sending | |
| 999 | an out-of-order nonce-count. | |
| 1000 | ||
| 1001 | If the response is valid, the server MAY choose to deem that | |
| 1002 | authentication has succeeded. However, if it has been too long since | |
| 1003 | the previous authentication, or for any o including the next | |
| 1004 | subsequent authentication, between the client and the server MUST be | |
| 1005 | integrity protected. Using as a base session key the value of H(A1) | |
| 1006 | as defined above the client and server calculate a pair of message | |
| 1007 | integrity keys as follows. | |
| 1008 | ||
| 1009 | The key for integrity protecting messages from client to server is: | |
| 1010 | ||
| 1011 | Kic = MD5({H(A1), | |
| 1012 | "Digest session key to client-to-server signing key magic constant"}) | |
| 1013 | ||
| 1014 | ||
| 1015 | ||
| 1016 | ||
| 1017 | Leach & Newman Expires: December 2003 [Page 17] | |
| 1018 | ||
| 1019 | ||
| 1020 | ||
| 1021 | ||
| 1022 | ||
| 1023 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1024 | ||
| 1025 | ||
| 1026 | The key for integrity protecting messages from server to client is: | |
| 1027 | ||
| 1028 | Kis = MD5({H(A1), | |
| 1029 | "Digest session key to server-to-client signing key magic constant"}) | |
| 1030 | ||
| 1031 | where MD5 is as specified in [RFC 1321]. If message integrity is | |
| 1032 | negotiated, a MAC block for each message is appended to the message. | |
| 1033 | The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC | |
| 1034 | 2104] of the message, a 2-byte message type number in network byte | |
| 1035 | order with value 1, and the 4-byte sequence number in network byte | |
| 1036 | order. The message type is to allow for future extensions such as | |
| 1037 | rekeying. | |
| 1038 | ||
| 1039 | MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001, | |
| 1040 | SeqNum) | |
| 1041 | ||
| 1042 | where Ki is Kic for messages sent by the client and Kis for those | |
| 1043 | sent by the server. The sequence number (SeqNum) is an unsigned | |
| 1044 | number initialized to zero after initial or subsequent | |
| 1045 | authentication, and incremented by one for each message | |
| 1046 | sent/successfully verified. (Note, that there are two independent | |
| 1047 | counters for sending and receiving.) The sequence number wraps around | |
| 1048 | to 0 after 2**32-1. | |
| 1049 | ||
| 1050 | Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the | |
| 1051 | received value; the message is discarded if they differ. The | |
| 1052 | receiver's sequence counter is incremented if they match. | |
| 1053 | ||
| 1054 | 2.4 Confidentiality Protection | |
| 1055 | ||
| 1056 | If the server sent a "cipher-opts" directive and the client responded | |
| 1057 | with a "cipher" directive, then subsequent messages between the | |
| 1058 | client and the server MUST be confidentiality protected. Using as a | |
| 1059 | base session key the value of H(A1) as defined above the client and | |
| 1060 | server calculate a pair of message integrity keys as follows. | |
| 1061 | ||
| 1062 | The key for confidentiality protecting messages from client to server | |
| 1063 | is: | |
| 1064 | ||
| 1065 | Kcc = MD5({H(A1)[0..n-1], | |
| 1066 | "Digest H(A1) to client-to-server sealing key magic constant"}) | |
| 1067 | ||
| 1068 | The key for confidentiality protecting messages from server to client | |
| 1069 | is: | |
| 1070 | ||
| 1071 | Kcs = MD5({H(A1)[0..n-1], | |
| 1072 | "Digest H(A1) to server-to-client sealing key magic constant"}) | |
| 1073 | ||
| 1074 | ||
| 1075 | ||
| 1076 | ||
| 1077 | Leach & Newman Expires: December 2003 [Page 18] | |
| 1078 | ||
| 1079 | ||
| 1080 | ||
| 1081 | ||
| 1082 | ||
| 1083 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1084 | ||
| 1085 | ||
| 1086 | where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; | |
| 1087 | for "rc4-56" n is 7; for the rest n is 16. The key for the "rc4-*" | |
| 1088 | and "aes" ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is | |
| 1089 | the first 7 bytes; the key for "3des" is the first 14 bytes. | |
| 1090 | ||
| 1091 | The IV used to send/receive the initial buffer of security encoded | |
| 1092 | data for "des" and "3des" is the last 8 bytes of Kcc or Kcs. For all | |
| 1093 | subsequent buffers the last 8 bytes of the ciphertext of the buffer | |
| 1094 | NNN is used as the IV for the buffer (NNN + 1). | |
| 1095 | ||
| 1096 | The IV for the "aes" cipher in CBC mode for messages going from the | |
| 1097 | client to the server (IVc) consists of 16 bytes calculated as | |
| 1098 | follows: | |
| 1099 | ||
| 1100 | IVc = MD5({Kcc, "aes-128"}) | |
| 1101 | ||
| 1102 | The IV for the "aes" cipher in CBC mode for messages going from the | |
| 1103 | server to the client (IVs) consists of 16 bytes calculated as | |
| 1104 | follows: | |
| 1105 | ||
| 1106 | IVs = MD5({Kcs, "aes-128"}) | |
| 1107 | ||
| 1108 | The IV is XOR'd with the first plaintext block before it is encrypted | |
| 1109 | with "aes". Then for successive blocks, the previous ciphertext | |
| 1110 | block is XOR'd with the current plaintext, before it is encrypted. | |
| 1111 | ||
| 1112 | rc4 cipher state MUST NOT be reset before sending/receiving a next | |
| 1113 | buffer of security encoded data. | |
| 1114 | ||
| 1115 | The MAC block is a variable length padding prefix followed by 16 | |
| 1116 | bytes formatted as follows: the first 10 bytes of the HMAC-MD5 [RFC | |
| 1117 | 2104] of the message, a 2-byte message type number in network byte | |
| 1118 | order with value 1, and the 4-byte sequence number in network byte | |
| 1119 | order. If the blocksize of the chosen cipher is not 1 byte, the | |
| 1120 | padding prefix is one or more octets each containing the number of | |
| 1121 | padding bytes, such that total length of the encrypted part of the | |
| 1122 | message is a multiple of the blocksize. The padding and first 10 | |
| 1123 | bytes of the MAC block are encrypted with the chosen cipher along | |
| 1124 | with the message. | |
| 1125 | ||
| 1126 | SEAL(Ki, Kc, SeqNum, msg) = | |
| 1127 | {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9]}), 0x0001, | |
| 1128 | SeqNum} | |
| 1129 | ||
| 1130 | where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for | |
| 1131 | messages sent by the client and Kis and Kcs for those sent by the | |
| 1132 | server. The sequence number (SeqNum) is an unsigned number | |
| 1133 | initialized to zero after initial or subsequent authentication, and | |
| 1134 | ||
| 1135 | ||
| 1136 | ||
| 1137 | Leach & Newman Expires: December 2003 [Page 19] | |
| 1138 | ||
| 1139 | ||
| 1140 | ||
| 1141 | ||
| 1142 | ||
| 1143 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1144 | ||
| 1145 | ||
| 1146 | incremented by one for each message sent/successfully verified. | |
| 1147 | (Note, that there are two independent counters for sending and | |
| 1148 | receiving.) The sequence number wraps around to 0 after 2**32-1. | |
| 1149 | ||
| 1150 | Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is | |
| 1151 | computed and compared with the received value; the padding is | |
| 1152 | verified. The message is discarded if the received and the | |
| 1153 | calculated HMACs differ and/or the padding is invalid. See also | |
| 1154 | section 3.8 for important information about MAC and padding | |
| 1155 | verification. The receiver's sequence counter is then compared with | |
| 1156 | the received SeqNum value; the message is discarded if they differ. | |
| 1157 | The receiver's sequence counter is incremented if they match. | |
| 1158 | ||
| 1159 | ||
| 1160 | ||
| 1161 | ||
| 1162 | ||
| 1163 | ||
| 1164 | ||
| 1165 | ||
| 1166 | ||
| 1167 | ||
| 1168 | ||
| 1169 | ||
| 1170 | ||
| 1171 | ||
| 1172 | ||
| 1173 | ||
| 1174 | ||
| 1175 | ||
| 1176 | ||
| 1177 | ||
| 1178 | ||
| 1179 | ||
| 1180 | ||
| 1181 | ||
| 1182 | ||
| 1183 | ||
| 1184 | ||
| 1185 | ||
| 1186 | ||
| 1187 | ||
| 1188 | ||
| 1189 | ||
| 1190 | ||
| 1191 | ||
| 1192 | ||
| 1193 | ||
| 1194 | ||
| 1195 | ||
| 1196 | ||
| 1197 | Leach & Newman Expires: December 2003 [Page 20] | |
| 1198 | ||
| 1199 | ||
| 1200 | ||
| 1201 | ||
| 1202 | ||
| 1203 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1204 | ||
| 1205 | ||
| 1206 | 3 Security Considerations | |
| 1207 | ||
| 1208 | General SASL security considerations apply to this mechanism. | |
| 1209 | "stringprep" and Unicode security considerations also apply. | |
| 1210 | ||
| 1211 | Detailed discussion of other DIGEST-MD5 specific security issues is | |
| 1212 | below. | |
| 1213 | ||
| 1214 | 3.1 Authentication of Clients using Digest Authentication | |
| 1215 | ||
| 1216 | Digest Authentication does not provide a strong authentication | |
| 1217 | mechanism, when compared to public key based mechanisms, for example. | |
| 1218 | However, since it prevents chosen plaintext attacks, it is stronger | |
| 1219 | than (e.g.) CRAM-MD5, which has been proposed for use with ACAP [RFC | |
| 1220 | 2244], POP and IMAP [RFC 2195]. It is intended to replace the much | |
| 1221 | weaker and even more dangerous use of plaintext passwords; however, | |
| 1222 | since it is still a password based mechanism it avoids some of the | |
| 1223 | potential deployabilty issues with public-key, OTP or similar | |
| 1224 | mechanisms. | |
| 1225 | ||
| 1226 | Digest Authentication offers no confidentiality protection beyond | |
| 1227 | protecting the actual password. All of the rest of the challenge and | |
| 1228 | response are available to an eavesdropper, including the user's name | |
| 1229 | and authentication realm. | |
| 1230 | ||
| 1231 | 3.2 Comparison of Digest with Plaintext Passwords | |
| 1232 | ||
| 1233 | The greatest threat to the type of transactions for which these | |
| 1234 | protocols are used is network snooping. This kind of transaction | |
| 1235 | might involve, for example, online access to a mail service whose use | |
| 1236 | is restricted to paying subscribers. With plaintext password | |
| 1237 | authentication an eavesdropper can obtain the password of the user. | |
| 1238 | This not only permits him to access anything in the database, but, | |
| 1239 | often worse, will permit access to anything else the user protects | |
| 1240 | with the same password. | |
| 1241 | ||
| 1242 | 3.3 Replay Attacks | |
| 1243 | ||
| 1244 | Replay attacks are defeated if the client or the server chooses a | |
| 1245 | fresh nonce for each authentication, as this specification requires. | |
| 1246 | ||
| 1247 | As a security precaution, the server, when verifying a response from | |
| 1248 | the client, must use the original server nonce ("nonce") it sent, not | |
| 1249 | the one returned by the client in the response, as it might have been | |
| 1250 | modified by an attacker. | |
| 1251 | ||
| 1252 | To prevent some redirection attacks it is recommended that the server | |
| 1253 | verifies that the "serv-type" part of the "digest-uri" matches the | |
| 1254 | ||
| 1255 | ||
| 1256 | ||
| 1257 | Leach & Newman Expires: December 2003 [Page 21] | |
| 1258 | ||
| 1259 | ||
| 1260 | ||
| 1261 | ||
| 1262 | ||
| 1263 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1264 | ||
| 1265 | ||
| 1266 | service name and that the hostname/IP address belongs to the server. | |
| 1267 | ||
| 1268 | 3.4 Online dictionary attacks | |
| 1269 | ||
| 1270 | If the attacker can eavesdrop, then it can test any overheard | |
| 1271 | nonce/response pairs against a (potentially very large) list of | |
| 1272 | common words. Such a list is usually much smaller than the total | |
| 1273 | number of possible passwords. The cost of computing the response for | |
| 1274 | each password on the list is paid once for each challenge. | |
| 1275 | ||
| 1276 | The server can mitigate this attack by not allowing users to select | |
| 1277 | passwords that are in a dictionary. | |
| 1278 | ||
| 1279 | 3.5 Offline dictionary attacks | |
| 1280 | ||
| 1281 | If the attacker can choose the challenge, then it can precompute the | |
| 1282 | possible responses to that challenge for a list of common words. Such | |
| 1283 | a list is usually much smaller than the total number of possible | |
| 1284 | passwords. The cost of computing the response for each password on | |
| 1285 | the list is paid just once. | |
| 1286 | ||
| 1287 | Offline dictionary attacks are defeated if the client chooses a fresh | |
| 1288 | nonce for each authentication, as this specification requires. | |
| 1289 | ||
| 1290 | 3.6 Man in the Middle | |
| 1291 | ||
| 1292 | Digest authentication is vulnerable to "man in the middle" (MITM) | |
| 1293 | attacks. Clearly, a MITM would present all the problems of | |
| 1294 | eavesdropping. But it also offers some additional opportunities to | |
| 1295 | the attacker. | |
| 1296 | ||
| 1297 | A possible man-in-the-middle attack would be to substitute a weaker | |
| 1298 | qop scheme for the one(s) sent by the server; the server will not be | |
| 1299 | able to detect this attack. For this reason, the client should always | |
| 1300 | use the strongest scheme that it understands from the choices | |
| 1301 | offered, and should never choose a scheme that does not meet its | |
| 1302 | minimum requirements. | |
| 1303 | ||
| 1304 | A man-in-the-middle attack may also make the client and the server | |
| 1305 | that agreed to use confidentiality protection to use different (and | |
| 1306 | possibly weaker) cipher's. This is because the chosen cipher is not | |
| 1307 | used in the shared secret calculation. | |
| 1308 | ||
| 1309 | 3.7 Chosen plaintext attacks | |
| 1310 | ||
| 1311 | A chosen plaintext attack is where a MITM or a malicious server can | |
| 1312 | arbitrarily choose the challenge that the client will use to compute | |
| 1313 | the response. The ability to choose the challenge is known to make | |
| 1314 | ||
| 1315 | ||
| 1316 | ||
| 1317 | Leach & Newman Expires: December 2003 [Page 22] | |
| 1318 | ||
| 1319 | ||
| 1320 | ||
| 1321 | ||
| 1322 | ||
| 1323 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1324 | ||
| 1325 | ||
| 1326 | cryptanalysis much easier [MD5]. | |
| 1327 | ||
| 1328 | However, Digest does not permit the attack to choose the challenge as | |
| 1329 | long as the client chooses a fresh nonce for each authentication, as | |
| 1330 | this specification requires. | |
| 1331 | ||
| 1332 | 3.8 CBC Mode attacks | |
| 1333 | ||
| 1334 | The following attack can be launched when the connection uses | |
| 1335 | Confidentiality protection with ciphers in CBC mode. If bad padding | |
| 1336 | is treated differently from bad MACs when decrypting a DIGEST-MD5 | |
| 1337 | buffer of security encoded data, the attacker may be able to launch | |
| 1338 | Vaudenay's attack on padding. | |
| 1339 | ||
| 1340 | An error logfile will suffice to launch the attack if it reveals the | |
| 1341 | type of error -- even if file permissions prevent the attacker from | |
| 1342 | actually reading the file (the file length increase cause by the | |
| 1343 | attack is likely to reveal which of the two errors occured). | |
| 1344 | ||
| 1345 | A different approach to distinguish these two error cases and launch | |
| 1346 | the attack is to examine the timing of error responses: if the MAC | |
| 1347 | verification is skipped when bad padding has been found, the error | |
| 1348 | will appear quicker in the case of incorrect block cipher padding | |
| 1349 | than in the case of an incorrect MAC. | |
| 1350 | ||
| 1351 | A countermeasure is to compute a MAC of the plaintext anyway, even if | |
| 1352 | the usual padding removal step fails because of incorrect padding, to | |
| 1353 | obtain (nearly) uniform timing. | |
| 1354 | ||
| 1355 | 3.9 Spoofing by Counterfeit Servers | |
| 1356 | ||
| 1357 | If a user can be led to believe that she is connecting to a host | |
| 1358 | containing information protected by a password she knows, when in | |
| 1359 | fact she is connecting to a hostile server, then the hostile server | |
| 1360 | can obtain challenge/response pairs where it was able to partly | |
| 1361 | choose the challenge. There is no known way that this can be | |
| 1362 | exploited. | |
| 1363 | ||
| 1364 | 3.10 Storing passwords | |
| 1365 | ||
| 1366 | Digest authentication requires that the authenticating agent (usually | |
| 1367 | the server) store some data derived from the user's name and password | |
| 1368 | in a "password file" associated with a given realm. Normally this | |
| 1369 | might contain pairs consisting of username and H({ username-value, | |
| 1370 | ":", realm-value, ":", passwd }), which is adequate to compute H(A1) | |
| 1371 | as described above without directly exposing the user's password. | |
| 1372 | ||
| 1373 | The security implications of this are that if this password file is | |
| 1374 | ||
| 1375 | ||
| 1376 | ||
| 1377 | Leach & Newman Expires: December 2003 [Page 23] | |
| 1378 | ||
| 1379 | ||
| 1380 | ||
| 1381 | ||
| 1382 | ||
| 1383 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1384 | ||
| 1385 | ||
| 1386 | compromised, then an attacker gains immediate access to documents on | |
| 1387 | the server using this realm. Unlike, say a standard UNIX password | |
| 1388 | file, this information need not be decrypted in order to access | |
| 1389 | documents in the server realm associated with this file. On the other | |
| 1390 | hand, decryption, or more likely a brute force attack, would be | |
| 1391 | necessary to obtain the user's password. This is the reason that the | |
| 1392 | realm is part of the digested data stored in the password file. It | |
| 1393 | means that if one Digest authentication password file is compromised, | |
| 1394 | it does not automatically compromise others with the same username | |
| 1395 | and password (though it does expose them to brute force attack). | |
| 1396 | ||
| 1397 | There are two important security consequences of this. First the | |
| 1398 | password file must be protected as if it contained plaintext | |
| 1399 | passwords, because for the purpose of accessing documents in its | |
| 1400 | realm, it effectively does. | |
| 1401 | ||
| 1402 | A second consequence of this is that the realm string should be | |
| 1403 | unique among all realms that any single user is likely to use. In | |
| 1404 | particular a realm string should include the name of the host doing | |
| 1405 | the authentication. | |
| 1406 | ||
| 1407 | ||
| 1408 | ||
| 1409 | ||
| 1410 | ||
| 1411 | ||
| 1412 | ||
| 1413 | ||
| 1414 | ||
| 1415 | ||
| 1416 | ||
| 1417 | ||
| 1418 | ||
| 1419 | ||
| 1420 | ||
| 1421 | ||
| 1422 | ||
| 1423 | ||
| 1424 | ||
| 1425 | ||
| 1426 | ||
| 1427 | ||
| 1428 | ||
| 1429 | ||
| 1430 | ||
| 1431 | ||
| 1432 | ||
| 1433 | ||
| 1434 | ||
| 1435 | ||
| 1436 | ||
| 1437 | Leach & Newman Expires: December 2003 [Page 24] | |
| 1438 | ||
| 1439 | ||
| 1440 | ||
| 1441 | ||
| 1442 | ||
| 1443 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1444 | ||
| 1445 | ||
| 1446 | 3.11 Multiple realms | |
| 1447 | ||
| 1448 | Use of multiple realms may mean both that compromise of a the | |
| 1449 | security database for a single realm does not compromise all | |
| 1450 | security, and that there are more things to protect in order to keep | |
| 1451 | the whole system secure. | |
| 1452 | ||
| 1453 | 3.11 Summary | |
| 1454 | ||
| 1455 | By modern cryptographic standards Digest Authentication is weak, | |
| 1456 | compared to (say) public key based mechanisms. But for a large range | |
| 1457 | of purposes it is valuable as a replacement for plaintext passwords. | |
| 1458 | Its strength may vary depending on the implementation. | |
| 1459 | ||
| 1460 | ||
| 1461 | 4 Example | |
| 1462 | ||
| 1463 | This example shows the use of the Digest SASL mechanism with the | |
| 1464 | IMAP4 AUTHENTICATE command [RFC 3501]. | |
| 1465 | ||
| 1466 | In this example, "C:" and "S:" represent a line sent by the client or | |
| 1467 | server respectively including a CRLF at the end. Linebreaks and | |
| 1468 | indentation within a "C:" or "S:" are editorial and not part of the | |
| 1469 | protocol. The password in this example was "secret". Note that the | |
| 1470 | base64 encoding of the challenges and responses is part of the IMAP4 | |
| 1471 | AUTHENTICATE command, not part of the Digest specification itself. | |
| 1472 | ||
| 1473 | S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9 | |
| 1474 | C: c CAPABILITY | |
| 1475 | S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA | |
| 1476 | UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN | |
| 1477 | S: c OK Completed | |
| 1478 | C: a AUTHENTICATE DIGEST-MD5 | |
| 1479 | S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 | |
| 1480 | RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh | |
| 1481 | cnNldD11dGYtOA== | |
| 1482 | C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 | |
| 1483 | QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw | |
| 1484 | MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im | |
| 1485 | ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw | |
| 1486 | ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= | |
| 1487 | S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== | |
| 1488 | C: | |
| 1489 | S: a OK User logged in | |
| 1490 | --- | |
| 1491 | ||
| 1492 | The base64-decoded version of the SASL exchange is: | |
| 1493 | ||
| 1494 | ||
| 1495 | ||
| 1496 | ||
| 1497 | Leach & Newman Expires: December 2003 [Page 25] | |
| 1498 | ||
| 1499 | ||
| 1500 | ||
| 1501 | ||
| 1502 | ||
| 1503 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1504 | ||
| 1505 | ||
| 1506 | S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth", | |
| 1507 | algorithm=md5-sess,charset=utf-8 | |
| 1508 | C: charset=utf-8,username="chris",realm="elwood.innosoft.com", | |
| 1509 | nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk", | |
| 1510 | digest-uri="imap/elwood.innosoft.com", | |
| 1511 | response=d388dad90d4bbd760a152321f2143af7,qop=auth | |
| 1512 | S: rspauth=ea40f60335c427b5527b84dbabcdfffd | |
| 1513 | ||
| 1514 | The password in this example was "secret". | |
| 1515 | ||
| 1516 | This example shows the use of the Digest SASL mechanism with the | |
| 1517 | ACAP, using the same notational conventions and password as in the | |
| 1518 | previous example. Note that ACAP does not base64 encode and uses | |
| 1519 | fewer round trips that IMAP4. | |
| 1520 | ||
| 1521 | S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5" | |
| 1522 | "DIGEST-MD5" "PLAIN") | |
| 1523 | C: a AUTHENTICATE "DIGEST-MD5" | |
| 1524 | S: + {94} | |
| 1525 | S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth", | |
| 1526 | algorithm=md5-sess,charset=utf-8 | |
| 1527 | C: {206} | |
| 1528 | C: charset=utf-8,username="chris",realm="elwood.innosoft.com", | |
| 1529 | nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m", | |
| 1530 | digest-uri="acap/elwood.innosoft.com", | |
| 1531 | response=6084c6db3fede7352c551284490fd0fc,qop=auth | |
| 1532 | S: a OK (SASL {40} | |
| 1533 | S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE | |
| 1534 | Completed" | |
| 1535 | --- | |
| 1536 | ||
| 1537 | The server uses the values of all the directives, plus knowledge of | |
| 1538 | the users password (or the hash of the user's name, server's realm | |
| 1539 | and the user's password) to verify the computations above. If they | |
| 1540 | check, then the user has authenticated. | |
| 1541 | ||
| 1542 | ||
| 1543 | ||
| 1544 | ||
| 1545 | ||
| 1546 | ||
| 1547 | ||
| 1548 | ||
| 1549 | ||
| 1550 | ||
| 1551 | ||
| 1552 | ||
| 1553 | ||
| 1554 | ||
| 1555 | ||
| 1556 | ||
| 1557 | Leach & Newman Expires: December 2003 [Page 26] | |
| 1558 | ||
| 1559 | ||
| 1560 | ||
| 1561 | ||
| 1562 | ||
| 1563 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1564 | ||
| 1565 | ||
| 1566 | 5 References | |
| 1567 | ||
| 1568 | 5.1 Normative references | |
| 1569 | ||
| 1570 | [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest | |
| 1571 | Access Authentication", RFC 2617, June 1999. | |
| 1572 | ||
| 1573 | [ISO-8859] ISO-8859. International Standard--Information Processing-- | |
| 1574 | 8-bit Single-Byte Coded Graphic Character Sets -- | |
| 1575 | Part 1: Latin alphabet No. 1, ISO-8859-1:1987. | |
| 1576 | Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. | |
| 1577 | Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. | |
| 1578 | Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. | |
| 1579 | Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. | |
| 1580 | Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. | |
| 1581 | Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. | |
| 1582 | Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. | |
| 1583 | Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. | |
| 1584 | ||
| 1585 | [RFC 822] Crocker, D., "Standard for The Format of ARPA Internet | |
| 1586 | Text Messages," STD 11, RFC 822, August 1982. | |
| 1587 | ||
| 1588 | [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |
| 1589 | April 1992. | |
| 1590 | ||
| 1591 | [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the | |
| 1592 | location of services (DNS SRV)", RFC 2052, October 1996. | |
| 1593 | ||
| 1594 | [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- | |
| 1595 | Hashing for Message Authentication", RFC 2104, February | |
| 1596 | 1997. | |
| 1597 | ||
| 1598 | [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | |
| 1599 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
| 1600 | ||
| 1601 | [RFC 2222] Myers, J., "Simple Authentication and Security Layer | |
| 1602 | (SASL)", RFC 2222, October 1997. | |
| 1603 | ||
| 1604 | [Stringprep] Hoffman, P., Blanchet, M., "Preparation of | |
| 1605 | Internationalized Strings ("stringprep")", RFC 3454, | |
| 1606 | December 2002. | |
| 1607 | ||
| 1608 | [Unicode] The Unicode Consortium, "The Unicode Standard, Version | |
| 1609 | 3.2.0", defined by: The Unicode Standard, Version 3.0 | |
| 1610 | (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), | |
| 1611 | as amended by the Unicode Standard Annex #28: Unicode 3.2 | |
| 1612 | (http://www.unicode.org/reports/tr28/tr28-3.html). | |
| 1613 | ||
| 1614 | ||
| 1615 | ||
| 1616 | ||
| 1617 | Leach & Newman Expires: December 2003 [Page 27] | |
| 1618 | ||
| 1619 | ||
| 1620 | ||
| 1621 | ||
| 1622 | ||
| 1623 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1624 | ||
| 1625 | ||
| 1626 | [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC | |
| 1627 | 2279, Janyary 1998. | |
| 1628 | ||
| 1629 | [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard | |
| 1630 | Code for Information Interchange. Standard ANSI X3.4-1986, | |
| 1631 | ANSI, 1986. | |
| 1632 | ||
| 1633 | [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names | |
| 1634 | and passwords", Work in progress, draft-ietf-sasl- | |
| 1635 | saslprep-XX.txt. | |
| 1636 | ||
| 1637 | [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for | |
| 1638 | Literal IPv6 Addresses in URL's", RFC 2732, December 1999. | |
| 1639 | ||
| 1640 | [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing | |
| 1641 | Architecture", RFC 2373, July 1998. | |
| 1642 | ||
| 1643 | [RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform | |
| 1644 | Resource Identifiers (URI): Generic Syntax", RFC 2396, | |
| 1645 | August 1998. | |
| 1646 | ||
| 1647 | [FIPS] National Institute of Standards and Technology, "DES Modes of | |
| 1648 | Operation", http://www.itl.nist.gov/fipspubs/fip81.htm, | |
| 1649 | December 1980. | |
| 1650 | ||
| 1651 | [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher", | |
| 1652 | http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf, | |
| 1653 | 3rd September 1999. | |
| 1654 | ||
| 1655 | ||
| 1656 | 5.2 Informative references | |
| 1657 | ||
| 1658 | [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP | |
| 1659 | AUTHorize Extension for Simple Challenge/Response", RFC | |
| 1660 | 2195, September 1997. | |
| 1661 | ||
| 1662 | [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with MD5", | |
| 1663 | CryptoBytes, Sping 1995, RSA Inc, | |
| 1664 | (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm) | |
| 1665 | ||
| 1666 | [RFC 2078] Linn, J., "Generic Security Service Application Program | |
| 1667 | Interface, Version 2", RFC 2078, January 1997. | |
| 1668 | ||
| 1669 | [RFC 3501] Crispin, M., "Internet Message Access Protocol - Version | |
| 1670 | 4rev1", RFC 3501, March 2003. | |
| 1671 | ||
| 1672 | [RFC 2244] Newman, C., Myers, J., "ACAP -- Application Configuration | |
| 1673 | Access Protocol", RFC 2244, November 1997. | |
| 1674 | ||
| 1675 | ||
| 1676 | ||
| 1677 | Leach & Newman Expires: December 2003 [Page 28] | |
| 1678 | ||
| 1679 | ||
| 1680 | ||
| 1681 | ||
| 1682 | ||
| 1683 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1684 | ||
| 1685 | ||
| 1686 | [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |
| 1687 | Masinter, L., Leach, P., Berners-Lee, T., "Hypertext | |
| 1688 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |
| 1689 | ||
| 1690 | [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: | |
| 1691 | Problems and Countermeasures", | |
| 1692 | http://www.openssl.org/~bodo/tls-cbc.txt. | |
| 1693 | ||
| 1694 | ||
| 1695 | ||
| 1696 | ||
| 1697 | ||
| 1698 | ||
| 1699 | ||
| 1700 | ||
| 1701 | ||
| 1702 | ||
| 1703 | ||
| 1704 | ||
| 1705 | ||
| 1706 | ||
| 1707 | ||
| 1708 | ||
| 1709 | ||
| 1710 | ||
| 1711 | ||
| 1712 | ||
| 1713 | ||
| 1714 | ||
| 1715 | ||
| 1716 | ||
| 1717 | ||
| 1718 | ||
| 1719 | ||
| 1720 | ||
| 1721 | ||
| 1722 | ||
| 1723 | ||
| 1724 | ||
| 1725 | ||
| 1726 | ||
| 1727 | ||
| 1728 | ||
| 1729 | ||
| 1730 | ||
| 1731 | ||
| 1732 | ||
| 1733 | ||
| 1734 | ||
| 1735 | ||
| 1736 | ||
| 1737 | Leach & Newman Expires: December 2003 [Page 29] | |
| 1738 | ||
| 1739 | ||
| 1740 | ||
| 1741 | ||
| 1742 | ||
| 1743 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1744 | ||
| 1745 | ||
| 1746 | 6 Authors' Addresses | |
| 1747 | ||
| 1748 | Paul Leach | |
| 1749 | Microsoft | |
| 1750 | 1 Microsoft Way | |
| 1751 | Redmond, WA 98052, USA | |
| 1752 | ||
| 1753 | EMail: paulle@microsoft.com | |
| 1754 | ||
| 1755 | ||
| 1756 | Chris Newman | |
| 1757 | Sun Microsystems | |
| 1758 | 1050 Lakes Drive | |
| 1759 | West Covina, CA 91790, USA | |
| 1760 | ||
| 1761 | EMail: Chris.Newman@Sun.COM | |
| 1762 | ||
| 1763 | ||
| 1764 | Alexey Melnikov | |
| 1765 | Isode | |
| 1766 | 28 Gloucester Road, | |
| 1767 | Teddington, Middlesex, TW11 0NU, UK | |
| 1768 | ||
| 1769 | Email: mel@isode.com | |
| 1770 | ||
| 1771 | ||
| 1772 | ||
| 1773 | ||
| 1774 | ||
| 1775 | ||
| 1776 | ||
| 1777 | ||
| 1778 | ||
| 1779 | ||
| 1780 | ||
| 1781 | ||
| 1782 | ||
| 1783 | ||
| 1784 | ||
| 1785 | ||
| 1786 | ||
| 1787 | ||
| 1788 | ||
| 1789 | ||
| 1790 | ||
| 1791 | ||
| 1792 | ||
| 1793 | ||
| 1794 | ||
| 1795 | ||
| 1796 | ||
| 1797 | Leach & Newman Expires: December 2003 [Page 30] | |
| 1798 | ||
| 1799 | ||
| 1800 | ||
| 1801 | ||
| 1802 | ||
| 1803 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1804 | ||
| 1805 | ||
| 1806 | 7 ABNF | |
| 1807 | ||
| 1808 | What follows is the definition of the notation as is used in the | |
| 1809 | HTTP/1.1 specification [RFC 2616] and the HTTP authentication | |
| 1810 | specification [Digest]; it is reproduced here for ease of reference. | |
| 1811 | Since it is intended that a single Digest implementation can support | |
| 1812 | both HTTP and SASL-based protocols, the same notation is used in both | |
| 1813 | to facilitate comparison and prevention of unwanted differences. | |
| 1814 | Since it is cut-and-paste from the HTTP specifications, not all | |
| 1815 | productions may be used in this specification. It is also not quite | |
| 1816 | legal ABNF; again, the errors were copied from the HTTP | |
| 1817 | specifications. | |
| 1818 | ||
| 1819 | 7.1 Augmented BNF | |
| 1820 | ||
| 1821 | All of the mechanisms specified in this document are described in | |
| 1822 | both prose and an augmented Backus-Naur Form (BNF) similar to that | |
| 1823 | used by RFC 822 [RFC 822]. Implementers will need to be familiar with | |
| 1824 | the notation in order to understand this specification. | |
| 1825 | ||
| 1826 | The augmented BNF includes the following constructs: | |
| 1827 | ||
| 1828 | name = definition | |
| 1829 | The name of a rule is simply the name itself (without any | |
| 1830 | enclosing "<" and ">") and is separated from its definition by the | |
| 1831 | equal "=" character. White space is only significant in that | |
| 1832 | indentation of continuation lines is used to indicate a rule | |
| 1833 | definition that spans more than one line. Certain basic rules are | |
| 1834 | in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle | |
| 1835 | brackets are used within definitions whenever their presence will | |
| 1836 | facilitate discerning the use of rule names. | |
| 1837 | ||
| 1838 | "literal" | |
| 1839 | Quotation marks surround literal text. Unless stated otherwise, | |
| 1840 | the text is case-insensitive. | |
| 1841 | ||
| 1842 | rule1 | rule2 | |
| 1843 | Elements separated by a bar ("|") are alternatives, e.g., "yes | | |
| 1844 | no" will accept yes or no. | |
| 1845 | ||
| 1846 | (rule1 rule2) | |
| 1847 | Elements enclosed in parentheses are treated as a single element. | |
| 1848 | Thus, "(elem (foo | bar) elem)" allows the token sequences | |
| 1849 | "elem foo elem" and "elem bar elem". | |
| 1850 | ||
| 1851 | *rule | |
| 1852 | The character "*" preceding an element indicates repetition. The | |
| 1853 | full form is "<n>*<m>element" indicating at least <n> and at most | |
| 1854 | ||
| 1855 | ||
| 1856 | ||
| 1857 | Leach & Newman Expires: December 2003 [Page 31] | |
| 1858 | ||
| 1859 | ||
| 1860 | ||
| 1861 | ||
| 1862 | ||
| 1863 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1864 | ||
| 1865 | ||
| 1866 | <m> occurrences of element. Default values are 0 and infinity so | |
| 1867 | that "*(element)" allows any number, including zero; "1*element" | |
| 1868 | requires at least one; and "1*2element" allows one or two. | |
| 1869 | ||
| 1870 | [rule] | |
| 1871 | Square brackets enclose optional elements; "[foo bar]" is | |
| 1872 | equivalent to "*1(foo bar)". | |
| 1873 | ||
| 1874 | N rule | |
| 1875 | Specific repetition: "<n>(element)" is equivalent to | |
| 1876 | "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). | |
| 1877 | Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three | |
| 1878 | alphabetic characters. | |
| 1879 | ||
| 1880 | #rule | |
| 1881 | A construct "#" is defined, similar to "*", for defining lists of | |
| 1882 | elements. The full form is "<n>#<m>element" indicating at least | |
| 1883 | <n> and at most <m> elements, each separated by one or more commas | |
| 1884 | (",") and OPTIONAL linear white space (LWS). This makes the usual | |
| 1885 | form of lists very easy; a rule such as | |
| 1886 | ( *LWS element *( *LWS "," *LWS element )) | |
| 1887 | can be shown as | |
| 1888 | 1#element | |
| 1889 | Wherever this construct is used, null elements are allowed, but do | |
| 1890 | not contribute to the count of elements present. That is, | |
| 1891 | "(element), , (element) " is permitted, but counts as only two | |
| 1892 | elements. Therefore, where at least one element is required, at | |
| 1893 | least one non-null element MUST be present. Default values are 0 | |
| 1894 | and infinity so that "#element" allows any number, including zero; | |
| 1895 | "1#element" requires at least one; and "1#2element" allows one or | |
| 1896 | two. | |
| 1897 | ||
| 1898 | ; comment | |
| 1899 | A semi-colon, set off some distance to the right of rule text, | |
| 1900 | starts a comment that continues to the end of line. This is a | |
| 1901 | simple way of including useful notes in parallel with the | |
| 1902 | specifications. | |
| 1903 | ||
| 1904 | implied *LWS | |
| 1905 | The grammar described by this specification is word-based. Except | |
| 1906 | where noted otherwise, linear white space (LWS) can be included | |
| 1907 | between any two adjacent words (token or quoted-string), and | |
| 1908 | between adjacent words and separators, without changing the | |
| 1909 | interpretation of a field. At least one delimiter (LWS and/or | |
| 1910 | separators) MUST exist between any two tokens (for the definition | |
| 1911 | of "token" below), since they would otherwise be interpreted as a | |
| 1912 | single token. | |
| 1913 | ||
| 1914 | ||
| 1915 | ||
| 1916 | ||
| 1917 | Leach & Newman Expires: December 2003 [Page 32] | |
| 1918 | ||
| 1919 | ||
| 1920 | ||
| 1921 | ||
| 1922 | ||
| 1923 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1924 | ||
| 1925 | ||
| 1926 | 7.2 Basic Rules | |
| 1927 | ||
| 1928 | The following rules are used throughout this specification to | |
| 1929 | describe basic parsing constructs. The US-ASCII coded character set | |
| 1930 | is defined by ANSI X3.4-1986 [USASCII]. | |
| 1931 | ||
| 1932 | OCTET = <any 8-bit character> | |
| 1933 | CHAR = <any US-ASCII character (octets 0 - 127)> | |
| 1934 | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> | |
| 1935 | LOALPHA = <any US-ASCII lowercase letter "a".."z"> | |
| 1936 | ALPHA = UPALPHA | LOALPHA | |
| 1937 | DIGIT = <any US-ASCII digit "0".."9"> | |
| 1938 | CTL = <any US-ASCII control character | |
| 1939 | (octets 0 - 31) and DEL (127)> | |
| 1940 | CR = <US-ASCII CR, carriage return (13)> | |
| 1941 | LF = <US-ASCII LF, linefeed (10)> | |
| 1942 | SP = <US-ASCII SP, space (32)> | |
| 1943 | HT = <US-ASCII HT, horizontal-tab (9)> | |
| 1944 | <"> = <US-ASCII double-quote mark (34)> | |
| 1945 | TEXTCHAR = <any OCTET except CTLs, but including HT> | |
| 1946 | CRLF = CR LF | |
| 1947 | ||
| 1948 | All linear white space, including folding, has the same semantics as | |
| 1949 | SP. A recipient MAY replace any linear white space with a single SP | |
| 1950 | before interpreting the field value or forwarding the message | |
| 1951 | downstream. | |
| 1952 | ||
| 1953 | LWS = [CRLF] 1*( SP | HT ) | |
| 1954 | ||
| 1955 | The TEXT rule is only used for descriptive field contents and values | |
| 1956 | that are not intended to be interpreted by the message parser. Words | |
| 1957 | of TEXT contains characters either from ISO-8859-1 [ISO-8859] | |
| 1958 | character set or UTF-8 [UTF-8]. | |
| 1959 | ||
| 1960 | TEXT = <any *OCTET except CTLs, | |
| 1961 | but including LWS> | |
| 1962 | ||
| 1963 | A CRLF is allowed in the definition of TEXT only as part of a header | |
| 1964 | field continuation. It is expected that the folding LWS will be | |
| 1965 | replaced with a single SP before interpretation of the TEXT value. | |
| 1966 | ||
| 1967 | Hexadecimal numeric characters are used in several protocol elements. | |
| 1968 | ||
| 1969 | HEX = "A" | "B" | "C" | "D" | "E" | "F" | |
| 1970 | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | |
| 1971 | ||
| 1972 | Many HTTP/1.1 header field values consist of words separated by LWS | |
| 1973 | or special characters. These special characters MUST be in a quoted | |
| 1974 | ||
| 1975 | ||
| 1976 | ||
| 1977 | Leach & Newman Expires: December 2003 [Page 33] | |
| 1978 | ||
| 1979 | ||
| 1980 | ||
| 1981 | ||
| 1982 | ||
| 1983 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 1984 | ||
| 1985 | ||
| 1986 | string to be used within a parameter value. | |
| 1987 | ||
| 1988 | token = 1*TOKENCHAR | |
| 1989 | separators = "(" | ")" | "<" | ">" | "@" | |
| 1990 | | "," | ";" | ":" | "\" | <"> | |
| 1991 | | "/" | "[" | "]" | "?" | "=" | |
| 1992 | | "{" | "}" | SP | HT | |
| 1993 | TOKENCHAR = <any CHAR except CTLs or separators> | |
| 1994 | ||
| 1995 | A string of text is parsed as a single word if it is quoted using | |
| 1996 | double-quote marks. | |
| 1997 | ||
| 1998 | quoted-string = ( <"> qdstr-val <"> ) | |
| 1999 | qdstr-val = *( qdtext | quoted-pair ) | |
| 2000 | qdtext = <any TEXTCHAR except <"> and "\"> | |
| 2001 | ||
| 2002 | Note that LWS is NOT implicit between the double-quote marks (<">) | |
| 2003 | surrounding a qdstr-val and the qdstr-val; any LWS will be considered | |
| 2004 | part of the qdstr-val. This is also the case for quotation marks | |
| 2005 | surrounding any other construct. | |
| 2006 | ||
| 2007 | The backslash character ("\") MAY be used as a single-character | |
| 2008 | quoting mechanism only within qdstr-val and comment constructs. | |
| 2009 | ||
| 2010 | quoted-pair = "\" CHAR | |
| 2011 | ||
| 2012 | The value of this construct is CHAR. Note that an effect of this rule | |
| 2013 | is that backslash itself MUST be quoted. | |
| 2014 | ||
| 2015 | ||
| 2016 | ||
| 2017 | ||
| 2018 | ||
| 2019 | ||
| 2020 | ||
| 2021 | ||
| 2022 | ||
| 2023 | ||
| 2024 | ||
| 2025 | ||
| 2026 | ||
| 2027 | ||
| 2028 | ||
| 2029 | ||
| 2030 | ||
| 2031 | ||
| 2032 | ||
| 2033 | ||
| 2034 | ||
| 2035 | ||
| 2036 | ||
| 2037 | Leach & Newman Expires: December 2003 [Page 34] | |
| 2038 | ||
| 2039 | ||
| 2040 | ||
| 2041 | ||
| 2042 | ||
| 2043 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 2044 | ||
| 2045 | ||
| 2046 | 8 Sample Code | |
| 2047 | ||
| 2048 | The sample implementation in [Digest] also applies to DIGEST-MD5. | |
| 2049 | ||
| 2050 | The following code implements the conversion from UTF-8 to 8859-1 if | |
| 2051 | necessary. | |
| 2052 | ||
| 2053 | /* if the string is entirely in the 8859-1 subset of UTF-8, then | |
| 2054 | * translate to 8859-1 prior to MD5 | |
| 2055 | */ | |
| 2056 | void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base, | |
| 2057 | int len) | |
| 2058 | { | |
| 2059 | const unsigned char *scan, *end; | |
| 2060 | unsigned char cbuf; | |
| 2061 | ||
| 2062 | end = base + len; | |
| 2063 | for (scan = base; scan < end; ++scan) { | |
| 2064 | if (*scan > 0xC3) break; /* abort if outside 8859-1 */ | |
| 2065 | if (*scan >= 0xC0 && *scan <= 0xC3) { | |
| 2066 | if (++scan == end || *scan < 0x80 || *scan > 0xBF) | |
| 2067 | break; | |
| 2068 | } | |
| 2069 | } | |
| 2070 | /* if we found a character outside 8859-1, don't alter string | |
| 2071 | */ | |
| 2072 | if (scan < end) { | |
| 2073 | MD5Update(ctx, base, len); | |
| 2074 | return; | |
| 2075 | } | |
| 2076 | ||
| 2077 | /* convert to 8859-1 prior to applying hash | |
| 2078 | */ | |
| 2079 | do { | |
| 2080 | for (scan = base; scan < end && *scan < 0xC0; ++scan) | |
| 2081 | ; | |
| 2082 | if (scan != base) MD5Update(ctx, base, scan - base); | |
| 2083 | if (scan + 1 >= end) break; | |
| 2084 | cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f); | |
| 2085 | MD5Update(ctx, &cbuf, 1); | |
| 2086 | base = scan + 2; | |
| 2087 | } while (base < end); | |
| 2088 | } | |
| 2089 | ||
| 2090 | ||
| 2091 | ||
| 2092 | ||
| 2093 | ||
| 2094 | ||
| 2095 | ||
| 2096 | ||
| 2097 | Leach & Newman Expires: December 2003 [Page 35] | |
| 2098 | ||
| 2099 | ||
| 2100 | ||
| 2101 | ||
| 2102 | ||
| 2103 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 2104 | ||
| 2105 | ||
| 2106 | 9 Interoperability considerations | |
| 2107 | ||
| 2108 | 9.1 Implementing DES cipher in CBC mode | |
| 2109 | ||
| 2110 | Several cryptographic libraries (Ebones, OpenSSL) provide a convenience | |
| 2111 | function des_cbc_encrypt for implementing DES cipher in CBC mode. | |
| 2112 | There is a documented bug in this function: the function doesn't update | |
| 2113 | IV before returning. If an implementation uses this function to implement | |
| 2114 | DES cipher in CBC mode, it MUST update IV by copying the last 8 bytes of | |
| 2115 | the des_cbc_encrypt's output to the IV buffer. | |
| 2116 | Note that the function des_ede2_cbc_encrypt that may be used to implement | |
| 2117 | 3DES (in "two keys mode") in CBC mode works as expected. | |
| 2118 | ||
| 2119 | Care must be taken when configuring the DES keys for most DES | |
| 2120 | libraries. This specification gives 56 bits for the DES key (or 112 | |
| 2121 | bits for the 3DES key); libraries generally expect the key to be given | |
| 2122 | in a 64 bit (128 bit for 3DES) form. | |
| 2123 | ||
| 2124 | The following C function can be used to convert a 56 bit DES key into a | |
| 2125 | form acceptable for the libraries. The low order bit in each byte | |
| 2126 | would contain parity information and will be corrected by the library. | |
| 2127 | ||
| 2128 | /* slide the first 7 bytes of 'inbuf' into the high seven bits of the | |
| 2129 | first 8 bytes of 'keybuf'. 'keybuf' better be 8 bytes long or longer. */ | |
| 2130 | void slidebits(unsigned char *keybuf, unsigned char *inbuf) | |
| 2131 | { | |
| 2132 | keybuf[0] = inbuf[0]; | |
| 2133 | keybuf[1] = (inbuf[0]<<7) | (inbuf[1]>>1); | |
| 2134 | keybuf[2] = (inbuf[1]<<6) | (inbuf[2]>>2); | |
| 2135 | keybuf[3] = (inbuf[2]<<5) | (inbuf[3]>>3); | |
| 2136 | keybuf[4] = (inbuf[3]<<4) | (inbuf[4]>>4); | |
| 2137 | keybuf[5] = (inbuf[4]<<3) | (inbuf[5]>>5); | |
| 2138 | keybuf[6] = (inbuf[5]<<2) | (inbuf[6]>>6); | |
| 2139 | keybuf[7] = (inbuf[6]<<1); | |
| 2140 | } | |
| 2141 | ||
| 2142 | 10 Acknowledgements | |
| 2143 | ||
| 2144 | The following people had substantial contributions to the development | |
| 2145 | and/or refinement of this document: | |
| 2146 | ||
| 2147 | Lawrence Greenfield John Gardiner Myers Simon Josefsson RL Bob Morgan | |
| 2148 | Jeff Hodges Claus Assmann Tony Hansen Sam Hartman | |
| 2149 | ||
| 2150 | as well as other members of the SASL mailing list. | |
| 2151 | ||
| 2152 | The text used is section 3.8 was taken from [TLS-CBC] by Bodo | |
| 2153 | Moeller. | |
| 2154 | ||
| 2155 | ||
| 2156 | ||
| 2157 | Leach & Newman Expires: December 2003 [Page 36] | |
| 2158 | ||
| 2159 | ||
| 2160 | ||
| 2161 | ||
| 2162 | ||
| 2163 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 2164 | ||
| 2165 | ||
| 2166 | 11 Full Copyright Statement | |
| 2167 | ||
| 2168 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 2169 | ||
| 2170 | This document and translations of it may be copied and furnished to | |
| 2171 | others, and derivative works that comment on or otherwise explain it | |
| 2172 | or assist in its implementation may be prepared, copied, published | |
| 2173 | and distributed, in whole or in part, without restriction of any | |
| 2174 | kind, provided that the above copyright notice and this paragraph are | |
| 2175 | included on all such copies and derivative works. However, this | |
| 2176 | document itself may not be modified in any way, such as by removing | |
| 2177 | the copyright notice or references to the Internet Society or other | |
| 2178 | Internet organizations, except as needed for the purpose of | |
| 2179 | developing Internet standards in which case the procedures for | |
| 2180 | copyrights defined in the Internet Standards process must be | |
| 2181 | followed, or as required to translate it into languages other than | |
| 2182 | English. | |
| 2183 | ||
| 2184 | The limited permissions granted above are perpetual and will not be | |
| 2185 | revoked by the Internet Society or its successors or assigns. | |
| 2186 | ||
| 2187 | This document and the information contained herein is provided on an | |
| 2188 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 2189 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 2190 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 2191 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 2192 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 2193 | ||
| 2194 | Acknowledgement | |
| 2195 | ||
| 2196 | Funding for the RFC Editor function is currently provided by the | |
| 2197 | Internet Society. | |
| 2198 | ||
| 2199 | ||
| 2200 | ||
| 2201 | ||
| 2202 | ||
| 2203 | ||
| 2204 | ||
| 2205 | ||
| 2206 | ||
| 2207 | ||
| 2208 | ||
| 2209 | ||
| 2210 | ||
| 2211 | ||
| 2212 | ||
| 2213 | ||
| 2214 | ||
| 2215 | ||
| 2216 | ||
| 2217 | Leach & Newman Expires: December 2003 [Page 37] | |
| 2218 | ||
| 2219 | ||
| 2220 | ||
| 2221 | ||
| 2222 | ||
| 2223 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 2224 | ||
| 2225 | ||
| 2226 | Appendix A: Changes from 2831 | |
| 2227 | ||
| 2228 | 1). Fixed various typos in formulas. | |
| 2229 | ||
| 2230 | 2). Dropped DES as mandatory to implement cipher (3DES is mandatory | |
| 2231 | to implement). | |
| 2232 | ||
| 2233 | 3). Tighten ABNF. Fixed some bugs. | |
| 2234 | ||
| 2235 | 4). Clarified nc-value verification and which side is aborting | |
| 2236 | exchange. | |
| 2237 | ||
| 2238 | 5). Added text saying that for interoperability | |
| 2239 | username/password/realm MUST be prepared using the "SASLPrep" profile | |
| 2240 | [SASLPrep] of the "stringprep" algorithm [StringPrep]. | |
| 2241 | ||
| 2242 | 6). Clarified that unquoted version of the username, etc. used in A1 | |
| 2243 | calculation. | |
| 2244 | ||
| 2245 | 7). Various cleanup to References section. Split all references to | |
| 2246 | Normative and Informative. | |
| 2247 | ||
| 2248 | 8). Added minimal and maximal limits on maxbuf. Clarified how to | |
| 2249 | calculate max sender size. | |
| 2250 | ||
| 2251 | 9). Change ABNF for host to allow for IPv6 addresses. ABNF now | |
| 2252 | references RFC 2373 and RFC 2396. | |
| 2253 | ||
| 2254 | 10). Added DES cipher interoperability section. | |
| 2255 | ||
| 2256 | 11). Added man-in-the-middle considerations for ciphers. | |
| 2257 | ||
| 2258 | 12). Clarified how sequence counters are modified. | |
| 2259 | ||
| 2260 | 13). Addition warnings about preventing reply/redirection attacks. | |
| 2261 | ||
| 2262 | 14). Specified that "charset" directive affects "realm" and doesn't | |
| 2263 | affect | |
| 2264 | "authzid". | |
| 2265 | ||
| 2266 | 15). Removed text that described that "authzid" is in Unicode in | |
| 2267 | Normalization | |
| 2268 | Form KC, encoded as UTF-8. | |
| 2269 | ||
| 2270 | 16). Clarified that rc4 state is not reset between two sent/received | |
| 2271 | buffers | |
| 2272 | of encoded data. | |
| 2273 | ||
| 2274 | ||
| 2275 | ||
| 2276 | ||
| 2277 | Leach & Newman Expires: December 2003 [Page 38] | |
| 2278 | ||
| 2279 | ||
| 2280 | ||
| 2281 | ||
| 2282 | ||
| 2283 | INTERNET DRAFT Digest SASL Mechanism June 2003 | |
| 2284 | ||
| 2285 | ||
| 2286 | 17). Clarified that for DES/3DES the IV for the next buffer of | |
| 2287 | encoded data is | |
| 2288 | the last 8 bytes of the ciphertext. | |
| 2289 | ||
| 2290 | 18). Clarified how "maximal sender size" is calculated. | |
| 2291 | ||
| 2292 | 19). Prohibit an empty authzid. | |
| 2293 | ||
| 2294 | 20). Added AES cipher defined in "AES Ciphersuite for DIGEST-MD5 SASL | |
| 2295 | mechanism" | |
| 2296 | document (expired draft-ietf-sasl-digest-aes-00.txt). | |
| 2297 | ||
| 2298 | 21). Minor text clarifications. | |
| 2299 | ||
| 2300 | Appendix B: Open Issues/ToDo List | |
| 2301 | ||
| 2302 | 1). The latest revision prohibits escaped characters in nonce/cnonce. | |
| 2303 | This is different | |
| 2304 | from HTTP Digest. Any objections? | |
| 2305 | ||
| 2306 | 2). Do we need/want a new stringprep profile for "realm"? | |
| 2307 | ||
| 2308 | 3). What to do about CBC mode attack that affects TLS document and | |
| 2309 | DIGEST-MD5 as well? | |
| 2310 | ||
| 2311 | One of the proposals is to drop DES/3DES ciphers and define a new one | |
| 2312 | (e.g. AES) in such a way that is not susceptible to this kind of | |
| 2313 | attack. | |
| 2314 | ||
| 2315 | AES cipher has to be fixed to prevent this attack. | |
| 2316 | ||
| 2317 | 4). Add reference to CBC mode attack: | |
| 2318 | ||
| 2319 | This problem is described in LASEC Memo "Password Interception in a | |
| 2320 | SSL/TLS Channel" by Brice Canvel, published 2003-02-20: | |
| 2321 | http://lasecwww.epfl.ch/memo_ssl.shtml | |
| 2322 | ||
| 2323 | 5). Normative vs. Informative references must be carefully rechecked. | |
| 2324 | ||
| 2325 | ||
| 2326 | ||
| 2327 | ||
| 2328 | ||
| 2329 | ||
| 2330 | ||
| 2331 | ||
| 2332 | ||
| 2333 | ||
| 2334 | ||
| 2335 | ||
| 2336 | ||
| 2337 | Leach & Newman Expires: December 2003 [Page 39] | |
| 2338 | ||
| 2339 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | INTERNET-DRAFT Kurt D. Zeilenga | |
| 7 | Intended Category: Standards Track OpenLDAP Foundation | |
| 8 | Expires in six months 27 October 2003 | |
| 9 | ||
| 10 | ||
| 11 | SASLprep: Stringprep profile for user names and passwords | |
| 12 | <draft-ietf-sasl-saslprep-04.txt> | |
| 13 | ||
| 14 | ||
| 15 | Status of Memo | |
| 16 | ||
| 17 | This document is an Internet-Draft and is in full conformance with all | |
| 18 | provisions of Section 10 of RFC 2026. | |
| 19 | ||
| 20 | This document is intended to be, after appropriate review and | |
| 21 | revision, submitted to the RFC Editor as a Standards Track document. | |
| 22 | Distribution of this memo is unlimited. Technical discussion of this | |
| 23 | document will take place on the IETF SASL mailing list | |
| 24 | <ietf-sasl@imc.org>. Please send editorial comments directly to the | |
| 25 | document editor <Kurt@OpenLDAP.org>. | |
| 26 | ||
| 27 | Internet-Drafts are working documents of the Internet Engineering Task | |
| 28 | Force (IETF), its areas, and its working groups. Note that other | |
| 29 | groups may also distribute working documents as Internet-Drafts. | |
| 30 | Internet-Drafts are draft documents valid for a maximum of six months | |
| 31 | and may be updated, replaced, or obsoleted by other documents at any | |
| 32 | time. It is inappropriate to use Internet-Drafts as reference | |
| 33 | material or to cite them other than as ``work in progress.'' | |
| 34 | ||
| 35 | The list of current Internet-Drafts can be accessed at | |
| 36 | <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of | |
| 37 | Internet-Draft Shadow Directories can be accessed at | |
| 38 | <http://www.ietf.org/shadow.html>. | |
| 39 | ||
| 40 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 41 | ||
| 42 | Please see the Full Copyright section near the end of this document | |
| 43 | for more information. | |
| 44 | ||
| 45 | ||
| 46 | Abstract | |
| 47 | ||
| 48 | This document describes how to prepare Unicode strings representing | |
| 49 | user names and passwords for comparison. The document defines the | |
| 50 | "SASLprep" profile of the "stringprep" algorithm to be used for both | |
| 51 | user names and passwords. This profile is intended to be used by | |
| 52 | Simple Authentication and Security Layer (SASL) mechanisms (such as | |
| 53 | PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Zeilenga SASLprep [Page 1] | |
| 58 | ||
| 59 | INTERNET-DRAFT draft-ietf-sasl-saslprep-04.txt 27 October 2003 | |
| 60 | ||
| 61 | ||
| 62 | user names and/or passwords. | |
| 63 | ||
| 64 | ||
| 65 | 1. Introduction | |
| 66 | ||
| 67 | The use of simple user names and passwords in authentication and | |
| 68 | authorization is pervasive on the Internet. To increase the | |
| 69 | likelihood that user name and password input and comparison work in | |
| 70 | ways that make sense for typical users throughout the world, this | |
| 71 | document defines rules for preparing internationalized user names and | |
| 72 | passwords for comparison. For simplicity and implementation ease, a | |
| 73 | single algorithm is defined for both user names and passwords. | |
| 74 | ||
| 75 | This document defines the "SASLprep" profile of the "stringprep" | |
| 76 | algorithm [StringPrep]. | |
| 77 | ||
| 78 | The profile is designed for use in Simple Authentication and Security | |
| 79 | Layer ([SASL]) mechanisms such as [PLAIN]. It may be applicable | |
| 80 | elsewhere simple user names and passwords are used. This profile is | |
| 81 | not intended to be used for arbitrary text. This profile is also not | |
| 82 | intended to be used to prepare identity strings which are not simple | |
| 83 | user names (e.g., e-mail addresses, domain names, distinguished | |
| 84 | names). | |
| 85 | ||
| 86 | ||
| 87 | 2. The SASLprep profile | |
| 88 | ||
| 89 | This section defines the "SASLprep" profile. This profile is intended | |
| 90 | to be used to prepare strings representing simple user names and | |
| 91 | passwords. | |
| 92 | ||
| 93 | This profile uses Unicode 3.2, as defined in [StringPrep, A.1]. | |
| 94 | ||
| 95 | Character names in this document use the notation for code points and | |
| 96 | names from the Unicode Standard [Unicode]. For example, the letter | |
| 97 | "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. | |
| 98 | In the lists of mappings and the prohibited characters, the "U+" is | |
| 99 | left off to make the lists easier to read. The comments for character | |
| 100 | ranges are shown in square brackets (such as "[CONTROL CHARACTERS]") | |
| 101 | and do not come from the standard. | |
| 102 | ||
| 103 | Note: a glossary of terms used in Unicode can be found in [Glossary]. | |
| 104 | Information on the Unicode character encoding model can be found in | |
| 105 | [CharModel]. | |
| 106 | ||
| 107 | ||
| 108 | 2.1. Mapping | |
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Zeilenga SASLprep [Page 2] | |
| 114 | ||
| 115 | INTERNET-DRAFT draft-ietf-sasl-saslprep-04.txt 27 October 2003 | |
| 116 | ||
| 117 | ||
| 118 | This profile specifies: | |
| 119 | - non-ASCII space characters [StringPrep, C.1.2] be mapped to SPACE | |
| 120 | (U+0020), and | |
| 121 | ||
| 122 | - the "commonly mapped to nothing" characters [StringPrep, B.1] be | |
| 123 | mapped to nothing. | |
| 124 | ||
| 125 | ||
| 126 | ||
| 127 | 2.2. Normalization | |
| 128 | ||
| 129 | This profile specifies using Unicode normalization form KC, as | |
| 130 | described in Section 4 of [StringPrep]. | |
| 131 | ||
| 132 | ||
| 133 | 2.3. Prohibited Output | |
| 134 | ||
| 135 | This profile specifies the following characters: | |
| 136 | ||
| 137 | - Non-ASCII space characters [StringPrep, C.1.2], | |
| 138 | - ASCII control characters [StringPrep, C.2.1], | |
| 139 | - Non-ASCII control characters [StringPrep, C.2.2], | |
| 140 | - Private Use [StringPrep, C.3], | |
| 141 | - Non-character code points [StringPrep, C.4], | |
| 142 | - Surrogate code points [StringPrep, C.5], | |
| 143 | - Inappropriate for plain text [StringPrep, C.6], | |
| 144 | - Inappropriate for canonical representation [StringPrep, C.7], | |
| 145 | - Change display properties or are deprecated [StringPrep, C.8], and | |
| 146 | - Tagging characters [StringPrep, C.9]. | |
| 147 | ||
| 148 | are prohibited output. | |
| 149 | ||
| 150 | ||
| 151 | 2.4. Bidirectional characters | |
| 152 | ||
| 153 | This profile specifies checking bidirectional strings as described in | |
| 154 | [StringPrep, Section 6]. | |
| 155 | ||
| 156 | ||
| 157 | 2.5. Unassigned Code Points | |
| 158 | ||
| 159 | This profile specifies [StringPrep, A.1] table as its list of | |
| 160 | unassigned code points. | |
| 161 | ||
| 162 | ||
| 163 | 3. Security Considerations | |
| 164 | ||
| 165 | This profile is intended to used to prepare simple user names and | |
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Zeilenga SASLprep [Page 3] | |
| 170 | ||
| 171 | INTERNET-DRAFT draft-ietf-sasl-saslprep-04.txt 27 October 2003 | |
| 172 | ||
| 173 | ||
| 174 | passwords for comparison. It is not intended to be used for to | |
| 175 | prepare identities which are not simple user names (e.g., | |
| 176 | distinguished names and domain names). Nor is the profile intended to | |
| 177 | be used for simple user names which require different handling. | |
| 178 | Protocols (or applications of those protocols) which have | |
| 179 | application-specific identity forms and/or comparison algorithms | |
| 180 | should use mechanisms specifically designed for these forms and | |
| 181 | algorithms. | |
| 182 | ||
| 183 | User names and passwords should be protected from eavesdropping. | |
| 184 | ||
| 185 | General "stringprep" and Unicode security considerations apply. Both | |
| 186 | are discussed in [StringPrep]. | |
| 187 | ||
| 188 | ||
| 189 | 4. IANA Considerations | |
| 190 | ||
| 191 | This document details the "SASLprep" profile of [StringPrep] protocol. | |
| 192 | Upon Standards Action the profile should be registered in the | |
| 193 | stringprep profile registry. | |
| 194 | ||
| 195 | Name of this profile: SASLprep | |
| 196 | RFC in which the profile is defined: This RFC | |
| 197 | Indicator whether or not this is the newest version of the | |
| 198 | profile: This is the first version of the SASPprep profile. | |
| 199 | ||
| 200 | ||
| 201 | 5. Acknowledgment | |
| 202 | ||
| 203 | This document borrows text from "Preparation of Internationalized | |
| 204 | Strings ('stringprep')" and "Nameprep: A Stringprep Profile for | |
| 205 | Internationalized Domain Names", both by Paul Hoffman and Marc | |
| 206 | Blanchet. | |
| 207 | ||
| 208 | This document is a product of the IETF SASL WG. | |
| 209 | ||
| 210 | ||
| 211 | 6. Normative References | |
| 212 | ||
| 213 | [StringPrep] Hoffman P. and M. Blanchet, "Preparation of | |
| 214 | Internationalized Strings ('stringprep')", | |
| 215 | draft-hoffman-rfc3454bis-xx.txt, a work in progress. | |
| 216 | ||
| 217 | [SASL] Melnikov, A. (Editor), "Simple Authentication and | |
| 218 | Security Layer (SASL)", | |
| 219 | draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. | |
| 220 | ||
| 221 | [Unicode] The Unicode Consortium, "The Unicode Standard, Version | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Zeilenga SASLprep [Page 4] | |
| 226 | ||
| 227 | INTERNET-DRAFT draft-ietf-sasl-saslprep-04.txt 27 October 2003 | |
| 228 | ||
| 229 | ||
| 230 | 3.2.0" is defined by "The Unicode Standard, Version 3.0" | |
| 231 | (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), | |
| 232 | as amended by the "Unicode Standard Annex #27: Unicode | |
| 233 | 3.1" (http://www.unicode.org/reports/tr27/) and by the | |
| 234 | "Unicode Standard Annex #28: Unicode 3.2" | |
| 235 | (http://www.unicode.org/reports/tr28/). | |
| 236 | ||
| 237 | ||
| 238 | 7. Informative References | |
| 239 | ||
| 240 | [Glossary] The Unicode Consortium, "Unicode Glossary", | |
| 241 | <http://www.unicode.org/glossary/>. | |
| 242 | ||
| 243 | [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report | |
| 244 | #17, Character Encoding Model", UTR17, | |
| 245 | <http://www.unicode.org/unicode/reports/tr17/>, August | |
| 246 | 2000. | |
| 247 | ||
| 248 | [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", | |
| 249 | draft-ietf-sasl-crammd5-xx.txt, a work in progress. | |
| 250 | ||
| 251 | [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest | |
| 252 | Authentication as a SASL Mechanism", | |
| 253 | draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress. | |
| 254 | ||
| 255 | [PLAIN] Zeilenga, K. (Editor), "The Plain SASL Mechanism", | |
| 256 | draft-ietf-sasl-plain-xx.txt, a work in progress. | |
| 257 | ||
| 258 | ||
| 259 | 8. Editor's Address | |
| 260 | ||
| 261 | Kurt Zeilenga | |
| 262 | OpenLDAP Foundation | |
| 263 | ||
| 264 | Email: kurt@OpenLDAP.org | |
| 265 | ||
| 266 | ||
| 267 | Intellectual Property Rights | |
| 268 | ||
| 269 | The IETF takes no position regarding the validity or scope of any | |
| 270 | intellectual property or other rights that might be claimed to pertain | |
| 271 | to the implementation or use of the technology described in this | |
| 272 | document or the extent to which any license under such rights might or | |
| 273 | might not be available; neither does it represent that it has made any | |
| 274 | effort to identify any such rights. Information on the IETF's | |
| 275 | procedures with respect to rights in standards-track and | |
| 276 | standards-related documentation can be found in BCP-11. Copies of | |
| 277 | claims of rights made available for publication and any assurances of | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Zeilenga SASLprep [Page 5] | |
| 282 | ||
| 283 | INTERNET-DRAFT draft-ietf-sasl-saslprep-04.txt 27 October 2003 | |
| 284 | ||
| 285 | ||
| 286 | licenses to be made available, or the result of an attempt made to | |
| 287 | obtain a general license or permission for the use of such proprietary | |
| 288 | rights by implementors or users of this specification can be obtained | |
| 289 | from the IETF Secretariat. | |
| 290 | ||
| 291 | The IETF invites any interested party to bring to its attention any | |
| 292 | copyrights, patents or patent applications, or other proprietary | |
| 293 | rights which may cover technology that may be required to practice | |
| 294 | this standard. Please address the information to the IETF Executive | |
| 295 | Director. | |
| 296 | ||
| 297 | ||
| 298 | Full Copyright | |
| 299 | ||
| 300 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 301 | ||
| 302 | This document and translations of it may be copied and furnished to | |
| 303 | others, and derivative works that comment on or otherwise explain it | |
| 304 | or assist in its implmentation may be prepared, copied, published and | |
| 305 | distributed, in whole or in part, without restriction of any kind, | |
| 306 | provided that the above copyright notice and this paragraph are | |
| 307 | included on all such copies and derivative works. However, this | |
| 308 | document itself may not be modified in any way, such as by removing | |
| 309 | the copyright notice or references to the Internet Society or other | |
| 310 | Internet organizations, except as needed for the purpose of | |
| 311 | developing Internet standards in which case the procedures for | |
| 312 | copyrights defined in the Internet Standards process must be followed, | |
| 313 | or as required to translate it into languages other than English. | |
| 314 | ||
| 315 | ||
| 316 | ||
| 317 | ||
| 318 | ||
| 319 | ||
| 320 | ||
| 321 | ||
| 322 | ||
| 323 | ||
| 324 | ||
| 325 | ||
| 326 | ||
| 327 | ||
| 328 | ||
| 329 | ||
| 330 | ||
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Zeilenga SASLprep [Page 6] | |
| 338 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | ||
| 7 | Internet Draft K. Murchison | |
| 8 | Category: Informational M. Crispin | |
| 9 | Expires: March 2, 2004 28 August 2003 | |
| 10 | ||
| 11 | ||
| 12 | The LOGIN SASL Mechanism | |
| 13 | ||
| 14 | <draft-murchison-sasl-login-00.txt> | |
| 15 | ||
| 16 | ||
| 17 | Status of this Memo | |
| 18 | ||
| 19 | This document is an Internet-Draft and is subject to all provisions | |
| 20 | of Section 10 of RFC2026. | |
| 21 | ||
| 22 | Internet-Drafts are working documents of the Internet Engineering | |
| 23 | Task Force (IETF), its areas, and its working groups. Note that | |
| 24 | other groups may also distribute working documents as | |
| 25 | Internet-Drafts. | |
| 26 | ||
| 27 | Internet-Drafts are draft documents valid for a maximum of six months | |
| 28 | and may be updated, replaced, or obsoleted by other documents at any | |
| 29 | time. It is inappropriate to use Internet-Drafts as reference | |
| 30 | material or to cite them other than as "work in progress." | |
| 31 | ||
| 32 | The list of current Internet-Drafts can be accessed at | |
| 33 | http://www.ietf.org/1id-abstracts.html | |
| 34 | ||
| 35 | The list of Internet-Draft Shadow Directories can be accessed at | |
| 36 | http://www.ietf.org/shadow.html | |
| 37 | ||
| 38 | ||
| 39 | Copyright Notice | |
| 40 | ||
| 41 | Copyright (C) The Internet Society 2003. All Rights Reserved. | |
| 42 | ||
| 43 | ||
| 44 | Abstract | |
| 45 | ||
| 46 | This document documents the obsolete clear-text user/password Simple | |
| 47 | Authentication and Security Layer (SASL) mechanism called the LOGIN | |
| 48 | mechanism. The LOGIN mechanism was intended to be used, in | |
| 49 | combination with data confidentiality services provided by a lower | |
| 50 | layer, in protocols which lack a simple password authentication | |
| 51 | command. | |
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | ||
| 58 | Expires: March 2, 2004 Murchison [Page 1] | |
| 59 | ||
| 60 | Internet Draft LOGIN SASL Mechanism August 28, 2004 | |
| 61 | ||
| 62 | ||
| 63 | ||
| 64 | Conventions Used in the Document | |
| 65 | ||
| 66 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
| 67 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
| 68 | document are to be interpreted as described in [KEYWORDS]. | |
| 69 | ||
| 70 | ||
| 71 | 1. Background and Intended Usage | |
| 72 | ||
| 73 | This document documents the obsolete LOGIN Simple Authentication and | |
| 74 | Security Layer ([SASL]) mechanism which was in use in protocols with | |
| 75 | no clear-text login command (e.g., [SMTP-AUTH]). | |
| 76 | ||
| 77 | Note: The LOGIN SASL mechanism is obsoleted in favor of the PLAIN | |
| 78 | SASL mechanism ([PLAIN]). The LOGIN mechanism is documented here | |
| 79 | only for the purpose of backwards compatibility with legacy software. | |
| 80 | Clients SHOULD implement the PLAIN SASL mechanism and use it whenever | |
| 81 | offered by a server. The LOGIN SASL mechanism SHOULD NOT be used by | |
| 82 | a client when other plaintext mechanisms are offered by a server. | |
| 83 | ||
| 84 | The name associated with this mechanism is "LOGIN". | |
| 85 | ||
| 86 | The LOGIN SASL mechanism does not provide a security layer. This | |
| 87 | mechanism MUST NOT be used without adequate security protection as | |
| 88 | the mechanism affords no integrity nor confidentiality protection | |
| 89 | itself. The LOGIN SASL mechanism MUST NOT be advertised or used in | |
| 90 | any configuration that prohibits the PLAIN mechanism or plaintext | |
| 91 | LOGIN (or USER/PASS) command that sends passwords in the clear. | |
| 92 | ||
| 93 | ||
| 94 | 2. LOGIN SASL Mechanism | |
| 95 | ||
| 96 | The authorization identity is the same string as the "username" in | |
| 97 | the traditional (non-SASL) LOGIN or USER commands; the authorization | |
| 98 | authenticator is the same string as the traditional "password". The | |
| 99 | authentication identity is the same as the authorization identity in | |
| 100 | this mechanism. | |
| 101 | ||
| 102 | Only US-ASCII printable characters SHOULD be used in the username and | |
| 103 | password to permit maximal interoperability. If non-US-ASCII | |
| 104 | characters are used in a username, they MUST use UTF-8. Passwords | |
| 105 | MAY contain arbitrary binary data excluding NUL, CR and LF | |
| 106 | characters. However, if a password is supplied to the client as a | |
| 107 | sequence of characters (e.g., a password dialog box), those | |
| 108 | characters MUST be encoded as UTF-8. | |
| 109 | ||
| 110 | The username MUST be less than 64 characters in length. | |
| 111 | ||
| 112 | ||
| 113 | ||
| 114 | Expires: March 2, 2004 Murchison [Page 2] | |
| 115 | ||
| 116 | Internet Draft LOGIN SASL Mechanism August 28, 2004 | |
| 117 | ||
| 118 | ||
| 119 | 2.1. Client side of authentication protocol exchange | |
| 120 | ||
| 121 | The client expects the server to issue a challenge. The client then | |
| 122 | responds with the authorization identity. The client then expects | |
| 123 | the server to issue a second challenge. The client then responds | |
| 124 | with the authorization authenticator. The contents of both | |
| 125 | challenges SHOULD be ignored. | |
| 126 | ||
| 127 | ||
| 128 | 2.2. Server side of authentication protocol exchange | |
| 129 | ||
| 130 | The server issues the string "User Name" in challenge, and receives a | |
| 131 | client response. This response is recorded as the authorization | |
| 132 | identity. The server then issues the string "Password" in challenge, | |
| 133 | and receives a client response. This response is recorded as the | |
| 134 | authorization authenticator. The server must verify that the | |
| 135 | authorization authenticator permits login as the authorization | |
| 136 | identity. | |
| 137 | ||
| 138 | Note: There is at least one widely deployed client which requires | |
| 139 | that the challenge strings transmitted by the server be "Username:" | |
| 140 | and "Password:" respectively. For this reason, server | |
| 141 | implementations MAY send these challenge strings instead of those | |
| 142 | listed above. | |
| 143 | ||
| 144 | ||
| 145 | 2.3. Example | |
| 146 | ||
| 147 | This example shows the use of the LOGIN mechanism with the SMTP AUTH | |
| 148 | command [SMTP-AUTH] under the protection of SMTP STARTTLS [SMTP-TLS]. | |
| 149 | The user name is "tim" and the password is "tanstaaftanstaaf". The | |
| 150 | base64 encoding of the challenges and responses is part of the SMTP | |
| 151 | AUTH command, not part of the LOGIN specification itself. "C:" and | |
| 152 | "S:" indicate lines sent by the client and server respectively. | |
| 153 | ||
| 154 | S: 220 smtp.example.com ESMTP server ready | |
| 155 | C: EHLO test.example.com | |
| 156 | S: 250-smtp.example.com | |
| 157 | S: 250-STARTTLS | |
| 158 | S: 250 AUTH CRAM-MD5 | |
| 159 | C: STARTTLS | |
| 160 | S: 220 Ready to start TLS | |
| 161 | <TLS negotiation, further commands are under TLS layer> | |
| 162 | C: EHLO test.example.com | |
| 163 | S: 250-smtp.example.com | |
| 164 | S: 250 AUTH LOGIN CRAM-MD5 | |
| 165 | C: AUTH LOGIN | |
| 166 | S: 334 VXNlciBOYW1lAA== | |
| 167 | ||
| 168 | ||
| 169 | ||
| 170 | Expires: March 2, 2004 Murchison [Page 3] | |
| 171 | ||
| 172 | Internet Draft LOGIN SASL Mechanism August 28, 2004 | |
| 173 | ||
| 174 | ||
| 175 | C: dGlt | |
| 176 | S: 334 UGFzc3dvcmQA | |
| 177 | C: dGFuc3RhYWZ0YW5zdGFhZg== | |
| 178 | S: 235 Authentication successful. | |
| 179 | ||
| 180 | ||
| 181 | 3. | |
| 182 | Security Considerations | |
| 183 | ||
| 184 | The LOGIN mechanism relies upon an underlying encryption layer or | |
| 185 | other secure channel for security. When used without an encryption | |
| 186 | layer or secure channel, it is vulnerable to a common network | |
| 187 | eavesdropping attack. Therefore the LOGIN mechanism MUST NOT be | |
| 188 | advertised or used in any configuration that prohibits the PLAIN | |
| 189 | mechanism or a plaintext LOGIN (or USER/PASS) command that sends | |
| 190 | passwords in the clear. | |
| 191 | ||
| 192 | ||
| 193 | 4. | |
| 194 | IANA Considerations | |
| 195 | ||
| 196 | The registration for the LOGIN SASL mechanism follows: | |
| 197 | ||
| 198 | SASL mechanism name: LOGIN | |
| 199 | Security Considerations: See section 3 of this memo | |
| 200 | Published specification: this memo | |
| 201 | Person & email address to contact for futher information: | |
| 202 | See section 7 of this memo | |
| 203 | Intended usage: OBSOLETE | |
| 204 | Owner/Change controller: See section 7 of this memo | |
| 205 | ||
| 206 | ||
| 207 | 5. | |
| 208 | References | |
| 209 | ||
| 210 | ||
| 211 | 5.1. | |
| 212 | Normative References | |
| 213 | ||
| 214 | ||
| 215 | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |
| 216 | Requirement Levels", Harvard University, RFC 2119, March 1997. | |
| 217 | ||
| 218 | ||
| 219 | [SASL] Melnikov, A., Ed., "Simple Authentication and Security Layer | |
| 220 | (SASL)", Isode, draft-ietf-sasl-rfc2222bis-xx.txt, Work In | |
| 221 | Progress. | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | ||
| 226 | Expires: March 2, 2004 Murchison [Page 4] | |
| 227 | ||
| 228 | Internet Draft LOGIN SASL Mechanism August 28, 2004 | |
| 229 | ||
| 230 | ||
| 231 | 5.2. Informative References | |
| 232 | ||
| 233 | ||
| 234 | [PLAIN] Zeilenga, Kurt D., Ed., "The Plain SASL Mechanism", | |
| 235 | OpenLDAP Foundation, draft-ietf-sasl-plain-xx.txt, Work In | |
| 236 | Progress. | |
| 237 | ||
| 238 | ||
| 239 | [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", | |
| 240 | Netscape Communications, RFC 2554, March 1999. | |
| 241 | ||
| 242 | ||
| 243 | [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP | |
| 244 | over Transport Layer Security", Internet Mail Consortium, RFC | |
| 245 | 3207, February 2002. | |
| 246 | ||
| 247 | ||
| 248 | ||
| 249 | 6. Acknowledgments | |
| 250 | ||
| 251 | Thanks to Rob Siemborski for his input and feedback on this document. | |
| 252 | ||
| 253 | ||
| 254 | 7. | |
| 255 | Author's Address | |
| 256 | ||
| 257 | Kenneth Murchison | |
| 258 | Oceana Matrix Ltd. | |
| 259 | 21 Princeton Place | |
| 260 | Orchard Park, NY 14127 | |
| 261 | ||
| 262 | Phone: (716) 662-8973 | |
| 263 | ||
| 264 | EMail: ken@oceana.com | |
| 265 | ||
| 266 | ||
| 267 | ||
| 268 | ||
| 269 | Mark R. Crispin | |
| 270 | Networks and Distributed Computing | |
| 271 | University of Washington | |
| 272 | 4545 15th Avenue NE | |
| 273 | Seattle, WA 98105-4527 | |
| 274 | ||
| 275 | Phone: (206) 543-5762 | |
| 276 | ||
| 277 | EMail: MRC@CAC.Washington.EDU | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | ||
| 282 | Expires: March 2, 2004 Murchison [Page 5] | |
| 283 | ||
| 284 | Internet Draft LOGIN SASL Mechanism August 28, 2004 | |
| 285 | ||
| 286 | ||
| 287 | 8. | |
| 288 | Intellectual Property Considerations | |
| 289 | ||
| 290 | The IETF takes no position regarding the validity or scope of any | |
| 291 | intellectual property or other rights that might be claimed to | |
| 292 | pertain to the implementation or use of the technology described in | |
| 293 | this document or the extent to which any license under such rights | |
| 294 | might or might not be available; neither does it represent that it has | |
| 295 | made any effort to identify any such rights. Information on the | |
| 296 | IETF's procedures with respect to rights in standards-track and | |
| 297 | standards-related documentation can be found in BCP-11. Copies of | |
| 298 | claims of rights made available for publication and any assurances of | |
| 299 | licenses to be made available, or the result of an attempt made to | |
| 300 | obtain a general license or permission for the use of such proprietary | |
| 301 | rights by implementors or users of this specification can be obtained | |
| 302 | from the IETF Secretariat. | |
| 303 | ||
| 304 | The IETF invites any interested party to bring to its attention any | |
| 305 | copyrights, patents or patent applications, or other proprietary | |
| 306 | rights which may cover technology that may be required to practice | |
| 307 | this standard. Please address the information to the IETF Executive | |
| 308 | Director. | |
| 309 | ||
| 310 | ||
| 311 | ||
| 312 | ||
| 313 | ||
| 314 | ||
| 315 | ||
| 316 | ||
| 317 | ||
| 318 | ||
| 319 | ||
| 320 | ||
| 321 | ||
| 322 | ||
| 323 | ||
| 324 | ||
| 325 | ||
| 326 | ||
| 327 | ||
| 328 | ||
| 329 | ||
| 330 | ||
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | ||
| 338 | Expires: March 2, 2004 Murchison [Page 6] | |
| 339 | ||
| 340 | Internet Draft LOGIN SASL Mechanism August 28, 2004 | |
| 341 | ||
| 342 | ||
| 343 | 9. | |
| 344 | Full Copyright Statement | |
| 345 | ||
| 346 | Copyright (C) The Internet Society 2003. All Rights Reserved. | |
| 347 | ||
| 348 | This document and translations of it may be copied and furnished to | |
| 349 | others, and derivative works that comment on or otherwise explain it | |
| 350 | or assist in its implmentation may be prepared, copied, published and | |
| 351 | distributed, in whole or in part, without restriction of any kind, | |
| 352 | provided that the above copyright notice and this paragraph are | |
| 353 | included on all such copies and derivative works. However, this | |
| 354 | document itself may not be modified in any way, such as by removing | |
| 355 | the copyright notice or references to the Internet Society or other | |
| 356 | Internet organizations, except as needed for the purpose of | |
| 357 | developing Internet standards in which case the procedures for | |
| 358 | copyrights defined in the Internet Standards process must be followed, | |
| 359 | or as required to translate it into languages other than English. | |
| 360 | ||
| 361 | The limited permissions granted above are perpetual and will not be | |
| 362 | revoked by the Internet Society or its successors or assigns. | |
| 363 | ||
| 364 | This document and the information contained herein is provided on an | |
| 365 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET | |
| 366 | ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, | |
| 367 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |
| 368 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |
| 369 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 370 | ||
| 371 | ||
| 372 | ||
| 373 | ||
| 374 | ||
| 375 | ||
| 376 | ||
| 377 | ||
| 378 | ||
| 379 | ||
| 380 | ||
| 381 | ||
| 382 | ||
| 383 | ||
| 384 | ||
| 385 | ||
| 386 | ||
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | ||
| 394 | Expires: March 2, 2004 Murchison [Page 7] | |
| 395 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group C. Newman | |
| 7 | Internet Draft: SASL C API Innosoft | |
| 8 | Document: draft-newman-sasl-c-api-01.txt A. Melnikov | |
| 9 | MessagingDirect | |
| 10 | February 2003 | |
| 11 | Expires in six months | |
| 12 | ||
| 13 | ||
| 14 | Simple Authentication and Security Layer C API | |
| 15 | ||
| 16 | ||
| 17 | Status of this memo | |
| 18 | ||
| 19 | This document is an Internet-Draft and is in full conformance with | |
| 20 | all provisions of Section 10 of RFC2026 [RFC2026]. | |
| 21 | ||
| 22 | Internet-Drafts are working documents of the Internet Engineering | |
| 23 | Task Force (IETF), its areas, and its working groups. Note that other | |
| 24 | groups may also distribute working documents as Internet-Drafts. | |
| 25 | ||
| 26 | Internet-Drafts are draft documents valid for a maximum of six months | |
| 27 | and may be updated, replaced, or obsoleted by other documents at any | |
| 28 | time. It is inappropriate to use Internet-Drafts as reference | |
| 29 | material or to cite them other than as "work in progress." | |
| 30 | ||
| 31 | The list of current Internet-Drafts can be accessed at | |
| 32 | http://www.ietf.org/ietf/1id-abstracts.txt | |
| 33 | ||
| 34 | The list of Internet-Draft Shadow Directories can be accessed at | |
| 35 | http://www.ietf.org/shadow.html. | |
| 36 | ||
| 37 | Abstract | |
| 38 | ||
| 39 | Almost every protocol needs authentication. However, there does not | |
| 40 | exist an authentication mechanism suitable for all organizations, nor | |
| 41 | is it likely that a small fixed set of authentication mechanisms will | |
| 42 | remain suitable. SASL [SASL] provides the on-the-wire framework for | |
| 43 | authentication (and a security layer) which separates the design of | |
| 44 | authentication mechanisms from the protocols in which they're used. | |
| 45 | ||
| 46 | The SASL protocol model suggests a software architecture where | |
| 47 | application protocols call a generic API to authenticate which in | |
| 48 | turn calls a generic plug-in interface for extensible authentication | |
| 49 | modules. This memo documents the API used in one implementation of | |
| 50 | this architecture in the hope that it will be useful to others. An | |
| 51 | associated memo documenting the plug-in interface is forthcoming. | |
| 52 | ||
| 53 | 1. Conventions Used in this Memo | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Newman et al. Expires: August 2003 FORMFEED[Page 1] | |
| 58 | ||
| 59 | ||
| 60 | ||
| 61 | ||
| 62 | ||
| 63 | INTERNET DRAFT SASL C API February 2003 | |
| 64 | ||
| 65 | ||
| 66 | The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" | |
| 67 | in this document are to be interpreted as defined in "Key words for | |
| 68 | use in RFCs to Indicate Requirement Levels" [KEYWORDS]. | |
| 69 | ||
| 70 | This assumes familiarity the SASL [SASL] specification. | |
| 71 | ||
| 72 | 1.1. Concepts | |
| 73 | ||
| 74 | The following concepts are necessary to understand this | |
| 75 | specification. | |
| 76 | ||
| 77 | realm | |
| 78 | A realm is a name (usually a domain-style name) associated with a | |
| 79 | set of users on a server. One realm may span multiple servers. | |
| 80 | Alternatively, a single server may have multiple realms. Thus | |
| 81 | there may be multiple users with the username "chris" on the same | |
| 82 | server, each in a different realm. Some authentication mechanisms | |
| 83 | have a special field for the realm (e.g., DIGEST-MD5). For other | |
| 84 | mechanisms, a realm can be specified by the client by using the | |
| 85 | syntax "username@realm" in the username field. | |
| 86 | ||
| 87 | service | |
| 88 | A service is a basic function provided by one or more protocols. | |
| 89 | The GSSAPI service name [GSSAPI] registry is available at: | |
| 90 | ||
| 91 | <http://www.iana.org/numbers.html#G> | |
| 92 | ||
| 93 | This registry is used by SASL and the SASL API. The service name | |
| 94 | may be used for service-specific passwords for advanced users, or | |
| 95 | advanced authentication mechanisms may restrict the services a | |
| 96 | given server may offer. | |
| 97 | ||
| 98 | ||
| 99 | virtual domain | |
| 100 | When a single server has multiple realms and there is a DNS server | |
| 101 | entry for each realm pointing to the same server IP address, then | |
| 102 | those realms are "virtual domains". Virtual domains are extremely | |
| 103 | popular with web hosting services and are becoming more popular | |
| 104 | with POP mail services. The key to providing virtual domain sup- | |
| 105 | port is that the client informs the server of the domain it | |
| 106 | believes it is speaking to either through a special protocol ele- | |
| 107 | ment or by using a username of the form "user@realm". | |
| 108 | ||
| 109 | ||
| 110 | 2. Overview of the SASL C API | |
| 111 | ||
| 112 | The SASL API is initialized once at process startup. The | |
| 113 | sasl_server_init() and sasl_client_init() functions provide basic | |
| 114 | ||
| 115 | ||
| 116 | ||
| 117 | Newman et al. Expires: August 2003 FORMFEED[Page 2] | |
| 118 | ||
| 119 | ||
| 120 | ||
| 121 | ||
| 122 | ||
| 123 | INTERNET DRAFT SASL C API February 2003 | |
| 124 | ||
| 125 | ||
| 126 | initialization. | |
| 127 | ||
| 128 | When a network connection occurs where SASL will be used, a connec- | |
| 129 | tion-specific context is created for authentication with | |
| 130 | sasl_client_new() or sasl_server_new(). The API implementation must | |
| 131 | support multi-threaded servers and clients by creating the connection | |
| 132 | context in a thread-safe fashion permitting multiple contexts in a | |
| 133 | given process. At this point, the caller may adjust security policy | |
| 134 | for the context, and the set of mechanisms which are enabled is | |
| 135 | determined by requirements from the configuration or by the caller. | |
| 136 | ||
| 137 | The server end of the API may request a list of enabled authentica- | |
| 138 | tion mechanisms either in general or for a specific user. The client | |
| 139 | may either select a single mechanism or request a list from the | |
| 140 | server (if the SASL profile for the protocol in question supports | |
| 141 | that) and pass the list to the API for automated mechanism selection | |
| 142 | by configured policy. | |
| 143 | ||
| 144 | The SASL exchange begins with sasl_client_start() which determines if | |
| 145 | one of the desired mechanisms is available on the client and may gen- | |
| 146 | erate an initial client response. The client then sends the appro- | |
| 147 | priate protocol message to initiate the SASL exchange that the server | |
| 148 | passes to sasl_server_start(). | |
| 149 | ||
| 150 | The SASL exchange continues with calls to sasl_client_step() and | |
| 151 | sasl_server_step(), until the server indicates completion or the | |
| 152 | client cancels the exchange. | |
| 153 | ||
| 154 | The server queries the user name and user realm resulting from the | |
| 155 | exchange with the sasl_getprop() routine. | |
| 156 | ||
| 157 | A connection context is released with sasl_dispose() and process ter- | |
| 158 | mination is indicated with sasl_done(). | |
| 159 | ||
| 160 | There are a number of utility functions and customization functions | |
| 161 | available in the API for additional services. | |
| 162 | ||
| 163 | Note, that all functions described in this documen can be implemented | |
| 164 | as macroses, so an application using this API MUST NOT assume that | |
| 165 | they are functions. | |
| 166 | ||
| 167 | An application or library trying to use SASL API described in this | |
| 168 | document must include "sasl.h" include file. | |
| 169 | ||
| 170 | 3. Basic SASL API Routines | |
| 171 | ||
| 172 | This section describes the types and functions likely to be used by | |
| 173 | every caller of the SASL API. | |
| 174 | ||
| 175 | ||
| 176 | ||
| 177 | Newman et al. Expires: August 2003 FORMFEED[Page 3] | |
| 178 | ||
| 179 | ||
| 180 | ||
| 181 | ||
| 182 | ||
| 183 | INTERNET DRAFT SASL C API February 2003 | |
| 184 | ||
| 185 | ||
| 186 | 3.1. Basic SASL API Data Structures | |
| 187 | ||
| 188 | The following datastructures are basic to the SASL API. | |
| 189 | ||
| 190 | 3.1.1. sasl_callback_t | |
| 191 | ||
| 192 | The sasl_callback_t structure is used for the caller of the SASL API | |
| 193 | to provide services to both the core SASL API and SASL plug-ins via | |
| 194 | callbacks. The most important callback is the "getopt" callback (see | |
| 195 | section 3.3.3) which is used to retrieve security policy option set- | |
| 196 | tings from the caller's preferences. | |
| 197 | ||
| 198 | typedef struct sasl_callback { | |
| 199 | unsigned long id; | |
| 200 | int (*proc)(); | |
| 201 | void *context; | |
| 202 | } sasl_callback_t; | |
| 203 | ||
| 204 | id is the label for the callback (XXX IANA registry needed), proc is | |
| 205 | a function pointer whose exact type is determined by the id, and con- | |
| 206 | text is a context variable which will be passed to the callback (usu- | |
| 207 | ally as the first argument). The last callback in the list of call- | |
| 208 | backs is indicated with an id of SASL_CB_LIST_END. | |
| 209 | ||
| 210 | If proc is NULL, this means that the application doesn't want to | |
| 211 | specify a corresponding callback, but would provide the necessary | |
| 212 | data via interaction. See also section 3.1.4. | |
| 213 | ||
| 214 | 3.1.2. sasl_secret_t | |
| 215 | ||
| 216 | The sasl_secret_t structure is used to hold text or binary passwords | |
| 217 | for the client API. | |
| 218 | ||
| 219 | typedef struct sasl_secret { | |
| 220 | unsigned long len; | |
| 221 | unsigned char data[1]; | |
| 222 | } sasl_secret_t; | |
| 223 | ||
| 224 | The len field holds the length of the password, while the data field | |
| 225 | holds the actual data. The structure is variable sized: enough space | |
| 226 | must be reserved after the data field to hold the desired password. | |
| 227 | An additional that binary passwords are permitted to contain '\0' | |
| 228 | characters. | |
| 229 | ||
| 230 | 3.1.3. sasl_conn_t | |
| 231 | ||
| 232 | The sasl_conn_t data type is an opaque data type which reflects the | |
| 233 | SASL context for a single server connection. Only one SASL API call | |
| 234 | ||
| 235 | ||
| 236 | ||
| 237 | Newman et al. Expires: August 2003 FORMFEED[Page 4] | |
| 238 | ||
| 239 | ||
| 240 | ||
| 241 | ||
| 242 | ||
| 243 | INTERNET DRAFT SASL C API February 2003 | |
| 244 | ||
| 245 | ||
| 246 | using a given sasl_conn_t as an argument may be active at a time. | |
| 247 | However, each sasl_conn_t is independent and thus the SASL API may be | |
| 248 | used in a true multi-processor multi-threaded environment. | |
| 249 | ||
| 250 | 3.1.4. sasl_interact_t | |
| 251 | ||
| 252 | The sasl_interact_t structure is used by sasl_client_start and | |
| 253 | sasl_client_step to request certain information from the application, | |
| 254 | when the application did not provide corresponding callbacks. For | |
| 255 | example, an application may choose to present a single dialog to the | |
| 256 | user in order to collect all required information interactively. | |
| 257 | ||
| 258 | typedef struct sasl_interact { | |
| 259 | unsigned long id; | |
| 260 | const char *challenge; | |
| 261 | const char *prompt; | |
| 262 | const char *defresult; | |
| 263 | const void *result; | |
| 264 | unsigned len; | |
| 265 | } sasl_interact_t; | |
| 266 | ||
| 267 | The id field holds the value of the callback ID. The prompt field | |
| 268 | contains a string that should be presented to the user. If non-NULL, | |
| 269 | challenge is a NUL-terminated string that will allow the user to pre- | |
| 270 | sent a specific credential when prompted. This is different from the | |
| 271 | prompt in that the prompt is more like a label for a text box (for | |
| 272 | example "Response:" while challenge is a string that tells the user | |
| 273 | what specifically is required by the response (for example, an OTP | |
| 274 | challenge string). The defresult field contains a default value, if | |
| 275 | any. Upon return from sasl_client_* the "result" field points to the | |
| 276 | defresult. The client must present the information in the challenge | |
| 277 | and the prompt to the user and store the result and its length in the | |
| 278 | result and the len fields respectively. | |
| 279 | ||
| 280 | For example, SASL_CB_PASS interaction may contain the following | |
| 281 | information: | |
| 282 | id - SASL_CB_PASS | |
| 283 | challenge - NULL | |
| 284 | prompt - "Password:" | |
| 285 | defresult - NULL (no default). | |
| 286 | ||
| 287 | 3.2. Basic SASL API Client Routines | |
| 288 | ||
| 289 | This section discusses the functions likely to be used by every | |
| 290 | client caller of the SASL API. | |
| 291 | ||
| 292 | 3.2.1. sasl_client_init function | |
| 293 | ||
| 294 | ||
| 295 | ||
| 296 | ||
| 297 | Newman et al. Expires: August 2003 FORMFEED[Page 5] | |
| 298 | ||
| 299 | ||
| 300 | ||
| 301 | ||
| 302 | ||
| 303 | INTERNET DRAFT SASL C API February 2003 | |
| 304 | ||
| 305 | ||
| 306 | Arguments: | |
| 307 | sasl_callback_t *callbacks | |
| 308 | ||
| 309 | Results: | |
| 310 | SASL_OK -- Success | |
| 311 | SASL_NOMEM -- Not enough memory | |
| 312 | SASL_BADVERS -- Mechanism version mismatch | |
| 313 | SASL_BADPARAM -- Error in config file | |
| 314 | ||
| 315 | This function initializes the client routines for the SASL API. | |
| 316 | ||
| 317 | The callbacks argument is the default list of callbacks (see sec- | |
| 318 | tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD | |
| 319 | include the sasl_getopt_t callback (see section 3.3.3). The call- | |
| 320 | backs may be NULL. On success, SASL_OK is returned, and on fail- | |
| 321 | ure a SASL C API error code such as the ones listed above is | |
| 322 | returned. This function may be called a second time to change the | |
| 323 | default callbacks used for new connections, but the first call | |
| 324 | must be made in a single-threaded environment. The data refer- | |
| 325 | enced by the sasl_callback_t structure must persist until | |
| 326 | sasl_done() is called. | |
| 327 | ||
| 328 | 3.2.2. sasl_client_new function | |
| 329 | ||
| 330 | Arguments: | |
| 331 | const char *service, | |
| 332 | const char *server_name, | |
| 333 | const char *iplocalport, | |
| 334 | const char *ipremoteport, | |
| 335 | const sasl_callback_t *prompt_supp, | |
| 336 | unsigned int flags, | |
| 337 | sasl_conn_t **pconn | |
| 338 | ||
| 339 | Results: | |
| 340 | SASL_OK -- Success | |
| 341 | SASL_NOTINIT -- SASL API not initialized | |
| 342 | SASL_NOMECH -- No mechanisms available | |
| 343 | SASL_NOMEM -- Not enough memory | |
| 344 | ||
| 345 | This function creates a client connection context variable. As | |
| 346 | long as each thread uses its own connection context, the SASL C | |
| 347 | API is thread-safe. | |
| 348 | ||
| 349 | The service argument is an IANA registered GSSAPI service element | |
| 350 | as defined in section 1.1. It MUST NOT be NULL. | |
| 351 | ||
| 352 | The server_name is the host name or IP address of the server to | |
| 353 | which the client is connecting. NULL may be used for server_name, | |
| 354 | ||
| 355 | ||
| 356 | ||
| 357 | Newman et al. Expires: August 2003 FORMFEED[Page 6] | |
| 358 | ||
| 359 | ||
| 360 | ||
| 361 | ||
| 362 | ||
| 363 | INTERNET DRAFT SASL C API February 2003 | |
| 364 | ||
| 365 | ||
| 366 | but may result in advanced mechanisms such as Kerberos being | |
| 367 | unavailable. | |
| 368 | ||
| 369 | The iplocalport is the string with the client IPv4/IPv6 address, | |
| 370 | followed by ":" and than by port number. An IPv6 address must be | |
| 371 | enclosed in "[" and "]". NULL may be used for iplocalport, but may | |
| 372 | result in mechanisms requiring IP address being unavailable. | |
| 373 | ||
| 374 | The ipremoteport is the string with the server IPv4/IPv6 address, | |
| 375 | followed by ":" and than by port number. An IPv6 address must be | |
| 376 | enclosed in "[" and "]". NULL may be used for ipremoteport, but | |
| 377 | may result in mechanisms requiring IP address being unavailable. | |
| 378 | ||
| 379 | User input to the SASL C API may be provided in two ways: either | |
| 380 | by supplying callbacks (prompt_supp) to this function, or by using | |
| 381 | an interaction model with the sasl_client_start/sasl_client_step | |
| 382 | functions. Callbacks are more convenient to obtain information | |
| 383 | programmatically, such as pulling authentication information | |
| 384 | directly from a configuration file. Interactions are more conve- | |
| 385 | nient if one wants to get all the data in parallel, for example by | |
| 386 | displaying a single dialog box instead of a separate popup for | |
| 387 | authentication name, authorization, password, etc. | |
| 388 | ||
| 389 | The prompt_supp is a list of supported user prompting callbacks | |
| 390 | discussed in the section 3.1.1. The prompt_supp argument MAY be | |
| 391 | NULL, which means that interactions (i.e. prompt_need parameter to | |
| 392 | sasl_client_start (see 3.2.3) and sasl_client_step (see 3.2.4)) | |
| 393 | are used instead of callbacks. If prompt_supp is NULL, the | |
| 394 | prompt_need argument to sasl_client_start (see 3.2.3) and | |
| 395 | sasl_client_step (see 3.2.4) MUST NOT be NULL. | |
| 396 | ||
| 397 | The flags argument represents client-supported security flags. | |
| 398 | The only values currently supported are SASL_SECURITY_LAYER to | |
| 399 | indicate the client supports the SASL security layer, or 0 to | |
| 400 | indicate it doesn't. | |
| 401 | ||
| 402 | The pconn argument is set to point to the newly created connection | |
| 403 | context. The sasl_conn_t type is opaque to the calling applica- | |
| 404 | tion. | |
| 405 | ||
| 406 | 3.2.3. sasl_client_start function | |
| 407 | ||
| 408 | ||
| 409 | ||
| 410 | ||
| 411 | ||
| 412 | ||
| 413 | ||
| 414 | ||
| 415 | ||
| 416 | ||
| 417 | Newman et al. Expires: August 2003 FORMFEED[Page 7] | |
| 418 | ||
| 419 | ||
| 420 | ||
| 421 | ||
| 422 | ||
| 423 | INTERNET DRAFT SASL C API February 2003 | |
| 424 | ||
| 425 | ||
| 426 | Arguments: | |
| 427 | sasl_conn_t *conn, | |
| 428 | const char *mechlist, | |
| 429 | sasl_interact_t **prompt_need, | |
| 430 | const char **clientout, | |
| 431 | unsigned int *clientoutlen, | |
| 432 | const char **mech | |
| 433 | ||
| 434 | Results: | |
| 435 | SASL_NOTINIT -- SASL API not initialized | |
| 436 | SASL_BADPARAM -- conn or mechlist is NULL | |
| 437 | SASL_NOMECH -- No matching mechanisms available | |
| 438 | SASL_NOMEM -- Not enough memory | |
| 439 | SASL_INTERACT -- User interaction needed to continue | |
| 440 | (see prompt_need description below) | |
| 441 | SASL_OK -- Success | |
| 442 | ||
| 443 | This selects an authentication mechanism to use and optionally | |
| 444 | generates an initial client response. | |
| 445 | ||
| 446 | The conn argument is the connection context from sasl_client_new. | |
| 447 | ||
| 448 | The mechlist argument is a '\0' terminated string containing one | |
| 449 | or more SASL mechanism names. All characters in the string that | |
| 450 | are not permitted in a SASL mechanism name [SASL] are ignored | |
| 451 | except for the purposes of delimiting mechanism names (this per- | |
| 452 | mits passing direct results from many protocol capability lists | |
| 453 | unparsed). Unknown mechanism names are ignored (although | |
| 454 | SASL_NOMECH is returned if no known mechanisms are found). Mecha- | |
| 455 | nisms are tried in an implementation-dependent order. Implementa- | |
| 456 | tions SHOULD try to use the most secure mechanism possible, within | |
| 457 | the constraints specified by the application (e.g. SSF value). | |
| 458 | ||
| 459 | For applications which support interactions, the prompt_need argu- | |
| 460 | ment should initially point to a NULL pointer. If the selected | |
| 461 | mechanism needs information from the user (for example, username | |
| 462 | or password), then prompt_need will be set to point to an array of | |
| 463 | sasl_interact_t structures (terminated by an entry with id equal | |
| 464 | to SASL_CB_LIST_END), and sasl_client_start will return | |
| 465 | SASL_INTERACT. After that the client must fill in the requested | |
| 466 | information and call this function again with the same parameters. | |
| 467 | ||
| 468 | Applications that do not support interactions MUST pass NULL for | |
| 469 | prompt_need. | |
| 470 | ||
| 471 | The clientout and clientoutlen parameters are set to the initial | |
| 472 | client response, if any. If a protocol's SASL profile uses base64 | |
| 473 | encoding, this represents the data prior to the encoding (see | |
| 474 | ||
| 475 | ||
| 476 | ||
| 477 | Newman et al. Expires: August 2003 FORMFEED[Page 8] | |
| 478 | ||
| 479 | ||
| 480 | ||
| 481 | ||
| 482 | ||
| 483 | INTERNET DRAFT SASL C API February 2003 | |
| 484 | ||
| 485 | ||
| 486 | sasl_encode64). If a protocol's SASL profile doesn't include an | |
| 487 | optional initial client response, then these may be NULL and 0 | |
| 488 | respectively. The memory used by clientout is interally managed by | |
| 489 | the SASL API and may be overwritten on the next call to | |
| 490 | sasl_client_step or a call to sasl_dispose. | |
| 491 | ||
| 492 | The mech argument is set to point to a '\0' terminated string | |
| 493 | specifying the mechanism actually selected using all uppercase | |
| 494 | letters. It may be NULL if the client does not care which mecha- | |
| 495 | nism was selected from mechlist. | |
| 496 | ||
| 497 | If sasl_client_start is called a second time using the same con- | |
| 498 | nection context, it will discard any cached information (e.g., the | |
| 499 | username and password) and restart the exchange from the begin- | |
| 500 | ning. <<???>> | |
| 501 | ||
| 502 | 3.2.4. sasl_client_step function | |
| 503 | ||
| 504 | Arguments: | |
| 505 | sasl_conn_t *conn, | |
| 506 | const char *serverin, | |
| 507 | unsigned int serverinlen, | |
| 508 | sasl_interact_t **prompt_need, | |
| 509 | const char **clientout, | |
| 510 | unsigned int *clientoutlen | |
| 511 | ||
| 512 | Results: | |
| 513 | SASL_NOTINIT -- SASL API not initialized | |
| 514 | SASL_NOMECH -- sasl_client_start not called | |
| 515 | SASL_BADPROT -- server protocol incorrect/cancelled | |
| 516 | SASL_BADSERV -- server failed mutual auth | |
| 517 | SASL_INTERACT -- user interaction needed | |
| 518 | SASL_OK -- success | |
| 519 | ||
| 520 | This routine performs one step in an authentication sequence. | |
| 521 | ||
| 522 | The conn argument must be a connection context created by | |
| 523 | sasl_client_new and used in a previous call to sasl_client_start. | |
| 524 | ||
| 525 | The serverin and serverinlen parameters hold the SASL octet string | |
| 526 | received from the server. Note that for those SASL profiles which | |
| 527 | base64 encode the exchange, this is the result after the removal | |
| 528 | of the base64 encoding (see the sasl_decode64 routine below). The | |
| 529 | serverin MUST have a terminating NUL character not counted by | |
| 530 | serverinlen | |
| 531 | ||
| 532 | The prompt_need argument is the same as for sasl_client_start. | |
| 533 | ||
| 534 | ||
| 535 | ||
| 536 | ||
| 537 | Newman et al. Expires: August 2003 FORMFEED[Page 9] | |
| 538 | ||
| 539 | ||
| 540 | ||
| 541 | ||
| 542 | ||
| 543 | INTERNET DRAFT SASL C API February 2003 | |
| 544 | ||
| 545 | ||
| 546 | The clientout and clientoutlen parameters hold the SASL octet | |
| 547 | string to encode (if necessary) and send to the server. | |
| 548 | ||
| 549 | 3.3. Basic SASL API Callback Routines | |
| 550 | ||
| 551 | This section describes the basic callback functions needed for a | |
| 552 | simple client implementation. See the definition of sasl_call- | |
| 553 | back_t in section 3.1.1 for a description of the basic callback | |
| 554 | structure. | |
| 555 | ||
| 556 | 3.3.1. sasl_getsimple_t | |
| 557 | ||
| 558 | Arguments: | |
| 559 | void *context, | |
| 560 | int id, | |
| 561 | const char **result, | |
| 562 | unsigned *len | |
| 563 | ||
| 564 | Results: | |
| 565 | SASL_OK -- success | |
| 566 | SASL_FAIL -- error | |
| 567 | ||
| 568 | This callback is used by the SASL API to request a simple constant | |
| 569 | string from the application. This is used with id SASL_CB_USER | |
| 570 | for the username, SASL_CB_AUTHNAME for the authentication name (if | |
| 571 | different), and SASL_CB_LANGUAGE for a comma separated list of RFC | |
| 572 | 1766 language tags. | |
| 573 | ||
| 574 | The context is the context variable from the sasl_callback_t | |
| 575 | structure, the id is the id from the sasl_callback_t structure, | |
| 576 | and the callback is expected to set the result to a constant | |
| 577 | string and the len to the length of that string. The result and | |
| 578 | len parameters are never NULL. | |
| 579 | ||
| 580 | 3.3.2. sasl_getsecret_t | |
| 581 | ||
| 582 | Arguments: | |
| 583 | sasl_conn_t *conn, | |
| 584 | void *context, | |
| 585 | int id, | |
| 586 | sasl_secret_t **psecret | |
| 587 | ||
| 588 | Results: | |
| 589 | SASL_OK -- success | |
| 590 | SASL_FAIL -- error | |
| 591 | ||
| 592 | This callback is expected to create, prompt or locate a secret and | |
| 593 | set it in the connection context with sasl_setprop. The conn | |
| 594 | ||
| 595 | ||
| 596 | ||
| 597 | Newman et al. Expires: August 2003 FORMFEED[Page 10] | |
| 598 | ||
| 599 | ||
| 600 | ||
| 601 | ||
| 602 | ||
| 603 | INTERNET DRAFT SASL C API February 2003 | |
| 604 | ||
| 605 | ||
| 606 | argument is the connection context, the context and id parameters | |
| 607 | are from the sasl_callback_t structure. The id SASL_CB_PASS is | |
| 608 | used to request a clear text password. | |
| 609 | ||
| 610 | 3.3.3. sasl_getopt_t | |
| 611 | ||
| 612 | Arguments: | |
| 613 | void *context, | |
| 614 | const char *plugin_name, | |
| 615 | const char *option, | |
| 616 | const char **result, | |
| 617 | unsigned int *len | |
| 618 | ||
| 619 | Results: | |
| 620 | SASL_OK -- success | |
| 621 | SASL_FAIL -- error | |
| 622 | ||
| 623 | This callback is used by the SASL API to read options from the | |
| 624 | application. This allows a SASL configuration to be encapsulated | |
| 625 | in the caller's configuration system. Configuration items may be | |
| 626 | mechanism-specific and are arbitrary strings. If the application | |
| 627 | does not provide a sasl_getopt_t callback, then the API MAY obtain | |
| 628 | configuration information from other sources, for example from a | |
| 629 | config file. | |
| 630 | ||
| 631 | The context is the context variable from the sasl_callback_t | |
| 632 | structure, the plugin_name is the name of plugin (or NULL), the | |
| 633 | option is the option name, and the callback is expected to set the | |
| 634 | result to a string valid till next call to sasl_getopt_t in the | |
| 635 | same thread and the len to the length of that string. The result | |
| 636 | and len parameters are never NULL. If the name of plugin is NULL, | |
| 637 | a general SASL option is requested, otherwise a plugin specific | |
| 638 | version. | |
| 639 | ||
| 640 | 3.4. Basic SASL C API Utility Routines | |
| 641 | ||
| 642 | This section describes utility functions provided as part of the | |
| 643 | SASL API which may be used both by clients and servers. | |
| 644 | ||
| 645 | 3.4.1. sasl_decode64 function | |
| 646 | ||
| 647 | ||
| 648 | ||
| 649 | ||
| 650 | ||
| 651 | ||
| 652 | ||
| 653 | ||
| 654 | ||
| 655 | ||
| 656 | ||
| 657 | Newman et al. Expires: August 2003 FORMFEED[Page 11] | |
| 658 | ||
| 659 | ||
| 660 | ||
| 661 | ||
| 662 | ||
| 663 | INTERNET DRAFT SASL C API February 2003 | |
| 664 | ||
| 665 | ||
| 666 | Arguments: | |
| 667 | const char *in, | |
| 668 | unsigned int inlen, | |
| 669 | char *out, | |
| 670 | unsigned int outmax, | |
| 671 | unsigned int *outlen | |
| 672 | ||
| 673 | Results: | |
| 674 | SASL_BUFOVER -- output buffer too small | |
| 675 | SASL_BADPROT -- invalid base64 string | |
| 676 | SASL_OK -- successful decode | |
| 677 | ||
| 678 | This utility routine converts a base64 string of length inlen | |
| 679 | pointed by in into an octet string. It is useful for SASL profiles | |
| 680 | which use base64 such as the IMAP [IMAP4] and POP [POP-AUTH] pro- | |
| 681 | files. The output is copied to the buffer specified by the out | |
| 682 | parameter. It is NUL terminated and the length of the output is | |
| 683 | placed in the outlen parameter if outlen is non-NULL. The lenght | |
| 684 | doesn't include the terminating NUL character. | |
| 685 | ||
| 686 | When the size of the output buffer, as specified by outmax, is too | |
| 687 | small, the function returns SASL_BUFOVER error code and the | |
| 688 | required length is stored in the outlen parameter if it is not | |
| 689 | NULL. | |
| 690 | ||
| 691 | The function may also return SASL_BADPROT error code when it | |
| 692 | encounters an invalid base64 character. | |
| 693 | ||
| 694 | 3.4.2. sasl_encode64 function | |
| 695 | ||
| 696 | Arguments: | |
| 697 | const char *in, | |
| 698 | unsigned int inlen, | |
| 699 | char *out, | |
| 700 | unsigned int outmax, | |
| 701 | unsigned int *outlen | |
| 702 | ||
| 703 | Results: | |
| 704 | SASL_BUFOVER -- output buffer too small | |
| 705 | SASL_OK -- successful decode | |
| 706 | ||
| 707 | This utility routine converts an octet string of length inlen | |
| 708 | pointed by in into a base64 string. It is useful for SASL profiles | |
| 709 | which use base64 such as the IMAP [IMAP4] and POP [POP-AUTH] pro- | |
| 710 | files. | |
| 711 | ||
| 712 | The output is copied to the buffer specified by the out parameter. | |
| 713 | It is NUL terminated and the length of the output is placed in the | |
| 714 | ||
| 715 | ||
| 716 | ||
| 717 | Newman et al. Expires: August 2003 FORMFEED[Page 12] | |
| 718 | ||
| 719 | ||
| 720 | ||
| 721 | ||
| 722 | ||
| 723 | INTERNET DRAFT SASL C API February 2003 | |
| 724 | ||
| 725 | ||
| 726 | outlen parameter if outlen is non-NULL. The lenght doesn't include | |
| 727 | the terminating NUL character. | |
| 728 | ||
| 729 | When the size of the output buffer, as specified by outmax, is too | |
| 730 | small, the function returns SASL_BUFOVER error code and the | |
| 731 | required length is stored in the outlen parameter if it is not | |
| 732 | NULL. | |
| 733 | ||
| 734 | 3.4.3. sasl_errstring function | |
| 735 | ||
| 736 | Arguments: | |
| 737 | int saslerr, | |
| 738 | const char *langlist, | |
| 739 | const char **outlang | |
| 740 | ||
| 741 | Results: | |
| 742 | const char * | |
| 743 | ||
| 744 | This converts a SASL error number into a constant string. The | |
| 745 | second argument MAY be NULL for the default language, or a comma- | |
| 746 | separated list of RFC 1766 language tags. The final parameter is | |
| 747 | set to the RFC 1766 language tag of the string returned which will | |
| 748 | be "i-default" if no matching language is found. The strings are | |
| 749 | UTF-8. This requires no context so it may be used for the result | |
| 750 | of an sasl_*_init or sasl_*_new result code. | |
| 751 | ||
| 752 | 3.4.4. sasl_errdetail function | |
| 753 | ||
| 754 | Arguments: | |
| 755 | sasl_conn_t *conn | |
| 756 | ||
| 757 | Results: | |
| 758 | const char * | |
| 759 | ||
| 760 | This converts the last SASL error code that occured on a connec- | |
| 761 | tion to UTF8 string. It uses the SASL_CB_LANGUAGE callback (see | |
| 762 | section 3.3.1) to determine the language to use. It may return | |
| 763 | more detailed information than sasl_errstring does. | |
| 764 | ||
| 765 | 3.4.5. sasl_seterror function | |
| 766 | ||
| 767 | ||
| 768 | ||
| 769 | ||
| 770 | ||
| 771 | ||
| 772 | ||
| 773 | ||
| 774 | ||
| 775 | ||
| 776 | ||
| 777 | Newman et al. Expires: August 2003 FORMFEED[Page 13] | |
| 778 | ||
| 779 | ||
| 780 | ||
| 781 | ||
| 782 | ||
| 783 | INTERNET DRAFT SASL C API February 2003 | |
| 784 | ||
| 785 | ||
| 786 | Arguments: | |
| 787 | sasl_conn_t *conn | |
| 788 | unsigned flags, | |
| 789 | const char *fmt, | |
| 790 | ... | |
| 791 | ||
| 792 | Results: | |
| 793 | none | |
| 794 | ||
| 795 | This function sets sets the error string which will be returned by | |
| 796 | sasl_errdetail. It uses syslog()-style formatting (i.e. printf- | |
| 797 | style with %m as the string form of an errno error). | |
| 798 | ||
| 799 | Messages should be sensitive to the current language setting. If | |
| 800 | there is no SASL_CB_LANGUAGE callback for the connection, text | |
| 801 | MUST be in US-ASCII. Otherwise UTF-8 is used and use of RFC 2482 | |
| 802 | for mixed-language text is encouraged. | |
| 803 | ||
| 804 | <<This will also trigger a call to the SASL logging callback (if | |
| 805 | any) with a level of SASL_LOG_FAIL unless the SASL_NOLOG flag is | |
| 806 | set.>> | |
| 807 | ||
| 808 | This function may be used by server callbacks. | |
| 809 | ||
| 810 | If conn is NULL, the function does nothing. | |
| 811 | ||
| 812 | 3.4.6. sasl_erasebuffer function | |
| 813 | ||
| 814 | Arguments: | |
| 815 | char *buf, | |
| 816 | unsigned len | |
| 817 | ||
| 818 | Results: | |
| 819 | none | |
| 820 | ||
| 821 | This function fills the buffer buf of the lenght len with '\0' | |
| 822 | characters. The function may be used to clear from memory sensi- | |
| 823 | tive informations, like passwords. | |
| 824 | ||
| 825 | 3.5. Basic SASL C API Server Routines | |
| 826 | ||
| 827 | This section describes the basic routines for a server implementa- | |
| 828 | tion of a SASL profile. | |
| 829 | ||
| 830 | 3.5.1. sasl_server_init function | |
| 831 | ||
| 832 | ||
| 833 | ||
| 834 | ||
| 835 | ||
| 836 | ||
| 837 | Newman et al. Expires: August 2003 FORMFEED[Page 14] | |
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | ||
| 842 | ||
| 843 | INTERNET DRAFT SASL C API February 2003 | |
| 844 | ||
| 845 | ||
| 846 | Arguments: | |
| 847 | const sasl_callback_t *callbacks, | |
| 848 | const char *appname | |
| 849 | ||
| 850 | Results: | |
| 851 | SASL_BADPARAM -- error in config file | |
| 852 | SASL_NOMEM -- out of memory | |
| 853 | SASL_BADVERS -- Plug-in version mismatch | |
| 854 | SASL_OK -- success | |
| 855 | ||
| 856 | This function initializes the server routines for the SASL C API. | |
| 857 | ||
| 858 | The callbacks argument is the default list of callbacks (see sec- | |
| 859 | tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD | |
| 860 | include the sasl_getopt_t callback (see section 3.3.3). The call- | |
| 861 | backs may be NULL. The appname argument is the name of the calling | |
| 862 | application and may be used by server plug-ins for logging. On | |
| 863 | success, SASL_OK is returned, and on failure a SASL C API error | |
| 864 | code is returned. This function may be called a second time to | |
| 865 | change the default callbacks, but the first call must be made in a | |
| 866 | single-threaded environment. The data referenced by the | |
| 867 | sasl_callback_t structure must persist until sasl_done() is | |
| 868 | called. | |
| 869 | ||
| 870 | appname specifies the application name. SASL API may use it, for | |
| 871 | example, for logging or to read an application specific configura- | |
| 872 | tion. A library must pass NULL as appname. appname can be also be | |
| 873 | set with sasl_setprop function, and can be queried with sasl_get- | |
| 874 | prop. <<Specify option name here>> | |
| 875 | ||
| 876 | 3.5.2. sasl_server_new function | |
| 877 | ||
| 878 | ||
| 879 | ||
| 880 | ||
| 881 | ||
| 882 | ||
| 883 | ||
| 884 | ||
| 885 | ||
| 886 | ||
| 887 | ||
| 888 | ||
| 889 | ||
| 890 | ||
| 891 | ||
| 892 | ||
| 893 | ||
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | Newman et al. Expires: August 2003 FORMFEED[Page 15] | |
| 898 | ||
| 899 | ||
| 900 | ||
| 901 | ||
| 902 | ||
| 903 | INTERNET DRAFT SASL C API February 2003 | |
| 904 | ||
| 905 | ||
| 906 | Arguments: | |
| 907 | const char *service, | |
| 908 | const char *serverFQDN, | |
| 909 | const char *user_realm, | |
| 910 | const char *iplocalport, | |
| 911 | const char *ipremoteport, | |
| 912 | const sasl_callback_t *callbacks, | |
| 913 | unsigned int flags, | |
| 914 | sasl_conn_t **pconn | |
| 915 | ||
| 916 | Results: | |
| 917 | SASL_OK -- success | |
| 918 | SASL_NOTINIT -- SASL API not initialized | |
| 919 | SASL_BADPARAM -- Invalid parameter supplied | |
| 920 | SASL_NOMECH -- No mechanisms available | |
| 921 | SASL_NOMEM -- Not enough memory | |
| 922 | ||
| 923 | This function creates a server connection context variable. As | |
| 924 | long as each thread uses its own connection context, the SASL C | |
| 925 | API is thread-safe. | |
| 926 | ||
| 927 | The service argument is an IANA registered GSSAPI service element | |
| 928 | as defined in section 1.1. It MUST NOT be NULL. | |
| 929 | ||
| 930 | The serverFQDN is the fully qualified name of the server. It MUST | |
| 931 | NOT be NULL. | |
| 932 | ||
| 933 | The user_realm specifies the default realm. A realm defines a set | |
| 934 | of users on the system for systems which support multiple user | |
| 935 | communities ("realms"). If user_realm is NULL, the value of | |
| 936 | serverFQDN is used as the default realm. | |
| 937 | ||
| 938 | The iplocalport is the string with the server IPv4/IPv6 address, | |
| 939 | followed by ":" and than by port number. An IPv6 address must be | |
| 940 | enclosed in "[" and "]". NULL may be used for iplocalport, but may | |
| 941 | result in mechanisms requiring IP address being unavailable. | |
| 942 | ||
| 943 | The ipremoteport is the string with the client IPv4/IPv6 address, | |
| 944 | followed by ":" and than by port number. An IPv6 address must be | |
| 945 | enclosed in "[" and "]". NULL may be used for ipremoteport, but | |
| 946 | may result in mechanisms requiring IP address being unavailable. | |
| 947 | ||
| 948 | The callbacks argument is a set of server callbacks which may | |
| 949 | include a connection-specific sasl_getopt_t and/or an authoriza- | |
| 950 | tion routine. | |
| 951 | ||
| 952 | The flags argument represents server-supported security flags. The | |
| 953 | only values currently supported are SASL_SECURITY_LAYER to | |
| 954 | ||
| 955 | ||
| 956 | ||
| 957 | Newman et al. Expires: August 2003 FORMFEED[Page 16] | |
| 958 | ||
| 959 | ||
| 960 | ||
| 961 | ||
| 962 | ||
| 963 | INTERNET DRAFT SASL C API February 2003 | |
| 964 | ||
| 965 | ||
| 966 | indicate the server supports the SASL security layer, or 0 to | |
| 967 | indicate it doesn't. | |
| 968 | ||
| 969 | The pconn argument is set to point to the newly created connection | |
| 970 | context. | |
| 971 | ||
| 972 | 3.5.3. sasl_server_start function | |
| 973 | ||
| 974 | Arguments: | |
| 975 | sasl_conn_t *conn, | |
| 976 | const char *mech, | |
| 977 | const char *clientin, | |
| 978 | insigned int clientinlen, | |
| 979 | const char **serverout, | |
| 980 | unsigned int *serveroutlen | |
| 981 | ||
| 982 | Results: | |
| 983 | SASL_CONTINUE -- Another authentication step required | |
| 984 | SASL_OK -- Authentication Complete | |
| 985 | SASL_NOTINIT -- SASL API not initialized | |
| 986 | SASL_BADPARAM -- Invalid parameter supplied | |
| 987 | SASL_BADPROT -- Client protocol error | |
| 988 | SASL_NOMECH -- Mechanism not supported | |
| 989 | SASL_NOVERIFY -- User exists, but no verifier exists for | |
| 990 | the mechanism | |
| 991 | SASL_TRANS -- A password transition is needed to use mechanism | |
| 992 | ||
| 993 | This begins an authentication exchange and is called after the | |
| 994 | client sends the initial authentication command. The mech argu- | |
| 995 | ment is the mechanism name the client is requesting. If the | |
| 996 | client includes an optional initial-response, it is passed in the | |
| 997 | clientin and clientinlen fields. Otherwise NULL and 0 are passed | |
| 998 | for those arguments. The serverout and serveroutlen are filled in | |
| 999 | with the server response, if any. If SASL_CONTINUE is returned, | |
| 1000 | the server will need to wait for another client message and call | |
| 1001 | sasl_server_step. If SASL_OK is returned, the authentication is | |
| 1002 | completed successfully, although server out data may be supplied. | |
| 1003 | ||
| 1004 | 3.5.4. sasl_server_step function | |
| 1005 | ||
| 1006 | ||
| 1007 | ||
| 1008 | ||
| 1009 | ||
| 1010 | ||
| 1011 | ||
| 1012 | ||
| 1013 | ||
| 1014 | ||
| 1015 | ||
| 1016 | ||
| 1017 | Newman et al. Expires: August 2003 FORMFEED[Page 17] | |
| 1018 | ||
| 1019 | ||
| 1020 | ||
| 1021 | ||
| 1022 | ||
| 1023 | INTERNET DRAFT SASL C API February 2003 | |
| 1024 | ||
| 1025 | ||
| 1026 | Arguments: | |
| 1027 | sasl_conn_t *conn, | |
| 1028 | const char *clientin, | |
| 1029 | insigned int clientinlen, | |
| 1030 | const char **serverout, | |
| 1031 | unsigned int *serveroutlen | |
| 1032 | ||
| 1033 | Results: | |
| 1034 | SASL_CONTINUE -- Another authentication step required | |
| 1035 | SASL_OK -- Authentication Complete | |
| 1036 | SASL_NOTINIT -- SASL API not initialized | |
| 1037 | SASL_NOMECH -- sasl_server_start not called | |
| 1038 | SASL_BADPARAM -- Invalid parameter supplied | |
| 1039 | SASL_BADPROT -- Client protocol error | |
| 1040 | SASL_NOVERIFY -- User exists, but no verifier exists for | |
| 1041 | the mechanism | |
| 1042 | SASL_TRANS -- A password transition is needed to use mechanism | |
| 1043 | ||
| 1044 | This routine performs one step in an authentication sequence. | |
| 1045 | ||
| 1046 | The conn argument must be a connection context created by | |
| 1047 | sasl_server_new and used in a previous call to sasl_server_start. | |
| 1048 | ||
| 1049 | The clientin and clientinlen parameters hold the SASL octet string | |
| 1050 | received from the client. Note that for those SASL profiles which | |
| 1051 | base64 encode the exchange, this is the result after the removal | |
| 1052 | of the base64 encoding (see the sasl_decode64 routine). The cli- | |
| 1053 | entin MUST have a terminating NUL character not counted by | |
| 1054 | serverinlen. | |
| 1055 | ||
| 1056 | The serverout and serveroutlen parameters hold the SASL octet | |
| 1057 | string to encode (if necessary) and send to the client. If | |
| 1058 | SASL_CONTINUE is returned, the server will need to wait for | |
| 1059 | another client message and call sasl_server_step. If SASL_OK is | |
| 1060 | returned, the authentication is completed successfully, although | |
| 1061 | server out data may be supplied. | |
| 1062 | ||
| 1063 | 3.6. Common SASL API Routines | |
| 1064 | ||
| 1065 | This section describes the routines that are common to both | |
| 1066 | clients and servers. | |
| 1067 | ||
| 1068 | 3.6.1. sasl_listmech function | |
| 1069 | ||
| 1070 | ||
| 1071 | ||
| 1072 | ||
| 1073 | ||
| 1074 | ||
| 1075 | ||
| 1076 | ||
| 1077 | Newman et al. Expires: August 2003 FORMFEED[Page 18] | |
| 1078 | ||
| 1079 | ||
| 1080 | ||
| 1081 | ||
| 1082 | ||
| 1083 | INTERNET DRAFT SASL C API February 2003 | |
| 1084 | ||
| 1085 | ||
| 1086 | Arguments: | |
| 1087 | sasl_conn_t *conn, | |
| 1088 | const char *user, | |
| 1089 | const char *prefix, | |
| 1090 | const char *sep, | |
| 1091 | const char *suffix, | |
| 1092 | char **result, | |
| 1093 | unsigned int *plen, | |
| 1094 | unsigned *pcount | |
| 1095 | ||
| 1096 | Results: | |
| 1097 | SASL_OK -- Success | |
| 1098 | SASL_NOMEM -- Not enough memory | |
| 1099 | SASL_NOMECH -- No enabled mechanisms | |
| 1100 | ||
| 1101 | This returns a list of enabled SASL mechanisms in a NUL-terminated | |
| 1102 | string. The list is constructed by placing the prefix string at | |
| 1103 | the beginning, placing the sep string between any pair of mecha- | |
| 1104 | nisms and placing the suffix string at the end. | |
| 1105 | ||
| 1106 | When calling this function plen and pcount MAY be NULL. | |
| 1107 | ||
| 1108 | This function returns the list of client side SASL mechanisms, if | |
| 1109 | the conn was created by sasl_client_new and the list of server | |
| 1110 | side mechanisms, if the conn was created by sasl_server_new. The | |
| 1111 | list returned by this function must persist till a next call to | |
| 1112 | sasl_free_listmech or sasl_listmech. | |
| 1113 | ||
| 1114 | 3.6.2. sasl_free_listmech function | |
| 1115 | ||
| 1116 | Arguments: | |
| 1117 | sasl_conn_t *conn, | |
| 1118 | char **result | |
| 1119 | ||
| 1120 | Results: | |
| 1121 | none | |
| 1122 | ||
| 1123 | This disposes of the result string returned by sasl_listmech. | |
| 1124 | ||
| 1125 | 3.6.3. sasl_setprop function | |
| 1126 | ||
| 1127 | ||
| 1128 | ||
| 1129 | ||
| 1130 | ||
| 1131 | ||
| 1132 | ||
| 1133 | ||
| 1134 | ||
| 1135 | ||
| 1136 | ||
| 1137 | Newman et al. Expires: August 2003 FORMFEED[Page 19] | |
| 1138 | ||
| 1139 | ||
| 1140 | ||
| 1141 | ||
| 1142 | ||
| 1143 | INTERNET DRAFT SASL C API February 2003 | |
| 1144 | ||
| 1145 | ||
| 1146 | Arguments: | |
| 1147 | sasl_conn_t *conn, | |
| 1148 | int propnum, | |
| 1149 | const void *value | |
| 1150 | ||
| 1151 | Results: | |
| 1152 | SASL_OK -- property set | |
| 1153 | SASL_BADPARAM -- invalid propnum or value | |
| 1154 | SASL_NOMEM -- not enough memory to perform operation | |
| 1155 | ||
| 1156 | This sets a property in a connection context. Commonly used prop- | |
| 1157 | erties with their descriptions are listed below: | |
| 1158 | ||
| 1159 | SASL_SSF_EXTERNAL | |
| 1160 | ||
| 1161 | Security layer strength factor (SSF) -- an unsigned integer usable | |
| 1162 | by the caller to specify approximate security layer strength | |
| 1163 | desired. It roughly corresponds to the effective key length for | |
| 1164 | encryption, e.g. | |
| 1165 | 0 = no protection | |
| 1166 | 1 = integrity protection only >1 = key lenght of the cipher | |
| 1167 | ||
| 1168 | SASL_SSF_EXTERNAL property denotes SSF of the external security | |
| 1169 | layer (e.g. provided by TLS). The value parameter points to | |
| 1170 | sasl_ssf_t, that is described as follows: | |
| 1171 | ||
| 1172 | typedef unsigned sasl_ssf_t; | |
| 1173 | ||
| 1174 | ||
| 1175 | ||
| 1176 | SASL_SEC_PROPS | |
| 1177 | ||
| 1178 | The value parameter for SASL_SEC_PROPS points to sasl_secu- | |
| 1179 | rity_properties_t structure defined below. A particular implemen- | |
| 1180 | tation may extend it with additional fields. | |
| 1181 | ||
| 1182 | typedef struct sasl_security_properties | |
| 1183 | { | |
| 1184 | sasl_ssf_t min_ssf; | |
| 1185 | sasl_ssf_t max_ssf; | |
| 1186 | ||
| 1187 | unsigned maxbufsize; | |
| 1188 | ||
| 1189 | /* bitfield for attacks to protect against */ | |
| 1190 | unsigned security_flags; | |
| 1191 | } sasl_security_properties_t; | |
| 1192 | ||
| 1193 | The min_ssf and the max_ssf define the minimal and the maximal | |
| 1194 | ||
| 1195 | ||
| 1196 | ||
| 1197 | Newman et al. Expires: August 2003 FORMFEED[Page 20] | |
| 1198 | ||
| 1199 | ||
| 1200 | ||
| 1201 | ||
| 1202 | ||
| 1203 | INTERNET DRAFT SASL C API February 2003 | |
| 1204 | ||
| 1205 | ||
| 1206 | acceptable SSF. | |
| 1207 | ||
| 1208 | The maxbufsize specifies the biggest buffer size that the | |
| 1209 | client/server is able to decode. 0 means that security layer is | |
| 1210 | not supported. | |
| 1211 | ||
| 1212 | The security_flags is a bitmask of the various security flags | |
| 1213 | described below: | |
| 1214 | ||
| 1215 | SASL_SEC_NOPLAINTEXT -- don't permit mechanisms susceptible to simple | |
| 1216 | passive attack (e.g., PLAIN, LOGIN) | |
| 1217 | SASL_SEC_NOACTIVE -- protection from active (non-dictionary) attacks | |
| 1218 | during authentication exchange. | |
| 1219 | Authenticates server. | |
| 1220 | SASL_SEC_NODICTIONARY -- don't permit mechanisms susceptible to passive | |
| 1221 | dictionary attack | |
| 1222 | SASL_SEC_FORWARD_SECRECY -- require forward secrecy between sessions | |
| 1223 | (breaking one won't help break next) | |
| 1224 | SASL_SEC_NOANONYMOUS -- don't permit mechanisms that allow anonymous login | |
| 1225 | SASL_SEC_PASS_CREDENTIALS -- require mechanisms which pass client | |
| 1226 | credentials, and allow mechanisms which can pass | |
| 1227 | credentials to do so | |
| 1228 | SASL_SEC_MUTUAL_AUTH -- require mechanisms which provide mutual | |
| 1229 | authentication | |
| 1230 | ||
| 1231 | SASL_AUTH_EXTERNAL | |
| 1232 | ||
| 1233 | The value parameter for SASL_AUTH_EXTERNAL property points to the | |
| 1234 | external authentication ID as provided by external authentication | |
| 1235 | method, e.g. TLS, PPP or IPSec. | |
| 1236 | ||
| 1237 | 3.6.4. sasl_getprop function | |
| 1238 | ||
| 1239 | Arguments: | |
| 1240 | sasl_conn_t *conn, | |
| 1241 | int propnum, | |
| 1242 | const void **pvalue | |
| 1243 | ||
| 1244 | Results: | |
| 1245 | SASL_OK -- Success | |
| 1246 | SASL_NOTDONE -- Authentication exchange must complete prior to | |
| 1247 | retrieving this attribute | |
| 1248 | SASL_BADPARAM -- bad property number | |
| 1249 | ||
| 1250 | This requests a pointer to a constant property available through | |
| 1251 | the SASL API. The most common use by servers is to get the | |
| 1252 | SASL_USERNAME property which returns the authorization identity | |
| 1253 | (user to login as) from the SASL mechanism as a UTF-8 string in | |
| 1254 | ||
| 1255 | ||
| 1256 | ||
| 1257 | Newman et al. Expires: August 2003 FORMFEED[Page 21] | |
| 1258 | ||
| 1259 | ||
| 1260 | ||
| 1261 | ||
| 1262 | ||
| 1263 | INTERNET DRAFT SASL C API February 2003 | |
| 1264 | ||
| 1265 | ||
| 1266 | the pvalue parameter. Additional properties are listed in section | |
| 1267 | 6. | |
| 1268 | ||
| 1269 | 3.6.5. sasl_dispose function | |
| 1270 | ||
| 1271 | Arguments: | |
| 1272 | sasl_conn_t **pconn | |
| 1273 | ||
| 1274 | Results: | |
| 1275 | none | |
| 1276 | ||
| 1277 | This function disposes of the connection state created with | |
| 1278 | sasl_client_new or sasl_server_new, and sets the pointer to NULL. | |
| 1279 | If the pconn is already NULL the function does nothing. | |
| 1280 | ||
| 1281 | 3.6.6. sasl_done function | |
| 1282 | ||
| 1283 | Arguments: | |
| 1284 | none | |
| 1285 | ||
| 1286 | Results: | |
| 1287 | none | |
| 1288 | ||
| 1289 | A SASL application that is finished with the SASL API must call | |
| 1290 | this function. This function frees any memory allocated by the | |
| 1291 | SASL library or any other library state. After this call most of | |
| 1292 | the SASL API function will again return the SASL_NOTINIT error | |
| 1293 | code. | |
| 1294 | ||
| 1295 | There must be a call to sasl_done for every successful call to | |
| 1296 | sasl_server_init or sasl_client_init made. Only the final | |
| 1297 | sasl_done does the actual cleanup; the preceding calls simply | |
| 1298 | decrement an internal reference count. | |
| 1299 | ||
| 1300 | Connection states MUST be disposed of with sasl_dispose before | |
| 1301 | calling this function. | |
| 1302 | ||
| 1303 | 4. SASL Security Layer Routines | |
| 1304 | ||
| 1305 | This section describes the routines need to support a security | |
| 1306 | layer. | |
| 1307 | ||
| 1308 | 4.1. sasl_encode function | |
| 1309 | ||
| 1310 | ||
| 1311 | ||
| 1312 | ||
| 1313 | ||
| 1314 | ||
| 1315 | ||
| 1316 | ||
| 1317 | Newman et al. Expires: August 2003 FORMFEED[Page 22] | |
| 1318 | ||
| 1319 | ||
| 1320 | ||
| 1321 | ||
| 1322 | ||
| 1323 | INTERNET DRAFT SASL C API February 2003 | |
| 1324 | ||
| 1325 | ||
| 1326 | Arguments: | |
| 1327 | sasl_conn_t *conn, | |
| 1328 | const char *input, | |
| 1329 | unsigned int inputlen, | |
| 1330 | const char **output, | |
| 1331 | unsigned int *outputlen | |
| 1332 | ||
| 1333 | Results: | |
| 1334 | SASL_OK -- Success (returns input if no layer negotiated) | |
| 1335 | SASL_NOTDONE -- Security layer negotiation not finished | |
| 1336 | SASL_BADPARAM -- inputlen is greater than the SASL_MAXOUTBUF property | |
| 1337 | ||
| 1338 | This function encodes a block of data for transmission using secu- | |
| 1339 | rity layer (if any). The output and outputlen are filled in with | |
| 1340 | the encoded data and its length respectively. If there is no secu- | |
| 1341 | rity layer the input buffer is returned in the output. Otherwise, | |
| 1342 | the output is only valid until a next call to sasl_encode or | |
| 1343 | sasl_dispose. | |
| 1344 | ||
| 1345 | 4.1. sasl_decode function | |
| 1346 | ||
| 1347 | Arguments: | |
| 1348 | sasl_conn_t *conn, | |
| 1349 | const char *input, | |
| 1350 | unsigned int inputlen, | |
| 1351 | const char **output, | |
| 1352 | unsigned int *outputlen | |
| 1353 | ||
| 1354 | Results: | |
| 1355 | SASL_OK -- Success (returns input if no layer negotiated) | |
| 1356 | SASL_NOTDONE -- Security layer negotiation not finished | |
| 1357 | SASL_BADMAC -- Bad message integrity check | |
| 1358 | ||
| 1359 | This function decodes a block of data received using security | |
| 1360 | layer (if any). The output and outputlen are filled in with the | |
| 1361 | decoded data and its length respectively. If there is no security | |
| 1362 | layer the input buffer is returned in the output. Otherwise, the | |
| 1363 | output is only valid until a next call to sasl_decode or sasl_dis- | |
| 1364 | pose. | |
| 1365 | ||
| 1366 | 5. Advanced SASL API Routines | |
| 1367 | ||
| 1368 | This section describes the less frequently used functions avail- | |
| 1369 | able in the SASL API. | |
| 1370 | ||
| 1371 | 5.1. Additional Initialization Routines | |
| 1372 | ||
| 1373 | 5.1.1. sasl_set_mutex function | |
| 1374 | ||
| 1375 | ||
| 1376 | ||
| 1377 | Newman et al. Expires: August 2003 FORMFEED[Page 23] | |
| 1378 | ||
| 1379 | ||
| 1380 | ||
| 1381 | ||
| 1382 | ||
| 1383 | INTERNET DRAFT SASL C API February 2003 | |
| 1384 | ||
| 1385 | ||
| 1386 | Arguments: | |
| 1387 | sasl_mutex_alloc_t *mutex_alloc, | |
| 1388 | sasl_mutex_lock_t *mutex_lock, | |
| 1389 | sasl_mutex_unlock_t *mutex_unlock, | |
| 1390 | sasl_mutex_free_t *mutex_free | |
| 1391 | ||
| 1392 | Results: | |
| 1393 | None | |
| 1394 | ||
| 1395 | The sasl_set_mutex call sets the callbacks which the SASL API and | |
| 1396 | plug-ins will use whenever exclusive access to a process shared | |
| 1397 | resource is needed. A single-threaded client or server need not | |
| 1398 | call this. The types are designed to be compatible with the LDAP | |
| 1399 | API [LDAP-API]: | |
| 1400 | ||
| 1401 | typedef void *sasl_mutex_alloc_t(void); | |
| 1402 | ||
| 1403 | On success, this returns a pointer to an allocated and initialized | |
| 1404 | mutex structure. On failure, it returns NULL. | |
| 1405 | ||
| 1406 | typedef int sasl_mutex_lock_t(void *mutex); | |
| 1407 | ||
| 1408 | This will block the current thread until it is possible to get an | |
| 1409 | exclusive lock on a mutex allocated by the mutex_alloc callback. | |
| 1410 | On success it returns 0, on failure due to deadlock or bad parame- | |
| 1411 | ter, it returns -1. | |
| 1412 | ||
| 1413 | typedef int sasl_mutex_unlock_t(void *mutex); | |
| 1414 | ||
| 1415 | This releases a lock on a mutex allocated by the mutex_alloc call- | |
| 1416 | back. On success it returns 0, on failure due to an already | |
| 1417 | unlocked mutex, or bad parameter, it returns -1. | |
| 1418 | ||
| 1419 | typedef void sasl_mutex_free_t(void *mutex); | |
| 1420 | ||
| 1421 | This disposes of a mutex allocated by mutex_alloc. | |
| 1422 | ||
| 1423 | 5.1.2. sasl_set_alloc function | |
| 1424 | ||
| 1425 | ||
| 1426 | ||
| 1427 | ||
| 1428 | ||
| 1429 | ||
| 1430 | ||
| 1431 | ||
| 1432 | ||
| 1433 | ||
| 1434 | ||
| 1435 | ||
| 1436 | ||
| 1437 | Newman et al. Expires: August 2003 FORMFEED[Page 24] | |
| 1438 | ||
| 1439 | ||
| 1440 | ||
| 1441 | ||
| 1442 | ||
| 1443 | INTERNET DRAFT SASL C API February 2003 | |
| 1444 | ||
| 1445 | ||
| 1446 | Arguments: | |
| 1447 | sasl_malloc_t *malloc, | |
| 1448 | sasl_calloc_t *calloc, | |
| 1449 | sasl_realloc_t *realloc, | |
| 1450 | sasl_free_t *free | |
| 1451 | ||
| 1452 | Results: | |
| 1453 | None | |
| 1454 | ||
| 1455 | This sets the memory allocation functions which the SASL API will | |
| 1456 | use. The SASL API will use its own routines (usually the standard | |
| 1457 | C library) if these are not set. | |
| 1458 | ||
| 1459 | typedef void *sasl_malloc_t(unsigned long mem_size); | |
| 1460 | ||
| 1461 | This allocates memory mem_size bytes of memory. The memory is not | |
| 1462 | initialized to any particular value. It returns NULL on a fail- | |
| 1463 | ure, or when mem_size is 0. | |
| 1464 | ||
| 1465 | typedef void *sasl_calloc_t(unsigned long elem_size, | |
| 1466 | unsigned long num_elem); | |
| 1467 | ||
| 1468 | This allocates elem_size * num_elem bytes of memory. The memory | |
| 1469 | is initialized to 0. It returns NULL on a failure or when either | |
| 1470 | elem_size and/or num_elem is 0. | |
| 1471 | ||
| 1472 | typedef void *sasl_realloc_t(void *mem_ptr, unsigned long | |
| 1473 | new_size); | |
| 1474 | ||
| 1475 | This changes the size of a memory block previously allocated by | |
| 1476 | malloc or calloc, and returns a pointer to the new location (which | |
| 1477 | may be different from mem_ptr). If mem_ptr is NULL, it is identi- | |
| 1478 | cal to the malloc function. | |
| 1479 | ||
| 1480 | It returns NULL on a failure or when new_size is 0. On failure the | |
| 1481 | original block is unchanged. When new_size is 0 the function works | |
| 1482 | as the free function. | |
| 1483 | ||
| 1484 | typedef void sasl_free_t(void *mem_ptr); | |
| 1485 | ||
| 1486 | This releases the memory in mem_ptr that was allocated by the mal- | |
| 1487 | loc or the calloc or resized by the realloc. If mem_ptr is NULL, | |
| 1488 | the function does nothing and returns immediately. The contents of | |
| 1489 | the memory may be altered by this call. | |
| 1490 | ||
| 1491 | 6. Additional Properties | |
| 1492 | ||
| 1493 | <<To be completed>> | |
| 1494 | ||
| 1495 | ||
| 1496 | ||
| 1497 | Newman et al. Expires: August 2003 FORMFEED[Page 25] | |
| 1498 | ||
| 1499 | ||
| 1500 | ||
| 1501 | ||
| 1502 | ||
| 1503 | INTERNET DRAFT SASL C API February 2003 | |
| 1504 | ||
| 1505 | ||
| 1506 | SASL_SSF -- security layer security strength factor, | |
| 1507 | if 0, call to sasl_encode, sasl_decode unnecessary | |
| 1508 | SASL_MAXOUTBUF -- security layer max output buf unsigned | |
| 1509 | SASL_DEFUSERREALM -- default realm passed to sasl_server_new or set with | |
| 1510 | sasl_setprop | |
| 1511 | SASL_GETOPTCTX -- context for getopt callback | |
| 1512 | SASL_CALLBACK -- current callback function list | |
| 1513 | SASL_IPLOCALPORT -- iplocalport string passed to sasl_server_new/ | |
| 1514 | sasl_client_new | |
| 1515 | SASL_IPREMOTEPORT -- ipremoteport string passed to sasl_server_new/ | |
| 1516 | sasl_client_new | |
| 1517 | SASL_SERVICE -- service passed to sasl_*_new | |
| 1518 | SASL_SERVERFQDN -- serverFQDN passed to sasl_*_new | |
| 1519 | SASL_AUTHSOURCE -- name of the active plugin, if any | |
| 1520 | SASL_MECHNAME -- active SASL mechanism name, if any | |
| 1521 | SASL_AUTHUSER -- authentication/admin user (authorization id?) | |
| 1522 | ||
| 1523 | 7. References | |
| 1524 | ||
| 1525 | [IMAP4] Crispin, M., "Internet Message Access Protocol - Version | |
| 1526 | 4rev1", RFC 2060, University of Washington, December 1996. | |
| 1527 | ||
| 1528 | [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate | |
| 1529 | Requirement Levels", RFC 2119, Harvard University, March 1997. | |
| 1530 | ||
| 1531 | [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", | |
| 1532 | RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. | |
| 1533 | ||
| 1534 | [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, | |
| 1535 | Carnegie Mellon, December 1994. | |
| 1536 | ||
| 1537 | [SASL] Myers, "Simple Authentication and Security Layer (SASL)", | |
| 1538 | RFC 2222, Netscape Communications, October 1997. | |
| 1539 | ||
| 1540 | [GSSAPI] | |
| 1541 | ||
| 1542 | 8. Acknowledgements | |
| 1543 | ||
| 1544 | The editor would like to thank Rob Siemborski and Ken Murchison | |
| 1545 | for providing useful feedback and suggestions. | |
| 1546 | ||
| 1547 | 9. Author's and Editor's Addresses | |
| 1548 | ||
| 1549 | ||
| 1550 | Author: | |
| 1551 | ||
| 1552 | Chris Newman | |
| 1553 | Innosoft International, Inc. | |
| 1554 | ||
| 1555 | ||
| 1556 | ||
| 1557 | Newman et al. Expires: August 2003 FORMFEED[Page 26] | |
| 1558 | ||
| 1559 | ||
| 1560 | ||
| 1561 | ||
| 1562 | ||
| 1563 | INTERNET DRAFT SASL C API February 2003 | |
| 1564 | ||
| 1565 | ||
| 1566 | 1050 Lakes Drive | |
| 1567 | West Covina, CA 91790 USA | |
| 1568 | ||
| 1569 | Email: chris.newman@innosoft.com | |
| 1570 | ||
| 1571 | ||
| 1572 | Editor: | |
| 1573 | ||
| 1574 | Alexey Melnikov | |
| 1575 | ACI WorldWide/MessagingDirect | |
| 1576 | 59 Clarendon Road | |
| 1577 | Watford, Hertfordshire, WD17 1FQ, UK | |
| 1578 | ||
| 1579 | Email: mel@messagingdirect.com | |
| 1580 | ||
| 1581 | ||
| 1582 | 10. Full Copyright Statement | |
| 1583 | ||
| 1584 | Copyright (C) The Internet Society (2003). All Rights Reserved. | |
| 1585 | ||
| 1586 | This document and translations of it may be copied and furnished to | |
| 1587 | others, and derivative works that comment on or otherwise explain it | |
| 1588 | or assist in its implementation may be prepared, copied, published | |
| 1589 | and distributed, in whole or in part, without restriction of any | |
| 1590 | kind, provided that the above copyright notice and this paragraph are | |
| 1591 | included on all such copies and derivative works. However, this doc- | |
| 1592 | ument itself may not be modified in any way, such as by removing the | |
| 1593 | copyright notice or references to the Internet Society or other | |
| 1594 | Internet organizations, except as needed for the purpose of develop- | |
| 1595 | ing Internet standards in which case the procedures for copyrights | |
| 1596 | defined in the Internet Standards process must be followed, or as | |
| 1597 | required to translate it into languages other than English. | |
| 1598 | ||
| 1599 | The limited permissions granted above are perpetual and will not be | |
| 1600 | revoked by the Internet Society or its successors or assigns. | |
| 1601 | ||
| 1602 | This document and the information contained herein is provided on an | |
| 1603 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 1604 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 1605 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 1606 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- | |
| 1607 | CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 1608 | ||
| 1609 | Acknowledgement | |
| 1610 | ||
| 1611 | Funding for the RFC Editor function is currently provided by the | |
| 1612 | Internet Society. | |
| 1613 | ||
| 1614 | ||
| 1615 | ||
| 1616 | ||
| 1617 | Newman et al. Expires: August 2003 FORMFEED[Page 27] | |
| 1618 | ||
| 1619 | ||
| 1620 | ||
| 1621 | ||
| 1622 | ||
| 1623 | INTERNET DRAFT SASL C API February 2003 | |
| 1624 | ||
| 1625 | ||
| 1626 | A. Appendix A -- Design Goals | |
| 1627 | ||
| 1628 | The design goals of the SASL C API are as follows: | |
| 1629 | ||
| 1630 | ||
| 1631 | o To be simple and practical to use. | |
| 1632 | ||
| 1633 | o To provide related utility services in addition to core SASL func- | |
| 1634 | tionality. | |
| 1635 | ||
| 1636 | o To be reasonably extensible. | |
| 1637 | ||
| 1638 | o To be suitable for use in a multi-threaded server or client. | |
| 1639 | ||
| 1640 | o To avoid dependancies on a specific memory allocation system, thread | |
| 1641 | package or network model. | |
| 1642 | ||
| 1643 | o To be an independent service rather than a new layer. | |
| 1644 | ||
| 1645 | ||
| 1646 | B. SASL API Index | |
| 1647 | ||
| 1648 | <<To be completed>> | |
| 1649 | ||
| 1650 | ||
| 1651 | ||
| 1652 | ||
| 1653 | ||
| 1654 | ||
| 1655 | ||
| 1656 | ||
| 1657 | ||
| 1658 | ||
| 1659 | ||
| 1660 | ||
| 1661 | ||
| 1662 | ||
| 1663 | ||
| 1664 | ||
| 1665 | ||
| 1666 | ||
| 1667 | ||
| 1668 | ||
| 1669 | ||
| 1670 | ||
| 1671 | ||
| 1672 | ||
| 1673 | ||
| 1674 | ||
| 1675 | ||
| 1676 | ||
| 1677 | Newman et al. Expires: August 2003 FORMFEED[Page 28] | |
| 1678 | ||
| 1679 | ||
| 1680 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group C. Newman | |
| 7 | Internet Draft: PASSDSS-3DES-1 SASL Mechanism Innosoft | |
| 8 | Document: draft-newman-sasl-passdss-01.txt March 1998 | |
| 9 | Expires in six months | |
| 10 | ||
| 11 | ||
| 12 | DSS Secured Password Authentication Mechanism | |
| 13 | ||
| 14 | ||
| 15 | Status of this memo | |
| 16 | ||
| 17 | This document is an Internet-Draft. Internet-Drafts are working | |
| 18 | documents of the Internet Engineering Task Force (IETF), its areas, | |
| 19 | and its working groups. Note that other groups may also distribute | |
| 20 | working documents as Internet-Drafts. | |
| 21 | ||
| 22 | Internet-Drafts are draft documents valid for a maximum of six | |
| 23 | months and may be updated, replaced, or obsoleted by other | |
| 24 | documents at any time. It is inappropriate to use Internet-Drafts | |
| 25 | as reference material or to cite them other than as "work in | |
| 26 | progress." | |
| 27 | ||
| 28 | To view the entire list of current Internet-Drafts, please check | |
| 29 | the "1id-abstracts.txt" listing contained in the Internet-Drafts | |
| 30 | Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net | |
| 31 | (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East | |
| 32 | Coast), or ftp.isi.edu (US West Coast). | |
| 33 | ||
| 34 | ||
| 35 | Abstract | |
| 36 | ||
| 37 | Some system administrators are faced with a choice between | |
| 38 | deploying a new authentication infrastructure or sending | |
| 39 | unencrypted passwords in the clear over the Internet. Deploying a | |
| 40 | new authentication infrastructure often involves modifying | |
| 41 | operating system services or keeping parallel authentication | |
| 42 | databases up to date and is thus unacceptable to many | |
| 43 | administrators. | |
| 44 | ||
| 45 | Solutions which encrypt the entire session are often crippled with | |
| 46 | weak keys (due to government restrictions) which are unsuitable for | |
| 47 | passwords. In addition, such solutions often reduce performance of | |
| 48 | the entire session to an unacceptable level. This specification | |
| 49 | defines a SASL [SASL] mechanism which is compatible with existing | |
| 50 | password-based authentication databases and does not require a | |
| 51 | security layer for the remainder of the session. | |
| 52 | ||
| 53 | [NOTE: Public discussion of this mechanism may take place on the | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Newman [Page 1] | |
| 58 | ||
| 59 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 60 | ||
| 61 | ||
| 62 | ietf-sasl@imc.org mailing list with a subscription address of | |
| 63 | ietf-sasl-request@imc.org. Private comments may be sent to the | |
| 64 | author]. | |
| 65 | ||
| 66 | 1. How to Read This Document | |
| 67 | ||
| 68 | This document is intended primarily for a programmer. If | |
| 69 | successful, it should be possible for a competent programmer to | |
| 70 | write a client implementation using this specification, the SASL | |
| 71 | [SASL] specification, an understanding of how to generate random | |
| 72 | numbers [RANDOM], a description or implementation of the DES and | |
| 73 | SHA1 [SHA1] algorithms and a multi-precision integer math library. | |
| 74 | A cryptographic library or a copy of "Applied Cryptography" | |
| 75 | [SCHNEIER] or similar reference is helpful for any implementation | |
| 76 | and necessary for server DSS key generation. | |
| 77 | ||
| 78 | The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" | |
| 79 | in this document are to be interpreted as defined in "Key words for | |
| 80 | use in RFCs to Indicate Requirement Levels" [KEYWORDS]. | |
| 81 | ||
| 82 | 1.1. Data Types Used in this Document | |
| 83 | ||
| 84 | A list of data types used in this document follows. Note that the | |
| 85 | majority of this section is copied from the secure shell | |
| 86 | specification [SSH-ARCH]. | |
| 87 | ||
| 88 | octet A basic 8-bit unit of data. | |
| 89 | ||
| 90 | uint32 A 32-bit unsigned integer. Stored as four octets in | |
| 91 | network byte order (also known as big endian or most | |
| 92 | significant byte [MSB] first). For example, the decimal | |
| 93 | value 699921578 (hexadecimal 29b7f4aa) is represented with | |
| 94 | the hexadecimal octet sequence 29 b7 f4 aa. | |
| 95 | ||
| 96 | string A string is a length-prefixed octet string. The length is | |
| 97 | represented as a uint32 with the data immediately | |
| 98 | following. A length of 0 indicates an empty string. The | |
| 99 | string MAY contain NUL or 8-bit octets. When used to | |
| 100 | represent textual strings, the characters are interpreted | |
| 101 | in UTF-8 [UTF-8]. Other character encoding schemes MUST | |
| 102 | NOT be used. | |
| 103 | ||
| 104 | mpint Represents multiple precision integers in two's complement | |
| 105 | format, stored as a string, most significant octet first. | |
| 106 | Negative numbers have one in the most significant bit of | |
| 107 | the first octet of the string data. If the most significant | |
| 108 | bit would be set for a positive number, the number MUST be | |
| 109 | preceded by a zero byte. Unnecessary leading zero or 255 | |
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Newman [Page 2] | |
| 114 | ||
| 115 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 116 | ||
| 117 | ||
| 118 | bytes MUST NOT be included. The value zero MUST be stored | |
| 119 | as a string with zero bytes of data. | |
| 120 | ||
| 121 | By convention, a number that is used in modular | |
| 122 | computations in the field of integers mod n SHOULD be | |
| 123 | represented in the range 0 <= x < n. | |
| 124 | ||
| 125 | Examples: | |
| 126 | ||
| 127 | value (hex) representation (hex) | |
| 128 | ----------------------------------------------------------- | |
| 129 | 0 00 00 00 00 | |
| 130 | 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 | |
| 131 | 80 00 00 00 02 00 80 | |
| 132 | -1234 00 00 00 02 ed cc | |
| 133 | -deadbeef 00 00 00 05 ff 21 52 41 11 | |
| 134 | ||
| 135 | 1.2. Glossary | |
| 136 | ||
| 137 | This section includes some acronyms used in this document. | |
| 138 | ||
| 139 | DES The U.S. Government Data Encryption Standard is a symmetric | |
| 140 | encryption algorithm introduced in 1975 which uses a 56 bit | |
| 141 | key. The algorithm is documented in [SCHNEIER]. | |
| 142 | ||
| 143 | DSA The U.S. Government Digital Signature Algorithm standard. A | |
| 144 | public key signature algorithm available for unrestricted use | |
| 145 | without a license. | |
| 146 | ||
| 147 | DSS The U.S. Government Digital Signature Standard [DSS] which | |
| 148 | employs the DSA algorithm. | |
| 149 | ||
| 150 | HMAC A hash-based message authentication code [HMAC] summarized in | |
| 151 | Appendix A.4. Test cases are available in [HMAC-TEST]. | |
| 152 | ||
| 153 | SHA The Secure Hash Algorithm (version 1) which is part of the DSS | |
| 154 | standard. | |
| 155 | ||
| 156 | triple-DES | |
| 157 | Use of the DES algorithm three times in an encrypt-decrypt- | |
| 158 | encrypt mode with three independent keys as described in | |
| 159 | appendix A.3. | |
| 160 | ||
| 161 | 2. Overview | |
| 162 | ||
| 163 | This section includes a brief discussion of design goals, intended | |
| 164 | use and an overview for this SASL mechanism. An overview of some | |
| 165 | of the algorithms used is in Appendix A. | |
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Newman [Page 3] | |
| 170 | ||
| 171 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 172 | ||
| 173 | ||
| 174 | 2.1. Design Goals | |
| 175 | ||
| 176 | The ideal authentication mechanism would be simple, fast, fully | |
| 177 | secure, freely distributable without restrictions and backwards | |
| 178 | compatible with deployed back-end authentication databases. | |
| 179 | Unfortunately, it is not possible to achieve all these goals so | |
| 180 | priorities and tradeoffs are necessary. This mechanism has | |
| 181 | compatibility with deployed back-end authentication databases and | |
| 182 | protection from passive and active attacks on the underlying | |
| 183 | connection as primary design goals. Simplicity and unrestricted | |
| 184 | binary distribution are secondary design goals. | |
| 185 | ||
| 186 | Backwards compatibility is achieved by using plain-text | |
| 187 | passphrases. Protection from passive and active attacks is | |
| 188 | achieved by using public and symmetric key technology to encrypt | |
| 189 | the passphrase and optionally protect the remainder of the session. | |
| 190 | Some simplicity is achieved by avoiding complicated public key | |
| 191 | certification issues and formats as well as making the SASL session | |
| 192 | security layer and certification by the client optional. | |
| 193 | Unrestricted binary distribution is hopefully achieved by using | |
| 194 | unencumbered algorithms and making the SASL privacy layer optional. | |
| 195 | ||
| 196 | 2.2. Intended Use | |
| 197 | ||
| 198 | This is intended as a plug-and-play mechanism for services layered | |
| 199 | on top of deployed passphrase-based back-end authentication | |
| 200 | databases. When no security layer is implemented it can be added | |
| 201 | to a SASL-based protocol without modifying or substituting network | |
| 202 | read and write APIs. When the optional session privacy protection | |
| 203 | is omitted, the author speculates that it may be possible to make a | |
| 204 | binary implementation which would be exportable from the United | |
| 205 | States. | |
| 206 | ||
| 207 | For cases where simplicity, speed or unrestricted source code | |
| 208 | distribution is more desirable than backwards compatibility or | |
| 209 | security, a mechanism such as CRAM-MD5 [CRAM-MD5] or SCRAM [SCRAM] | |
| 210 | is preferred. | |
| 211 | ||
| 212 | The optional SASL integrity and privacy protection is provided as a | |
| 213 | simple alternative to full service security layers such as TLS | |
| 214 | [TLS] or Secure Shell [SSH-ARCH]. However, there are many | |
| 215 | advantages to full service security layers such as compression, | |
| 216 | faster symmetric cipher options, and the ability to leverage other | |
| 217 | public key infrastructures. An implementation which supports TLS | |
| 218 | may have no incentive to support SASL security layers at all. The | |
| 219 | complexity verses functionality tradeoff is significant enough that | |
| 220 | these mechanisms do not compete. | |
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Newman [Page 4] | |
| 226 | ||
| 227 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 228 | ||
| 229 | ||
| 230 | 2.3. Mechanism Overview | |
| 231 | ||
| 232 | The PASSDSS-3DES-1 mechanism uses three components to perform a | |
| 233 | secure authentication against a legacy passphrase database. | |
| 234 | ||
| 235 | In order to protect against active attacks, a DSS public key in a | |
| 236 | format compatible with Secure Shell [SSH-TRANS] is used to | |
| 237 | authenticate the server to the client. The client is presumed to | |
| 238 | have the server's public key or a SHA-1 hash thereof stored locally | |
| 239 | in a secure database. If the client is willing to risk exposure to | |
| 240 | active attacks, it may skip the public key certification step | |
| 241 | altogether or do a one-time initialization of its local database, | |
| 242 | perhaps with user interaction. | |
| 243 | ||
| 244 | In addition to the DSS public key, a Diffie-Hellman key exchange is | |
| 245 | used to generate a key for encrypting the passphrase. The | |
| 246 | "PASSDSS-3DES-1" variant of this mechanism uses the same fixed | |
| 247 | Diffie-Hellman group used by Secure Shell's diffie-hellman-group1- | |
| 248 | sha1 key exchange [SSH-TRANS]. If more groups are necessary, they | |
| 249 | will be assigned to mechanism variants "PASSDSS-3DES-2" and so | |
| 250 | forth. | |
| 251 | ||
| 252 | Finally, the triple-DES algorithm is used to encrypt the client's | |
| 253 | passphrase and send it to the server. | |
| 254 | ||
| 255 | 2.4. Message Format Overview | |
| 256 | ||
| 257 | This section provides a quick overview of the format of the | |
| 258 | messages. The formal definition of the syntax for these messages | |
| 259 | is in section 6. A detailed discussion of their implementation on | |
| 260 | clients and servers is in sections 3 and 4 respectively. | |
| 261 | ||
| 262 | First message from client to server: | |
| 263 | string azname ; the user name to login as, may be empty if | |
| 264 | same as authentication name | |
| 265 | string authname ; the authentication name | |
| 266 | mpint X ; Diffie-Hellman parameter X | |
| 267 | ||
| 268 | The challenge from server to client is as follows: | |
| 269 | uint32 pklength ; length of SSH-style DSA server public key | |
| 270 | string "ssh-dss" ; constant string "ssh-dss" (lower case) | |
| 271 | mpint p ; DSA public key parameters | |
| 272 | mpint q | |
| 273 | mpint g | |
| 274 | mpint y | |
| 275 | mpint Y ; Diffie-Hellman parameter Y | |
| 276 | OCTET ssecmask ; SASL security layers offered | |
| 277 | 3 OCTET sbuflen ; maximum server security layer block size | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Newman [Page 5] | |
| 282 | ||
| 283 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 284 | ||
| 285 | ||
| 286 | uint32 siglength ; length of SSH-style dss signature | |
| 287 | string "ssh-dss" ; constant string "ssh-dss" (lower case) | |
| 288 | mpint r ; DSA signature parameters | |
| 289 | mpint s | |
| 290 | ||
| 291 | The client then sends the following message encrypted with | |
| 292 | triple-DES: | |
| 293 | OCTET csecmask ; SASL security layer selection | |
| 294 | 3 OCTET cbuflen ; maximum client block size | |
| 295 | string passphrase ; the user's passphrase | |
| 296 | 20 OCTET cli-hmac ; a client HMAC-SHA-1 signature | |
| 297 | ||
| 298 | 3. Client Implementation of PASSDSS-3DES-1 | |
| 299 | ||
| 300 | This section includes a step-by-step guide for client implementors. | |
| 301 | Although section 6 contains the formal definition of the syntax and | |
| 302 | is the authoritative reference in case of errors here, this section | |
| 303 | should be sufficient to build a correct implementation. | |
| 304 | ||
| 305 | The SASL mechanism name is "PASSDSS-3DES-1". | |
| 306 | ||
| 307 | The value of n used for the Diffie-Hellman exchange is as follows | |
| 308 | (represented as an unsigned hexadecimal integer): | |
| 309 | ||
| 310 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | |
| 311 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | |
| 312 | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | |
| 313 | E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED | |
| 314 | EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 | |
| 315 | FFFFFFFF FFFFFFFF. | |
| 316 | ||
| 317 | When represented as an "mpint", this would have a prefix of | |
| 318 | "0000008100." The value of g is 2. This group was taken from the | |
| 319 | ISAKMP/Oakley specification, and was originally generated by | |
| 320 | Richard Schroeppel at the University of Arizona. Properties of | |
| 321 | this prime are described in [Orm96]. | |
| 322 | ||
| 323 | The client begins by doing the following: | |
| 324 | ||
| 325 | (A) Generate the Diffie-Hellman private value "x". This should be | |
| 326 | less than (n - 1)/2. The number of bits of entropy to use in "x" | |
| 327 | is an important decision, as shorter lengths will be less secure | |
| 328 | and longer lengths will noticeably reduce performance. At the time | |
| 329 | this was written, 192 bits of entropy [RANDOM] is probably | |
| 330 | sufficient. For more information on this topic, see [SHORT-EXP]. | |
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Newman [Page 6] | |
| 338 | ||
| 339 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 340 | ||
| 341 | ||
| 342 | (B) Compute the Diffie-Hellman public value "X" as follows. If X | |
| 343 | has a value of 0, repeat step (A). | |
| 344 | x | |
| 345 | X = 2 mod n | |
| 346 | ||
| 347 | The client then sends the following three pieces of information to | |
| 348 | the server: | |
| 349 | ||
| 350 | (1) An authorization identity represented as a string. When the | |
| 351 | empty string is used, this defaults to the authentication identity. | |
| 352 | This is used by system administrators or proxy servers to login | |
| 353 | with a different user identity. | |
| 354 | ||
| 355 | (2) An authentication identity represented as a string. This is | |
| 356 | the identity whose passphrase will be used. | |
| 357 | ||
| 358 | (3) The "X" result from step (B) represented as an mpint. | |
| 359 | ||
| 360 | The server responds by sending a message containing the following | |
| 361 | information: | |
| 362 | ||
| 363 | (4) An "ssh-dss" public key compatible with Secure Shell, including | |
| 364 | the 32-bit length prefix in network byte order, the Secure Shell | |
| 365 | string "ssh-dss" and mpints for "p", "q", "g" and "y" (see Appendix | |
| 366 | A.1). | |
| 367 | ||
| 368 | (5) The mpint "Y" as defined for the Diffie-Hellman key exchange | |
| 369 | (see Appendix A.2). | |
| 370 | ||
| 371 | (6) A single octet bit mask representing the security layers | |
| 372 | available in the same format used by the KERBEROS_V4 mechanism | |
| 373 | [SASL]. Bit 0 (value 1) indicates it is permissible to have no | |
| 374 | security layer. Bit 1 (value 2) indicates integrity protection is | |
| 375 | permissible. Bit 2 (value 4) indicates privacy protection for the | |
| 376 | rest of the session is available. The remaining bits are reserved | |
| 377 | for future use. | |
| 378 | ||
| 379 | (7) A three octet unsigned integer in network byte order | |
| 380 | representing the maximum cipher-text buffer size the server is able | |
| 381 | to receive. If this is less than 32, it indicates that a SASL | |
| 382 | security layer is not supported. | |
| 383 | ||
| 384 | (8) A DSA signature, including a 32-bit length, the Secure Shell | |
| 385 | string "ssh-dss" and mpints for "r" and "s". | |
| 386 | ||
| 387 | The client then does the following: | |
| 388 | ||
| 389 | (C) Verify that "Y" is between 1 and n - 1 inclusive. If "Y" is | |
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Newman [Page 7] | |
| 394 | ||
| 395 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 396 | ||
| 397 | ||
| 398 | outside this range, the client MUST cancel the authentication. | |
| 399 | ||
| 400 | (D) Verify that the public key from step (4) belongs to the server. | |
| 401 | This can be done either with a database of SSH public keys or with | |
| 402 | a database of SHA1 hashes of such public keys. If the client does | |
| 403 | not have a matching entry for the server or does not have a public | |
| 404 | key database, it MAY skip this step although it SHOULD alert the | |
| 405 | user that the connection is susceptible to active attacks if it | |
| 406 | does so. It MAY also record the public key (or SHA1 hash thereof) | |
| 407 | in its database with permission from the user. | |
| 408 | ||
| 409 | (E) Compute the Diffie-Hellman key K as follows. It may be | |
| 410 | necessary to mask timing attacks [TIMING]. | |
| 411 | x | |
| 412 | K = Y mod n | |
| 413 | ||
| 414 | (F) Create a buffer containing data from steps (1) through (7) in | |
| 415 | order immediately followed by K represented as an mpint. | |
| 416 | ||
| 417 | (G) Compute the SHA1 hash of the buffer from (F). This produces a | |
| 418 | 20 octet result. | |
| 419 | ||
| 420 | (H) If the public key from step (4) was not certified, this step | |
| 421 | MAY be skipped. Otherwise, verify that the DSS signature is a | |
| 422 | signature of (G). This computation is done as defined in appendix | |
| 423 | A.1 where the output of step (G) represents the message "m" (note | |
| 424 | that this results in SHA1 being applied twice). | |
| 425 | ||
| 426 | (I) Compute the following 20-octet values. K represents the output | |
| 427 | of step (E) in mpint format. H represents the output of step (G). | |
| 428 | The || symbol represents string concatenation. "A" represents a | |
| 429 | single octet containing the US-ASCII value of capital letter A. | |
| 430 | cs-encryption-iv = SHA1( K || "A" || H ) | |
| 431 | sc-encryption-iv = SHA1( K || "B" || H ) | |
| 432 | cs-encryption-key-1 = SHA1( K || "C" || H ) | |
| 433 | cs-encryption-key-2 = SHA1( K || cs-encryption-key-1 ) | |
| 434 | cs-encryption-key = cs-encryption-key-1 || cs-encryption-key-2 | |
| 435 | sc-encryption-key-1 = SHA1( K || "D" || H ) | |
| 436 | sc-encryption-key-2 = SHA1( K || sc-encryption-key-1 ) | |
| 437 | sc-encryption-key = sc-encryption-key-1 || sc-encryption-key-2 | |
| 438 | cs-integrity-key = SHA1( K || "E" || H ) | |
| 439 | sc-integrity-key = SHA1( K || "F" || H ) | |
| 440 | ||
| 441 | (J) Create a buffer beginning with a bit mask for the selected | |
| 442 | security layer (it MUST be one offered in 6) followed by three | |
| 443 | octets representing the maximum cipher-text buffer size (at least | |
| 444 | 32) the client can accept in network byte order. This is followed | |
| 445 | by a string containing the passphrase. Note that integrity | |
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Newman [Page 8] | |
| 450 | ||
| 451 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 452 | ||
| 453 | ||
| 454 | protection is pointless unless the public key was certified in | |
| 455 | step (D) and the signature was verified in step (H). | |
| 456 | ||
| 457 | (K) Create a buffer containing items (1) through (7) immediately | |
| 458 | followed by the first four octets of (J). | |
| 459 | ||
| 460 | (L) Compute HMAC-SHA-1 with (K) as the data and the cs-integrity- | |
| 461 | key from step (I) as the key. This produces a 20 octet result. A | |
| 462 | summary of the HMAC-SHA-1 algorithm [HMAC] is in appendix A.4. | |
| 463 | ||
| 464 | (M) Create a buffer containing (J) followed by (L) followed by an | |
| 465 | arbitrary number of zero octets as necessary to reach the block | |
| 466 | size of DES and conceal the passphrase length from an eavesdropper. | |
| 467 | ||
| 468 | (N) Apply the triple-DES algorithm to (M) with the first 8 octets | |
| 469 | of cs-encryption-iv from step (I) as the initialization vector and | |
| 470 | the first 24 octets of cs-encryption-key as the key. If optional | |
| 471 | privacy protection is negotiated on, the triple-DES state is not | |
| 472 | reset. | |
| 473 | ||
| 474 | The client then sends a message to the server containing the | |
| 475 | following: | |
| 476 | ||
| 477 | (9) The output of step (N). | |
| 478 | ||
| 479 | If a SASL security layer is negotiated on, the following steps are | |
| 480 | used when sending a message: | |
| 481 | ||
| 482 | (O) Create a buffer containing a uint32 client packet number | |
| 483 | (starting from 0) immediately followed by the cs-integrity-key from | |
| 484 | step (I). | |
| 485 | ||
| 486 | (P) Compute HMAC-SHA-1 with (O) as the key and the data to transmit | |
| 487 | as the data. | |
| 488 | ||
| 489 | (Q) Create a buffer containing the data to transmit followed by the | |
| 490 | 20-octet output of (P). If privacy was negotiated on, this is | |
| 491 | followed by zero to seven padding octets followed by one more octet | |
| 492 | indicating the number of padding octets. The total size MUST be a | |
| 493 | multiple of the DES block size. | |
| 494 | ||
| 495 | (R) The result of step (Q) is encrypted with triple-DES if privacy | |
| 496 | was negotiated and is sent prefixed by a uint32 length, as required | |
| 497 | by SASL. | |
| 498 | ||
| 499 | If a SASL security layer was negotiated on, the following steps are | |
| 500 | taken when receiving a message: | |
| 501 | ||
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Newman [Page 9] | |
| 506 | ||
| 507 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 508 | ||
| 509 | ||
| 510 | (S) If privacy was negotiated on, the message is decrypted using | |
| 511 | triple-DES with the first 24 octets of sc-encryption-key as the | |
| 512 | key. The value of the last octet plus one indicates the number of | |
| 513 | octets to ignore at the end of the output. The sc-encryption-iv is | |
| 514 | used to initialize triple-DES state the first time this is done. | |
| 515 | ||
| 516 | (T) Create a buffer containing a uint32 server packet number | |
| 517 | (starting from 0) immediately followed by the sc-integrity-key. | |
| 518 | ||
| 519 | (U) Compute HMAC-SHA-1 with (T) as the key over the portion of the | |
| 520 | data excluding the 20 octet signature and any encryption padding. | |
| 521 | If this is the same as the 20 octet signature, then the data is not | |
| 522 | corrupted. | |
| 523 | ||
| 524 | 4. Server Implementation of PASSDSS-3DES-1 | |
| 525 | ||
| 526 | The section includes a step-by-step guide for server implementors. | |
| 527 | It is intended to be read in conjunction with section 3. | |
| 528 | ||
| 529 | The server MUST have a persistent DSS-SSH public key. Mechanisms | |
| 530 | for generating such keys are described in [SCHNEIER] and [DSS]. | |
| 531 | ||
| 532 | IMPORTANT NOTE: The server MUST be able to process any message from | |
| 533 | the client, including messages of any size, messages with invalid | |
| 534 | content and messages with NULs in the middle of strings. When | |
| 535 | input is illegal, the server MUST gracefully reject authentication | |
| 536 | or in extreme cases gracefully terminate the connection. | |
| 537 | Particular care to avoid buffer overruns is important if the user | |
| 538 | name or passphrase strings are copied. | |
| 539 | ||
| 540 | The server performs the following computations prior to or during | |
| 541 | the connection by the client: | |
| 542 | ||
| 543 | (a) Select a random number k less than (p - 1)/2. It is important | |
| 544 | to generate a good random number [RANDOM]. | |
| 545 | ||
| 546 | (b) Compute signature component "r" as follows: | |
| 547 | k | |
| 548 | r = (g mod p) mod q | |
| 549 | ||
| 550 | (c) Optionally pre-compute the group inverse of k, mod q and the | |
| 551 | value xr. | |
| 552 | ||
| 553 | (d) Select a random Diffie-Hellman private key y less than (n - | |
| 554 | 1)/2. Follow the same guidance as in (A) above. | |
| 555 | ||
| 556 | ||
| 557 | ||
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Newman [Page 10] | |
| 562 | ||
| 563 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 564 | ||
| 565 | ||
| 566 | (e) Compute the Diffie-Hellman public value Y as follows. If Y has | |
| 567 | a value of 0, repeat step (d) above. | |
| 568 | y | |
| 569 | Y = 2 mod n | |
| 570 | ||
| 571 | (f) Verify that the value X from the client is between 1 and (n - | |
| 572 | 1). If it isn't, fail the authentication. | |
| 573 | ||
| 574 | (g) Compute the Diffie-Hellman shared key K as follows. It may be | |
| 575 | necessary to mask timing attacks [TIMING]. | |
| 576 | y | |
| 577 | K = X mod n | |
| 578 | ||
| 579 | (h) Create a buffer containing items (1) through (7) above followed | |
| 580 | by K represented as an mpint. | |
| 581 | ||
| 582 | (i) Compute the SHA-1 hash of the buffer from (h). This produces a | |
| 583 | 20 octet result. | |
| 584 | ||
| 585 | (j) Generate a DSS signature of (i). The signature is made up of | |
| 586 | "r" from step (b) and the result following computation (partially | |
| 587 | completed in step c): | |
| 588 | -1 | |
| 589 | s = (k (SHA1(h) + xr)) mod q | |
| 590 | ||
| 591 | (k) Create a buffer containing items (4) through (8) and send it to | |
| 592 | the client. | |
| 593 | ||
| 594 | (l) Perform the computations as described in step (I) where K is | |
| 595 | the result of step (g) in mpint format and H is the result of step | |
| 596 | (i). | |
| 597 | ||
| 598 | (m) Decrypt message (9) from the client using triple-DES with cs- | |
| 599 | encryption-iv as the initialization vector and the first 24 octets | |
| 600 | of cs-encryption-key as the key. | |
| 601 | ||
| 602 | (n) Verify the passphrase from the output of step (m) against the | |
| 603 | authentication database. Fail the authentication if verification | |
| 604 | fails. | |
| 605 | ||
| 606 | (o) Verify that the selected security layer is permitted and the | |
| 607 | cipher text buffer size is at least 32. If not, fail the | |
| 608 | authentication. | |
| 609 | ||
| 610 | (p) Create a buffer containing steps (1) through (7) followed by | |
| 611 | the first four octets of the result from (m). | |
| 612 | ||
| 613 | (q) Compute the HMAC-SHA-1 of (p) with cs-integrity-key as the key. | |
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | Newman [Page 11] | |
| 618 | ||
| 619 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 620 | ||
| 621 | ||
| 622 | This produces a 20-octet result. | |
| 623 | ||
| 624 | (r) Compare the output of (q) with the 20 octet signature after the | |
| 625 | passphrase in the output of (m). If they don't match, fail the | |
| 626 | authentication. | |
| 627 | ||
| 628 | If a SASL security layer is negotiated on, sending and receiving | |
| 629 | procedures are similar to steps (O)-(U), with client and server | |
| 630 | roles exchanged (and thus sc-* values and cs-* value exchanged). | |
| 631 | Note that triple-DES state from step (m) is not reset. | |
| 632 | ||
| 633 | 5. Example | |
| 634 | ||
| 635 | The following is an example of the PASSDSS-3DES-1 mechanism using | |
| 636 | the IMAP [IMAP4] profile of SASL. Note that base64 encoding and | |
| 637 | the lack of an initial client response with the first command are | |
| 638 | characteristics of the IMAP profile of SASL and not characteristics | |
| 639 | of SASL or this mechanism. | |
| 640 | ||
| 641 | In this example, "C:" represents lines sent from the client to the | |
| 642 | server and "S:" represents lines sent from the server to the | |
| 643 | client. The wrapped lines are for editorial clarity -- there are | |
| 644 | no actual newlines in the middle of the messages. | |
| 645 | ||
| 646 | C: a001 AUTHENTICATE PASSDSS-3DES-1 | |
| 647 | S: + | |
| 648 | C: AAAAAAAAAAVjaHJpcwAAAIEAhuVbMxdLxrAQVyUWbAp+X09h6QmZ2Jebz | |
| 649 | H7YhtcbQyLbB9AGi1eIdojZYtAuVeE+PYkKUANLHI9XzWSFliIGMeUvBc | |
| 650 | bflHr+s9tZ5/5YZh9blb33km3tUYVKyB5XP530bDn+lY1lAv6tXHKZPrx | |
| 651 | b0zPhc+JGgpWGlmT5k9vx2Wk= | |
| 652 | S: + AAAA8gAAAAdzc2gtZHNzAAAAQQDPVlO6nFefrq6fA/dQKIoNj75Jjpp | |
| 653 | kVv3DkyILABCox2dMql0bnO48rHFuo167y6oukT/ocKupIw6bgKmdofgd | |
| 654 | AAAAFQDRpB6FrxemUGRuLjY/oiH/Qef14QAAAEEAkVr9rOlB58k5XoqmP | |
| 655 | NYTrVGZKWbCPcYtaL92ANxgWyjyRo49+m0+fHPNhNibQoLddEZF8lHPKW | |
| 656 | gb7z7qz0QMdgAAAEARcIEiMz5jTZo8COf2njL3BTWRND5NGAgZY7s1YOm | |
| 657 | 2BfjVyf1/MkOiQMiXeonrsfMc0sWQGgpRYRtJWpe56cc2AAAAgQDoV5Uk | |
| 658 | bcy3Gjf16MZwPLlJlvmjpSNv2dSSApoddd4+BgZr01zyt7hzb0yRruaN5 | |
| 659 | fG43DbJLkk7mtL1Hw8aYXBMQQzrPpHtx+anpCDoN2jlersCGFY2cnjxTf | |
| 660 | HqY139ohA8vVXYpapeXxKXR4//Ib/ApTGmwlOeIikKDrBmEGX/JgEAAAA | |
| 661 | AAAA8AAAAB3NzaC1kc3MAAAAVAI7j3HG8HyjCOxaGFOUTwZqe0xSHAAAA | |
| 662 | FHSqU41vPHTCRTqmxNFwXqazPlJH | |
| 663 | C: Obp6vQ83q1O/OnQDifZB1rWOci9LaSck8VxNB4UAFhRI56BAs4XPLqOWI | |
| 664 | CoB3LYZ | |
| 665 | S: a001 OK Authentication Completed | |
| 666 | ||
| 667 | The following private values were used in this example. These | |
| 668 | values are all represented as an mpint in hexadecimal (msb first). | |
| 669 | ||
| 670 | ||
| 671 | ||
| 672 | ||
| 673 | Newman [Page 12] | |
| 674 | ||
| 675 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 676 | ||
| 677 | ||
| 678 | The client private Diffie-Hellman "x" value: | |
| 679 | ||
| 680 | 00000018 666E35B4 3BF4BF2B 40E31359 7A5D3AD0 61FD4F6F 736A6114 | |
| 681 | ||
| 682 | The server private Diffie-Hellman "y" value: | |
| 683 | ||
| 684 | 00000018 587BDFD6 800D101C 8E82E233 3B5A07AA DB87B8F1 68DC194D | |
| 685 | ||
| 686 | The Diffie-Hellman shared secret: | |
| 687 | ||
| 688 | 00000080 3B46D3A8 D2163930 1C33D9FE EAFA528D F4B881CF DF906A03 | |
| 689 | 33249A88 42547FF6 49FDC149 1A5084B1 B425A105 CE571283 AC61D896 | |
| 690 | AF8F7AF7 F95643F3 00A91E57 BCB8CFD7 77A25CBD 35F59A9E 59E98BEA | |
| 691 | EA866339 7F0F9AA0 2F0F335C 8C6AAFF7 76BDB668 DF4D51AF 5B4FB807 | |
| 692 | 81A70901 F478FB86 BF42055C BAF46094 EC72E98A | |
| 693 | ||
| 694 | The DSA private key value (the public key is in the exchange): | |
| 695 | ||
| 696 | 00000014 252BCBFA 5634D706 6ED43128 972E181E 66BF9C30 | |
| 697 | ||
| 698 | The SHA-1 hash value used to compute the keys: | |
| 699 | ||
| 700 | 26 75 97 06 EB FE E3 69 C9 03 7D 49 64 19 D5 D2 97 66 E8 CE | |
| 701 | ||
| 702 | 6. Formal Syntax of PASSDSS-3DES-1 Messages | |
| 703 | ||
| 704 | This is the formal syntactic definition of the client and server | |
| 705 | messages. This uses ABNF [ABNF] notation including the core rules. | |
| 706 | The first three rules define the formal exchange. The later rules | |
| 707 | define the elements of the exchange. | |
| 708 | ||
| 709 | client-msg-1 = [azname] authname diffie-hellman-X | |
| 710 | ||
| 711 | server-msg-1 = dss-public-key diffie-hellman-Y | |
| 712 | ssecmask sbuflen dss-signature | |
| 713 | ||
| 714 | client-msg-2 = client-blob | |
| 715 | ||
| 716 | ||
| 717 | authname = string | |
| 718 | ;; interpreted as UTF-8 [UTF-8] | |
| 719 | ||
| 720 | azname = string | |
| 721 | ;; interpreted as UTF-8 [UTF-8] | |
| 722 | ||
| 723 | cbuflen = 3OCTET | |
| 724 | ;; Big endian binary unsigned integer | |
| 725 | ;; max length of client read buffer | |
| 726 | ||
| 727 | ||
| 728 | ||
| 729 | Newman [Page 13] | |
| 730 | ||
| 731 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 732 | ||
| 733 | ||
| 734 | cli-hmac = 20OCTET | |
| 735 | ||
| 736 | client-blob = 8*OCTET | |
| 737 | ;; encrypted version of client-encrypted | |
| 738 | ||
| 739 | client-encrypted = csecmask cbuflen passphrase cli-hmac *NUL | |
| 740 | ;; MUST be multiple of DES block size | |
| 741 | ||
| 742 | csecmask = OCTET | |
| 743 | ;; client selected protection layer | |
| 744 | ||
| 745 | diffie-hellman-X = mpint | |
| 746 | ||
| 747 | diffie-hellman-Y = mpint | |
| 748 | ||
| 749 | dss-g = mpint | |
| 750 | ||
| 751 | dss-p = mpint | |
| 752 | ||
| 753 | dss-public-key = length NUL NUL NUL %x07 "ssh-dss" | |
| 754 | dss-p dss-q dss-g dss-y | |
| 755 | ;; length is total length of remainder | |
| 756 | ;; as defined in [SSH-TRANS] | |
| 757 | ||
| 758 | dss-q = mpint | |
| 759 | ||
| 760 | dss-r = mpint | |
| 761 | ||
| 762 | dss-signature = length NUL NUL NUL %x07 "ssh-dss" | |
| 763 | dss-r dss-s | |
| 764 | ;; length is total length of remainder | |
| 765 | ||
| 766 | dss-s = mpint | |
| 767 | ||
| 768 | dss-y = mpint | |
| 769 | ||
| 770 | length = 4OCTET | |
| 771 | ;; binary number, big endian format (MSB first) | |
| 772 | ||
| 773 | mpint = length *OCTET | |
| 774 | ;; length specifies number of octets | |
| 775 | ;; see section 1 for detailed mpint definition | |
| 776 | ||
| 777 | passphrase = string | |
| 778 | ;; At least 64 octets MUST be supported | |
| 779 | ||
| 780 | ||
| 781 | ||
| 782 | ||
| 783 | ||
| 784 | ||
| 785 | Newman [Page 14] | |
| 786 | ||
| 787 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 788 | ||
| 789 | ||
| 790 | sbuflen = 3OCTET | |
| 791 | ;; Big endian binary unsigned integer | |
| 792 | ;; max length of server read buffer | |
| 793 | ||
| 794 | ssecmask = OCTET | |
| 795 | ;; server protection layer mask | |
| 796 | ||
| 797 | string = length *OCTET | |
| 798 | ;; the length determines the number of octets | |
| 799 | ;; OCTETs are interpreted as UTF-8 | |
| 800 | ||
| 801 | NUL = %x00 ;; US-ASCII NUL character | |
| 802 | ||
| 803 | 7. Security Considerations | |
| 804 | ||
| 805 | Security considerations are discussed throughout this memo. | |
| 806 | ||
| 807 | This mechanism supplies the server with the plain-text passphrase, | |
| 808 | so the server gains the ability to masquerade as the user to any | |
| 809 | other services which share the same passphrase. | |
| 810 | ||
| 811 | If the public key certification step is skipped, then an active | |
| 812 | attacker can gain the client's passphrase and thus the ability to | |
| 813 | masquerade as the user to any other services which share the same | |
| 814 | passphrase. Negotiating a security layer will fail to provide | |
| 815 | protection from an active attacker in this case. | |
| 816 | ||
| 817 | If no security layer is negotiated, the rest of the protocol | |
| 818 | session is subject to active and passive attacks. | |
| 819 | ||
| 820 | If an integrity-only layer is negotiated, the rest of the protocol | |
| 821 | is subject to passive eavesdropping. | |
| 822 | ||
| 823 | The quality of this mechanism depends on the quality of the random | |
| 824 | number generator used. See [RANDOM] for more information. | |
| 825 | ||
| 826 | 8. Multinational Considerations | |
| 827 | ||
| 828 | As remote access is a crucial service, users are encouraged to | |
| 829 | restrict user names and passphrases to the US-ASCII character set. | |
| 830 | However, if characters outside the US-ASCII character set are used | |
| 831 | in user names and passphrases, then they are interpreted according | |
| 832 | to UTF-8 [UTF-8] and it is a protocol error to include any octet | |
| 833 | sequences not legal for UTF-8. Servers are encouraged to enforce | |
| 834 | this restriction to discourage clients from using non-interoperable | |
| 835 | local character sets in this context. | |
| 836 | ||
| 837 | ||
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | Newman [Page 15] | |
| 842 | ||
| 843 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 844 | ||
| 845 | ||
| 846 | 9. Intellectual Property Issues and Acknowledgments | |
| 847 | ||
| 848 | David Kravitz holds U.S. Patent #5,231,668 on the DSA algorithm. | |
| 849 | NIST has made this patent available world-wide on a royalty-free | |
| 850 | basis. | |
| 851 | ||
| 852 | Diffie-Hellman was first published in 1976 [DIFFIE-HELLMAN]. U.S. | |
| 853 | Patent #4,200,770 granted April 1980 has expired. Canada Patent | |
| 854 | #1,121,480 was granted April 6, 1982 and may still apply at this | |
| 855 | time. | |
| 856 | ||
| 857 | DES is covered under U.S. Patent #3,962,539 granted June 1978, | |
| 858 | which has expired. | |
| 859 | ||
| 860 | The majority of the constructions in this specification were copied | |
| 861 | from the Secure Shell specifications [SSH-ARCH, SSH-TRANS]. | |
| 862 | Additional information is paraphrased from "Applied Cryptography" | |
| 863 | [SCHNEIER]. | |
| 864 | ||
| 865 | 10. References | |
| 866 | ||
| 867 | [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: | |
| 868 | ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, | |
| 869 | November 1997. | |
| 870 | ||
| 871 | [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension | |
| 872 | for Simple Challenge/Response", RFC 2195, MCI, September 1997. | |
| 873 | ||
| 874 | [DIFFIE-HELLMAN] Diffie, W., Hellman, M.E., "Privacy and | |
| 875 | Authentication: An introduction to Cryptography," Proceedings of | |
| 876 | the IEEE, v. 67, n. 3, March 1979, pp. 397-427. | |
| 877 | ||
| 878 | [DSS] National Institute of Standards and Technology, "Digital | |
| 879 | Signature Standard," NIST FIPS PUB 186, U.S. Department of | |
| 880 | Commerce, May 1994. | |
| 881 | ||
| 882 | [HMAC] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message | |
| 883 | Authentication", RFC 2104, IBM, UCSD, February 1997. | |
| 884 | ||
| 885 | [HMAC-TEST] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", | |
| 886 | RFC 2202, IBM, NIST, September 1997. | |
| 887 | ||
| 888 | [IMAP4] Crispin, M., "Internet Message Access Protocol - Version | |
| 889 | 4rev1", RFC 2060, University of Washington, December 1996. | |
| 890 | ||
| 891 | [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate | |
| 892 | Requirement Levels", RFC 2119, Harvard University, March 1997. | |
| 893 | ||
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | Newman [Page 16] | |
| 898 | ||
| 899 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 900 | ||
| 901 | ||
| 902 | [Orm96] Orman, H., "The Oakley Key Determination Protocol", version | |
| 903 | 1, TR97-92, Department of Computer Science Technical Report, | |
| 904 | University of Arizona. | |
| 905 | ||
| 906 | [RANDOM] Eastlake, Crocker, Schiller, "Randomness Recommendations | |
| 907 | for Security", RFC 1750, DEC, Cybercash, MIT, December 1994. | |
| 908 | ||
| 909 | [SASL] Myers, "Simple Authentication and Security Layer (SASL)", | |
| 910 | RFC 2222, Netscape Communications, October 1997. | |
| 911 | ||
| 912 | [SCHNEIER] Schneier, B., "Applied Cryptography: Protocols, | |
| 913 | Algorithms and Source Code in C," John Wiley and Sons, Inc., 1996. | |
| 914 | ||
| 915 | [SCRAM] Newman, "Salted Challenge Response Authentication Mechanism | |
| 916 | (SCRAM)", work in progress, January 1998. | |
| 917 | ||
| 918 | [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National | |
| 919 | Institute of Standards and Technology, U.S. Department of Commerce, | |
| 920 | April 1995. | |
| 921 | ||
| 922 | [SHORT-EXP] van Oorschot, P., Wiener, M., "On Diffie-Hellman Key | |
| 923 | Agreement with Short Exponents", Advances in Cryptography -- | |
| 924 | EUROCRYPT Springer-Verlag, ISBN 3-540-61186-X, pp. 332-343. | |
| 925 | ||
| 926 | [SSH-ARCH] Ylonen, Kivinen, Saarinen, "SSH Protocol Architecture", | |
| 927 | Work in progress, SSH, October 1997. | |
| 928 | ||
| 929 | [SSH-TRANS] Ylonen, Kivinen, Saarinen, "SSH Transport Layer | |
| 930 | Protocol", Work in progress, SSH, October 1997. | |
| 931 | ||
| 932 | [TIMING] Kocher, P., "Timing Attacks on Implementations of Diffie- | |
| 933 | Hellman, RSA, DSS and Other Systems", Advances in Cryptography -- | |
| 934 | CRYPTO '96 Proceedings, Lecture Notes in Computer Science, Vol | |
| 935 | 1109, Springer-Verlag, ISBN 3-540-61512-1, pp. 104-113. | |
| 936 | ||
| 937 | [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in | |
| 938 | progress. | |
| 939 | ||
| 940 | [UTF8] Yergeau, "UTF-8, a transformation format of ISO 10646", | |
| 941 | RFC 2279, Alis Technologies, January 1998. | |
| 942 | ||
| 943 | ||
| 944 | ||
| 945 | ||
| 946 | ||
| 947 | ||
| 948 | ||
| 949 | ||
| 950 | ||
| 951 | ||
| 952 | ||
| 953 | Newman [Page 17] | |
| 954 | ||
| 955 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 956 | ||
| 957 | ||
| 958 | 11. Author's Address | |
| 959 | ||
| 960 | Chris Newman | |
| 961 | Innosoft International, Inc. | |
| 962 | 1050 Lakes Drive | |
| 963 | West Covina, CA 91790 USA | |
| 964 | ||
| 965 | Email: chris.newman@innosoft.com | |
| 966 | ||
| 967 | Appendix A. Algorithm Overview | |
| 968 | ||
| 969 | This section provides a quick overview of the algorithms used. For | |
| 970 | a full understanding, the reader is encouraged to read "Applied | |
| 971 | Cryptography" [SCHNEIER]. The follow descriptions are paraphrased | |
| 972 | from that source. | |
| 973 | ||
| 974 | Note that an overview of the DES algorithm is not included as | |
| 975 | publicly available implementations and descriptions are very | |
| 976 | common. | |
| 977 | ||
| 978 | Appendix A.1. DSA Algorithm | |
| 979 | ||
| 980 | The DSA algorithm is a public key algorithm which can be used to | |
| 981 | sign messages such that the source can be verified using a public | |
| 982 | key. The algorithm has the following parameters: | |
| 983 | ||
| 984 | p is a prime number L bits long. Implementations MUST support L | |
| 985 | between 512 and 1024 bits. | |
| 986 | ||
| 987 | q is a 160-bit prime factor of (p - 1). | |
| 988 | ||
| 989 | (p - 1)/q | |
| 990 | g = h mod p where h is any number less than p - 1 such | |
| 991 | ||
| 992 | (p - 1)/q | |
| 993 | that h is greater than 1. | |
| 994 | ||
| 995 | x is a number less than q and represents the private key. | |
| 996 | ||
| 997 | x | |
| 998 | y = g mod p and represents the public key. | |
| 999 | ||
| 1000 | To sign a message m, the client generates a random number k less | |
| 1001 | than q and computes: | |
| 1002 | ||
| 1003 | k | |
| 1004 | r = (g mod p) mod q | |
| 1005 | ||
| 1006 | ||
| 1007 | ||
| 1008 | ||
| 1009 | Newman [Page 18] | |
| 1010 | ||
| 1011 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 1012 | ||
| 1013 | ||
| 1014 | -1 | |
| 1015 | s = (k (SHA1(m) + xr)) mod q | |
| 1016 | ||
| 1017 | The signature is represented as r and s, and is verified as | |
| 1018 | follows: | |
| 1019 | ||
| 1020 | -1 | |
| 1021 | w = s mod q | |
| 1022 | ||
| 1023 | u1 = (SHA1(m) * w) mod q | |
| 1024 | ||
| 1025 | u2 = (rw) mod q | |
| 1026 | ||
| 1027 | u1 u2 | |
| 1028 | v = ((g * y ) mod p) mod q | |
| 1029 | ||
| 1030 | If v = r then the signature is verified. | |
| 1031 | ||
| 1032 | Appendix A.2. Diffie-Hellman Algorithm | |
| 1033 | ||
| 1034 | The Diffie-Hellman algorithm is a key-exchange algorithm. It | |
| 1035 | allows two ends of a communications channel to establish a shared | |
| 1036 | secret which a passive eavesdropper can not easily determine. This | |
| 1037 | key can then be used in a symmetric algorithm such as triple-DES. | |
| 1038 | The two ends have a prior agreement on two numbers: | |
| 1039 | ||
| 1040 | n a large prime number | |
| 1041 | ||
| 1042 | g a primitive mod n. | |
| 1043 | ||
| 1044 | The client chooses a random large integer x and computes: | |
| 1045 | ||
| 1046 | x | |
| 1047 | X = g mod n | |
| 1048 | ||
| 1049 | and sends X to the server. The server chooses a random large | |
| 1050 | integer y and computes: | |
| 1051 | ||
| 1052 | y | |
| 1053 | Y = g mod n | |
| 1054 | ||
| 1055 | y | |
| 1056 | K = X mod n | |
| 1057 | ||
| 1058 | The server sends Y to the client. The client computes: | |
| 1059 | ||
| 1060 | x | |
| 1061 | K = Y mod n | |
| 1062 | ||
| 1063 | ||
| 1064 | ||
| 1065 | Newman [Page 19] | |
| 1066 | ||
| 1067 | Internet Draft PASSDSS-3DES-1 SASL Mechanism March 1998 | |
| 1068 | ||
| 1069 | ||
| 1070 | At this point, the client and server share the same secret K. | |
| 1071 | ||
| 1072 | Appendix A.3. Triple-DES Algorithm in EDE/outer-CBC Mode | |
| 1073 | ||
| 1074 | The DES algorithm uses an 8 octet (64 bit) key of which 56 bits are | |
| 1075 | significant. The triple-DES EDE algorithm uses a 24 octet (192 | |
| 1076 | bit) key of which roughly 112 bits are significant see [SCHNEIER] | |
| 1077 | for more details. The "EDE" refers to encrypt-decrypt-encrypt, and | |
| 1078 | the "CBC" refers to cipher-block-chaining where each cipher block | |
| 1079 | affects future cipher blocks. If E() is the DES encryption | |
| 1080 | function, D() is the DES decryption function, C is a cipher text | |
| 1081 | block and P is a plain-text block, then triple-DES EDE in CBC mode | |
| 1082 | with outer chaining is: | |
| 1083 | ||
| 1084 | C = E (D (E (P XOR C ))) | |
| 1085 | i K3 K2 K1 i i-1 | |
| 1086 | ||
| 1087 | NOTE: C is the initialization vector | |
| 1088 | 0 | |
| 1089 | ||
| 1090 | and the decryption function is: | |
| 1091 | ||
| 1092 | P = C XOR D (E (D (C ))) | |
| 1093 | i i-1 K3 K2 K1 i | |
| 1094 | ||
| 1095 | K1 is the first 8 octets of the triple-DES key, K2 is the second 8 | |
| 1096 | octets and K3 is the final 8 octets. | |
| 1097 | ||
| 1098 | Appendix A.4. HMAC-SHA-1 Keyed hash function | |
| 1099 | ||
| 1100 | HMAC-SHA-1 uses the SHA-1 hash function to create a keyed hash | |
| 1101 | function suitable for use as an integrity protection function. A | |
| 1102 | more complete description is in [HMAC]. A brief summary of the | |
| 1103 | algorithm follows: | |
| 1104 | ||
| 1105 | (A) If the key is longer than 64 octets, it is run through the | |
| 1106 | SHA-1 function to produce a 20 octet key. | |
| 1107 | ||
| 1108 | (B) The key is exclusive-ored with a 64 octet buffer filled with | |
| 1109 | the octet value 0x36. | |
| 1110 | ||
| 1111 | (C) SHA-1 is computed over (B) followed by the input text. | |
| 1112 | ||
| 1113 | (D) The key is exclusive-ored with a 64 octet buffer filled with | |
| 1114 | the octet value 0x5C. | |
| 1115 | ||
| 1116 | (E) SHA-1 is computed over (D) followed by the output of (C). | |
| 1117 | ||
| 1118 | ||
| 1119 | ||
| 1120 | ||
| 1121 | Newman [Page 20] |
| 17 | 17 | ln -s /usr/local/lib/sasl2 /usr/lib/sasl2 |
| 18 | 18 | </pre> |
| 19 | 19 | |
| 20 | <p>If you're checking this directly out of CVS, you'll need to run "sh | |
| 20 | <p>If you're checking this directly out of GIT, you'll need to run "sh | |
| 21 | 21 | ./SMakefile" to build the configure script first. |
| 22 | 22 | |
| 23 | 23 | <p>Read <A HREF="sysadmin.html">the System Administrator's Guide</A> to |
| 70 | 70 | |
| 71 | 71 | <p>As of version 2.1.16, SASL uses and requires a recent version of GNU |
| 72 | 72 | autotools (autoconf, automake, and libtool) to build its configuration scripts. |
| 73 | If you are building from CVS, you will need to have the autotools installed | |
| 73 | If you are building from GIT, you will need to have the autotools installed | |
| 74 | 74 | on your system. The version included with all releases of the developer tools |
| 75 | 75 | for OS X 10.2.x is too old for this; if you aren't using OS X 10.3 or later, |
| 76 | 76 | you should upgrade to more recent patchlevels of these tools. The easiest way |
| 134 | 134 | <li><b>Important!</b> You must make sure that all files have their |
| 135 | 135 | correct HFS filetype before starting to build this code! In |
| 136 | 136 | particular, all source and text files must be of type <tt>'TEXT'</tt>, |
| 137 | which is not the default if you use the Mac OS X cvs client to check | |
| 137 | which is not the default if you use the Mac OS X GIT client to check | |
| 138 | 138 | out the projects. If you run into this problem, you may want to use a |
| 139 | 139 | utility such as FileTyper to recursively change the type on all |
| 140 | 140 | files. CodeWarrior is less picky about the projects' filetypes, but |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group R. Rivest | |
| 7 | Request for Comments: 1321 MIT Laboratory for Computer Science | |
| 8 | and RSA Data Security, Inc. | |
| 9 | April 1992 | |
| 10 | ||
| 11 | ||
| 12 | The MD5 Message-Digest Algorithm | |
| 13 | ||
| 14 | Status of this Memo | |
| 15 | ||
| 16 | This memo provides information for the Internet community. It does | |
| 17 | not specify an Internet standard. Distribution of this memo is | |
| 18 | unlimited. | |
| 19 | ||
| 20 | Acknowlegements | |
| 21 | ||
| 22 | We would like to thank Don Coppersmith, Burt Kaliski, Ralph Merkle, | |
| 23 | David Chaum, and Noam Nisan for numerous helpful comments and | |
| 24 | suggestions. | |
| 25 | ||
| 26 | Table of Contents | |
| 27 | ||
| 28 | 1. Executive Summary 1 | |
| 29 | 2. Terminology and Notation 2 | |
| 30 | 3. MD5 Algorithm Description 3 | |
| 31 | 4. Summary 6 | |
| 32 | 5. Differences Between MD4 and MD5 6 | |
| 33 | References 7 | |
| 34 | APPENDIX A - Reference Implementation 7 | |
| 35 | Security Considerations 21 | |
| 36 | Author's Address 21 | |
| 37 | ||
| 38 | 1. Executive Summary | |
| 39 | ||
| 40 | This document describes the MD5 message-digest algorithm. The | |
| 41 | algorithm takes as input a message of arbitrary length and produces | |
| 42 | as output a 128-bit "fingerprint" or "message digest" of the input. | |
| 43 | It is conjectured that it is computationally infeasible to produce | |
| 44 | two messages having the same message digest, or to produce any | |
| 45 | message having a given prespecified target message digest. The MD5 | |
| 46 | algorithm is intended for digital signature applications, where a | |
| 47 | large file must be "compressed" in a secure manner before being | |
| 48 | encrypted with a private (secret) key under a public-key cryptosystem | |
| 49 | such as RSA. | |
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Rivest [Page 1] | |
| 58 | ||
| 59 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 60 | ||
| 61 | ||
| 62 | The MD5 algorithm is designed to be quite fast on 32-bit machines. In | |
| 63 | addition, the MD5 algorithm does not require any large substitution | |
| 64 | tables; the algorithm can be coded quite compactly. | |
| 65 | ||
| 66 | The MD5 algorithm is an extension of the MD4 message-digest algorithm | |
| 67 | 1,2]. MD5 is slightly slower than MD4, but is more "conservative" in | |
| 68 | design. MD5 was designed because it was felt that MD4 was perhaps | |
| 69 | being adopted for use more quickly than justified by the existing | |
| 70 | critical review; because MD4 was designed to be exceptionally fast, | |
| 71 | it is "at the edge" in terms of risking successful cryptanalytic | |
| 72 | attack. MD5 backs off a bit, giving up a little in speed for a much | |
| 73 | greater likelihood of ultimate security. It incorporates some | |
| 74 | suggestions made by various reviewers, and contains additional | |
| 75 | optimizations. The MD5 algorithm is being placed in the public domain | |
| 76 | for review and possible adoption as a standard. | |
| 77 | ||
| 78 | For OSI-based applications, MD5's object identifier is | |
| 79 | ||
| 80 | md5 OBJECT IDENTIFIER ::= | |
| 81 | iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5} | |
| 82 | ||
| 83 | In the X.509 type AlgorithmIdentifier [3], the parameters for MD5 | |
| 84 | should have type NULL. | |
| 85 | ||
| 86 | 2. Terminology and Notation | |
| 87 | ||
| 88 | In this document a "word" is a 32-bit quantity and a "byte" is an | |
| 89 | eight-bit quantity. A sequence of bits can be interpreted in a | |
| 90 | natural manner as a sequence of bytes, where each consecutive group | |
| 91 | of eight bits is interpreted as a byte with the high-order (most | |
| 92 | significant) bit of each byte listed first. Similarly, a sequence of | |
| 93 | bytes can be interpreted as a sequence of 32-bit words, where each | |
| 94 | consecutive group of four bytes is interpreted as a word with the | |
| 95 | low-order (least significant) byte given first. | |
| 96 | ||
| 97 | Let x_i denote "x sub i". If the subscript is an expression, we | |
| 98 | surround it in braces, as in x_{i+1}. Similarly, we use ^ for | |
| 99 | superscripts (exponentiation), so that x^i denotes x to the i-th | |
| 100 | power. | |
| 101 | ||
| 102 | Let the symbol "+" denote addition of words (i.e., modulo-2^32 | |
| 103 | addition). Let X <<< s denote the 32-bit value obtained by circularly | |
| 104 | shifting (rotating) X left by s bit positions. Let not(X) denote the | |
| 105 | bit-wise complement of X, and let X v Y denote the bit-wise OR of X | |
| 106 | and Y. Let X xor Y denote the bit-wise XOR of X and Y, and let XY | |
| 107 | denote the bit-wise AND of X and Y. | |
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Rivest [Page 2] | |
| 114 | ||
| 115 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 116 | ||
| 117 | ||
| 118 | 3. MD5 Algorithm Description | |
| 119 | ||
| 120 | We begin by supposing that we have a b-bit message as input, and that | |
| 121 | we wish to find its message digest. Here b is an arbitrary | |
| 122 | nonnegative integer; b may be zero, it need not be a multiple of | |
| 123 | eight, and it may be arbitrarily large. We imagine the bits of the | |
| 124 | message written down as follows: | |
| 125 | ||
| 126 | m_0 m_1 ... m_{b-1} | |
| 127 | ||
| 128 | The following five steps are performed to compute the message digest | |
| 129 | of the message. | |
| 130 | ||
| 131 | 3.1 Step 1. Append Padding Bits | |
| 132 | ||
| 133 | The message is "padded" (extended) so that its length (in bits) is | |
| 134 | congruent to 448, modulo 512. That is, the message is extended so | |
| 135 | that it is just 64 bits shy of being a multiple of 512 bits long. | |
| 136 | Padding is always performed, even if the length of the message is | |
| 137 | already congruent to 448, modulo 512. | |
| 138 | ||
| 139 | Padding is performed as follows: a single "1" bit is appended to the | |
| 140 | message, and then "0" bits are appended so that the length in bits of | |
| 141 | the padded message becomes congruent to 448, modulo 512. In all, at | |
| 142 | least one bit and at most 512 bits are appended. | |
| 143 | ||
| 144 | 3.2 Step 2. Append Length | |
| 145 | ||
| 146 | A 64-bit representation of b (the length of the message before the | |
| 147 | padding bits were added) is appended to the result of the previous | |
| 148 | step. In the unlikely event that b is greater than 2^64, then only | |
| 149 | the low-order 64 bits of b are used. (These bits are appended as two | |
| 150 | 32-bit words and appended low-order word first in accordance with the | |
| 151 | previous conventions.) | |
| 152 | ||
| 153 | At this point the resulting message (after padding with bits and with | |
| 154 | b) has a length that is an exact multiple of 512 bits. Equivalently, | |
| 155 | this message has a length that is an exact multiple of 16 (32-bit) | |
| 156 | words. Let M[0 ... N-1] denote the words of the resulting message, | |
| 157 | where N is a multiple of 16. | |
| 158 | ||
| 159 | 3.3 Step 3. Initialize MD Buffer | |
| 160 | ||
| 161 | A four-word buffer (A,B,C,D) is used to compute the message digest. | |
| 162 | Here each of A, B, C, D is a 32-bit register. These registers are | |
| 163 | initialized to the following values in hexadecimal, low-order bytes | |
| 164 | first): | |
| 165 | ||
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Rivest [Page 3] | |
| 170 | ||
| 171 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 172 | ||
| 173 | ||
| 174 | word A: 01 23 45 67 | |
| 175 | word B: 89 ab cd ef | |
| 176 | word C: fe dc ba 98 | |
| 177 | word D: 76 54 32 10 | |
| 178 | ||
| 179 | 3.4 Step 4. Process Message in 16-Word Blocks | |
| 180 | ||
| 181 | We first define four auxiliary functions that each take as input | |
| 182 | three 32-bit words and produce as output one 32-bit word. | |
| 183 | ||
| 184 | F(X,Y,Z) = XY v not(X) Z | |
| 185 | G(X,Y,Z) = XZ v Y not(Z) | |
| 186 | H(X,Y,Z) = X xor Y xor Z | |
| 187 | I(X,Y,Z) = Y xor (X v not(Z)) | |
| 188 | ||
| 189 | In each bit position F acts as a conditional: if X then Y else Z. | |
| 190 | The function F could have been defined using + instead of v since XY | |
| 191 | and not(X)Z will never have 1's in the same bit position.) It is | |
| 192 | interesting to note that if the bits of X, Y, and Z are independent | |
| 193 | and unbiased, the each bit of F(X,Y,Z) will be independent and | |
| 194 | unbiased. | |
| 195 | ||
| 196 | The functions G, H, and I are similar to the function F, in that they | |
| 197 | act in "bitwise parallel" to produce their output from the bits of X, | |
| 198 | Y, and Z, in such a manner that if the corresponding bits of X, Y, | |
| 199 | and Z are independent and unbiased, then each bit of G(X,Y,Z), | |
| 200 | H(X,Y,Z), and I(X,Y,Z) will be independent and unbiased. Note that | |
| 201 | the function H is the bit-wise "xor" or "parity" function of its | |
| 202 | inputs. | |
| 203 | ||
| 204 | This step uses a 64-element table T[1 ... 64] constructed from the | |
| 205 | sine function. Let T[i] denote the i-th element of the table, which | |
| 206 | is equal to the integer part of 4294967296 times abs(sin(i)), where i | |
| 207 | is in radians. The elements of the table are given in the appendix. | |
| 208 | ||
| 209 | Do the following: | |
| 210 | ||
| 211 | /* Process each 16-word block. */ | |
| 212 | For i = 0 to N/16-1 do | |
| 213 | ||
| 214 | /* Copy block i into X. */ | |
| 215 | For j = 0 to 15 do | |
| 216 | Set X[j] to M[i*16+j]. | |
| 217 | end /* of loop on j */ | |
| 218 | ||
| 219 | /* Save A as AA, B as BB, C as CC, and D as DD. */ | |
| 220 | AA = A | |
| 221 | BB = B | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Rivest [Page 4] | |
| 226 | ||
| 227 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 228 | ||
| 229 | ||
| 230 | CC = C | |
| 231 | DD = D | |
| 232 | ||
| 233 | /* Round 1. */ | |
| 234 | /* Let [abcd k s i] denote the operation | |
| 235 | a = b + ((a + F(b,c,d) + X[k] + T[i]) <<< s). */ | |
| 236 | /* Do the following 16 operations. */ | |
| 237 | [ABCD 0 7 1] [DABC 1 12 2] [CDAB 2 17 3] [BCDA 3 22 4] | |
| 238 | [ABCD 4 7 5] [DABC 5 12 6] [CDAB 6 17 7] [BCDA 7 22 8] | |
| 239 | [ABCD 8 7 9] [DABC 9 12 10] [CDAB 10 17 11] [BCDA 11 22 12] | |
| 240 | [ABCD 12 7 13] [DABC 13 12 14] [CDAB 14 17 15] [BCDA 15 22 16] | |
| 241 | ||
| 242 | /* Round 2. */ | |
| 243 | /* Let [abcd k s i] denote the operation | |
| 244 | a = b + ((a + G(b,c,d) + X[k] + T[i]) <<< s). */ | |
| 245 | /* Do the following 16 operations. */ | |
| 246 | [ABCD 1 5 17] [DABC 6 9 18] [CDAB 11 14 19] [BCDA 0 20 20] | |
| 247 | [ABCD 5 5 21] [DABC 10 9 22] [CDAB 15 14 23] [BCDA 4 20 24] | |
| 248 | [ABCD 9 5 25] [DABC 14 9 26] [CDAB 3 14 27] [BCDA 8 20 28] | |
| 249 | [ABCD 13 5 29] [DABC 2 9 30] [CDAB 7 14 31] [BCDA 12 20 32] | |
| 250 | ||
| 251 | /* Round 3. */ | |
| 252 | /* Let [abcd k s t] denote the operation | |
| 253 | a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */ | |
| 254 | /* Do the following 16 operations. */ | |
| 255 | [ABCD 5 4 33] [DABC 8 11 34] [CDAB 11 16 35] [BCDA 14 23 36] | |
| 256 | [ABCD 1 4 37] [DABC 4 11 38] [CDAB 7 16 39] [BCDA 10 23 40] | |
| 257 | [ABCD 13 4 41] [DABC 0 11 42] [CDAB 3 16 43] [BCDA 6 23 44] | |
| 258 | [ABCD 9 4 45] [DABC 12 11 46] [CDAB 15 16 47] [BCDA 2 23 48] | |
| 259 | ||
| 260 | /* Round 4. */ | |
| 261 | /* Let [abcd k s t] denote the operation | |
| 262 | a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */ | |
| 263 | /* Do the following 16 operations. */ | |
| 264 | [ABCD 0 6 49] [DABC 7 10 50] [CDAB 14 15 51] [BCDA 5 21 52] | |
| 265 | [ABCD 12 6 53] [DABC 3 10 54] [CDAB 10 15 55] [BCDA 1 21 56] | |
| 266 | [ABCD 8 6 57] [DABC 15 10 58] [CDAB 6 15 59] [BCDA 13 21 60] | |
| 267 | [ABCD 4 6 61] [DABC 11 10 62] [CDAB 2 15 63] [BCDA 9 21 64] | |
| 268 | ||
| 269 | /* Then perform the following additions. (That is increment each | |
| 270 | of the four registers by the value it had before this block | |
| 271 | was started.) */ | |
| 272 | A = A + AA | |
| 273 | B = B + BB | |
| 274 | C = C + CC | |
| 275 | D = D + DD | |
| 276 | ||
| 277 | end /* of loop on i */ | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Rivest [Page 5] | |
| 282 | ||
| 283 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 284 | ||
| 285 | ||
| 286 | 3.5 Step 5. Output | |
| 287 | ||
| 288 | The message digest produced as output is A, B, C, D. That is, we | |
| 289 | begin with the low-order byte of A, and end with the high-order byte | |
| 290 | of D. | |
| 291 | ||
| 292 | This completes the description of MD5. A reference implementation in | |
| 293 | C is given in the appendix. | |
| 294 | ||
| 295 | 4. Summary | |
| 296 | ||
| 297 | The MD5 message-digest algorithm is simple to implement, and provides | |
| 298 | a "fingerprint" or message digest of a message of arbitrary length. | |
| 299 | It is conjectured that the difficulty of coming up with two messages | |
| 300 | having the same message digest is on the order of 2^64 operations, | |
| 301 | and that the difficulty of coming up with any message having a given | |
| 302 | message digest is on the order of 2^128 operations. The MD5 algorithm | |
| 303 | has been carefully scrutinized for weaknesses. It is, however, a | |
| 304 | relatively new algorithm and further security analysis is of course | |
| 305 | justified, as is the case with any new proposal of this sort. | |
| 306 | ||
| 307 | 5. Differences Between MD4 and MD5 | |
| 308 | ||
| 309 | The following are the differences between MD4 and MD5: | |
| 310 | ||
| 311 | 1. A fourth round has been added. | |
| 312 | ||
| 313 | 2. Each step now has a unique additive constant. | |
| 314 | ||
| 315 | 3. The function g in round 2 was changed from (XY v XZ v YZ) to | |
| 316 | (XZ v Y not(Z)) to make g less symmetric. | |
| 317 | ||
| 318 | 4. Each step now adds in the result of the previous step. This | |
| 319 | promotes a faster "avalanche effect". | |
| 320 | ||
| 321 | 5. The order in which input words are accessed in rounds 2 and | |
| 322 | 3 is changed, to make these patterns less like each other. | |
| 323 | ||
| 324 | 6. The shift amounts in each round have been approximately | |
| 325 | optimized, to yield a faster "avalanche effect." The shifts in | |
| 326 | different rounds are distinct. | |
| 327 | ||
| 328 | ||
| 329 | ||
| 330 | ||
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Rivest [Page 6] | |
| 338 | ||
| 339 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 340 | ||
| 341 | ||
| 342 | References | |
| 343 | ||
| 344 | [1] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT and | |
| 345 | RSA Data Security, Inc., April 1992. | |
| 346 | ||
| 347 | [2] Rivest, R., "The MD4 message digest algorithm", in A.J. Menezes | |
| 348 | and S.A. Vanstone, editors, Advances in Cryptology - CRYPTO '90 | |
| 349 | Proceedings, pages 303-311, Springer-Verlag, 1991. | |
| 350 | ||
| 351 | [3] CCITT Recommendation X.509 (1988), "The Directory - | |
| 352 | Authentication Framework." | |
| 353 | ||
| 354 | APPENDIX A - Reference Implementation | |
| 355 | ||
| 356 | This appendix contains the following files taken from RSAREF: A | |
| 357 | Cryptographic Toolkit for Privacy-Enhanced Mail: | |
| 358 | ||
| 359 | global.h -- global header file | |
| 360 | ||
| 361 | md5.h -- header file for MD5 | |
| 362 | ||
| 363 | md5c.c -- source code for MD5 | |
| 364 | ||
| 365 | For more information on RSAREF, send email to <rsaref@rsa.com>. | |
| 366 | ||
| 367 | The appendix also includes the following file: | |
| 368 | ||
| 369 | mddriver.c -- test driver for MD2, MD4 and MD5 | |
| 370 | ||
| 371 | The driver compiles for MD5 by default but can compile for MD2 or MD4 | |
| 372 | if the symbol MD is defined on the C compiler command line as 2 or 4. | |
| 373 | ||
| 374 | The implementation is portable and should work on many different | |
| 375 | plaforms. However, it is not difficult to optimize the implementation | |
| 376 | on particular platforms, an exercise left to the reader. For example, | |
| 377 | on "little-endian" platforms where the lowest-addressed byte in a 32- | |
| 378 | bit word is the least significant and there are no alignment | |
| 379 | restrictions, the call to Decode in MD5Transform can be replaced with | |
| 380 | a typecast. | |
| 381 | ||
| 382 | A.1 global.h | |
| 383 | ||
| 384 | /* GLOBAL.H - RSAREF types and constants | |
| 385 | */ | |
| 386 | ||
| 387 | /* PROTOTYPES should be set to one if and only if the compiler supports | |
| 388 | function argument prototyping. | |
| 389 | The following makes PROTOTYPES default to 0 if it has not already | |
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Rivest [Page 7] | |
| 394 | ||
| 395 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 396 | ||
| 397 | ||
| 398 | been defined with C compiler flags. | |
| 399 | */ | |
| 400 | #ifndef PROTOTYPES | |
| 401 | #define PROTOTYPES 0 | |
| 402 | #endif | |
| 403 | ||
| 404 | /* POINTER defines a generic pointer type */ | |
| 405 | typedef unsigned char *POINTER; | |
| 406 | ||
| 407 | /* UINT2 defines a two byte word */ | |
| 408 | typedef unsigned short int UINT2; | |
| 409 | ||
| 410 | /* UINT4 defines a four byte word */ | |
| 411 | typedef unsigned long int UINT4; | |
| 412 | ||
| 413 | /* PROTO_LIST is defined depending on how PROTOTYPES is defined above. | |
| 414 | If using PROTOTYPES, then PROTO_LIST returns the list, otherwise it | |
| 415 | returns an empty list. | |
| 416 | */ | |
| 417 | #if PROTOTYPES | |
| 418 | #define PROTO_LIST(list) list | |
| 419 | #else | |
| 420 | #define PROTO_LIST(list) () | |
| 421 | #endif | |
| 422 | ||
| 423 | A.2 md5.h | |
| 424 | ||
| 425 | /* MD5.H - header file for MD5C.C | |
| 426 | */ | |
| 427 | ||
| 428 | /* Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All | |
| 429 | rights reserved. | |
| 430 | ||
| 431 | License to copy and use this software is granted provided that it | |
| 432 | is identified as the "RSA Data Security, Inc. MD5 Message-Digest | |
| 433 | Algorithm" in all material mentioning or referencing this software | |
| 434 | or this function. | |
| 435 | ||
| 436 | License is also granted to make and use derivative works provided | |
| 437 | that such works are identified as "derived from the RSA Data | |
| 438 | Security, Inc. MD5 Message-Digest Algorithm" in all material | |
| 439 | mentioning or referencing the derived work. | |
| 440 | ||
| 441 | RSA Data Security, Inc. makes no representations concerning either | |
| 442 | the merchantability of this software or the suitability of this | |
| 443 | software for any particular purpose. It is provided "as is" | |
| 444 | without express or implied warranty of any kind. | |
| 445 | ||
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Rivest [Page 8] | |
| 450 | ||
| 451 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 452 | ||
| 453 | ||
| 454 | These notices must be retained in any copies of any part of this | |
| 455 | documentation and/or software. | |
| 456 | */ | |
| 457 | ||
| 458 | /* MD5 context. */ | |
| 459 | typedef struct { | |
| 460 | UINT4 state[4]; /* state (ABCD) */ | |
| 461 | UINT4 count[2]; /* number of bits, modulo 2^64 (lsb first) */ | |
| 462 | unsigned char buffer[64]; /* input buffer */ | |
| 463 | } MD5_CTX; | |
| 464 | ||
| 465 | void MD5Init PROTO_LIST ((MD5_CTX *)); | |
| 466 | void MD5Update PROTO_LIST | |
| 467 | ((MD5_CTX *, unsigned char *, unsigned int)); | |
| 468 | void MD5Final PROTO_LIST ((unsigned char [16], MD5_CTX *)); | |
| 469 | ||
| 470 | A.3 md5c.c | |
| 471 | ||
| 472 | /* MD5C.C - RSA Data Security, Inc., MD5 message-digest algorithm | |
| 473 | */ | |
| 474 | ||
| 475 | /* Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All | |
| 476 | rights reserved. | |
| 477 | ||
| 478 | License to copy and use this software is granted provided that it | |
| 479 | is identified as the "RSA Data Security, Inc. MD5 Message-Digest | |
| 480 | Algorithm" in all material mentioning or referencing this software | |
| 481 | or this function. | |
| 482 | ||
| 483 | License is also granted to make and use derivative works provided | |
| 484 | that such works are identified as "derived from the RSA Data | |
| 485 | Security, Inc. MD5 Message-Digest Algorithm" in all material | |
| 486 | mentioning or referencing the derived work. | |
| 487 | ||
| 488 | RSA Data Security, Inc. makes no representations concerning either | |
| 489 | the merchantability of this software or the suitability of this | |
| 490 | software for any particular purpose. It is provided "as is" | |
| 491 | without express or implied warranty of any kind. | |
| 492 | ||
| 493 | These notices must be retained in any copies of any part of this | |
| 494 | documentation and/or software. | |
| 495 | */ | |
| 496 | ||
| 497 | #include "global.h" | |
| 498 | #include "md5.h" | |
| 499 | ||
| 500 | /* Constants for MD5Transform routine. | |
| 501 | */ | |
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Rivest [Page 9] | |
| 506 | ||
| 507 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 508 | ||
| 509 | ||
| 510 | #define S11 7 | |
| 511 | #define S12 12 | |
| 512 | #define S13 17 | |
| 513 | #define S14 22 | |
| 514 | #define S21 5 | |
| 515 | #define S22 9 | |
| 516 | #define S23 14 | |
| 517 | #define S24 20 | |
| 518 | #define S31 4 | |
| 519 | #define S32 11 | |
| 520 | #define S33 16 | |
| 521 | #define S34 23 | |
| 522 | #define S41 6 | |
| 523 | #define S42 10 | |
| 524 | #define S43 15 | |
| 525 | #define S44 21 | |
| 526 | ||
| 527 | static void MD5Transform PROTO_LIST ((UINT4 [4], unsigned char [64])); | |
| 528 | static void Encode PROTO_LIST | |
| 529 | ((unsigned char *, UINT4 *, unsigned int)); | |
| 530 | static void Decode PROTO_LIST | |
| 531 | ((UINT4 *, unsigned char *, unsigned int)); | |
| 532 | static void MD5_memcpy PROTO_LIST ((POINTER, POINTER, unsigned int)); | |
| 533 | static void MD5_memset PROTO_LIST ((POINTER, int, unsigned int)); | |
| 534 | ||
| 535 | static unsigned char PADDING[64] = { | |
| 536 | 0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, | |
| 537 | 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, | |
| 538 | 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 | |
| 539 | }; | |
| 540 | ||
| 541 | /* F, G, H and I are basic MD5 functions. | |
| 542 | */ | |
| 543 | #define F(x, y, z) (((x) & (y)) | ((~x) & (z))) | |
| 544 | #define G(x, y, z) (((x) & (z)) | ((y) & (~z))) | |
| 545 | #define H(x, y, z) ((x) ^ (y) ^ (z)) | |
| 546 | #define I(x, y, z) ((y) ^ ((x) | (~z))) | |
| 547 | ||
| 548 | /* ROTATE_LEFT rotates x left n bits. | |
| 549 | */ | |
| 550 | #define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32-(n)))) | |
| 551 | ||
| 552 | /* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4. | |
| 553 | Rotation is separate from addition to prevent recomputation. | |
| 554 | */ | |
| 555 | #define FF(a, b, c, d, x, s, ac) { \ | |
| 556 | (a) += F ((b), (c), (d)) + (x) + (UINT4)(ac); \ | |
| 557 | (a) = ROTATE_LEFT ((a), (s)); \ | |
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Rivest [Page 10] | |
| 562 | ||
| 563 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 564 | ||
| 565 | ||
| 566 | (a) += (b); \ | |
| 567 | } | |
| 568 | #define GG(a, b, c, d, x, s, ac) { \ | |
| 569 | (a) += G ((b), (c), (d)) + (x) + (UINT4)(ac); \ | |
| 570 | (a) = ROTATE_LEFT ((a), (s)); \ | |
| 571 | (a) += (b); \ | |
| 572 | } | |
| 573 | #define HH(a, b, c, d, x, s, ac) { \ | |
| 574 | (a) += H ((b), (c), (d)) + (x) + (UINT4)(ac); \ | |
| 575 | (a) = ROTATE_LEFT ((a), (s)); \ | |
| 576 | (a) += (b); \ | |
| 577 | } | |
| 578 | #define II(a, b, c, d, x, s, ac) { \ | |
| 579 | (a) += I ((b), (c), (d)) + (x) + (UINT4)(ac); \ | |
| 580 | (a) = ROTATE_LEFT ((a), (s)); \ | |
| 581 | (a) += (b); \ | |
| 582 | } | |
| 583 | ||
| 584 | /* MD5 initialization. Begins an MD5 operation, writing a new context. | |
| 585 | */ | |
| 586 | void MD5Init (context) | |
| 587 | MD5_CTX *context; /* context */ | |
| 588 | { | |
| 589 | context->count[0] = context->count[1] = 0; | |
| 590 | /* Load magic initialization constants. | |
| 591 | */ | |
| 592 | context->state[0] = 0x67452301; | |
| 593 | context->state[1] = 0xefcdab89; | |
| 594 | context->state[2] = 0x98badcfe; | |
| 595 | context->state[3] = 0x10325476; | |
| 596 | } | |
| 597 | ||
| 598 | /* MD5 block update operation. Continues an MD5 message-digest | |
| 599 | operation, processing another message block, and updating the | |
| 600 | context. | |
| 601 | */ | |
| 602 | void MD5Update (context, input, inputLen) | |
| 603 | MD5_CTX *context; /* context */ | |
| 604 | unsigned char *input; /* input block */ | |
| 605 | unsigned int inputLen; /* length of input block */ | |
| 606 | { | |
| 607 | unsigned int i, index, partLen; | |
| 608 | ||
| 609 | /* Compute number of bytes mod 64 */ | |
| 610 | index = (unsigned int)((context->count[0] >> 3) & 0x3F); | |
| 611 | ||
| 612 | /* Update number of bits */ | |
| 613 | if ((context->count[0] += ((UINT4)inputLen << 3)) | |
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | Rivest [Page 11] | |
| 618 | ||
| 619 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 620 | ||
| 621 | ||
| 622 | < ((UINT4)inputLen << 3)) | |
| 623 | context->count[1]++; | |
| 624 | context->count[1] += ((UINT4)inputLen >> 29); | |
| 625 | ||
| 626 | partLen = 64 - index; | |
| 627 | ||
| 628 | /* Transform as many times as possible. | |
| 629 | */ | |
| 630 | if (inputLen >= partLen) { | |
| 631 | MD5_memcpy | |
| 632 | ((POINTER)&context->buffer[index], (POINTER)input, partLen); | |
| 633 | MD5Transform (context->state, context->buffer); | |
| 634 | ||
| 635 | for (i = partLen; i + 63 < inputLen; i += 64) | |
| 636 | MD5Transform (context->state, &input[i]); | |
| 637 | ||
| 638 | index = 0; | |
| 639 | } | |
| 640 | else | |
| 641 | i = 0; | |
| 642 | ||
| 643 | /* Buffer remaining input */ | |
| 644 | MD5_memcpy | |
| 645 | ((POINTER)&context->buffer[index], (POINTER)&input[i], | |
| 646 | inputLen-i); | |
| 647 | } | |
| 648 | ||
| 649 | /* MD5 finalization. Ends an MD5 message-digest operation, writing the | |
| 650 | the message digest and zeroizing the context. | |
| 651 | */ | |
| 652 | void MD5Final (digest, context) | |
| 653 | unsigned char digest[16]; /* message digest */ | |
| 654 | MD5_CTX *context; /* context */ | |
| 655 | { | |
| 656 | unsigned char bits[8]; | |
| 657 | unsigned int index, padLen; | |
| 658 | ||
| 659 | /* Save number of bits */ | |
| 660 | Encode (bits, context->count, 8); | |
| 661 | ||
| 662 | /* Pad out to 56 mod 64. | |
| 663 | */ | |
| 664 | index = (unsigned int)((context->count[0] >> 3) & 0x3f); | |
| 665 | padLen = (index < 56) ? (56 - index) : (120 - index); | |
| 666 | MD5Update (context, PADDING, padLen); | |
| 667 | ||
| 668 | /* Append length (before padding) */ | |
| 669 | MD5Update (context, bits, 8); | |
| 670 | ||
| 671 | ||
| 672 | ||
| 673 | Rivest [Page 12] | |
| 674 | ||
| 675 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 676 | ||
| 677 | ||
| 678 | /* Store state in digest */ | |
| 679 | Encode (digest, context->state, 16); | |
| 680 | ||
| 681 | /* Zeroize sensitive information. | |
| 682 | */ | |
| 683 | MD5_memset ((POINTER)context, 0, sizeof (*context)); | |
| 684 | } | |
| 685 | ||
| 686 | /* MD5 basic transformation. Transforms state based on block. | |
| 687 | */ | |
| 688 | static void MD5Transform (state, block) | |
| 689 | UINT4 state[4]; | |
| 690 | unsigned char block[64]; | |
| 691 | { | |
| 692 | UINT4 a = state[0], b = state[1], c = state[2], d = state[3], x[16]; | |
| 693 | ||
| 694 | Decode (x, block, 64); | |
| 695 | ||
| 696 | /* Round 1 */ | |
| 697 | FF (a, b, c, d, x[ 0], S11, 0xd76aa478); /* 1 */ | |
| 698 | FF (d, a, b, c, x[ 1], S12, 0xe8c7b756); /* 2 */ | |
| 699 | FF (c, d, a, b, x[ 2], S13, 0x242070db); /* 3 */ | |
| 700 | FF (b, c, d, a, x[ 3], S14, 0xc1bdceee); /* 4 */ | |
| 701 | FF (a, b, c, d, x[ 4], S11, 0xf57c0faf); /* 5 */ | |
| 702 | FF (d, a, b, c, x[ 5], S12, 0x4787c62a); /* 6 */ | |
| 703 | FF (c, d, a, b, x[ 6], S13, 0xa8304613); /* 7 */ | |
| 704 | FF (b, c, d, a, x[ 7], S14, 0xfd469501); /* 8 */ | |
| 705 | FF (a, b, c, d, x[ 8], S11, 0x698098d8); /* 9 */ | |
| 706 | FF (d, a, b, c, x[ 9], S12, 0x8b44f7af); /* 10 */ | |
| 707 | FF (c, d, a, b, x[10], S13, 0xffff5bb1); /* 11 */ | |
| 708 | FF (b, c, d, a, x[11], S14, 0x895cd7be); /* 12 */ | |
| 709 | FF (a, b, c, d, x[12], S11, 0x6b901122); /* 13 */ | |
| 710 | FF (d, a, b, c, x[13], S12, 0xfd987193); /* 14 */ | |
| 711 | FF (c, d, a, b, x[14], S13, 0xa679438e); /* 15 */ | |
| 712 | FF (b, c, d, a, x[15], S14, 0x49b40821); /* 16 */ | |
| 713 | ||
| 714 | /* Round 2 */ | |
| 715 | GG (a, b, c, d, x[ 1], S21, 0xf61e2562); /* 17 */ | |
| 716 | GG (d, a, b, c, x[ 6], S22, 0xc040b340); /* 18 */ | |
| 717 | GG (c, d, a, b, x[11], S23, 0x265e5a51); /* 19 */ | |
| 718 | GG (b, c, d, a, x[ 0], S24, 0xe9b6c7aa); /* 20 */ | |
| 719 | GG (a, b, c, d, x[ 5], S21, 0xd62f105d); /* 21 */ | |
| 720 | GG (d, a, b, c, x[10], S22, 0x2441453); /* 22 */ | |
| 721 | GG (c, d, a, b, x[15], S23, 0xd8a1e681); /* 23 */ | |
| 722 | GG (b, c, d, a, x[ 4], S24, 0xe7d3fbc8); /* 24 */ | |
| 723 | GG (a, b, c, d, x[ 9], S21, 0x21e1cde6); /* 25 */ | |
| 724 | GG (d, a, b, c, x[14], S22, 0xc33707d6); /* 26 */ | |
| 725 | GG (c, d, a, b, x[ 3], S23, 0xf4d50d87); /* 27 */ | |
| 726 | ||
| 727 | ||
| 728 | ||
| 729 | Rivest [Page 13] | |
| 730 | ||
| 731 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 732 | ||
| 733 | ||
| 734 | GG (b, c, d, a, x[ 8], S24, 0x455a14ed); /* 28 */ | |
| 735 | GG (a, b, c, d, x[13], S21, 0xa9e3e905); /* 29 */ | |
| 736 | GG (d, a, b, c, x[ 2], S22, 0xfcefa3f8); /* 30 */ | |
| 737 | GG (c, d, a, b, x[ 7], S23, 0x676f02d9); /* 31 */ | |
| 738 | GG (b, c, d, a, x[12], S24, 0x8d2a4c8a); /* 32 */ | |
| 739 | ||
| 740 | /* Round 3 */ | |
| 741 | HH (a, b, c, d, x[ 5], S31, 0xfffa3942); /* 33 */ | |
| 742 | HH (d, a, b, c, x[ 8], S32, 0x8771f681); /* 34 */ | |
| 743 | HH (c, d, a, b, x[11], S33, 0x6d9d6122); /* 35 */ | |
| 744 | HH (b, c, d, a, x[14], S34, 0xfde5380c); /* 36 */ | |
| 745 | HH (a, b, c, d, x[ 1], S31, 0xa4beea44); /* 37 */ | |
| 746 | HH (d, a, b, c, x[ 4], S32, 0x4bdecfa9); /* 38 */ | |
| 747 | HH (c, d, a, b, x[ 7], S33, 0xf6bb4b60); /* 39 */ | |
| 748 | HH (b, c, d, a, x[10], S34, 0xbebfbc70); /* 40 */ | |
| 749 | HH (a, b, c, d, x[13], S31, 0x289b7ec6); /* 41 */ | |
| 750 | HH (d, a, b, c, x[ 0], S32, 0xeaa127fa); /* 42 */ | |
| 751 | HH (c, d, a, b, x[ 3], S33, 0xd4ef3085); /* 43 */ | |
| 752 | HH (b, c, d, a, x[ 6], S34, 0x4881d05); /* 44 */ | |
| 753 | HH (a, b, c, d, x[ 9], S31, 0xd9d4d039); /* 45 */ | |
| 754 | HH (d, a, b, c, x[12], S32, 0xe6db99e5); /* 46 */ | |
| 755 | HH (c, d, a, b, x[15], S33, 0x1fa27cf8); /* 47 */ | |
| 756 | HH (b, c, d, a, x[ 2], S34, 0xc4ac5665); /* 48 */ | |
| 757 | ||
| 758 | /* Round 4 */ | |
| 759 | II (a, b, c, d, x[ 0], S41, 0xf4292244); /* 49 */ | |
| 760 | II (d, a, b, c, x[ 7], S42, 0x432aff97); /* 50 */ | |
| 761 | II (c, d, a, b, x[14], S43, 0xab9423a7); /* 51 */ | |
| 762 | II (b, c, d, a, x[ 5], S44, 0xfc93a039); /* 52 */ | |
| 763 | II (a, b, c, d, x[12], S41, 0x655b59c3); /* 53 */ | |
| 764 | II (d, a, b, c, x[ 3], S42, 0x8f0ccc92); /* 54 */ | |
| 765 | II (c, d, a, b, x[10], S43, 0xffeff47d); /* 55 */ | |
| 766 | II (b, c, d, a, x[ 1], S44, 0x85845dd1); /* 56 */ | |
| 767 | II (a, b, c, d, x[ 8], S41, 0x6fa87e4f); /* 57 */ | |
| 768 | II (d, a, b, c, x[15], S42, 0xfe2ce6e0); /* 58 */ | |
| 769 | II (c, d, a, b, x[ 6], S43, 0xa3014314); /* 59 */ | |
| 770 | II (b, c, d, a, x[13], S44, 0x4e0811a1); /* 60 */ | |
| 771 | II (a, b, c, d, x[ 4], S41, 0xf7537e82); /* 61 */ | |
| 772 | II (d, a, b, c, x[11], S42, 0xbd3af235); /* 62 */ | |
| 773 | II (c, d, a, b, x[ 2], S43, 0x2ad7d2bb); /* 63 */ | |
| 774 | II (b, c, d, a, x[ 9], S44, 0xeb86d391); /* 64 */ | |
| 775 | ||
| 776 | state[0] += a; | |
| 777 | state[1] += b; | |
| 778 | state[2] += c; | |
| 779 | state[3] += d; | |
| 780 | ||
| 781 | /* Zeroize sensitive information. | |
| 782 | ||
| 783 | ||
| 784 | ||
| 785 | Rivest [Page 14] | |
| 786 | ||
| 787 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 788 | ||
| 789 | ||
| 790 | */ | |
| 791 | MD5_memset ((POINTER)x, 0, sizeof (x)); | |
| 792 | } | |
| 793 | ||
| 794 | /* Encodes input (UINT4) into output (unsigned char). Assumes len is | |
| 795 | a multiple of 4. | |
| 796 | */ | |
| 797 | static void Encode (output, input, len) | |
| 798 | unsigned char *output; | |
| 799 | UINT4 *input; | |
| 800 | unsigned int len; | |
| 801 | { | |
| 802 | unsigned int i, j; | |
| 803 | ||
| 804 | for (i = 0, j = 0; j < len; i++, j += 4) { | |
| 805 | output[j] = (unsigned char)(input[i] & 0xff); | |
| 806 | output[j+1] = (unsigned char)((input[i] >> 8) & 0xff); | |
| 807 | output[j+2] = (unsigned char)((input[i] >> 16) & 0xff); | |
| 808 | output[j+3] = (unsigned char)((input[i] >> 24) & 0xff); | |
| 809 | } | |
| 810 | } | |
| 811 | ||
| 812 | /* Decodes input (unsigned char) into output (UINT4). Assumes len is | |
| 813 | a multiple of 4. | |
| 814 | */ | |
| 815 | static void Decode (output, input, len) | |
| 816 | UINT4 *output; | |
| 817 | unsigned char *input; | |
| 818 | unsigned int len; | |
| 819 | { | |
| 820 | unsigned int i, j; | |
| 821 | ||
| 822 | for (i = 0, j = 0; j < len; i++, j += 4) | |
| 823 | output[i] = ((UINT4)input[j]) | (((UINT4)input[j+1]) << 8) | | |
| 824 | (((UINT4)input[j+2]) << 16) | (((UINT4)input[j+3]) << 24); | |
| 825 | } | |
| 826 | ||
| 827 | /* Note: Replace "for loop" with standard memcpy if possible. | |
| 828 | */ | |
| 829 | ||
| 830 | static void MD5_memcpy (output, input, len) | |
| 831 | POINTER output; | |
| 832 | POINTER input; | |
| 833 | unsigned int len; | |
| 834 | { | |
| 835 | unsigned int i; | |
| 836 | ||
| 837 | for (i = 0; i < len; i++) | |
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | Rivest [Page 15] | |
| 842 | ||
| 843 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 844 | ||
| 845 | ||
| 846 | output[i] = input[i]; | |
| 847 | } | |
| 848 | ||
| 849 | /* Note: Replace "for loop" with standard memset if possible. | |
| 850 | */ | |
| 851 | static void MD5_memset (output, value, len) | |
| 852 | POINTER output; | |
| 853 | int value; | |
| 854 | unsigned int len; | |
| 855 | { | |
| 856 | unsigned int i; | |
| 857 | ||
| 858 | for (i = 0; i < len; i++) | |
| 859 | ((char *)output)[i] = (char)value; | |
| 860 | } | |
| 861 | ||
| 862 | A.4 mddriver.c | |
| 863 | ||
| 864 | /* MDDRIVER.C - test driver for MD2, MD4 and MD5 | |
| 865 | */ | |
| 866 | ||
| 867 | /* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All | |
| 868 | rights reserved. | |
| 869 | ||
| 870 | RSA Data Security, Inc. makes no representations concerning either | |
| 871 | the merchantability of this software or the suitability of this | |
| 872 | software for any particular purpose. It is provided "as is" | |
| 873 | without express or implied warranty of any kind. | |
| 874 | ||
| 875 | These notices must be retained in any copies of any part of this | |
| 876 | documentation and/or software. | |
| 877 | */ | |
| 878 | ||
| 879 | /* The following makes MD default to MD5 if it has not already been | |
| 880 | defined with C compiler flags. | |
| 881 | */ | |
| 882 | #ifndef MD | |
| 883 | #define MD MD5 | |
| 884 | #endif | |
| 885 | ||
| 886 | #include <stdio.h> | |
| 887 | #include <time.h> | |
| 888 | #include <string.h> | |
| 889 | #include "global.h" | |
| 890 | #if MD == 2 | |
| 891 | #include "md2.h" | |
| 892 | #endif | |
| 893 | #if MD == 4 | |
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | Rivest [Page 16] | |
| 898 | ||
| 899 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 900 | ||
| 901 | ||
| 902 | #include "md4.h" | |
| 903 | #endif | |
| 904 | #if MD == 5 | |
| 905 | #include "md5.h" | |
| 906 | #endif | |
| 907 | ||
| 908 | /* Length of test block, number of test blocks. | |
| 909 | */ | |
| 910 | #define TEST_BLOCK_LEN 1000 | |
| 911 | #define TEST_BLOCK_COUNT 1000 | |
| 912 | ||
| 913 | static void MDString PROTO_LIST ((char *)); | |
| 914 | static void MDTimeTrial PROTO_LIST ((void)); | |
| 915 | static void MDTestSuite PROTO_LIST ((void)); | |
| 916 | static void MDFile PROTO_LIST ((char *)); | |
| 917 | static void MDFilter PROTO_LIST ((void)); | |
| 918 | static void MDPrint PROTO_LIST ((unsigned char [16])); | |
| 919 | ||
| 920 | #if MD == 2 | |
| 921 | #define MD_CTX MD2_CTX | |
| 922 | #define MDInit MD2Init | |
| 923 | #define MDUpdate MD2Update | |
| 924 | #define MDFinal MD2Final | |
| 925 | #endif | |
| 926 | #if MD == 4 | |
| 927 | #define MD_CTX MD4_CTX | |
| 928 | #define MDInit MD4Init | |
| 929 | #define MDUpdate MD4Update | |
| 930 | #define MDFinal MD4Final | |
| 931 | #endif | |
| 932 | #if MD == 5 | |
| 933 | #define MD_CTX MD5_CTX | |
| 934 | #define MDInit MD5Init | |
| 935 | #define MDUpdate MD5Update | |
| 936 | #define MDFinal MD5Final | |
| 937 | #endif | |
| 938 | ||
| 939 | /* Main driver. | |
| 940 | ||
| 941 | Arguments (may be any combination): | |
| 942 | -sstring - digests string | |
| 943 | -t - runs time trial | |
| 944 | -x - runs test script | |
| 945 | filename - digests file | |
| 946 | (none) - digests standard input | |
| 947 | */ | |
| 948 | int main (argc, argv) | |
| 949 | int argc; | |
| 950 | ||
| 951 | ||
| 952 | ||
| 953 | Rivest [Page 17] | |
| 954 | ||
| 955 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 956 | ||
| 957 | ||
| 958 | char *argv[]; | |
| 959 | { | |
| 960 | int i; | |
| 961 | ||
| 962 | if (argc > 1) | |
| 963 | for (i = 1; i < argc; i++) | |
| 964 | if (argv[i][0] == '-' && argv[i][1] == 's') | |
| 965 | MDString (argv[i] + 2); | |
| 966 | else if (strcmp (argv[i], "-t") == 0) | |
| 967 | MDTimeTrial (); | |
| 968 | else if (strcmp (argv[i], "-x") == 0) | |
| 969 | MDTestSuite (); | |
| 970 | else | |
| 971 | MDFile (argv[i]); | |
| 972 | else | |
| 973 | MDFilter (); | |
| 974 | ||
| 975 | return (0); | |
| 976 | } | |
| 977 | ||
| 978 | /* Digests a string and prints the result. | |
| 979 | */ | |
| 980 | static void MDString (string) | |
| 981 | char *string; | |
| 982 | { | |
| 983 | MD_CTX context; | |
| 984 | unsigned char digest[16]; | |
| 985 | unsigned int len = strlen (string); | |
| 986 | ||
| 987 | MDInit (&context); | |
| 988 | MDUpdate (&context, string, len); | |
| 989 | MDFinal (digest, &context); | |
| 990 | ||
| 991 | printf ("MD%d (\"%s\") = ", MD, string); | |
| 992 | MDPrint (digest); | |
| 993 | printf ("\n"); | |
| 994 | } | |
| 995 | ||
| 996 | /* Measures the time to digest TEST_BLOCK_COUNT TEST_BLOCK_LEN-byte | |
| 997 | blocks. | |
| 998 | */ | |
| 999 | static void MDTimeTrial () | |
| 1000 | { | |
| 1001 | MD_CTX context; | |
| 1002 | time_t endTime, startTime; | |
| 1003 | unsigned char block[TEST_BLOCK_LEN], digest[16]; | |
| 1004 | unsigned int i; | |
| 1005 | ||
| 1006 | ||
| 1007 | ||
| 1008 | ||
| 1009 | Rivest [Page 18] | |
| 1010 | ||
| 1011 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 1012 | ||
| 1013 | ||
| 1014 | printf | |
| 1015 | ("MD%d time trial. Digesting %d %d-byte blocks ...", MD, | |
| 1016 | TEST_BLOCK_LEN, TEST_BLOCK_COUNT); | |
| 1017 | ||
| 1018 | /* Initialize block */ | |
| 1019 | for (i = 0; i < TEST_BLOCK_LEN; i++) | |
| 1020 | block[i] = (unsigned char)(i & 0xff); | |
| 1021 | ||
| 1022 | /* Start timer */ | |
| 1023 | time (&startTime); | |
| 1024 | ||
| 1025 | /* Digest blocks */ | |
| 1026 | MDInit (&context); | |
| 1027 | for (i = 0; i < TEST_BLOCK_COUNT; i++) | |
| 1028 | MDUpdate (&context, block, TEST_BLOCK_LEN); | |
| 1029 | MDFinal (digest, &context); | |
| 1030 | ||
| 1031 | /* Stop timer */ | |
| 1032 | time (&endTime); | |
| 1033 | ||
| 1034 | printf (" done\n"); | |
| 1035 | printf ("Digest = "); | |
| 1036 | MDPrint (digest); | |
| 1037 | printf ("\nTime = %ld seconds\n", (long)(endTime-startTime)); | |
| 1038 | printf | |
| 1039 | ("Speed = %ld bytes/second\n", | |
| 1040 | (long)TEST_BLOCK_LEN * (long)TEST_BLOCK_COUNT/(endTime-startTime)); | |
| 1041 | } | |
| 1042 | ||
| 1043 | /* Digests a reference suite of strings and prints the results. | |
| 1044 | */ | |
| 1045 | static void MDTestSuite () | |
| 1046 | { | |
| 1047 | printf ("MD%d test suite:\n", MD); | |
| 1048 | ||
| 1049 | MDString (""); | |
| 1050 | MDString ("a"); | |
| 1051 | MDString ("abc"); | |
| 1052 | MDString ("message digest"); | |
| 1053 | MDString ("abcdefghijklmnopqrstuvwxyz"); | |
| 1054 | MDString | |
| 1055 | ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"); | |
| 1056 | MDString | |
| 1057 | ("1234567890123456789012345678901234567890\ | |
| 1058 | 1234567890123456789012345678901234567890"); | |
| 1059 | } | |
| 1060 | ||
| 1061 | /* Digests a file and prints the result. | |
| 1062 | ||
| 1063 | ||
| 1064 | ||
| 1065 | Rivest [Page 19] | |
| 1066 | ||
| 1067 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 1068 | ||
| 1069 | ||
| 1070 | */ | |
| 1071 | static void MDFile (filename) | |
| 1072 | char *filename; | |
| 1073 | { | |
| 1074 | FILE *file; | |
| 1075 | MD_CTX context; | |
| 1076 | int len; | |
| 1077 | unsigned char buffer[1024], digest[16]; | |
| 1078 | ||
| 1079 | if ((file = fopen (filename, "rb")) == NULL) | |
| 1080 | printf ("%s can't be opened\n", filename); | |
| 1081 | ||
| 1082 | else { | |
| 1083 | MDInit (&context); | |
| 1084 | while (len = fread (buffer, 1, 1024, file)) | |
| 1085 | MDUpdate (&context, buffer, len); | |
| 1086 | MDFinal (digest, &context); | |
| 1087 | ||
| 1088 | fclose (file); | |
| 1089 | ||
| 1090 | printf ("MD%d (%s) = ", MD, filename); | |
| 1091 | MDPrint (digest); | |
| 1092 | printf ("\n"); | |
| 1093 | } | |
| 1094 | } | |
| 1095 | ||
| 1096 | /* Digests the standard input and prints the result. | |
| 1097 | */ | |
| 1098 | static void MDFilter () | |
| 1099 | { | |
| 1100 | MD_CTX context; | |
| 1101 | int len; | |
| 1102 | unsigned char buffer[16], digest[16]; | |
| 1103 | ||
| 1104 | MDInit (&context); | |
| 1105 | while (len = fread (buffer, 1, 16, stdin)) | |
| 1106 | MDUpdate (&context, buffer, len); | |
| 1107 | MDFinal (digest, &context); | |
| 1108 | ||
| 1109 | MDPrint (digest); | |
| 1110 | printf ("\n"); | |
| 1111 | } | |
| 1112 | ||
| 1113 | /* Prints a message digest in hexadecimal. | |
| 1114 | */ | |
| 1115 | static void MDPrint (digest) | |
| 1116 | unsigned char digest[16]; | |
| 1117 | { | |
| 1118 | ||
| 1119 | ||
| 1120 | ||
| 1121 | Rivest [Page 20] | |
| 1122 | ||
| 1123 | RFC 1321 MD5 Message-Digest Algorithm April 1992 | |
| 1124 | ||
| 1125 | ||
| 1126 | unsigned int i; | |
| 1127 | ||
| 1128 | for (i = 0; i < 16; i++) | |
| 1129 | printf ("%02x", digest[i]); | |
| 1130 | } | |
| 1131 | ||
| 1132 | A.5 Test suite | |
| 1133 | ||
| 1134 | The MD5 test suite (driver option "-x") should print the following | |
| 1135 | results: | |
| 1136 | ||
| 1137 | MD5 test suite: | |
| 1138 | MD5 ("") = d41d8cd98f00b204e9800998ecf8427e | |
| 1139 | MD5 ("a") = 0cc175b9c0f1b6a831c399e269772661 | |
| 1140 | MD5 ("abc") = 900150983cd24fb0d6963f7d28e17f72 | |
| 1141 | MD5 ("message digest") = f96b697d7cb7938d525a2f31aaf161d0 | |
| 1142 | MD5 ("abcdefghijklmnopqrstuvwxyz") = c3fcd3d76192e4007dfb496cca67e13b | |
| 1143 | MD5 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") = | |
| 1144 | d174ab98d277d9f5a5611c2c9f419d9f | |
| 1145 | MD5 ("123456789012345678901234567890123456789012345678901234567890123456 | |
| 1146 | 78901234567890") = 57edf4a22be3c955ac49da2e2107b67a | |
| 1147 | ||
| 1148 | Security Considerations | |
| 1149 | ||
| 1150 | The level of security discussed in this memo is considered to be | |
| 1151 | sufficient for implementing very high security hybrid digital- | |
| 1152 | signature schemes based on MD5 and a public-key cryptosystem. | |
| 1153 | ||
| 1154 | Author's Address | |
| 1155 | ||
| 1156 | Ronald L. Rivest | |
| 1157 | Massachusetts Institute of Technology | |
| 1158 | Laboratory for Computer Science | |
| 1159 | NE43-324 | |
| 1160 | 545 Technology Square | |
| 1161 | Cambridge, MA 02139-1986 | |
| 1162 | ||
| 1163 | Phone: (617) 253-5880 | |
| 1164 | EMail: rivest@theory.lcs.mit.edu | |
| 1165 | ||
| 1166 | ||
| 1167 | ||
| 1168 | ||
| 1169 | ||
| 1170 | ||
| 1171 | ||
| 1172 | ||
| 1173 | ||
| 1174 | ||
| 1175 | ||
| 1176 | ||
| 1177 | Rivest [Page 21] | |
| 1178 | ⏎ |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group J. Myers | |
| 7 | Request for Comments: 1939 Carnegie Mellon | |
| 8 | STD: 53 M. Rose | |
| 9 | Obsoletes: 1725 Dover Beach Consulting, Inc. | |
| 10 | Category: Standards Track May 1996 | |
| 11 | ||
| 12 | ||
| 13 | Post Office Protocol - Version 3 | |
| 14 | ||
| 15 | Status of this Memo | |
| 16 | ||
| 17 | This document specifies an Internet standards track protocol for the | |
| 18 | Internet community, and requests discussion and suggestions for | |
| 19 | improvements. Please refer to the current edition of the "Internet | |
| 20 | Official Protocol Standards" (STD 1) for the standardization state | |
| 21 | and status of this protocol. Distribution of this memo is unlimited. | |
| 22 | ||
| 23 | Table of Contents | |
| 24 | ||
| 25 | 1. Introduction ................................................ 2 | |
| 26 | 2. A Short Digression .......................................... 2 | |
| 27 | 3. Basic Operation ............................................. 3 | |
| 28 | 4. The AUTHORIZATION State ..................................... 4 | |
| 29 | QUIT Command ................................................ 5 | |
| 30 | 5. The TRANSACTION State ....................................... 5 | |
| 31 | STAT Command ................................................ 6 | |
| 32 | LIST Command ................................................ 6 | |
| 33 | RETR Command ................................................ 8 | |
| 34 | DELE Command ................................................ 8 | |
| 35 | NOOP Command ................................................ 9 | |
| 36 | RSET Command ................................................ 9 | |
| 37 | 6. The UPDATE State ............................................ 10 | |
| 38 | QUIT Command ................................................ 10 | |
| 39 | 7. Optional POP3 Commands ...................................... 11 | |
| 40 | TOP Command ................................................. 11 | |
| 41 | UIDL Command ................................................ 12 | |
| 42 | USER Command ................................................ 13 | |
| 43 | PASS Command ................................................ 14 | |
| 44 | APOP Command ................................................ 15 | |
| 45 | 8. Scaling and Operational Considerations ...................... 16 | |
| 46 | 9. POP3 Command Summary ........................................ 18 | |
| 47 | 10. Example POP3 Session ....................................... 19 | |
| 48 | 11. Message Format ............................................. 19 | |
| 49 | 12. References ................................................. 20 | |
| 50 | 13. Security Considerations .................................... 20 | |
| 51 | 14. Acknowledgements ........................................... 20 | |
| 52 | 15. Authors' Addresses ......................................... 21 | |
| 53 | Appendix A. Differences from RFC 1725 .......................... 22 | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Myers & Rose Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 1939 POP3 May 1996 | |
| 60 | ||
| 61 | ||
| 62 | Appendix B. Command Index ...................................... 23 | |
| 63 | ||
| 64 | 1. Introduction | |
| 65 | ||
| 66 | On certain types of smaller nodes in the Internet it is often | |
| 67 | impractical to maintain a message transport system (MTS). For | |
| 68 | example, a workstation may not have sufficient resources (cycles, | |
| 69 | disk space) in order to permit a SMTP server [RFC821] and associated | |
| 70 | local mail delivery system to be kept resident and continuously | |
| 71 | running. Similarly, it may be expensive (or impossible) to keep a | |
| 72 | personal computer interconnected to an IP-style network for long | |
| 73 | amounts of time (the node is lacking the resource known as | |
| 74 | "connectivity"). | |
| 75 | ||
| 76 | Despite this, it is often very useful to be able to manage mail on | |
| 77 | these smaller nodes, and they often support a user agent (UA) to aid | |
| 78 | the tasks of mail handling. To solve this problem, a node which can | |
| 79 | support an MTS entity offers a maildrop service to these less endowed | |
| 80 | nodes. The Post Office Protocol - Version 3 (POP3) is intended to | |
| 81 | permit a workstation to dynamically access a maildrop on a server | |
| 82 | host in a useful fashion. Usually, this means that the POP3 protocol | |
| 83 | is used to allow a workstation to retrieve mail that the server is | |
| 84 | holding for it. | |
| 85 | ||
| 86 | POP3 is not intended to provide extensive manipulation operations of | |
| 87 | mail on the server; normally, mail is downloaded and then deleted. A | |
| 88 | more advanced (and complex) protocol, IMAP4, is discussed in | |
| 89 | [RFC1730]. | |
| 90 | ||
| 91 | For the remainder of this memo, the term "client host" refers to a | |
| 92 | host making use of the POP3 service, while the term "server host" | |
| 93 | refers to a host which offers the POP3 service. | |
| 94 | ||
| 95 | 2. A Short Digression | |
| 96 | ||
| 97 | This memo does not specify how a client host enters mail into the | |
| 98 | transport system, although a method consistent with the philosophy of | |
| 99 | this memo is presented here: | |
| 100 | ||
| 101 | When the user agent on a client host wishes to enter a message | |
| 102 | into the transport system, it establishes an SMTP connection to | |
| 103 | its relay host and sends all mail to it. This relay host could | |
| 104 | be, but need not be, the POP3 server host for the client host. Of | |
| 105 | course, the relay host must accept mail for delivery to arbitrary | |
| 106 | recipient addresses, that functionality is not required of all | |
| 107 | SMTP servers. | |
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Myers & Rose Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 1939 POP3 May 1996 | |
| 116 | ||
| 117 | ||
| 118 | 3. Basic Operation | |
| 119 | ||
| 120 | Initially, the server host starts the POP3 service by listening on | |
| 121 | TCP port 110. When a client host wishes to make use of the service, | |
| 122 | it establishes a TCP connection with the server host. When the | |
| 123 | connection is established, the POP3 server sends a greeting. The | |
| 124 | client and POP3 server then exchange commands and responses | |
| 125 | (respectively) until the connection is closed or aborted. | |
| 126 | ||
| 127 | Commands in the POP3 consist of a case-insensitive keyword, possibly | |
| 128 | followed by one or more arguments. All commands are terminated by a | |
| 129 | CRLF pair. Keywords and arguments consist of printable ASCII | |
| 130 | characters. Keywords and arguments are each separated by a single | |
| 131 | SPACE character. Keywords are three or four characters long. Each | |
| 132 | argument may be up to 40 characters long. | |
| 133 | ||
| 134 | Responses in the POP3 consist of a status indicator and a keyword | |
| 135 | possibly followed by additional information. All responses are | |
| 136 | terminated by a CRLF pair. Responses may be up to 512 characters | |
| 137 | long, including the terminating CRLF. There are currently two status | |
| 138 | indicators: positive ("+OK") and negative ("-ERR"). Servers MUST | |
| 139 | send the "+OK" and "-ERR" in upper case. | |
| 140 | ||
| 141 | Responses to certain commands are multi-line. In these cases, which | |
| 142 | are clearly indicated below, after sending the first line of the | |
| 143 | response and a CRLF, any additional lines are sent, each terminated | |
| 144 | by a CRLF pair. When all lines of the response have been sent, a | |
| 145 | final line is sent, consisting of a termination octet (decimal code | |
| 146 | 046, ".") and a CRLF pair. If any line of the multi-line response | |
| 147 | begins with the termination octet, the line is "byte-stuffed" by | |
| 148 | pre-pending the termination octet to that line of the response. | |
| 149 | Hence a multi-line response is terminated with the five octets | |
| 150 | "CRLF.CRLF". When examining a multi-line response, the client checks | |
| 151 | to see if the line begins with the termination octet. If so and if | |
| 152 | octets other than CRLF follow, the first octet of the line (the | |
| 153 | termination octet) is stripped away. If so and if CRLF immediately | |
| 154 | follows the termination character, then the response from the POP | |
| 155 | server is ended and the line containing ".CRLF" is not considered | |
| 156 | part of the multi-line response. | |
| 157 | ||
| 158 | A POP3 session progresses through a number of states during its | |
| 159 | lifetime. Once the TCP connection has been opened and the POP3 | |
| 160 | server has sent the greeting, the session enters the AUTHORIZATION | |
| 161 | state. In this state, the client must identify itself to the POP3 | |
| 162 | server. Once the client has successfully done this, the server | |
| 163 | acquires resources associated with the client's maildrop, and the | |
| 164 | session enters the TRANSACTION state. In this state, the client | |
| 165 | requests actions on the part of the POP3 server. When the client has | |
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Myers & Rose Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 1939 POP3 May 1996 | |
| 172 | ||
| 173 | ||
| 174 | issued the QUIT command, the session enters the UPDATE state. In | |
| 175 | this state, the POP3 server releases any resources acquired during | |
| 176 | the TRANSACTION state and says goodbye. The TCP connection is then | |
| 177 | closed. | |
| 178 | ||
| 179 | A server MUST respond to an unrecognized, unimplemented, or | |
| 180 | syntactically invalid command by responding with a negative status | |
| 181 | indicator. A server MUST respond to a command issued when the | |
| 182 | session is in an incorrect state by responding with a negative status | |
| 183 | indicator. There is no general method for a client to distinguish | |
| 184 | between a server which does not implement an optional command and a | |
| 185 | server which is unwilling or unable to process the command. | |
| 186 | ||
| 187 | A POP3 server MAY have an inactivity autologout timer. Such a timer | |
| 188 | MUST be of at least 10 minutes' duration. The receipt of any command | |
| 189 | from the client during that interval should suffice to reset the | |
| 190 | autologout timer. When the timer expires, the session does NOT enter | |
| 191 | the UPDATE state--the server should close the TCP connection without | |
| 192 | removing any messages or sending any response to the client. | |
| 193 | ||
| 194 | 4. The AUTHORIZATION State | |
| 195 | ||
| 196 | Once the TCP connection has been opened by a POP3 client, the POP3 | |
| 197 | server issues a one line greeting. This can be any positive | |
| 198 | response. An example might be: | |
| 199 | ||
| 200 | S: +OK POP3 server ready | |
| 201 | ||
| 202 | The POP3 session is now in the AUTHORIZATION state. The client must | |
| 203 | now identify and authenticate itself to the POP3 server. Two | |
| 204 | possible mechanisms for doing this are described in this document, | |
| 205 | the USER and PASS command combination and the APOP command. Both | |
| 206 | mechanisms are described later in this document. Additional | |
| 207 | authentication mechanisms are described in [RFC1734]. While there is | |
| 208 | no single authentication mechanism that is required of all POP3 | |
| 209 | servers, a POP3 server must of course support at least one | |
| 210 | authentication mechanism. | |
| 211 | ||
| 212 | Once the POP3 server has determined through the use of any | |
| 213 | authentication command that the client should be given access to the | |
| 214 | appropriate maildrop, the POP3 server then acquires an exclusive- | |
| 215 | access lock on the maildrop, as necessary to prevent messages from | |
| 216 | being modified or removed before the session enters the UPDATE state. | |
| 217 | If the lock is successfully acquired, the POP3 server responds with a | |
| 218 | positive status indicator. The POP3 session now enters the | |
| 219 | TRANSACTION state, with no messages marked as deleted. If the | |
| 220 | maildrop cannot be opened for some reason (for example, a lock can | |
| 221 | not be acquired, the client is denied access to the appropriate | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Myers & Rose Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 1939 POP3 May 1996 | |
| 228 | ||
| 229 | ||
| 230 | maildrop, or the maildrop cannot be parsed), the POP3 server responds | |
| 231 | with a negative status indicator. (If a lock was acquired but the | |
| 232 | POP3 server intends to respond with a negative status indicator, the | |
| 233 | POP3 server must release the lock prior to rejecting the command.) | |
| 234 | After returning a negative status indicator, the server may close the | |
| 235 | connection. If the server does not close the connection, the client | |
| 236 | may either issue a new authentication command and start again, or the | |
| 237 | client may issue the QUIT command. | |
| 238 | ||
| 239 | After the POP3 server has opened the maildrop, it assigns a message- | |
| 240 | number to each message, and notes the size of each message in octets. | |
| 241 | The first message in the maildrop is assigned a message-number of | |
| 242 | "1", the second is assigned "2", and so on, so that the nth message | |
| 243 | in a maildrop is assigned a message-number of "n". In POP3 commands | |
| 244 | and responses, all message-numbers and message sizes are expressed in | |
| 245 | base-10 (i.e., decimal). | |
| 246 | ||
| 247 | Here is the summary for the QUIT command when used in the | |
| 248 | AUTHORIZATION state: | |
| 249 | ||
| 250 | QUIT | |
| 251 | ||
| 252 | Arguments: none | |
| 253 | ||
| 254 | Restrictions: none | |
| 255 | ||
| 256 | Possible Responses: | |
| 257 | +OK | |
| 258 | ||
| 259 | Examples: | |
| 260 | C: QUIT | |
| 261 | S: +OK dewey POP3 server signing off | |
| 262 | ||
| 263 | 5. The TRANSACTION State | |
| 264 | ||
| 265 | Once the client has successfully identified itself to the POP3 server | |
| 266 | and the POP3 server has locked and opened the appropriate maildrop, | |
| 267 | the POP3 session is now in the TRANSACTION state. The client may now | |
| 268 | issue any of the following POP3 commands repeatedly. After each | |
| 269 | command, the POP3 server issues a response. Eventually, the client | |
| 270 | issues the QUIT command and the POP3 session enters the UPDATE state. | |
| 271 | ||
| 272 | ||
| 273 | ||
| 274 | ||
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Myers & Rose Standards Track [Page 5] | |
| 282 | ||
| 283 | RFC 1939 POP3 May 1996 | |
| 284 | ||
| 285 | ||
| 286 | Here are the POP3 commands valid in the TRANSACTION state: | |
| 287 | ||
| 288 | STAT | |
| 289 | ||
| 290 | Arguments: none | |
| 291 | ||
| 292 | Restrictions: | |
| 293 | may only be given in the TRANSACTION state | |
| 294 | ||
| 295 | Discussion: | |
| 296 | The POP3 server issues a positive response with a line | |
| 297 | containing information for the maildrop. This line is | |
| 298 | called a "drop listing" for that maildrop. | |
| 299 | ||
| 300 | In order to simplify parsing, all POP3 servers are | |
| 301 | required to use a certain format for drop listings. The | |
| 302 | positive response consists of "+OK" followed by a single | |
| 303 | space, the number of messages in the maildrop, a single | |
| 304 | space, and the size of the maildrop in octets. This memo | |
| 305 | makes no requirement on what follows the maildrop size. | |
| 306 | Minimal implementations should just end that line of the | |
| 307 | response with a CRLF pair. More advanced implementations | |
| 308 | may include other information. | |
| 309 | ||
| 310 | NOTE: This memo STRONGLY discourages implementations | |
| 311 | from supplying additional information in the drop | |
| 312 | listing. Other, optional, facilities are discussed | |
| 313 | later on which permit the client to parse the messages | |
| 314 | in the maildrop. | |
| 315 | ||
| 316 | Note that messages marked as deleted are not counted in | |
| 317 | either total. | |
| 318 | ||
| 319 | Possible Responses: | |
| 320 | +OK nn mm | |
| 321 | ||
| 322 | Examples: | |
| 323 | C: STAT | |
| 324 | S: +OK 2 320 | |
| 325 | ||
| 326 | ||
| 327 | LIST [msg] | |
| 328 | ||
| 329 | Arguments: | |
| 330 | a message-number (optional), which, if present, may NOT | |
| 331 | refer to a message marked as deleted | |
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Myers & Rose Standards Track [Page 6] | |
| 338 | ||
| 339 | RFC 1939 POP3 May 1996 | |
| 340 | ||
| 341 | ||
| 342 | Restrictions: | |
| 343 | may only be given in the TRANSACTION state | |
| 344 | ||
| 345 | Discussion: | |
| 346 | If an argument was given and the POP3 server issues a | |
| 347 | positive response with a line containing information for | |
| 348 | that message. This line is called a "scan listing" for | |
| 349 | that message. | |
| 350 | ||
| 351 | If no argument was given and the POP3 server issues a | |
| 352 | positive response, then the response given is multi-line. | |
| 353 | After the initial +OK, for each message in the maildrop, | |
| 354 | the POP3 server responds with a line containing | |
| 355 | information for that message. This line is also called a | |
| 356 | "scan listing" for that message. If there are no | |
| 357 | messages in the maildrop, then the POP3 server responds | |
| 358 | with no scan listings--it issues a positive response | |
| 359 | followed by a line containing a termination octet and a | |
| 360 | CRLF pair. | |
| 361 | ||
| 362 | In order to simplify parsing, all POP3 servers are | |
| 363 | required to use a certain format for scan listings. A | |
| 364 | scan listing consists of the message-number of the | |
| 365 | message, followed by a single space and the exact size of | |
| 366 | the message in octets. Methods for calculating the exact | |
| 367 | size of the message are described in the "Message Format" | |
| 368 | section below. This memo makes no requirement on what | |
| 369 | follows the message size in the scan listing. Minimal | |
| 370 | implementations should just end that line of the response | |
| 371 | with a CRLF pair. More advanced implementations may | |
| 372 | include other information, as parsed from the message. | |
| 373 | ||
| 374 | NOTE: This memo STRONGLY discourages implementations | |
| 375 | from supplying additional information in the scan | |
| 376 | listing. Other, optional, facilities are discussed | |
| 377 | later on which permit the client to parse the messages | |
| 378 | in the maildrop. | |
| 379 | ||
| 380 | Note that messages marked as deleted are not listed. | |
| 381 | ||
| 382 | Possible Responses: | |
| 383 | +OK scan listing follows | |
| 384 | -ERR no such message | |
| 385 | ||
| 386 | Examples: | |
| 387 | C: LIST | |
| 388 | S: +OK 2 messages (320 octets) | |
| 389 | S: 1 120 | |
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Myers & Rose Standards Track [Page 7] | |
| 394 | ||
| 395 | RFC 1939 POP3 May 1996 | |
| 396 | ||
| 397 | ||
| 398 | S: 2 200 | |
| 399 | S: . | |
| 400 | ... | |
| 401 | C: LIST 2 | |
| 402 | S: +OK 2 200 | |
| 403 | ... | |
| 404 | C: LIST 3 | |
| 405 | S: -ERR no such message, only 2 messages in maildrop | |
| 406 | ||
| 407 | ||
| 408 | RETR msg | |
| 409 | ||
| 410 | Arguments: | |
| 411 | a message-number (required) which may NOT refer to a | |
| 412 | message marked as deleted | |
| 413 | ||
| 414 | Restrictions: | |
| 415 | may only be given in the TRANSACTION state | |
| 416 | ||
| 417 | Discussion: | |
| 418 | If the POP3 server issues a positive response, then the | |
| 419 | response given is multi-line. After the initial +OK, the | |
| 420 | POP3 server sends the message corresponding to the given | |
| 421 | message-number, being careful to byte-stuff the termination | |
| 422 | character (as with all multi-line responses). | |
| 423 | ||
| 424 | Possible Responses: | |
| 425 | +OK message follows | |
| 426 | -ERR no such message | |
| 427 | ||
| 428 | Examples: | |
| 429 | C: RETR 1 | |
| 430 | S: +OK 120 octets | |
| 431 | S: <the POP3 server sends the entire message here> | |
| 432 | S: . | |
| 433 | ||
| 434 | ||
| 435 | DELE msg | |
| 436 | ||
| 437 | Arguments: | |
| 438 | a message-number (required) which may NOT refer to a | |
| 439 | message marked as deleted | |
| 440 | ||
| 441 | Restrictions: | |
| 442 | may only be given in the TRANSACTION state | |
| 443 | ||
| 444 | ||
| 445 | ||
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Myers & Rose Standards Track [Page 8] | |
| 450 | ||
| 451 | RFC 1939 POP3 May 1996 | |
| 452 | ||
| 453 | ||
| 454 | Discussion: | |
| 455 | The POP3 server marks the message as deleted. Any future | |
| 456 | reference to the message-number associated with the message | |
| 457 | in a POP3 command generates an error. The POP3 server does | |
| 458 | not actually delete the message until the POP3 session | |
| 459 | enters the UPDATE state. | |
| 460 | ||
| 461 | Possible Responses: | |
| 462 | +OK message deleted | |
| 463 | -ERR no such message | |
| 464 | ||
| 465 | Examples: | |
| 466 | C: DELE 1 | |
| 467 | S: +OK message 1 deleted | |
| 468 | ... | |
| 469 | C: DELE 2 | |
| 470 | S: -ERR message 2 already deleted | |
| 471 | ||
| 472 | ||
| 473 | NOOP | |
| 474 | ||
| 475 | Arguments: none | |
| 476 | ||
| 477 | Restrictions: | |
| 478 | may only be given in the TRANSACTION state | |
| 479 | ||
| 480 | Discussion: | |
| 481 | The POP3 server does nothing, it merely replies with a | |
| 482 | positive response. | |
| 483 | ||
| 484 | Possible Responses: | |
| 485 | +OK | |
| 486 | ||
| 487 | Examples: | |
| 488 | C: NOOP | |
| 489 | S: +OK | |
| 490 | ||
| 491 | ||
| 492 | RSET | |
| 493 | ||
| 494 | Arguments: none | |
| 495 | ||
| 496 | Restrictions: | |
| 497 | may only be given in the TRANSACTION state | |
| 498 | ||
| 499 | Discussion: | |
| 500 | If any messages have been marked as deleted by the POP3 | |
| 501 | server, they are unmarked. The POP3 server then replies | |
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Myers & Rose Standards Track [Page 9] | |
| 506 | ||
| 507 | RFC 1939 POP3 May 1996 | |
| 508 | ||
| 509 | ||
| 510 | with a positive response. | |
| 511 | ||
| 512 | Possible Responses: | |
| 513 | +OK | |
| 514 | ||
| 515 | Examples: | |
| 516 | C: RSET | |
| 517 | S: +OK maildrop has 2 messages (320 octets) | |
| 518 | ||
| 519 | 6. The UPDATE State | |
| 520 | ||
| 521 | When the client issues the QUIT command from the TRANSACTION state, | |
| 522 | the POP3 session enters the UPDATE state. (Note that if the client | |
| 523 | issues the QUIT command from the AUTHORIZATION state, the POP3 | |
| 524 | session terminates but does NOT enter the UPDATE state.) | |
| 525 | ||
| 526 | If a session terminates for some reason other than a client-issued | |
| 527 | QUIT command, the POP3 session does NOT enter the UPDATE state and | |
| 528 | MUST not remove any messages from the maildrop. | |
| 529 | ||
| 530 | QUIT | |
| 531 | ||
| 532 | Arguments: none | |
| 533 | ||
| 534 | Restrictions: none | |
| 535 | ||
| 536 | Discussion: | |
| 537 | The POP3 server removes all messages marked as deleted | |
| 538 | from the maildrop and replies as to the status of this | |
| 539 | operation. If there is an error, such as a resource | |
| 540 | shortage, encountered while removing messages, the | |
| 541 | maildrop may result in having some or none of the messages | |
| 542 | marked as deleted be removed. In no case may the server | |
| 543 | remove any messages not marked as deleted. | |
| 544 | ||
| 545 | Whether the removal was successful or not, the server | |
| 546 | then releases any exclusive-access lock on the maildrop | |
| 547 | and closes the TCP connection. | |
| 548 | ||
| 549 | Possible Responses: | |
| 550 | +OK | |
| 551 | -ERR some deleted messages not removed | |
| 552 | ||
| 553 | Examples: | |
| 554 | C: QUIT | |
| 555 | S: +OK dewey POP3 server signing off (maildrop empty) | |
| 556 | ... | |
| 557 | C: QUIT | |
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Myers & Rose Standards Track [Page 10] | |
| 562 | ||
| 563 | RFC 1939 POP3 May 1996 | |
| 564 | ||
| 565 | ||
| 566 | S: +OK dewey POP3 server signing off (2 messages left) | |
| 567 | ... | |
| 568 | ||
| 569 | 7. Optional POP3 Commands | |
| 570 | ||
| 571 | The POP3 commands discussed above must be supported by all minimal | |
| 572 | implementations of POP3 servers. | |
| 573 | ||
| 574 | The optional POP3 commands described below permit a POP3 client | |
| 575 | greater freedom in message handling, while preserving a simple POP3 | |
| 576 | server implementation. | |
| 577 | ||
| 578 | NOTE: This memo STRONGLY encourages implementations to support | |
| 579 | these commands in lieu of developing augmented drop and scan | |
| 580 | listings. In short, the philosophy of this memo is to put | |
| 581 | intelligence in the part of the POP3 client and not the POP3 | |
| 582 | server. | |
| 583 | ||
| 584 | TOP msg n | |
| 585 | ||
| 586 | Arguments: | |
| 587 | a message-number (required) which may NOT refer to to a | |
| 588 | message marked as deleted, and a non-negative number | |
| 589 | of lines (required) | |
| 590 | ||
| 591 | Restrictions: | |
| 592 | may only be given in the TRANSACTION state | |
| 593 | ||
| 594 | Discussion: | |
| 595 | If the POP3 server issues a positive response, then the | |
| 596 | response given is multi-line. After the initial +OK, the | |
| 597 | POP3 server sends the headers of the message, the blank | |
| 598 | line separating the headers from the body, and then the | |
| 599 | number of lines of the indicated message's body, being | |
| 600 | careful to byte-stuff the termination character (as with | |
| 601 | all multi-line responses). | |
| 602 | ||
| 603 | Note that if the number of lines requested by the POP3 | |
| 604 | client is greater than than the number of lines in the | |
| 605 | body, then the POP3 server sends the entire message. | |
| 606 | ||
| 607 | Possible Responses: | |
| 608 | +OK top of message follows | |
| 609 | -ERR no such message | |
| 610 | ||
| 611 | Examples: | |
| 612 | C: TOP 1 10 | |
| 613 | S: +OK | |
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | Myers & Rose Standards Track [Page 11] | |
| 618 | ||
| 619 | RFC 1939 POP3 May 1996 | |
| 620 | ||
| 621 | ||
| 622 | S: <the POP3 server sends the headers of the | |
| 623 | message, a blank line, and the first 10 lines | |
| 624 | of the body of the message> | |
| 625 | S: . | |
| 626 | ... | |
| 627 | C: TOP 100 3 | |
| 628 | S: -ERR no such message | |
| 629 | ||
| 630 | ||
| 631 | UIDL [msg] | |
| 632 | ||
| 633 | Arguments: | |
| 634 | a message-number (optional), which, if present, may NOT | |
| 635 | refer to a message marked as deleted | |
| 636 | ||
| 637 | Restrictions: | |
| 638 | may only be given in the TRANSACTION state. | |
| 639 | ||
| 640 | Discussion: | |
| 641 | If an argument was given and the POP3 server issues a positive | |
| 642 | response with a line containing information for that message. | |
| 643 | This line is called a "unique-id listing" for that message. | |
| 644 | ||
| 645 | If no argument was given and the POP3 server issues a positive | |
| 646 | response, then the response given is multi-line. After the | |
| 647 | initial +OK, for each message in the maildrop, the POP3 server | |
| 648 | responds with a line containing information for that message. | |
| 649 | This line is called a "unique-id listing" for that message. | |
| 650 | ||
| 651 | In order to simplify parsing, all POP3 servers are required to | |
| 652 | use a certain format for unique-id listings. A unique-id | |
| 653 | listing consists of the message-number of the message, | |
| 654 | followed by a single space and the unique-id of the message. | |
| 655 | No information follows the unique-id in the unique-id listing. | |
| 656 | ||
| 657 | The unique-id of a message is an arbitrary server-determined | |
| 658 | string, consisting of one to 70 characters in the range 0x21 | |
| 659 | to 0x7E, which uniquely identifies a message within a | |
| 660 | maildrop and which persists across sessions. This | |
| 661 | persistence is required even if a session ends without | |
| 662 | entering the UPDATE state. The server should never reuse an | |
| 663 | unique-id in a given maildrop, for as long as the entity | |
| 664 | using the unique-id exists. | |
| 665 | ||
| 666 | Note that messages marked as deleted are not listed. | |
| 667 | ||
| 668 | While it is generally preferable for server implementations | |
| 669 | to store arbitrarily assigned unique-ids in the maildrop, | |
| 670 | ||
| 671 | ||
| 672 | ||
| 673 | Myers & Rose Standards Track [Page 12] | |
| 674 | ||
| 675 | RFC 1939 POP3 May 1996 | |
| 676 | ||
| 677 | ||
| 678 | this specification is intended to permit unique-ids to be | |
| 679 | calculated as a hash of the message. Clients should be able | |
| 680 | to handle a situation where two identical copies of a | |
| 681 | message in a maildrop have the same unique-id. | |
| 682 | ||
| 683 | Possible Responses: | |
| 684 | +OK unique-id listing follows | |
| 685 | -ERR no such message | |
| 686 | ||
| 687 | Examples: | |
| 688 | C: UIDL | |
| 689 | S: +OK | |
| 690 | S: 1 whqtswO00WBw418f9t5JxYwZ | |
| 691 | S: 2 QhdPYR:00WBw1Ph7x7 | |
| 692 | S: . | |
| 693 | ... | |
| 694 | C: UIDL 2 | |
| 695 | S: +OK 2 QhdPYR:00WBw1Ph7x7 | |
| 696 | ... | |
| 697 | C: UIDL 3 | |
| 698 | S: -ERR no such message, only 2 messages in maildrop | |
| 699 | ||
| 700 | ||
| 701 | USER name | |
| 702 | ||
| 703 | Arguments: | |
| 704 | a string identifying a mailbox (required), which is of | |
| 705 | significance ONLY to the server | |
| 706 | ||
| 707 | Restrictions: | |
| 708 | may only be given in the AUTHORIZATION state after the POP3 | |
| 709 | greeting or after an unsuccessful USER or PASS command | |
| 710 | ||
| 711 | Discussion: | |
| 712 | To authenticate using the USER and PASS command | |
| 713 | combination, the client must first issue the USER | |
| 714 | command. If the POP3 server responds with a positive | |
| 715 | status indicator ("+OK"), then the client may issue | |
| 716 | either the PASS command to complete the authentication, | |
| 717 | or the QUIT command to terminate the POP3 session. If | |
| 718 | the POP3 server responds with a negative status indicator | |
| 719 | ("-ERR") to the USER command, then the client may either | |
| 720 | issue a new authentication command or may issue the QUIT | |
| 721 | command. | |
| 722 | ||
| 723 | The server may return a positive response even though no | |
| 724 | such mailbox exists. The server may return a negative | |
| 725 | response if mailbox exists, but does not permit plaintext | |
| 726 | ||
| 727 | ||
| 728 | ||
| 729 | Myers & Rose Standards Track [Page 13] | |
| 730 | ||
| 731 | RFC 1939 POP3 May 1996 | |
| 732 | ||
| 733 | ||
| 734 | password authentication. | |
| 735 | ||
| 736 | Possible Responses: | |
| 737 | +OK name is a valid mailbox | |
| 738 | -ERR never heard of mailbox name | |
| 739 | ||
| 740 | Examples: | |
| 741 | C: USER frated | |
| 742 | S: -ERR sorry, no mailbox for frated here | |
| 743 | ... | |
| 744 | C: USER mrose | |
| 745 | S: +OK mrose is a real hoopy frood | |
| 746 | ||
| 747 | ||
| 748 | PASS string | |
| 749 | ||
| 750 | Arguments: | |
| 751 | a server/mailbox-specific password (required) | |
| 752 | ||
| 753 | Restrictions: | |
| 754 | may only be given in the AUTHORIZATION state immediately | |
| 755 | after a successful USER command | |
| 756 | ||
| 757 | Discussion: | |
| 758 | When the client issues the PASS command, the POP3 server | |
| 759 | uses the argument pair from the USER and PASS commands to | |
| 760 | determine if the client should be given access to the | |
| 761 | appropriate maildrop. | |
| 762 | ||
| 763 | Since the PASS command has exactly one argument, a POP3 | |
| 764 | server may treat spaces in the argument as part of the | |
| 765 | password, instead of as argument separators. | |
| 766 | ||
| 767 | Possible Responses: | |
| 768 | +OK maildrop locked and ready | |
| 769 | -ERR invalid password | |
| 770 | -ERR unable to lock maildrop | |
| 771 | ||
| 772 | Examples: | |
| 773 | C: USER mrose | |
| 774 | S: +OK mrose is a real hoopy frood | |
| 775 | C: PASS secret | |
| 776 | S: -ERR maildrop already locked | |
| 777 | ... | |
| 778 | C: USER mrose | |
| 779 | S: +OK mrose is a real hoopy frood | |
| 780 | C: PASS secret | |
| 781 | S: +OK mrose's maildrop has 2 messages (320 octets) | |
| 782 | ||
| 783 | ||
| 784 | ||
| 785 | Myers & Rose Standards Track [Page 14] | |
| 786 | ||
| 787 | RFC 1939 POP3 May 1996 | |
| 788 | ||
| 789 | ||
| 790 | APOP name digest | |
| 791 | ||
| 792 | Arguments: | |
| 793 | a string identifying a mailbox and a MD5 digest string | |
| 794 | (both required) | |
| 795 | ||
| 796 | Restrictions: | |
| 797 | may only be given in the AUTHORIZATION state after the POP3 | |
| 798 | greeting or after an unsuccessful USER or PASS command | |
| 799 | ||
| 800 | Discussion: | |
| 801 | Normally, each POP3 session starts with a USER/PASS | |
| 802 | exchange. This results in a server/user-id specific | |
| 803 | password being sent in the clear on the network. For | |
| 804 | intermittent use of POP3, this may not introduce a sizable | |
| 805 | risk. However, many POP3 client implementations connect to | |
| 806 | the POP3 server on a regular basis -- to check for new | |
| 807 | mail. Further the interval of session initiation may be on | |
| 808 | the order of five minutes. Hence, the risk of password | |
| 809 | capture is greatly enhanced. | |
| 810 | ||
| 811 | An alternate method of authentication is required which | |
| 812 | provides for both origin authentication and replay | |
| 813 | protection, but which does not involve sending a password | |
| 814 | in the clear over the network. The APOP command provides | |
| 815 | this functionality. | |
| 816 | ||
| 817 | A POP3 server which implements the APOP command will | |
| 818 | include a timestamp in its banner greeting. The syntax of | |
| 819 | the timestamp corresponds to the `msg-id' in [RFC822], and | |
| 820 | MUST be different each time the POP3 server issues a banner | |
| 821 | greeting. For example, on a UNIX implementation in which a | |
| 822 | separate UNIX process is used for each instance of a POP3 | |
| 823 | server, the syntax of the timestamp might be: | |
| 824 | ||
| 825 | <process-ID.clock@hostname> | |
| 826 | ||
| 827 | where `process-ID' is the decimal value of the process's | |
| 828 | PID, clock is the decimal value of the system clock, and | |
| 829 | hostname is the fully-qualified domain-name corresponding | |
| 830 | to the host where the POP3 server is running. | |
| 831 | ||
| 832 | The POP3 client makes note of this timestamp, and then | |
| 833 | issues the APOP command. The `name' parameter has | |
| 834 | identical semantics to the `name' parameter of the USER | |
| 835 | command. The `digest' parameter is calculated by applying | |
| 836 | the MD5 algorithm [RFC1321] to a string consisting of the | |
| 837 | timestamp (including angle-brackets) followed by a shared | |
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | Myers & Rose Standards Track [Page 15] | |
| 842 | ||
| 843 | RFC 1939 POP3 May 1996 | |
| 844 | ||
| 845 | ||
| 846 | secret. This shared secret is a string known only to the | |
| 847 | POP3 client and server. Great care should be taken to | |
| 848 | prevent unauthorized disclosure of the secret, as knowledge | |
| 849 | of the secret will allow any entity to successfully | |
| 850 | masquerade as the named user. The `digest' parameter | |
| 851 | itself is a 16-octet value which is sent in hexadecimal | |
| 852 | format, using lower-case ASCII characters. | |
| 853 | ||
| 854 | When the POP3 server receives the APOP command, it verifies | |
| 855 | the digest provided. If the digest is correct, the POP3 | |
| 856 | server issues a positive response, and the POP3 session | |
| 857 | enters the TRANSACTION state. Otherwise, a negative | |
| 858 | response is issued and the POP3 session remains in the | |
| 859 | AUTHORIZATION state. | |
| 860 | ||
| 861 | Note that as the length of the shared secret increases, so | |
| 862 | does the difficulty of deriving it. As such, shared | |
| 863 | secrets should be long strings (considerably longer than | |
| 864 | the 8-character example shown below). | |
| 865 | ||
| 866 | Possible Responses: | |
| 867 | +OK maildrop locked and ready | |
| 868 | -ERR permission denied | |
| 869 | ||
| 870 | Examples: | |
| 871 | S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> | |
| 872 | C: APOP mrose c4c9334bac560ecc979e58001b3e22fb | |
| 873 | S: +OK maildrop has 1 message (369 octets) | |
| 874 | ||
| 875 | In this example, the shared secret is the string `tan- | |
| 876 | staaf'. Hence, the MD5 algorithm is applied to the string | |
| 877 | ||
| 878 | <1896.697170952@dbc.mtview.ca.us>tanstaaf | |
| 879 | ||
| 880 | which produces a digest value of | |
| 881 | ||
| 882 | c4c9334bac560ecc979e58001b3e22fb | |
| 883 | ||
| 884 | 8. Scaling and Operational Considerations | |
| 885 | ||
| 886 | Since some of the optional features described above were added to the | |
| 887 | POP3 protocol, experience has accumulated in using them in large- | |
| 888 | scale commercial post office operations where most of the users are | |
| 889 | unrelated to each other. In these situations and others, users and | |
| 890 | vendors of POP3 clients have discovered that the combination of using | |
| 891 | the UIDL command and not issuing the DELE command can provide a weak | |
| 892 | version of the "maildrop as semi-permanent repository" functionality | |
| 893 | normally associated with IMAP. Of course the other capabilities of | |
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | Myers & Rose Standards Track [Page 16] | |
| 898 | ||
| 899 | RFC 1939 POP3 May 1996 | |
| 900 | ||
| 901 | ||
| 902 | IMAP, such as polling an existing connection for newly arrived | |
| 903 | messages and supporting multiple folders on the server, are not | |
| 904 | present in POP3. | |
| 905 | ||
| 906 | When these facilities are used in this way by casual users, there has | |
| 907 | been a tendency for already-read messages to accumulate on the server | |
| 908 | without bound. This is clearly an undesirable behavior pattern from | |
| 909 | the standpoint of the server operator. This situation is aggravated | |
| 910 | by the fact that the limited capabilities of the POP3 do not permit | |
| 911 | efficient handling of maildrops which have hundreds or thousands of | |
| 912 | messages. | |
| 913 | ||
| 914 | Consequently, it is recommended that operators of large-scale multi- | |
| 915 | user servers, especially ones in which the user's only access to the | |
| 916 | maildrop is via POP3, consider such options as: | |
| 917 | ||
| 918 | * Imposing a per-user maildrop storage quota or the like. | |
| 919 | ||
| 920 | A disadvantage to this option is that accumulation of messages may | |
| 921 | result in the user's inability to receive new ones into the | |
| 922 | maildrop. Sites which choose this option should be sure to inform | |
| 923 | users of impending or current exhaustion of quota, perhaps by | |
| 924 | inserting an appropriate message into the user's maildrop. | |
| 925 | ||
| 926 | * Enforce a site policy regarding mail retention on the server. | |
| 927 | ||
| 928 | Sites are free to establish local policy regarding the storage and | |
| 929 | retention of messages on the server, both read and unread. For | |
| 930 | example, a site might delete unread messages from the server after | |
| 931 | 60 days and delete read messages after 7 days. Such message | |
| 932 | deletions are outside the scope of the POP3 protocol and are not | |
| 933 | considered a protocol violation. | |
| 934 | ||
| 935 | Server operators enforcing message deletion policies should take | |
| 936 | care to make all users aware of the policies in force. | |
| 937 | ||
| 938 | Clients must not assume that a site policy will automate message | |
| 939 | deletions, and should continue to explicitly delete messages using | |
| 940 | the DELE command when appropriate. | |
| 941 | ||
| 942 | It should be noted that enforcing site message deletion policies | |
| 943 | may be confusing to the user community, since their POP3 client | |
| 944 | may contain configuration options to leave mail on the server | |
| 945 | which will not in fact be supported by the server. | |
| 946 | ||
| 947 | One special case of a site policy is that messages may only be | |
| 948 | downloaded once from the server, and are deleted after this has | |
| 949 | been accomplished. This could be implemented in POP3 server | |
| 950 | ||
| 951 | ||
| 952 | ||
| 953 | Myers & Rose Standards Track [Page 17] | |
| 954 | ||
| 955 | RFC 1939 POP3 May 1996 | |
| 956 | ||
| 957 | ||
| 958 | software by the following mechanism: "following a POP3 login by a | |
| 959 | client which was ended by a QUIT, delete all messages downloaded | |
| 960 | during the session with the RETR command". It is important not to | |
| 961 | delete messages in the event of abnormal connection termination | |
| 962 | (ie, if no QUIT was received from the client) because the client | |
| 963 | may not have successfully received or stored the messages. | |
| 964 | Servers implementing a download-and-delete policy may also wish to | |
| 965 | disable or limit the optional TOP command, since it could be used | |
| 966 | as an alternate mechanism to download entire messages. | |
| 967 | ||
| 968 | 9. POP3 Command Summary | |
| 969 | ||
| 970 | Minimal POP3 Commands: | |
| 971 | ||
| 972 | USER name valid in the AUTHORIZATION state | |
| 973 | PASS string | |
| 974 | QUIT | |
| 975 | ||
| 976 | STAT valid in the TRANSACTION state | |
| 977 | LIST [msg] | |
| 978 | RETR msg | |
| 979 | DELE msg | |
| 980 | NOOP | |
| 981 | RSET | |
| 982 | QUIT | |
| 983 | ||
| 984 | Optional POP3 Commands: | |
| 985 | ||
| 986 | APOP name digest valid in the AUTHORIZATION state | |
| 987 | ||
| 988 | TOP msg n valid in the TRANSACTION state | |
| 989 | UIDL [msg] | |
| 990 | ||
| 991 | POP3 Replies: | |
| 992 | ||
| 993 | +OK | |
| 994 | -ERR | |
| 995 | ||
| 996 | Note that with the exception of the STAT, LIST, and UIDL commands, | |
| 997 | the reply given by the POP3 server to any command is significant | |
| 998 | only to "+OK" and "-ERR". Any text occurring after this reply | |
| 999 | may be ignored by the client. | |
| 1000 | ||
| 1001 | ||
| 1002 | ||
| 1003 | ||
| 1004 | ||
| 1005 | ||
| 1006 | ||
| 1007 | ||
| 1008 | ||
| 1009 | Myers & Rose Standards Track [Page 18] | |
| 1010 | ||
| 1011 | RFC 1939 POP3 May 1996 | |
| 1012 | ||
| 1013 | ||
| 1014 | 10. Example POP3 Session | |
| 1015 | ||
| 1016 | S: <wait for connection on TCP port 110> | |
| 1017 | C: <open connection> | |
| 1018 | S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> | |
| 1019 | C: APOP mrose c4c9334bac560ecc979e58001b3e22fb | |
| 1020 | S: +OK mrose's maildrop has 2 messages (320 octets) | |
| 1021 | C: STAT | |
| 1022 | S: +OK 2 320 | |
| 1023 | C: LIST | |
| 1024 | S: +OK 2 messages (320 octets) | |
| 1025 | S: 1 120 | |
| 1026 | S: 2 200 | |
| 1027 | S: . | |
| 1028 | C: RETR 1 | |
| 1029 | S: +OK 120 octets | |
| 1030 | S: <the POP3 server sends message 1> | |
| 1031 | S: . | |
| 1032 | C: DELE 1 | |
| 1033 | S: +OK message 1 deleted | |
| 1034 | C: RETR 2 | |
| 1035 | S: +OK 200 octets | |
| 1036 | S: <the POP3 server sends message 2> | |
| 1037 | S: . | |
| 1038 | C: DELE 2 | |
| 1039 | S: +OK message 2 deleted | |
| 1040 | C: QUIT | |
| 1041 | S: +OK dewey POP3 server signing off (maildrop empty) | |
| 1042 | C: <close connection> | |
| 1043 | S: <wait for next connection> | |
| 1044 | ||
| 1045 | 11. Message Format | |
| 1046 | ||
| 1047 | All messages transmitted during a POP3 session are assumed to conform | |
| 1048 | to the standard for the format of Internet text messages [RFC822]. | |
| 1049 | ||
| 1050 | It is important to note that the octet count for a message on the | |
| 1051 | server host may differ from the octet count assigned to that message | |
| 1052 | due to local conventions for designating end-of-line. Usually, | |
| 1053 | during the AUTHORIZATION state of the POP3 session, the POP3 server | |
| 1054 | can calculate the size of each message in octets when it opens the | |
| 1055 | maildrop. For example, if the POP3 server host internally represents | |
| 1056 | end-of-line as a single character, then the POP3 server simply counts | |
| 1057 | each occurrence of this character in a message as two octets. Note | |
| 1058 | that lines in the message which start with the termination octet need | |
| 1059 | not (and must not) be counted twice, since the POP3 client will | |
| 1060 | remove all byte-stuffed termination characters when it receives a | |
| 1061 | multi-line response. | |
| 1062 | ||
| 1063 | ||
| 1064 | ||
| 1065 | Myers & Rose Standards Track [Page 19] | |
| 1066 | ||
| 1067 | RFC 1939 POP3 May 1996 | |
| 1068 | ||
| 1069 | ||
| 1070 | 12. References | |
| 1071 | ||
| 1072 | [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC | |
| 1073 | 821, USC/Information Sciences Institute, August 1982. | |
| 1074 | ||
| 1075 | [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text | |
| 1076 | Messages", STD 11, RFC 822, University of Delaware, August 1982. | |
| 1077 | ||
| 1078 | [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |
| 1079 | MIT Laboratory for Computer Science, April 1992. | |
| 1080 | ||
| 1081 | [RFC1730] Crispin, M., "Internet Message Access Protocol - Version | |
| 1082 | 4", RFC 1730, University of Washington, December 1994. | |
| 1083 | ||
| 1084 | [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, | |
| 1085 | Carnegie Mellon, December 1994. | |
| 1086 | ||
| 1087 | 13. Security Considerations | |
| 1088 | ||
| 1089 | It is conjectured that use of the APOP command provides origin | |
| 1090 | identification and replay protection for a POP3 session. | |
| 1091 | Accordingly, a POP3 server which implements both the PASS and APOP | |
| 1092 | commands should not allow both methods of access for a given user; | |
| 1093 | that is, for a given mailbox name, either the USER/PASS command | |
| 1094 | sequence or the APOP command is allowed, but not both. | |
| 1095 | ||
| 1096 | Further, note that as the length of the shared secret increases, so | |
| 1097 | does the difficulty of deriving it. | |
| 1098 | ||
| 1099 | Servers that answer -ERR to the USER command are giving potential | |
| 1100 | attackers clues about which names are valid. | |
| 1101 | ||
| 1102 | Use of the PASS command sends passwords in the clear over the | |
| 1103 | network. | |
| 1104 | ||
| 1105 | Use of the RETR and TOP commands sends mail in the clear over the | |
| 1106 | network. | |
| 1107 | ||
| 1108 | Otherwise, security issues are not discussed in this memo. | |
| 1109 | ||
| 1110 | 14. Acknowledgements | |
| 1111 | ||
| 1112 | The POP family has a long and checkered history. Although primarily | |
| 1113 | a minor revision to RFC 1460, POP3 is based on the ideas presented in | |
| 1114 | RFCs 918, 937, and 1081. | |
| 1115 | ||
| 1116 | In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff | |
| 1117 | provided significant comments on the APOP command. | |
| 1118 | ||
| 1119 | ||
| 1120 | ||
| 1121 | Myers & Rose Standards Track [Page 20] | |
| 1122 | ||
| 1123 | RFC 1939 POP3 May 1996 | |
| 1124 | ||
| 1125 | ||
| 1126 | 15. Authors' Addresses | |
| 1127 | ||
| 1128 | John G. Myers | |
| 1129 | Carnegie-Mellon University | |
| 1130 | 5000 Forbes Ave | |
| 1131 | Pittsburgh, PA 15213 | |
| 1132 | ||
| 1133 | EMail: jgm+@cmu.edu | |
| 1134 | ||
| 1135 | ||
| 1136 | Marshall T. Rose | |
| 1137 | Dover Beach Consulting, Inc. | |
| 1138 | 420 Whisman Court | |
| 1139 | Mountain View, CA 94043-2186 | |
| 1140 | ||
| 1141 | EMail: mrose@dbc.mtview.ca.us | |
| 1142 | ||
| 1143 | ||
| 1144 | ||
| 1145 | ||
| 1146 | ||
| 1147 | ||
| 1148 | ||
| 1149 | ||
| 1150 | ||
| 1151 | ||
| 1152 | ||
| 1153 | ||
| 1154 | ||
| 1155 | ||
| 1156 | ||
| 1157 | ||
| 1158 | ||
| 1159 | ||
| 1160 | ||
| 1161 | ||
| 1162 | ||
| 1163 | ||
| 1164 | ||
| 1165 | ||
| 1166 | ||
| 1167 | ||
| 1168 | ||
| 1169 | ||
| 1170 | ||
| 1171 | ||
| 1172 | ||
| 1173 | ||
| 1174 | ||
| 1175 | ||
| 1176 | ||
| 1177 | Myers & Rose Standards Track [Page 21] | |
| 1178 | ||
| 1179 | RFC 1939 POP3 May 1996 | |
| 1180 | ||
| 1181 | ||
| 1182 | Appendix A. Differences from RFC 1725 | |
| 1183 | ||
| 1184 | This memo is a revision to RFC 1725, a Draft Standard. It makes the | |
| 1185 | following changes from that document: | |
| 1186 | ||
| 1187 | - clarifies that command keywords are case insensitive. | |
| 1188 | ||
| 1189 | - specifies that servers must send "+OK" and "-ERR" in | |
| 1190 | upper case. | |
| 1191 | ||
| 1192 | - specifies that the initial greeting is a positive response, | |
| 1193 | instead of any string which should be a positive response. | |
| 1194 | ||
| 1195 | - clarifies behavior for unimplemented commands. | |
| 1196 | ||
| 1197 | - makes the USER and PASS commands optional. | |
| 1198 | ||
| 1199 | - clarified the set of possible responses to the USER command. | |
| 1200 | ||
| 1201 | - reverses the order of the examples in the USER and PASS | |
| 1202 | commands, to reduce confusion. | |
| 1203 | ||
| 1204 | - clarifies that the PASS command may only be given immediately | |
| 1205 | after a successful USER command. | |
| 1206 | ||
| 1207 | - clarified the persistence requirements of UIDs and added some | |
| 1208 | implementation notes. | |
| 1209 | ||
| 1210 | - specifies a UID length limitation of one to 70 octets. | |
| 1211 | ||
| 1212 | - specifies a status indicator length limitation | |
| 1213 | of 512 octets, including the CRLF. | |
| 1214 | ||
| 1215 | - clarifies that LIST with no arguments on an empty mailbox | |
| 1216 | returns success. | |
| 1217 | ||
| 1218 | - adds a reference from the LIST command to the Message Format | |
| 1219 | section | |
| 1220 | ||
| 1221 | - clarifies the behavior of QUIT upon failure | |
| 1222 | ||
| 1223 | - clarifies the security section to not imply the use of the | |
| 1224 | USER command with the APOP command. | |
| 1225 | ||
| 1226 | - adds references to RFCs 1730 and 1734 | |
| 1227 | ||
| 1228 | - clarifies the method by which a UA may enter mail into the | |
| 1229 | transport system. | |
| 1230 | ||
| 1231 | ||
| 1232 | ||
| 1233 | Myers & Rose Standards Track [Page 22] | |
| 1234 | ||
| 1235 | RFC 1939 POP3 May 1996 | |
| 1236 | ||
| 1237 | ||
| 1238 | - clarifies that the second argument to the TOP command is a | |
| 1239 | number of lines. | |
| 1240 | ||
| 1241 | - changes the suggestion in the Security Considerations section | |
| 1242 | for a server to not accept both PASS and APOP for a given user | |
| 1243 | from a "must" to a "should". | |
| 1244 | ||
| 1245 | - adds a section on scaling and operational considerations | |
| 1246 | ||
| 1247 | Appendix B. Command Index | |
| 1248 | ||
| 1249 | APOP ....................................................... 15 | |
| 1250 | DELE ....................................................... 8 | |
| 1251 | LIST ....................................................... 6 | |
| 1252 | NOOP ....................................................... 9 | |
| 1253 | PASS ....................................................... 14 | |
| 1254 | QUIT ....................................................... 5 | |
| 1255 | QUIT ....................................................... 10 | |
| 1256 | RETR ....................................................... 8 | |
| 1257 | RSET ....................................................... 9 | |
| 1258 | STAT ....................................................... 6 | |
| 1259 | TOP ........................................................ 11 | |
| 1260 | UIDL ....................................................... 12 | |
| 1261 | USER ....................................................... 13 | |
| 1262 | ||
| 1263 | ||
| 1264 | ||
| 1265 | ||
| 1266 | ||
| 1267 | ||
| 1268 | ||
| 1269 | ||
| 1270 | ||
| 1271 | ||
| 1272 | ||
| 1273 | ||
| 1274 | ||
| 1275 | ||
| 1276 | ||
| 1277 | ||
| 1278 | ||
| 1279 | ||
| 1280 | ||
| 1281 | ||
| 1282 | ||
| 1283 | ||
| 1284 | ||
| 1285 | ||
| 1286 | ||
| 1287 | ||
| 1288 | ||
| 1289 | Myers & Rose Standards Track [Page 23] | |
| 1290 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group H. Krawczyk | |
| 7 | Request for Comments: 2104 IBM | |
| 8 | Category: Informational M. Bellare | |
| 9 | UCSD | |
| 10 | R. Canetti | |
| 11 | IBM | |
| 12 | February 1997 | |
| 13 | ||
| 14 | ||
| 15 | HMAC: Keyed-Hashing for Message Authentication | |
| 16 | ||
| 17 | Status of This Memo | |
| 18 | ||
| 19 | This memo provides information for the Internet community. This memo | |
| 20 | does not specify an Internet standard of any kind. Distribution of | |
| 21 | this memo is unlimited. | |
| 22 | ||
| 23 | Abstract | |
| 24 | ||
| 25 | This document describes HMAC, a mechanism for message authentication | |
| 26 | using cryptographic hash functions. HMAC can be used with any | |
| 27 | iterative cryptographic hash function, e.g., MD5, SHA-1, in | |
| 28 | combination with a secret shared key. The cryptographic strength of | |
| 29 | HMAC depends on the properties of the underlying hash function. | |
| 30 | ||
| 31 | 1. Introduction | |
| 32 | ||
| 33 | Providing a way to check the integrity of information transmitted | |
| 34 | over or stored in an unreliable medium is a prime necessity in the | |
| 35 | world of open computing and communications. Mechanisms that provide | |
| 36 | such integrity check based on a secret key are usually called | |
| 37 | "message authentication codes" (MAC). Typically, message | |
| 38 | authentication codes are used between two parties that share a secret | |
| 39 | key in order to validate information transmitted between these | |
| 40 | parties. In this document we present such a MAC mechanism based on | |
| 41 | cryptographic hash functions. This mechanism, called HMAC, is based | |
| 42 | on work by the authors [BCK1] where the construction is presented and | |
| 43 | cryptographically analyzed. We refer to that work for the details on | |
| 44 | the rationale and security analysis of HMAC, and its comparison to | |
| 45 | other keyed-hash methods. | |
| 46 | ||
| 47 | ||
| 48 | ||
| 49 | ||
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Krawczyk, et. al. Informational [Page 1] | |
| 58 | ||
| 59 | RFC 2104 HMAC February 1997 | |
| 60 | ||
| 61 | ||
| 62 | HMAC can be used in combination with any iterated cryptographic hash | |
| 63 | function. MD5 and SHA-1 are examples of such hash functions. HMAC | |
| 64 | also uses a secret key for calculation and verification of the | |
| 65 | message authentication values. The main goals behind this | |
| 66 | construction are | |
| 67 | ||
| 68 | * To use, without modifications, available hash functions. | |
| 69 | In particular, hash functions that perform well in software, | |
| 70 | and for which code is freely and widely available. | |
| 71 | ||
| 72 | * To preserve the original performance of the hash function without | |
| 73 | incurring a significant degradation. | |
| 74 | ||
| 75 | * To use and handle keys in a simple way. | |
| 76 | ||
| 77 | * To have a well understood cryptographic analysis of the strength of | |
| 78 | the authentication mechanism based on reasonable assumptions on the | |
| 79 | underlying hash function. | |
| 80 | ||
| 81 | * To allow for easy replaceability of the underlying hash function in | |
| 82 | case that faster or more secure hash functions are found or | |
| 83 | required. | |
| 84 | ||
| 85 | This document specifies HMAC using a generic cryptographic hash | |
| 86 | function (denoted by H). Specific instantiations of HMAC need to | |
| 87 | define a particular hash function. Current candidates for such hash | |
| 88 | functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD]. | |
| 89 | These different realizations of HMAC will be denoted by HMAC-SHA1, | |
| 90 | HMAC-MD5, HMAC-RIPEMD, etc. | |
| 91 | ||
| 92 | Note: To the date of writing of this document MD5 and SHA-1 are the | |
| 93 | most widely used cryptographic hash functions. MD5 has been recently | |
| 94 | shown to be vulnerable to collision search attacks [Dobb]. This | |
| 95 | attack and other currently known weaknesses of MD5 do not compromise | |
| 96 | the use of MD5 within HMAC as specified in this document (see | |
| 97 | [Dobb]); however, SHA-1 appears to be a cryptographically stronger | |
| 98 | function. To this date, MD5 can be considered for use in HMAC for | |
| 99 | applications where the superior performance of MD5 is critical. In | |
| 100 | any case, implementers and users need to be aware of possible | |
| 101 | cryptanalytic developments regarding any of these cryptographic hash | |
| 102 | functions, and the eventual need to replace the underlying hash | |
| 103 | function. (See section 6 for more information on the security of | |
| 104 | HMAC.) | |
| 105 | ||
| 106 | ||
| 107 | ||
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Krawczyk, et. al. Informational [Page 2] | |
| 114 | ||
| 115 | RFC 2104 HMAC February 1997 | |
| 116 | ||
| 117 | ||
| 118 | 2. Definition of HMAC | |
| 119 | ||
| 120 | The definition of HMAC requires a cryptographic hash function, which | |
| 121 | we denote by H, and a secret key K. We assume H to be a cryptographic | |
| 122 | hash function where data is hashed by iterating a basic compression | |
| 123 | function on blocks of data. We denote by B the byte-length of such | |
| 124 | blocks (B=64 for all the above mentioned examples of hash functions), | |
| 125 | and by L the byte-length of hash outputs (L=16 for MD5, L=20 for | |
| 126 | SHA-1). The authentication key K can be of any length up to B, the | |
| 127 | block length of the hash function. Applications that use keys longer | |
| 128 | than B bytes will first hash the key using H and then use the | |
| 129 | resultant L byte string as the actual key to HMAC. In any case the | |
| 130 | minimal recommended length for K is L bytes (as the hash output | |
| 131 | length). See section 3 for more information on keys. | |
| 132 | ||
| 133 | We define two fixed and different strings ipad and opad as follows | |
| 134 | (the 'i' and 'o' are mnemonics for inner and outer): | |
| 135 | ||
| 136 | ipad = the byte 0x36 repeated B times | |
| 137 | opad = the byte 0x5C repeated B times. | |
| 138 | ||
| 139 | To compute HMAC over the data `text' we perform | |
| 140 | ||
| 141 | H(K XOR opad, H(K XOR ipad, text)) | |
| 142 | ||
| 143 | Namely, | |
| 144 | ||
| 145 | (1) append zeros to the end of K to create a B byte string | |
| 146 | (e.g., if K is of length 20 bytes and B=64, then K will be | |
| 147 | appended with 44 zero bytes 0x00) | |
| 148 | (2) XOR (bitwise exclusive-OR) the B byte string computed in step | |
| 149 | (1) with ipad | |
| 150 | (3) append the stream of data 'text' to the B byte string resulting | |
| 151 | from step (2) | |
| 152 | (4) apply H to the stream generated in step (3) | |
| 153 | (5) XOR (bitwise exclusive-OR) the B byte string computed in | |
| 154 | step (1) with opad | |
| 155 | (6) append the H result from step (4) to the B byte string | |
| 156 | resulting from step (5) | |
| 157 | (7) apply H to the stream generated in step (6) and output | |
| 158 | the result | |
| 159 | ||
| 160 | For illustration purposes, sample code based on MD5 is provided as an | |
| 161 | appendix. | |
| 162 | ||
| 163 | ||
| 164 | ||
| 165 | ||
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Krawczyk, et. al. Informational [Page 3] | |
| 170 | ||
| 171 | RFC 2104 HMAC February 1997 | |
| 172 | ||
| 173 | ||
| 174 | 3. Keys | |
| 175 | ||
| 176 | The key for HMAC can be of any length (keys longer than B bytes are | |
| 177 | first hashed using H). However, less than L bytes is strongly | |
| 178 | discouraged as it would decrease the security strength of the | |
| 179 | function. Keys longer than L bytes are acceptable but the extra | |
| 180 | length would not significantly increase the function strength. (A | |
| 181 | longer key may be advisable if the randomness of the key is | |
| 182 | considered weak.) | |
| 183 | ||
| 184 | Keys need to be chosen at random (or using a cryptographically strong | |
| 185 | pseudo-random generator seeded with a random seed), and periodically | |
| 186 | refreshed. (Current attacks do not indicate a specific recommended | |
| 187 | frequency for key changes as these attacks are practically | |
| 188 | infeasible. However, periodic key refreshment is a fundamental | |
| 189 | security practice that helps against potential weaknesses of the | |
| 190 | function and keys, and limits the damage of an exposed key.) | |
| 191 | ||
| 192 | 4. Implementation Note | |
| 193 | ||
| 194 | HMAC is defined in such a way that the underlying hash function H can | |
| 195 | be used with no modification to its code. In particular, it uses the | |
| 196 | function H with the pre-defined initial value IV (a fixed value | |
| 197 | specified by each iterative hash function to initialize its | |
| 198 | compression function). However, if desired, a performance | |
| 199 | improvement can be achieved at the cost of (possibly) modifying the | |
| 200 | code of H to support variable IVs. | |
| 201 | ||
| 202 | The idea is that the intermediate results of the compression function | |
| 203 | on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed | |
| 204 | only once at the time of generation of the key K, or before its first | |
| 205 | use. These intermediate results are stored and then used to | |
| 206 | initialize the IV of H each time that a message needs to be | |
| 207 | authenticated. This method saves, for each authenticated message, | |
| 208 | the application of the compression function of H on two B-byte blocks | |
| 209 | (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be | |
| 210 | significant when authenticating short streams of data. We stress | |
| 211 | that the stored intermediate values need to be treated and protected | |
| 212 | the same as secret keys. | |
| 213 | ||
| 214 | Choosing to implement HMAC in the above way is a decision of the | |
| 215 | local implementation and has no effect on inter-operability. | |
| 216 | ||
| 217 | ||
| 218 | ||
| 219 | ||
| 220 | ||
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Krawczyk, et. al. Informational [Page 4] | |
| 226 | ||
| 227 | RFC 2104 HMAC February 1997 | |
| 228 | ||
| 229 | ||
| 230 | 5. Truncated output | |
| 231 | ||
| 232 | A well-known practice with message authentication codes is to | |
| 233 | truncate the output of the MAC and output only part of the bits | |
| 234 | (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some | |
| 235 | analytical advantages of truncating the output of hash-based MAC | |
| 236 | functions. The results in this area are not absolute as for the | |
| 237 | overall security advantages of truncation. It has advantages (less | |
| 238 | information on the hash result available to an attacker) and | |
| 239 | disadvantages (less bits to predict for the attacker). Applications | |
| 240 | of HMAC can choose to truncate the output of HMAC by outputting the t | |
| 241 | leftmost bits of the HMAC computation for some parameter t (namely, | |
| 242 | the computation is carried in the normal way as defined in section 2 | |
| 243 | above but the end result is truncated to t bits). We recommend that | |
| 244 | the output length t be not less than half the length of the hash | |
| 245 | output (to match the birthday attack bound) and not less than 80 bits | |
| 246 | (a suitable lower bound on the number of bits that need to be | |
| 247 | predicted by an attacker). We propose denoting a realization of HMAC | |
| 248 | that uses a hash function H with t bits of output as HMAC-H-t. For | |
| 249 | example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function | |
| 250 | and with the output truncated to 80 bits. (If the parameter t is not | |
| 251 | specified, e.g. HMAC-MD5, then it is assumed that all the bits of the | |
| 252 | hash are output.) | |
| 253 | ||
| 254 | 6. Security | |
| 255 | ||
| 256 | The security of the message authentication mechanism presented here | |
| 257 | depends on cryptographic properties of the hash function H: the | |
| 258 | resistance to collision finding (limited to the case where the | |
| 259 | initial value is secret and random, and where the output of the | |
| 260 | function is not explicitly available to the attacker), and the | |
| 261 | message authentication property of the compression function of H when | |
| 262 | applied to single blocks (in HMAC these blocks are partially unknown | |
| 263 | to an attacker as they contain the result of the inner H computation | |
| 264 | and, in particular, cannot be fully chosen by the attacker). | |
| 265 | ||
| 266 | These properties, and actually stronger ones, are commonly assumed | |
| 267 | for hash functions of the kind used with HMAC. In particular, a hash | |
| 268 | function for which the above properties do not hold would become | |
| 269 | unsuitable for most (probably, all) cryptographic applications, | |
| 270 | including alternative message authentication schemes based on such | |
| 271 | functions. (For a complete analysis and rationale of the HMAC | |
| 272 | function the reader is referred to [BCK1].) | |
| 273 | ||
| 274 | ||
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Krawczyk, et. al. Informational [Page 5] | |
| 282 | ||
| 283 | RFC 2104 HMAC February 1997 | |
| 284 | ||
| 285 | ||
| 286 | Given the limited confidence gained so far as for the cryptographic | |
| 287 | strength of candidate hash functions, it is important to observe the | |
| 288 | following two properties of the HMAC construction and its secure use | |
| 289 | for message authentication: | |
| 290 | ||
| 291 | 1. The construction is independent of the details of the particular | |
| 292 | hash function H in use and then the latter can be replaced by any | |
| 293 | other secure (iterative) cryptographic hash function. | |
| 294 | ||
| 295 | 2. Message authentication, as opposed to encryption, has a | |
| 296 | "transient" effect. A published breaking of a message authentication | |
| 297 | scheme would lead to the replacement of that scheme, but would have | |
| 298 | no adversarial effect on information authenticated in the past. This | |
| 299 | is in sharp contrast with encryption, where information encrypted | |
| 300 | today may suffer from exposure in the future if, and when, the | |
| 301 | encryption algorithm is broken. | |
| 302 | ||
| 303 | The strongest attack known against HMAC is based on the frequency of | |
| 304 | collisions for the hash function H ("birthday attack") [PV,BCK2], and | |
| 305 | is totally impractical for minimally reasonable hash functions. | |
| 306 | ||
| 307 | As an example, if we consider a hash function like MD5 where the | |
| 308 | output length equals L=16 bytes (128 bits) the attacker needs to | |
| 309 | acquire the correct message authentication tags computed (with the | |
| 310 | _same_ secret key K!) on about 2**64 known plaintexts. This would | |
| 311 | require the processing of at least 2**64 blocks under H, an | |
| 312 | impossible task in any realistic scenario (for a block length of 64 | |
| 313 | bytes this would take 250,000 years in a continuous 1Gbps link, and | |
| 314 | without changing the secret key K during all this time). This attack | |
| 315 | could become realistic only if serious flaws in the collision | |
| 316 | behavior of the function H are discovered (e.g. collisions found | |
| 317 | after 2**30 messages). Such a discovery would determine the immediate | |
| 318 | replacement of the function H (the effects of such failure would be | |
| 319 | far more severe for the traditional uses of H in the context of | |
| 320 | digital signatures, public key certificates, etc.). | |
| 321 | ||
| 322 | Note: this attack needs to be strongly contrasted with regular | |
| 323 | collision attacks on cryptographic hash functions where no secret key | |
| 324 | is involved and where 2**64 off-line parallelizable (!) operations | |
| 325 | suffice to find collisions. The latter attack is approaching | |
| 326 | feasibility [VW] while the birthday attack on HMAC is totally | |
| 327 | impractical. (In the above examples, if one uses a hash function | |
| 328 | with, say, 160 bit of output then 2**64 should be replaced by 2**80.) | |
| 329 | ||
| 330 | ||
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Krawczyk, et. al. Informational [Page 6] | |
| 338 | ||
| 339 | RFC 2104 HMAC February 1997 | |
| 340 | ||
| 341 | ||
| 342 | A correct implementation of the above construction, the choice of | |
| 343 | random (or cryptographically pseudorandom) keys, a secure key | |
| 344 | exchange mechanism, frequent key refreshments, and good secrecy | |
| 345 | protection of keys are all essential ingredients for the security of | |
| 346 | the integrity verification mechanism provided by HMAC. | |
| 347 | ||
| 348 | ||
| 349 | ||
| 350 | ||
| 351 | ||
| 352 | ||
| 353 | ||
| 354 | ||
| 355 | ||
| 356 | ||
| 357 | ||
| 358 | ||
| 359 | ||
| 360 | ||
| 361 | ||
| 362 | ||
| 363 | ||
| 364 | ||
| 365 | ||
| 366 | ||
| 367 | ||
| 368 | ||
| 369 | ||
| 370 | ||
| 371 | ||
| 372 | ||
| 373 | ||
| 374 | ||
| 375 | ||
| 376 | ||
| 377 | ||
| 378 | ||
| 379 | ||
| 380 | ||
| 381 | ||
| 382 | ||
| 383 | ||
| 384 | ||
| 385 | ||
| 386 | ||
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Krawczyk, et. al. Informational [Page 7] | |
| 394 | ||
| 395 | RFC 2104 HMAC February 1997 | |
| 396 | ||
| 397 | ||
| 398 | Appendix -- Sample Code | |
| 399 | ||
| 400 | For the sake of illustration we provide the following sample code for | |
| 401 | the implementation of HMAC-MD5 as well as some corresponding test | |
| 402 | vectors (the code is based on MD5 code as described in [MD5]). | |
| 403 | ||
| 404 | /* | |
| 405 | ** Function: hmac_md5 | |
| 406 | */ | |
| 407 | ||
| 408 | void | |
| 409 | hmac_md5(text, text_len, key, key_len, digest) | |
| 410 | unsigned char* text; /* pointer to data stream */ | |
| 411 | int text_len; /* length of data stream */ | |
| 412 | unsigned char* key; /* pointer to authentication key */ | |
| 413 | int key_len; /* length of authentication key */ | |
| 414 | caddr_t digest; /* caller digest to be filled in */ | |
| 415 | ||
| 416 | { | |
| 417 | MD5_CTX context; | |
| 418 | unsigned char k_ipad[65]; /* inner padding - | |
| 419 | * key XORd with ipad | |
| 420 | */ | |
| 421 | unsigned char k_opad[65]; /* outer padding - | |
| 422 | * key XORd with opad | |
| 423 | */ | |
| 424 | unsigned char tk[16]; | |
| 425 | int i; | |
| 426 | /* if key is longer than 64 bytes reset it to key=MD5(key) */ | |
| 427 | if (key_len > 64) { | |
| 428 | ||
| 429 | MD5_CTX tctx; | |
| 430 | ||
| 431 | MD5Init(&tctx); | |
| 432 | MD5Update(&tctx, key, key_len); | |
| 433 | MD5Final(tk, &tctx); | |
| 434 | ||
| 435 | key = tk; | |
| 436 | key_len = 16; | |
| 437 | } | |
| 438 | ||
| 439 | /* | |
| 440 | * the HMAC_MD5 transform looks like: | |
| 441 | * | |
| 442 | * MD5(K XOR opad, MD5(K XOR ipad, text)) | |
| 443 | * | |
| 444 | * where K is an n byte key | |
| 445 | * ipad is the byte 0x36 repeated 64 times | |
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Krawczyk, et. al. Informational [Page 8] | |
| 450 | ||
| 451 | RFC 2104 HMAC February 1997 | |
| 452 | ||
| 453 | ||
| 454 | * opad is the byte 0x5c repeated 64 times | |
| 455 | * and text is the data being protected | |
| 456 | */ | |
| 457 | ||
| 458 | /* start out by storing key in pads */ | |
| 459 | bzero( k_ipad, sizeof k_ipad); | |
| 460 | bzero( k_opad, sizeof k_opad); | |
| 461 | bcopy( key, k_ipad, key_len); | |
| 462 | bcopy( key, k_opad, key_len); | |
| 463 | ||
| 464 | /* XOR key with ipad and opad values */ | |
| 465 | for (i=0; i<64; i++) { | |
| 466 | k_ipad[i] ^= 0x36; | |
| 467 | k_opad[i] ^= 0x5c; | |
| 468 | } | |
| 469 | /* | |
| 470 | * perform inner MD5 | |
| 471 | */ | |
| 472 | MD5Init(&context); /* init context for 1st | |
| 473 | * pass */ | |
| 474 | MD5Update(&context, k_ipad, 64) /* start with inner pad */ | |
| 475 | MD5Update(&context, text, text_len); /* then text of datagram */ | |
| 476 | MD5Final(digest, &context); /* finish up 1st pass */ | |
| 477 | /* | |
| 478 | * perform outer MD5 | |
| 479 | */ | |
| 480 | MD5Init(&context); /* init context for 2nd | |
| 481 | * pass */ | |
| 482 | MD5Update(&context, k_opad, 64); /* start with outer pad */ | |
| 483 | MD5Update(&context, digest, 16); /* then results of 1st | |
| 484 | * hash */ | |
| 485 | MD5Final(digest, &context); /* finish up 2nd pass */ | |
| 486 | } | |
| 487 | ||
| 488 | Test Vectors (Trailing '\0' of a character string not included in test): | |
| 489 | ||
| 490 | key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b | |
| 491 | key_len = 16 bytes | |
| 492 | data = "Hi There" | |
| 493 | data_len = 8 bytes | |
| 494 | digest = 0x9294727a3638bb1c13f48ef8158bfc9d | |
| 495 | ||
| 496 | key = "Jefe" | |
| 497 | data = "what do ya want for nothing?" | |
| 498 | data_len = 28 bytes | |
| 499 | digest = 0x750c783e6ab0b503eaa86e310a5db738 | |
| 500 | ||
| 501 | key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | |
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Krawczyk, et. al. Informational [Page 9] | |
| 506 | ||
| 507 | RFC 2104 HMAC February 1997 | |
| 508 | ||
| 509 | ||
| 510 | key_len 16 bytes | |
| 511 | data = 0xDDDDDDDDDDDDDDDDDDDD... | |
| 512 | ..DDDDDDDDDDDDDDDDDDDD... | |
| 513 | ..DDDDDDDDDDDDDDDDDDDD... | |
| 514 | ..DDDDDDDDDDDDDDDDDDDD... | |
| 515 | ..DDDDDDDDDDDDDDDDDDDD | |
| 516 | data_len = 50 bytes | |
| 517 | digest = 0x56be34521d144c88dbb8c733f0e8b3f6 | |
| 518 | ||
| 519 | Acknowledgments | |
| 520 | ||
| 521 | Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided | |
| 522 | useful comments on early drafts, and ran the first interoperability | |
| 523 | tests of this specification. Jeff and Pau-Chen kindly provided the | |
| 524 | sample code and test vectors that appear in the appendix. Burt | |
| 525 | Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van | |
| 526 | Oorschot have provided useful comments and suggestions during the | |
| 527 | investigation of the HMAC construction. | |
| 528 | ||
| 529 | References | |
| 530 | ||
| 531 | [ANSI] ANSI X9.9, "American National Standard for Financial | |
| 532 | Institution Message Authentication (Wholesale)," American | |
| 533 | Bankers Association, 1981. Revised 1986. | |
| 534 | ||
| 535 | [Atk] Atkinson, R., "IP Authentication Header", RFC 1826, August | |
| 536 | 1995. | |
| 537 | ||
| 538 | [BCK1] M. Bellare, R. Canetti, and H. Krawczyk, | |
| 539 | "Keyed Hash Functions and Message Authentication", | |
| 540 | Proceedings of Crypto'96, LNCS 1109, pp. 1-15. | |
| 541 | (http://www.research.ibm.com/security/keyed-md5.html) | |
| 542 | ||
| 543 | [BCK2] M. Bellare, R. Canetti, and H. Krawczyk, | |
| 544 | "Pseudorandom Functions Revisited: The Cascade Construction", | |
| 545 | Proceedings of FOCS'96. | |
| 546 | ||
| 547 | [Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", | |
| 548 | RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. | |
| 549 | http://www.rsa.com/rsalabs/pubs/cryptobytes.html | |
| 550 | ||
| 551 | [PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash | |
| 552 | functions", Advances in Cryptology -- CRYPTO'95 Proceedings, | |
| 553 | Lecture Notes in Computer Science, Springer-Verlag Vol.963, | |
| 554 | 1995, pp. 1-14. | |
| 555 | ||
| 556 | [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", | |
| 557 | RFC 1321, April 1992. | |
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Krawczyk, et. al. Informational [Page 10] | |
| 562 | ||
| 563 | RFC 2104 HMAC February 1997 | |
| 564 | ||
| 565 | ||
| 566 | [MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, | |
| 567 | 1982. | |
| 568 | ||
| 569 | [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A | |
| 570 | strengthened version of RIPEMD", Fast Software Encryption, | |
| 571 | LNCS Vol 1039, pp. 71-82. | |
| 572 | ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/. | |
| 573 | ||
| 574 | [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. | |
| 575 | ||
| 576 | [Tsu] G. Tsudik, "Message authentication with one-way hash | |
| 577 | functions", In Proceedings of Infocom'92, May 1992. | |
| 578 | (Also in "Access Control and Policy Enforcement in | |
| 579 | Internetworks", Ph.D. Dissertation, Computer Science | |
| 580 | Department, University of Southern California, April 1991.) | |
| 581 | ||
| 582 | [VW] P. van Oorschot and M. Wiener, "Parallel Collision | |
| 583 | Search with Applications to Hash Functions and Discrete | |
| 584 | Logarithms", Proceedings of the 2nd ACM Conf. Computer and | |
| 585 | Communications Security, Fairfax, VA, November 1994. | |
| 586 | ||
| 587 | Authors' Addresses | |
| 588 | ||
| 589 | Hugo Krawczyk | |
| 590 | IBM T.J. Watson Research Center | |
| 591 | P.O.Box 704 | |
| 592 | Yorktown Heights, NY 10598 | |
| 593 | ||
| 594 | EMail: hugo@watson.ibm.com | |
| 595 | ||
| 596 | Mihir Bellare | |
| 597 | Dept of Computer Science and Engineering | |
| 598 | Mail Code 0114 | |
| 599 | University of California at San Diego | |
| 600 | 9500 Gilman Drive | |
| 601 | La Jolla, CA 92093 | |
| 602 | ||
| 603 | EMail: mihir@cs.ucsd.edu | |
| 604 | ||
| 605 | Ran Canetti | |
| 606 | IBM T.J. Watson Research Center | |
| 607 | P.O.Box 704 | |
| 608 | Yorktown Heights, NY 10598 | |
| 609 | ||
| 610 | EMail: canetti@watson.ibm.com | |
| 611 | ||
| 612 | ||
| 613 | ||
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | Krawczyk, et. al. Informational [Page 11] | |
| 618 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group J. Klensin | |
| 7 | Request for Comments: 2195 R. Catoe | |
| 8 | Category: Standards Track P. Krumviede | |
| 9 | Obsoletes: 2095 MCI | |
| 10 | September 1997 | |
| 11 | ||
| 12 | ||
| 13 | IMAP/POP AUTHorize Extension for Simple Challenge/Response | |
| 14 | ||
| 15 | Status of this Memo | |
| 16 | ||
| 17 | This document specifies an Internet standards track protocol for the | |
| 18 | Internet community, and requests discussion and suggestions for | |
| 19 | improvements. Please refer to the current edition of the "Internet | |
| 20 | Official Protocol Standards" (STD 1) for the standardization state | |
| 21 | and status of this protocol. Distribution of this memo is unlimited. | |
| 22 | ||
| 23 | Abstract | |
| 24 | ||
| 25 | While IMAP4 supports a number of strong authentication mechanisms as | |
| 26 | described in RFC 1731, it lacks any mechanism that neither passes | |
| 27 | cleartext, reusable passwords across the network nor requires either | |
| 28 | a significant security infrastructure or that the mail server update | |
| 29 | a mail-system-wide user authentication file on each mail access. | |
| 30 | This specification provides a simple challenge-response | |
| 31 | authentication protocol that is suitable for use with IMAP4. Since | |
| 32 | it utilizes Keyed-MD5 digests and does not require that the secret be | |
| 33 | stored in the clear on the server, it may also constitute an | |
| 34 | improvement on APOP for POP3 use as specified in RFC 1734. | |
| 35 | ||
| 36 | 1. Introduction | |
| 37 | ||
| 38 | Existing Proposed Standards specify an AUTHENTICATE mechanism for the | |
| 39 | IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for | |
| 40 | the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is | |
| 41 | intended to be extensible; the four methods specified in [IMAP-AUTH] | |
| 42 | are all fairly powerful and require some security infrastructure to | |
| 43 | support. The base POP3 specification [POP3] also contains a | |
| 44 | lightweight challenge-response mechanism called APOP. APOP is | |
| 45 | associated with most of the risks associated with such protocols: in | |
| 46 | particular, it requires that both the client and server machines have | |
| 47 | access to the shared secret in cleartext form. CRAM offers a method | |
| 48 | for avoiding such cleartext storage while retaining the algorithmic | |
| 49 | simplicity of APOP in using only MD5, though in a "keyed" method. | |
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Klensin, Catoe & Krumviede Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 2195 IMAP/POP AUTHorize Extension September 1997 | |
| 60 | ||
| 61 | ||
| 62 | At present, IMAP [IMAP] lacks any facility corresponding to APOP. | |
| 63 | The only alternative to the strong mechanisms identified in [IMAP- | |
| 64 | AUTH] is a presumably cleartext username and password, supported | |
| 65 | through the LOGIN command in [IMAP]. This document describes a | |
| 66 | simple challenge-response mechanism, similar to APOP and PPP CHAP | |
| 67 | [PPP], that can be used with IMAP (and, in principle, with POP3). | |
| 68 | ||
| 69 | This mechanism also has the advantage over some possible alternatives | |
| 70 | of not requiring that the server maintain information about email | |
| 71 | "logins" on a per-login basis. While mechanisms that do require such | |
| 72 | per-login history records may offer enhanced security, protocols such | |
| 73 | as IMAP, which may have several connections between a given client | |
| 74 | and server open more or less simultaneous, may make their | |
| 75 | implementation particularly challenging. | |
| 76 | ||
| 77 | 2. Challenge-Response Authentication Mechanism (CRAM) | |
| 78 | ||
| 79 | The authentication type associated with CRAM is "CRAM-MD5". | |
| 80 | ||
| 81 | The data encoded in the first ready response contains an | |
| 82 | presumptively arbitrary string of random digits, a timestamp, and the | |
| 83 | fully-qualified primary host name of the server. The syntax of the | |
| 84 | unencoded form must correspond to that of an RFC 822 'msg-id' | |
| 85 | [RFC822] as described in [POP3]. | |
| 86 | ||
| 87 | The client makes note of the data and then responds with a string | |
| 88 | consisting of the user name, a space, and a 'digest'. The latter is | |
| 89 | computed by applying the keyed MD5 algorithm from [KEYED-MD5] where | |
| 90 | the key is a shared secret and the digested text is the timestamp | |
| 91 | (including angle-brackets). | |
| 92 | ||
| 93 | This shared secret is a string known only to the client and server. | |
| 94 | The `digest' parameter itself is a 16-octet value which is sent in | |
| 95 | hexadecimal format, using lower-case ASCII characters. | |
| 96 | ||
| 97 | When the server receives this client response, it verifies the digest | |
| 98 | provided. If the digest is correct, the server should consider the | |
| 99 | client authenticated and respond appropriately. | |
| 100 | ||
| 101 | Keyed MD5 is chosen for this application because of the greater | |
| 102 | security imparted to authentication of short messages. In addition, | |
| 103 | the use of the techniques described in [KEYED-MD5] for precomputation | |
| 104 | of intermediate results make it possible to avoid explicit cleartext | |
| 105 | storage of the shared secret on the server system by instead storing | |
| 106 | the intermediate results which are known as "contexts". | |
| 107 | ||
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Klensin, Catoe & Krumviede Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 2195 IMAP/POP AUTHorize Extension September 1997 | |
| 116 | ||
| 117 | ||
| 118 | CRAM does not support a protection mechanism. | |
| 119 | ||
| 120 | Example: | |
| 121 | ||
| 122 | The examples in this document show the use of the CRAM mechanism with | |
| 123 | the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of | |
| 124 | the challenges and responses is part of the IMAP4 AUTHENTICATE | |
| 125 | command, not part of the CRAM specification itself. | |
| 126 | ||
| 127 | S: * OK IMAP4 Server | |
| 128 | C: A0001 AUTHENTICATE CRAM-MD5 | |
| 129 | S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ | |
| 130 | C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw | |
| 131 | S: A0001 OK CRAM authentication successful | |
| 132 | ||
| 133 | In this example, the shared secret is the string | |
| 134 | 'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by | |
| 135 | calculating | |
| 136 | ||
| 137 | MD5((tanstaaftanstaaf XOR opad), | |
| 138 | MD5((tanstaaftanstaaf XOR ipad), | |
| 139 | <1896.697170952@postoffice.reston.mci.net>)) | |
| 140 | ||
| 141 | where ipad and opad are as defined in the keyed-MD5 Work in | |
| 142 | Progress [KEYED-MD5] and the string shown in the challenge is the | |
| 143 | base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The | |
| 144 | shared secret is null-padded to a length of 64 bytes. If the | |
| 145 | shared secret is longer than 64 bytes, the MD5 digest of the | |
| 146 | shared secret is used as a 16 byte input to the keyed MD5 | |
| 147 | calculation. | |
| 148 | ||
| 149 | This produces a digest value (in hexadecimal) of | |
| 150 | ||
| 151 | b913a602c7eda7a495b4e6e7334d3890 | |
| 152 | ||
| 153 | The user name is then prepended to it, forming | |
| 154 | ||
| 155 | tim b913a602c7eda7a495b4e6e7334d3890 | |
| 156 | ||
| 157 | Which is then base64 encoded to meet the requirements of the IMAP4 | |
| 158 | AUTHENTICATE command (or the similar POP3 AUTH command), yielding | |
| 159 | ||
| 160 | dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw | |
| 161 | ||
| 162 | ||
| 163 | ||
| 164 | ||
| 165 | ||
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Klensin, Catoe & Krumviede Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 2195 IMAP/POP AUTHorize Extension September 1997 | |
| 172 | ||
| 173 | ||
| 174 | 3. References | |
| 175 | ||
| 176 | [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", | |
| 177 | RFC 1334, October 1992. | |
| 178 | ||
| 179 | [IMAP] Crispin, M., "Internet Message Access Protocol - Version | |
| 180 | 4rev1", RFC 2060, University of Washington, December 1996. | |
| 181 | ||
| 182 | [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", | |
| 183 | RFC 1731, Carnegie Mellon, December 1994. | |
| 184 | ||
| 185 | [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for | |
| 186 | Message Authentication", RFC 2104, February 1997. | |
| 187 | ||
| 188 | [MD5] Rivest, R., "The MD5 Message Digest Algorithm", | |
| 189 | RFC 1321, MIT Laboratory for Computer Science, April 1992. | |
| 190 | ||
| 191 | [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3", | |
| 192 | STD 53, RFC 1939, Carnegie Mellon, May 1996. | |
| 193 | ||
| 194 | [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, | |
| 195 | Carnegie Mellon, December, 1994. | |
| 196 | ||
| 197 | 4. Security Considerations | |
| 198 | ||
| 199 | It is conjectured that use of the CRAM authentication mechanism | |
| 200 | provides origin identification and replay protection for a session. | |
| 201 | Accordingly, a server that implements both a cleartext password | |
| 202 | command and this authentication type should not allow both methods of | |
| 203 | access for a given user. | |
| 204 | ||
| 205 | While the saving, on the server, of "contexts" (see section 2) is | |
| 206 | marginally better than saving the shared secrets in cleartext as is | |
| 207 | required by CHAP [CHAP] and APOP [POP3], it is not sufficient to | |
| 208 | protect the secrets if the server itself is compromised. | |
| 209 | Consequently, servers that store the secrets or contexts must both be | |
| 210 | protected to a level appropriate to the potential information value | |
| 211 | in user mailboxes and identities. | |
| 212 | ||
| 213 | As the length of the shared secret increases, so does the difficulty | |
| 214 | of deriving it. | |
| 215 | ||
| 216 | While there are now suggestions in the literature that the use of MD5 | |
| 217 | and keyed MD5 in authentication procedures probably has a limited | |
| 218 | effective lifetime, the technique is now widely deployed and widely | |
| 219 | understood. It is believed that this general understanding may | |
| 220 | assist with the rapid replacement, by CRAM-MD5, of the current uses | |
| 221 | of permanent cleartext passwords in IMAP. This document has been | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Klensin, Catoe & Krumviede Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 2195 IMAP/POP AUTHorize Extension September 1997 | |
| 228 | ||
| 229 | ||
| 230 | deliberately written to permit easy upgrading to use SHA (or whatever | |
| 231 | alternatives emerge) when they are considered to be widely available | |
| 232 | and adequately safe. | |
| 233 | ||
| 234 | Even with the use of CRAM, users are still vulnerable to active | |
| 235 | attacks. An example of an increasingly common active attack is 'TCP | |
| 236 | Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95]. | |
| 237 | ||
| 238 | See section 1 above for additional discussion. | |
| 239 | ||
| 240 | 5. Acknowledgements | |
| 241 | ||
| 242 | This memo borrows ideas and some text liberally from [POP3] and | |
| 243 | [RFC-1731] and thanks are due the authors of those documents. Ran | |
| 244 | Atkinson made a number of valuable technical and editorial | |
| 245 | contributions to the document. | |
| 246 | ||
| 247 | 6. Authors' Addresses | |
| 248 | ||
| 249 | John C. Klensin | |
| 250 | MCI Telecommunications | |
| 251 | 800 Boylston St, 7th floor | |
| 252 | Boston, MA 02199 | |
| 253 | USA | |
| 254 | ||
| 255 | EMail: klensin@mci.net | |
| 256 | Phone: +1 617 960 1011 | |
| 257 | ||
| 258 | Randy Catoe | |
| 259 | MCI Telecommunications | |
| 260 | 2100 Reston Parkway | |
| 261 | Reston, VA 22091 | |
| 262 | USA | |
| 263 | ||
| 264 | EMail: randy@mci.net | |
| 265 | Phone: +1 703 715 7366 | |
| 266 | ||
| 267 | Paul Krumviede | |
| 268 | MCI Telecommunications | |
| 269 | 2100 Reston Parkway | |
| 270 | Reston, VA 22091 | |
| 271 | USA | |
| 272 | ||
| 273 | EMail: paul@mci.net | |
| 274 | Phone: +1 703 715 7251 | |
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Klensin, Catoe & Krumviede Standards Track [Page 5] | |
| 282 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group J. Myers | |
| 7 | Request for Comments: 2222 Netscape Communications | |
| 8 | Category: Standards Track October 1997 | |
| 9 | ||
| 10 | ||
| 11 | Simple Authentication and Security Layer (SASL) | |
| 12 | ||
| 13 | Status of this Memo | |
| 14 | ||
| 15 | This document specifies an Internet standards track protocol for the | |
| 16 | Internet community, and requests discussion and suggestions for | |
| 17 | improvements. Please refer to the current edition of the "Internet | |
| 18 | Official Protocol Standards" (STD 1) for the standardization state | |
| 19 | and status of this protocol. Distribution of this memo is unlimited. | |
| 20 | ||
| 21 | Copyright Notice | |
| 22 | ||
| 23 | Copyright (C) The Internet Society (1997). All Rights Reserved. | |
| 24 | ||
| 25 | Table of Contents | |
| 26 | ||
| 27 | 1. Abstract .............................................. 2 | |
| 28 | 2. Organization of this Document ......................... 2 | |
| 29 | 2.1. How to Read This Document ............................. 2 | |
| 30 | 2.2. Conventions Used in this Document ..................... 2 | |
| 31 | 2.3. Examples .............................................. 3 | |
| 32 | 3. Introduction and Overview ............................. 3 | |
| 33 | 4. Profiling requirements ................................ 4 | |
| 34 | 5. Specific issues ....................................... 5 | |
| 35 | 5.1. Client sends data first ............................... 5 | |
| 36 | 5.2. Server returns success with additional data ........... 5 | |
| 37 | 5.3. Multiple authentications .............................. 5 | |
| 38 | 6. Registration procedures ............................... 6 | |
| 39 | 6.1. Comments on SASL mechanism registrations .............. 6 | |
| 40 | 6.2. Location of Registered SASL Mechanism List ............ 6 | |
| 41 | 6.3. Change Control ........................................ 7 | |
| 42 | 6.4. Registration Template ................................. 7 | |
| 43 | 7. Mechanism definitions ................................. 8 | |
| 44 | 7.1. Kerberos version 4 mechanism .......................... 8 | |
| 45 | 7.2. GSSAPI mechanism ...................................... 9 | |
| 46 | 7.2.1 Client side of authentication protocol exchange ....... 9 | |
| 47 | 7.2.2 Server side of authentication protocol exchange ....... 10 | |
| 48 | 7.2.3 Security layer ........................................ 11 | |
| 49 | 7.3. S/Key mechanism ....................................... 11 | |
| 50 | 7.4. External mechanism .................................... 12 | |
| 51 | 8. References ............................................ 13 | |
| 52 | 9. Security Considerations ............................... 13 | |
| 53 | 10. Author's Address ...................................... 14 | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Myers Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 2222 SASL October 1997 | |
| 60 | ||
| 61 | ||
| 62 | Appendix A. Relation of SASL to Transport Security .......... 15 | |
| 63 | Full Copyright Statement .................................... 16 | |
| 64 | ||
| 65 | 1. Abstract | |
| 66 | ||
| 67 | This document describes a method for adding authentication support to | |
| 68 | connection-based protocols. To use this specification, a protocol | |
| 69 | includes a command for identifying and authenticating a user to a | |
| 70 | server and for optionally negotiating protection of subsequent | |
| 71 | protocol interactions. If its use is negotiated, a security layer is | |
| 72 | inserted between the protocol and the connection. This document | |
| 73 | describes how a protocol specifies such a command, defines several | |
| 74 | mechanisms for use by the command, and defines the protocol used for | |
| 75 | carrying a negotiated security layer over the connection. | |
| 76 | ||
| 77 | 2. Organization of this Document | |
| 78 | ||
| 79 | 2.1. How to Read This Document | |
| 80 | ||
| 81 | This document is written to serve two different audiences, protocol | |
| 82 | designers using this specification to support authentication in their | |
| 83 | protocol, and implementors of clients or servers for those protocols | |
| 84 | using this specification. | |
| 85 | ||
| 86 | The sections "Introduction and Overview", "Profiling requirements", | |
| 87 | and "Security Considerations" cover issues that protocol designers | |
| 88 | need to understand and address in profiling this specification for | |
| 89 | use in a specific protocol. | |
| 90 | ||
| 91 | Implementors of a protocol using this specification need the | |
| 92 | protocol-specific profiling information in addition to the | |
| 93 | information in this document. | |
| 94 | ||
| 95 | 2.2. Conventions Used in this Document | |
| 96 | ||
| 97 | In examples, "C:" and "S:" indicate lines sent by the client and | |
| 98 | server respectively. | |
| 99 | ||
| 100 | The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" | |
| 101 | in this document are to be interpreted as defined in "Key words for | |
| 102 | use in RFCs to Indicate Requirement Levels" [RFC 2119]. | |
| 103 | ||
| 104 | ||
| 105 | ||
| 106 | ||
| 107 | ||
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Myers Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 2222 SASL October 1997 | |
| 116 | ||
| 117 | ||
| 118 | 2.3. Examples | |
| 119 | ||
| 120 | Examples in this document are for the IMAP profile [RFC 2060] of this | |
| 121 | specification. The base64 encoding of challenges and responses, as | |
| 122 | well as the "+ " preceding the responses are part of the IMAP4 | |
| 123 | profile, not part of the SASL specification itself. | |
| 124 | ||
| 125 | 3. Introduction and Overview | |
| 126 | ||
| 127 | The Simple Authentication and Security Layer (SASL) is a method for | |
| 128 | adding authentication support to connection-based protocols. To use | |
| 129 | this specification, a protocol includes a command for identifying and | |
| 130 | authenticating a user to a server and for optionally negotiating a | |
| 131 | security layer for subsequent protocol interactions. | |
| 132 | ||
| 133 | The command has a required argument identifying a SASL mechanism. | |
| 134 | SASL mechanisms are named by strings, from 1 to 20 characters in | |
| 135 | length, consisting of upper-case letters, digits, hyphens, and/or | |
| 136 | underscores. SASL mechanism names must be registered with the IANA. | |
| 137 | Procedures for registering new SASL mechanisms are given in the | |
| 138 | section "Registration procedures" | |
| 139 | ||
| 140 | If a server supports the requested mechanism, it initiates an | |
| 141 | authentication protocol exchange. This consists of a series of | |
| 142 | server challenges and client responses that are specific to the | |
| 143 | requested mechanism. The challenges and responses are defined by the | |
| 144 | mechanisms as binary tokens of arbitrary length. The protocol's | |
| 145 | profile then specifies how these binary tokens are then encoded for | |
| 146 | transfer over the connection. | |
| 147 | ||
| 148 | After receiving the authentication command or any client response, a | |
| 149 | server may issue a challenge, indicate failure, or indicate | |
| 150 | completion. The protocol's profile specifies how the server | |
| 151 | indicates which of the above it is doing. | |
| 152 | ||
| 153 | After receiving a challenge, a client may issue a response or abort | |
| 154 | the exchange. The protocol's profile specifies how the client | |
| 155 | indicates which of the above it is doing. | |
| 156 | ||
| 157 | During the authentication protocol exchange, the mechanism performs | |
| 158 | authentication, transmits an authorization identity (frequently known | |
| 159 | as a userid) from the client to server, and negotiates the use of a | |
| 160 | mechanism-specific security layer. If the use of a security layer is | |
| 161 | agreed upon, then the mechanism must also define or negotiate the | |
| 162 | maximum cipher-text buffer size that each side is able to receive. | |
| 163 | ||
| 164 | ||
| 165 | ||
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Myers Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 2222 SASL October 1997 | |
| 172 | ||
| 173 | ||
| 174 | The transmitted authorization identity may be different than the | |
| 175 | identity in the client's authentication credentials. This permits | |
| 176 | agents such as proxy servers to authenticate using their own | |
| 177 | credentials, yet request the access privileges of the identity for | |
| 178 | which they are proxying. With any mechanism, transmitting an | |
| 179 | authorization identity of the empty string directs the server to | |
| 180 | derive an authorization identity from the client's authentication | |
| 181 | credentials. | |
| 182 | ||
| 183 | If use of a security layer is negotiated, it is applied to all | |
| 184 | subsequent data sent over the connection. The security layer takes | |
| 185 | effect immediately following the last response of the authentication | |
| 186 | exchange for data sent by the client and the completion indication | |
| 187 | for data sent by the server. Once the security layer is in effect, | |
| 188 | the protocol stream is processed by the security layer into buffers | |
| 189 | of cipher-text. Each buffer is transferred over the connection as a | |
| 190 | stream of octets prepended with a four octet field in network byte | |
| 191 | order that represents the length of the following buffer. The length | |
| 192 | of the cipher-text buffer must be no larger than the maximum size | |
| 193 | that was defined or negotiated by the other side. | |
| 194 | ||
| 195 | 4. Profiling requirements | |
| 196 | ||
| 197 | In order to use this specification, a protocol definition must supply | |
| 198 | the following information: | |
| 199 | ||
| 200 | 1. A service name, to be selected from the IANA registry of "service" | |
| 201 | elements for the GSSAPI host-based service name form [RFC 2078]. | |
| 202 | ||
| 203 | 2. A definition of the command to initiate the authentication | |
| 204 | protocol exchange. This command must have as a parameter the | |
| 205 | mechanism name being selected by the client. | |
| 206 | ||
| 207 | The command SHOULD have an optional parameter giving an initial | |
| 208 | response. This optional parameter allows the client to avoid a | |
| 209 | round trip when using a mechanism which is defined to have the | |
| 210 | client send data first. When this initial response is sent by the | |
| 211 | client and the selected mechanism is defined to have the server | |
| 212 | start with an initial challenge, the command fails. See section | |
| 213 | 5.1 of this document for further information. | |
| 214 | ||
| 215 | 3. A definition of the method by which the authentication protocol | |
| 216 | exchange is carried out, including how the challenges and | |
| 217 | responses are encoded, how the server indicates completion or | |
| 218 | failure of the exchange, how the client aborts an exchange, and | |
| 219 | how the exchange method interacts with any line length limits in | |
| 220 | the protocol. | |
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Myers Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 2222 SASL October 1997 | |
| 228 | ||
| 229 | ||
| 230 | 4. Identification of the octet where any negotiated security layer | |
| 231 | starts to take effect, in both directions. | |
| 232 | ||
| 233 | 5. A specification of how the authorization identity passed from the | |
| 234 | client to the server is to be interpreted. | |
| 235 | ||
| 236 | 5. Specific issues | |
| 237 | ||
| 238 | 5.1. Client sends data first | |
| 239 | ||
| 240 | Some mechanisms specify that the first data sent in the | |
| 241 | authentication protocol exchange is from the client to the server. | |
| 242 | ||
| 243 | If a protocol's profile permits the command which initiates an | |
| 244 | authentication protocol exchange to contain an initial client | |
| 245 | response, this parameter SHOULD be used with such mechanisms. | |
| 246 | ||
| 247 | If the initial client response parameter is not given, or if a | |
| 248 | protocol's profile does not permit the command which initiates an | |
| 249 | authentication protocol exchange to contain an initial client | |
| 250 | response, then the server issues a challenge with no data. The | |
| 251 | client's response to this challenge is then used as the initial | |
| 252 | client response. (The server then proceeds to send the next | |
| 253 | challenge, indicates completion, or indicates failure.) | |
| 254 | ||
| 255 | 5.2. Server returns success with additional data | |
| 256 | ||
| 257 | Some mechanisms may specify that server challenge data be sent to the | |
| 258 | client along with an indication of successful completion of the | |
| 259 | exchange. This data would, for example, authenticate the server to | |
| 260 | the client. | |
| 261 | ||
| 262 | If a protocol's profile does not permit this server challenge to be | |
| 263 | returned with a success indication, then the server issues the server | |
| 264 | challenge without an indication of successful completion. The client | |
| 265 | then responds with no data. After receiving this empty response, the | |
| 266 | server then indicates successful completion. | |
| 267 | ||
| 268 | 5.3. Multiple authentications | |
| 269 | ||
| 270 | Unless otherwise stated by the protocol's profile, only one | |
| 271 | successful SASL negotiation may occur in a protocol session. In this | |
| 272 | case, once an authentication protocol exchange has successfully | |
| 273 | completed, further attempts to initiate an authentication protocol | |
| 274 | exchange fail. | |
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Myers Standards Track [Page 5] | |
| 282 | ||
| 283 | RFC 2222 SASL October 1997 | |
| 284 | ||
| 285 | ||
| 286 | In the case that a profile explicitly permits multiple successful | |
| 287 | SASL negotiations to occur, then in no case may multiple security | |
| 288 | layers be simultaneously in effect. If a security layer is in effect | |
| 289 | and a subsequent SASL negotiation selects no security layer, the | |
| 290 | original security layer remains in effect. If a security layer is in | |
| 291 | effect and a subsequent SASL negotiation selects a second security | |
| 292 | layer, then the second security layer replaces the first. | |
| 293 | ||
| 294 | 6. Registration procedures | |
| 295 | ||
| 296 | Registration of a SASL mechanism is done by filling in the template | |
| 297 | in section 6.4 and sending it in to iana@isi.edu. IANA has the right | |
| 298 | to reject obviously bogus registrations, but will perform no review | |
| 299 | of clams made in the registration form. | |
| 300 | ||
| 301 | There is no naming convention for SASL mechanisms; any name that | |
| 302 | conforms to the syntax of a SASL mechanism name can be registered. | |
| 303 | ||
| 304 | While the registration procedures do not require it, authors of SASL | |
| 305 | mechanisms are encouraged to seek community review and comment | |
| 306 | whenever that is feasible. Authors may seek community review by | |
| 307 | posting a specification of their proposed mechanism as an internet- | |
| 308 | draft. SASL mechanisms intended for widespread use should be | |
| 309 | standardized through the normal IETF process, when appropriate. | |
| 310 | ||
| 311 | 6.1. Comments on SASL mechanism registrations | |
| 312 | ||
| 313 | Comments on registered SASL mechanisms should first be sent to the | |
| 314 | "owner" of the mechanism. Submitters of comments may, after a | |
| 315 | reasonable attempt to contact the owner, request IANA to attach their | |
| 316 | comment to the SASL mechanism registration itself. If IANA approves | |
| 317 | of this the comment will be made accessible in conjunction with the | |
| 318 | SASL mechanism registration itself. | |
| 319 | ||
| 320 | 6.2. Location of Registered SASL Mechanism List | |
| 321 | ||
| 322 | SASL mechanism registrations will be posted in the anonymous FTP | |
| 323 | directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- | |
| 324 | mechanisms/" and all registered SASL mechanisms will be listed in the | |
| 325 | periodically issued "Assigned Numbers" RFC [currently STD 2, RFC | |
| 326 | 1700]. The SASL mechanism description and other supporting material | |
| 327 | may also be published as an Informational RFC by sending it to "rfc- | |
| 328 | editor@isi.edu" (please follow the instructions to RFC authors [RFC | |
| 329 | 2223]). | |
| 330 | ||
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Myers Standards Track [Page 6] | |
| 338 | ||
| 339 | RFC 2222 SASL October 1997 | |
| 340 | ||
| 341 | ||
| 342 | 6.3. Change Control | |
| 343 | ||
| 344 | Once a SASL mechanism registration has been published by IANA, the | |
| 345 | author may request a change to its definition. The change request | |
| 346 | follows the same procedure as the registration request. | |
| 347 | ||
| 348 | The owner of a SASL mechanism may pass responsibility for the SASL | |
| 349 | mechanism to another person or agency by informing IANA; this can be | |
| 350 | done without discussion or review. | |
| 351 | ||
| 352 | The IESG may reassign responsibility for a SASL mechanism. The most | |
| 353 | common case of this will be to enable changes to be made to | |
| 354 | mechanisms where the author of the registration has died, moved out | |
| 355 | of contact or is otherwise unable to make changes that are important | |
| 356 | to the community. | |
| 357 | ||
| 358 | SASL mechanism registrations may not be deleted; mechanisms which are | |
| 359 | no longer believed appropriate for use can be declared OBSOLETE by a | |
| 360 | change to their "intended use" field; such SASL mechanisms will be | |
| 361 | clearly marked in the lists published by IANA. | |
| 362 | ||
| 363 | The IESG is considered to be the owner of all SASL mechanisms which | |
| 364 | are on the IETF standards track. | |
| 365 | ||
| 366 | 6.4. Registration Template | |
| 367 | ||
| 368 | To: iana@iana.org | |
| 369 | Subject: Registration of SASL mechanism X | |
| 370 | ||
| 371 | SASL mechanism name: | |
| 372 | ||
| 373 | Security considerations: | |
| 374 | ||
| 375 | Published specification (optional, recommended): | |
| 376 | ||
| 377 | Person & email address to contact for further information: | |
| 378 | ||
| 379 | Intended usage: | |
| 380 | ||
| 381 | (One of COMMON, LIMITED USE or OBSOLETE) | |
| 382 | ||
| 383 | Author/Change controller: | |
| 384 | ||
| 385 | (Any other information that the author deems interesting may be | |
| 386 | added below this line.) | |
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Myers Standards Track [Page 7] | |
| 394 | ||
| 395 | RFC 2222 SASL October 1997 | |
| 396 | ||
| 397 | ||
| 398 | 7. Mechanism definitions | |
| 399 | ||
| 400 | The following mechanisms are hereby defined. | |
| 401 | ||
| 402 | 7.1. Kerberos version 4 mechanism | |
| 403 | ||
| 404 | The mechanism name associated with Kerberos version 4 is | |
| 405 | "KERBEROS_V4". | |
| 406 | ||
| 407 | The first challenge consists of a random 32-bit number in network | |
| 408 | byte order. The client responds with a Kerberos ticket and an | |
| 409 | authenticator for the principal "service.hostname@realm", where | |
| 410 | "service" is the service name specified in the protocol's profile, | |
| 411 | "hostname" is the first component of the host name of the server with | |
| 412 | all letters in lower case, and where "realm" is the Kerberos realm of | |
| 413 | the server. The encrypted checksum field included within the | |
| 414 | Kerberos authenticator contains the server provided challenge in | |
| 415 | network byte order. | |
| 416 | ||
| 417 | Upon decrypting and verifying the ticket and authenticator, the | |
| 418 | server verifies that the contained checksum field equals the original | |
| 419 | server provided random 32-bit number. Should the verification be | |
| 420 | successful, the server must add one to the checksum and construct 8 | |
| 421 | octets of data, with the first four octets containing the incremented | |
| 422 | checksum in network byte order, the fifth octet containing a bit-mask | |
| 423 | specifying the security layers supported by the server, and the sixth | |
| 424 | through eighth octets containing, in network byte order, the maximum | |
| 425 | cipher-text buffer size the server is able to receive. The server | |
| 426 | must encrypt using DES ECB mode the 8 octets of data in the session | |
| 427 | key and issue that encrypted data in a second challenge. The client | |
| 428 | considers the server authenticated if the first four octets of the | |
| 429 | un-encrypted data is equal to one plus the checksum it previously | |
| 430 | sent. | |
| 431 | ||
| 432 | The client must construct data with the first four octets containing | |
| 433 | the original server-issued checksum in network byte order, the fifth | |
| 434 | octet containing the bit-mask specifying the selected security layer, | |
| 435 | the sixth through eighth octets containing in network byte order the | |
| 436 | maximum cipher-text buffer size the client is able to receive, and | |
| 437 | the following octets containing the authorization identity. The | |
| 438 | client must then append from one to eight zero-valued octets so that | |
| 439 | the length of the data is a multiple of eight octets. The client must | |
| 440 | then encrypt using DES PCBC mode the data with the session key and | |
| 441 | respond with the encrypted data. The server decrypts the data and | |
| 442 | verifies the contained checksum. The server must verify that the | |
| 443 | principal identified in the Kerberos ticket is authorized to connect | |
| 444 | as that authorization identity. After this verification, the | |
| 445 | authentication process is complete. | |
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Myers Standards Track [Page 8] | |
| 450 | ||
| 451 | RFC 2222 SASL October 1997 | |
| 452 | ||
| 453 | ||
| 454 | The security layers and their corresponding bit-masks are as follows: | |
| 455 | ||
| 456 | 1 No security layer | |
| 457 | 2 Integrity (krb_mk_safe) protection | |
| 458 | 4 Privacy (krb_mk_priv) protection | |
| 459 | ||
| 460 | Other bit-masks may be defined in the future; bits which are not | |
| 461 | understood must be negotiated off. | |
| 462 | ||
| 463 | EXAMPLE: The following are two Kerberos version 4 login scenarios to | |
| 464 | the IMAP4 protocol (note that the line breaks in the sample | |
| 465 | authenticators are for editorial clarity and are not in real | |
| 466 | authenticators) | |
| 467 | ||
| 468 | S: * OK IMAP4 Server | |
| 469 | C: A001 AUTHENTICATE KERBEROS_V4 | |
| 470 | S: + AmFYig== | |
| 471 | C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT | |
| 472 | +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd | |
| 473 | WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh | |
| 474 | S: + or//EoAADZI= | |
| 475 | C: DiAF5A4gA+oOIALuBkAAmw== | |
| 476 | S: A001 OK Kerberos V4 authentication successful | |
| 477 | ||
| 478 | ||
| 479 | S: * OK IMAP4 Server | |
| 480 | C: A001 AUTHENTICATE KERBEROS_V4 | |
| 481 | S: + gcfgCA== | |
| 482 | C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT | |
| 483 | +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd | |
| 484 | WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh | |
| 485 | S: A001 NO Kerberos V4 authentication failed | |
| 486 | ||
| 487 | 7.2. GSSAPI mechanism | |
| 488 | ||
| 489 | The mechanism name associated with all mechanisms employing the | |
| 490 | GSSAPI [RFC 2078] is "GSSAPI". | |
| 491 | ||
| 492 | 7.2.1 Client side of authentication protocol exchange | |
| 493 | ||
| 494 | The client calls GSS_Init_sec_context, passing in 0 for | |
| 495 | input_context_handle (initially) and a targ_name equal to output_name | |
| 496 | from GSS_Import_Name called with input_name_type of | |
| 497 | GSS_C_NT_HOSTBASED_SERVICE and input_name_string of | |
| 498 | "service@hostname" where "service" is the service name specified in | |
| 499 | the protocol's profile, and "hostname" is the fully qualified host | |
| 500 | name of the server. The client then responds with the resulting | |
| 501 | output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, | |
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Myers Standards Track [Page 9] | |
| 506 | ||
| 507 | RFC 2222 SASL October 1997 | |
| 508 | ||
| 509 | ||
| 510 | then the client should expect the server to issue a token in a | |
| 511 | subsequent challenge. The client must pass the token to another call | |
| 512 | to GSS_Init_sec_context, repeating the actions in this paragraph. | |
| 513 | ||
| 514 | When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes | |
| 515 | the following actions: If the last call to GSS_Init_sec_context | |
| 516 | returned an output_token, then the client responds with the | |
| 517 | output_token, otherwise the client responds with no data. The client | |
| 518 | should then expect the server to issue a token in a subsequent | |
| 519 | challenge. The client passes this token to GSS_Unwrap and interprets | |
| 520 | the first octet of resulting cleartext as a bit-mask specifying the | |
| 521 | security layers supported by the server and the second through fourth | |
| 522 | octets as the maximum size output_message to send to the server. The | |
| 523 | client then constructs data, with the first octet containing the | |
| 524 | bit-mask specifying the selected security layer, the second through | |
| 525 | fourth octets containing in network byte order the maximum size | |
| 526 | output_message the client is able to receive, and the remaining | |
| 527 | octets containing the authorization identity. The client passes the | |
| 528 | data to GSS_Wrap with conf_flag set to FALSE, and responds with the | |
| 529 | generated output_message. The client can then consider the server | |
| 530 | authenticated. | |
| 531 | ||
| 532 | 7.2.2 Server side of authentication protocol exchange | |
| 533 | ||
| 534 | The server passes the initial client response to | |
| 535 | GSS_Accept_sec_context as input_token, setting input_context_handle | |
| 536 | to 0 (initially). If GSS_Accept_sec_context returns | |
| 537 | GSS_S_CONTINUE_NEEDED, the server returns the generated output_token | |
| 538 | to the client in challenge and passes the resulting response to | |
| 539 | another call to GSS_Accept_sec_context, repeating the actions in this | |
| 540 | paragraph. | |
| 541 | ||
| 542 | When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes | |
| 543 | the following actions: If the last call to GSS_Accept_sec_context | |
| 544 | returned an output_token, the server returns it to the client in a | |
| 545 | challenge and expects a reply from the client with no data. Whether | |
| 546 | or not an output_token was returned (and after receipt of any | |
| 547 | response from the client to such an output_token), the server then | |
| 548 | constructs 4 octets of data, with the first octet containing a bit- | |
| 549 | mask specifying the security layers supported by the server and the | |
| 550 | second through fourth octets containing in network byte order the | |
| 551 | maximum size output_token the server is able to receive. The server | |
| 552 | must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE | |
| 553 | and issue the generated output_message to the client in a challenge. | |
| 554 | The server must then pass the resulting response to GSS_Unwrap and | |
| 555 | interpret the first octet of resulting cleartext as the bit-mask for | |
| 556 | the selected security layer, the second through fourth octets as the | |
| 557 | maximum size output_message to send to the client, and the remaining | |
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Myers Standards Track [Page 10] | |
| 562 | ||
| 563 | RFC 2222 SASL October 1997 | |
| 564 | ||
| 565 | ||
| 566 | octets as the authorization identity. The server must verify that | |
| 567 | the src_name is authorized to authenticate as the authorization | |
| 568 | identity. After these verifications, the authentication process is | |
| 569 | complete. | |
| 570 | ||
| 571 | 7.2.3 Security layer | |
| 572 | ||
| 573 | The security layers and their corresponding bit-masks are as follows: | |
| 574 | ||
| 575 | 1 No security layer | |
| 576 | 2 Integrity protection. | |
| 577 | Sender calls GSS_Wrap with conf_flag set to FALSE | |
| 578 | 4 Privacy protection. | |
| 579 | Sender calls GSS_Wrap with conf_flag set to TRUE | |
| 580 | ||
| 581 | Other bit-masks may be defined in the future; bits which are not | |
| 582 | understood must be negotiated off. | |
| 583 | ||
| 584 | 7.3. S/Key mechanism | |
| 585 | ||
| 586 | The mechanism name associated with S/Key [RFC 1760] using the MD4 | |
| 587 | digest algorithm is "SKEY". | |
| 588 | ||
| 589 | The client sends an initial response with the authorization identity. | |
| 590 | ||
| 591 | The server then issues a challenge which contains the decimal | |
| 592 | sequence number followed by a single space and the seed string for | |
| 593 | the indicated authorization identity. The client responds with the | |
| 594 | one-time-password, as either a 64-bit value in network byte order or | |
| 595 | encoded in the "six English words" format. | |
| 596 | ||
| 597 | The server must verify the one-time-password. After this | |
| 598 | verification, the authentication process is complete. | |
| 599 | ||
| 600 | S/Key authentication does not provide for any security layers. | |
| 601 | ||
| 602 | EXAMPLE: The following are two S/Key login scenarios in the IMAP4 | |
| 603 | protocol. | |
| 604 | ||
| 605 | S: * OK IMAP4 Server | |
| 606 | C: A001 AUTHENTICATE SKEY | |
| 607 | S: + | |
| 608 | C: bW9yZ2Fu | |
| 609 | S: + OTUgUWE1ODMwOA== | |
| 610 | C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== | |
| 611 | S: A001 OK S/Key authentication successful | |
| 612 | ||
| 613 | ||
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | Myers Standards Track [Page 11] | |
| 618 | ||
| 619 | RFC 2222 SASL October 1997 | |
| 620 | ||
| 621 | ||
| 622 | S: * OK IMAP4 Server | |
| 623 | C: A001 AUTHENTICATE SKEY | |
| 624 | S: + | |
| 625 | C: c21pdGg= | |
| 626 | S: + OTUgUWE1ODMwOA== | |
| 627 | C: BsAY3g4gBNo= | |
| 628 | S: A001 NO S/Key authentication failed | |
| 629 | ||
| 630 | The following is an S/Key login scenario in an IMAP4-like protocol | |
| 631 | which has an optional "initial response" argument to the AUTHENTICATE | |
| 632 | command. | |
| 633 | ||
| 634 | S: * OK IMAP4-Like Server | |
| 635 | C: A001 AUTHENTICATE SKEY bW9yZ2Fu | |
| 636 | S: + OTUgUWE1ODMwOA== | |
| 637 | C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== | |
| 638 | S: A001 OK S/Key authentication successful | |
| 639 | ||
| 640 | 7.4. External mechanism | |
| 641 | ||
| 642 | The mechanism name associated with external authentication is | |
| 643 | "EXTERNAL". | |
| 644 | ||
| 645 | The client sends an initial response with the authorization identity. | |
| 646 | ||
| 647 | The server uses information, external to SASL, to determine whether | |
| 648 | the client is authorized to authenticate as the authorization | |
| 649 | identity. If the client is so authorized, the server indicates | |
| 650 | successful completion of the authentication exchange; otherwise the | |
| 651 | server indicates failure. | |
| 652 | ||
| 653 | The system providing this external information may be, for example, | |
| 654 | IPsec or TLS. | |
| 655 | ||
| 656 | If the client sends the empty string as the authorization identity | |
| 657 | (thus requesting the authorization identity be derived from the | |
| 658 | client's authentication credentials), the authorization identity is | |
| 659 | to be derived from authentication credentials which exist in the | |
| 660 | system which is providing the external authentication. | |
| 661 | ||
| 662 | ||
| 663 | ||
| 664 | ||
| 665 | ||
| 666 | ||
| 667 | ||
| 668 | ||
| 669 | ||
| 670 | ||
| 671 | ||
| 672 | ||
| 673 | Myers Standards Track [Page 12] | |
| 674 | ||
| 675 | RFC 2222 SASL October 1997 | |
| 676 | ||
| 677 | ||
| 678 | 8. References | |
| 679 | ||
| 680 | [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version | |
| 681 | 4rev1", RFC 2060, December 1996. | |
| 682 | ||
| 683 | [RFC 2078] Linn, J., "Generic Security Service Application Program | |
| 684 | Interface, Version 2", RFC 2078, January 1997. | |
| 685 | ||
| 686 | [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | |
| 687 | Requirement Levels", RFC 2119, March 1997. | |
| 688 | ||
| 689 | [RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC | |
| 690 | Authors", RFC 2223, October 1997. | |
| 691 | ||
| 692 | [RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC | |
| 693 | 1760, February 1995. | |
| 694 | ||
| 695 | [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, | |
| 696 | RFC 1700, October 1994. | |
| 697 | ||
| 698 | 9. Security Considerations | |
| 699 | ||
| 700 | Security issues are discussed throughout this memo. | |
| 701 | ||
| 702 | The mechanisms that support integrity protection are designed such | |
| 703 | that the negotiation of the security layer and authorization identity | |
| 704 | is integrity protected. When the client selects a security layer | |
| 705 | with at least integrity protection, this protects against an active | |
| 706 | attacker hijacking the connection and modifying the authentication | |
| 707 | exchange to negotiate a plaintext connection. | |
| 708 | ||
| 709 | When a server or client supports multiple authentication mechanisms, | |
| 710 | each of which has a different security strength, it is possible for | |
| 711 | an active attacker to cause a party to use the least secure mechanism | |
| 712 | supported. To protect against this sort of attack, a client or | |
| 713 | server which supports mechanisms of different strengths should have a | |
| 714 | configurable minimum strength that it will use. It is not sufficient | |
| 715 | for this minimum strength check to only be on the server, since an | |
| 716 | active attacker can change which mechanisms the client sees as being | |
| 717 | supported, causing the client to send authentication credentials for | |
| 718 | its weakest supported mechanism. | |
| 719 | ||
| 720 | ||
| 721 | ||
| 722 | ||
| 723 | ||
| 724 | ||
| 725 | ||
| 726 | ||
| 727 | ||
| 728 | ||
| 729 | Myers Standards Track [Page 13] | |
| 730 | ||
| 731 | RFC 2222 SASL October 1997 | |
| 732 | ||
| 733 | ||
| 734 | The client's selection of a SASL mechanism is done in the clear and | |
| 735 | may be modified by an active attacker. It is important for any new | |
| 736 | SASL mechanisms to be designed such that an active attacker cannot | |
| 737 | obtain an authentication with weaker security properties by modifying | |
| 738 | the SASL mechanism name and/or the challenges and responses. | |
| 739 | ||
| 740 | Any protocol interactions prior to authentication are performed in | |
| 741 | the clear and may be modified by an active attacker. In the case | |
| 742 | where a client selects integrity protection, it is important that any | |
| 743 | security-sensitive protocol negotiations be performed after | |
| 744 | authentication is complete. Protocols should be designed such that | |
| 745 | negotiations performed prior to authentication should be either | |
| 746 | ignored or revalidated once authentication is complete. | |
| 747 | ||
| 748 | 10. Author's Address | |
| 749 | ||
| 750 | John G. Myers | |
| 751 | Netscape Communications | |
| 752 | 501 E. Middlefield Road | |
| 753 | Mail Stop MV-029 | |
| 754 | Mountain View, CA 94043-4042 | |
| 755 | ||
| 756 | EMail: jgmyers@netscape.com | |
| 757 | ||
| 758 | ||
| 759 | ||
| 760 | ||
| 761 | ||
| 762 | ||
| 763 | ||
| 764 | ||
| 765 | ||
| 766 | ||
| 767 | ||
| 768 | ||
| 769 | ||
| 770 | ||
| 771 | ||
| 772 | ||
| 773 | ||
| 774 | ||
| 775 | ||
| 776 | ||
| 777 | ||
| 778 | ||
| 779 | ||
| 780 | ||
| 781 | ||
| 782 | ||
| 783 | ||
| 784 | ||
| 785 | Myers Standards Track [Page 14] | |
| 786 | ||
| 787 | RFC 2222 SASL October 1997 | |
| 788 | ||
| 789 | ||
| 790 | Appendix A. Relation of SASL to Transport Security | |
| 791 | ||
| 792 | Questions have been raised about the relationship between SASL and | |
| 793 | various services (such as IPsec and TLS) which provide a secured | |
| 794 | connection. | |
| 795 | ||
| 796 | Two of the key features of SASL are: | |
| 797 | ||
| 798 | 1. The separation of the authorization identity from the identity in | |
| 799 | the client's credentials. This permits agents such as proxy | |
| 800 | servers to authenticate using their own credentials, yet request | |
| 801 | the access privileges of the identity for which they are proxying. | |
| 802 | ||
| 803 | 2. Upon successful completion of an authentication exchange, the | |
| 804 | server knows the authorization identity the client wishes to use. | |
| 805 | This allows servers to move to a "user is authenticated" state in | |
| 806 | the protocol. | |
| 807 | ||
| 808 | These features are extremely important to some application protocols, | |
| 809 | yet Transport Security services do not always provide them. To | |
| 810 | define SASL mechanisms based on these services would be a very messy | |
| 811 | task, as the framing of these services would be redundant with the | |
| 812 | framing of SASL and some method of providing these important SASL | |
| 813 | features would have to be devised. | |
| 814 | ||
| 815 | Sometimes it is desired to enable within an existing connection the | |
| 816 | use of a security service which does not fit the SASL model. (TLS is | |
| 817 | an example of such a service.) This can be done by adding a command, | |
| 818 | for example "STARTTLS", to the protocol. Such a command is outside | |
| 819 | the scope of SASL, and should be different from the command which | |
| 820 | starts a SASL authentication protocol exchange. | |
| 821 | ||
| 822 | In certain situations, it is reasonable to use SASL underneath one of | |
| 823 | these Transport Security services. The transport service would | |
| 824 | secure the connection, either service would authenticate the client, | |
| 825 | and SASL would negotiate the authorization identity. The SASL | |
| 826 | negotiation would be what moves the protocol from "unauthenticated" | |
| 827 | to "authenticated" state. The "EXTERNAL" SASL mechanism is | |
| 828 | explicitly intended to handle the case where the transport service | |
| 829 | secures the connection and authenticates the client and SASL | |
| 830 | negotiates the authorization identity. | |
| 831 | ||
| 832 | When using SASL underneath a sufficiently strong Transport Security | |
| 833 | service, a SASL security layer would most likely be redundant. The | |
| 834 | client and server would thus probably want to negotiate off the use | |
| 835 | of a SASL security layer. | |
| 836 | ||
| 837 | ||
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | Myers Standards Track [Page 15] | |
| 842 | ||
| 843 | RFC 2222 SASL October 1997 | |
| 844 | ||
| 845 | ||
| 846 | Full Copyright Statement | |
| 847 | ||
| 848 | Copyright (C) The Internet Society (1997). All Rights Reserved. | |
| 849 | ||
| 850 | This document and translations of it may be copied and furnished to | |
| 851 | others, and derivative works that comment on or otherwise explain it | |
| 852 | or assist in its implmentation may be prepared, copied, published | |
| 853 | andand distributed, in whole or in part, without restriction of any | |
| 854 | kind, provided that the above copyright notice and this paragraph are | |
| 855 | included on all such copies and derivative works. However, this | |
| 856 | document itself may not be modified in any way, such as by removing | |
| 857 | the copyright notice or references to the Internet Society or other | |
| 858 | Internet organizations, except as needed for the purpose of | |
| 859 | developing Internet standards in which case the procedures for | |
| 860 | copyrights defined in the Internet Standards process must be | |
| 861 | followed, or as required to translate it into languages other than | |
| 862 | English. | |
| 863 | ||
| 864 | The limited permissions granted above are perpetual and will not be | |
| 865 | revoked by the Internet Society or its successors or assigns. | |
| 866 | ||
| 867 | This document and the information contained herein is provided on an | |
| 868 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 869 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 870 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 871 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 872 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 873 | ||
| 874 | ||
| 875 | ||
| 876 | ||
| 877 | ||
| 878 | ||
| 879 | ||
| 880 | ||
| 881 | ||
| 882 | ||
| 883 | ||
| 884 | ||
| 885 | ||
| 886 | ||
| 887 | ||
| 888 | ||
| 889 | ||
| 890 | ||
| 891 | ||
| 892 | ||
| 893 | ||
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | Myers Standards Track [Page 16] | |
| 898 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group C. Metz | |
| 7 | Request for Comments: 2243 The Inner Net | |
| 8 | Category: Standards Track November 1997 | |
| 9 | ||
| 10 | ||
| 11 | ||
| 12 | ||
| 13 | OTP Extended Responses | |
| 14 | ||
| 15 | ||
| 16 | Status of this Memo | |
| 17 | ||
| 18 | This document specifies an Internet standards track protocol for the | |
| 19 | Internet community, and requests discussion and suggestions for | |
| 20 | improvements. Please refer to the current edition of the "Internet | |
| 21 | Official Protocol Standards" (STD 1) for the standardization state | |
| 22 | and status of this protocol. Distribution of this memo is unlimited. | |
| 23 | ||
| 24 | Copyright Notice | |
| 25 | ||
| 26 | Copyright (C) The Internet Society (1997). All Rights Reserved. | |
| 27 | ||
| 28 | Abstract | |
| 29 | ||
| 30 | This document provides a specification for a type of response to an | |
| 31 | OTP [RFC 1938] challenge that carries explicit indication of the | |
| 32 | response's encoding. Codings for the two mandatory OTP data formats | |
| 33 | using this new type of response are presented. | |
| 34 | ||
| 35 | This document also provides a specification for a response that | |
| 36 | allows an OTP generator to request that a server re-initialize a | |
| 37 | sequence and change parameters such as the secret pass phrase. | |
| 38 | ||
| 39 | 1. Conventions, Terms, and Notation | |
| 40 | ||
| 41 | This document specifies the data formats and software behaviors | |
| 42 | needed to use OTP extended responses. The data formats are described | |
| 43 | three ways: using an ad-hoc UNIX manual page style syntax, using | |
| 44 | augmented BNF described in sections two and three of RFC 822, and by | |
| 45 | examples. Should there be any conflict between these descriptions, | |
| 46 | the augmented BNF takes precedence. The software behaviors are | |
| 47 | described in words, and specific behavior compliance requirements are | |
| 48 | itemized using the requirements terminology (specifically, the words | |
| 49 | MUST, SHOULD, and MAY) defined in RFC 2119. | |
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Metz Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 2243 OTP Extended Responses November 1997 | |
| 60 | ||
| 61 | ||
| 62 | 2. Extended Challenges and Extended Responses | |
| 63 | ||
| 64 | This document builds on the protocol and terminology specified in RFC | |
| 65 | 1938 and assumes that you have already read this document and | |
| 66 | understand its contents. | |
| 67 | ||
| 68 | An extended challenge is a single line of printable text terminated | |
| 69 | by either a new line sequence appropriate for the context of its use | |
| 70 | (e.g., ASCII CR followed by ASCII LF) or a whitespace character. It | |
| 71 | contains a standard OTP challenge, a whitespace character, and a list | |
| 72 | that generators use to determine which extended responses are | |
| 73 | supported by a server. | |
| 74 | ||
| 75 | An extended response is a single line of printable text terminated by | |
| 76 | a new line sequence appropriate for the context of its use. It | |
| 77 | contains two or more tokens that are separated with a single colon | |
| 78 | (':') character. The first token contains a type specifier that | |
| 79 | indicates the format of the rest of the response. The tokens that | |
| 80 | follow are argument data for the OTP extended response. At least one | |
| 81 | token of data MUST be present. | |
| 82 | ||
| 83 | 2.1. Syntax | |
| 84 | ||
| 85 | In UNIX manual page like syntax, the general form of an extended | |
| 86 | challenge could be described as: | |
| 87 | ||
| 88 | <standard OTP challenge> ext[,<extension set id>[, ...]] | |
| 89 | ||
| 90 | And the general form of an extended response could be described as: | |
| 91 | ||
| 92 | <type-specifier>:<arg1>[:<arg2>[:...]] | |
| 93 | ||
| 94 | In augmented BNF syntax, the syntax of the general form of an | |
| 95 | extended challenge and an extended response is: | |
| 96 | ||
| 97 | extended-challenge = otp-challenge 1*LWSP-char capability-list | |
| 98 | (NL / *LWSP-char) | |
| 99 | otp-challenge = <a standard OTP challenge> | |
| 100 | capability-list = "ext" *("," extension-set-id) | |
| 101 | extension-set-id = *<any CHAR except LWSP, CTLs, or ","> | |
| 102 | extended-response = type 1*(":" argument) NL | |
| 103 | type = token | |
| 104 | argument = token | |
| 105 | token = 1*<any CHAR except ":" and CTLs> | |
| 106 | NL = <new line sequence appropriate for the context | |
| 107 | in which OTP is being used> | |
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Metz Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 2243 OTP Extended Responses November 1997 | |
| 116 | ||
| 117 | ||
| 118 | An example of an extended challenge indicating support for OTP | |
| 119 | extended responses and for a mythical response set "foo" is: | |
| 120 | ||
| 121 | otp-md5 123 mi1234 ext,foo | |
| 122 | ||
| 123 | An example of an extended response using a mythical type named "foo" | |
| 124 | is: | |
| 125 | ||
| 126 | foo:some data:some more data:12345 | |
| 127 | ||
| 128 | 2.2. Requirements | |
| 129 | ||
| 130 | A server compliant with this specification: | |
| 131 | ||
| 132 | 1. MUST be able to receive and parse the general form of an | |
| 133 | extended response | |
| 134 | 2. MUST be able to receive, parse, and correctly process all | |
| 135 | extended responses specified in this document | |
| 136 | 3. MUST process the type field in a case-insensitive manner | |
| 137 | 4. MUST reject any authentication attempt using an extended | |
| 138 | response if it does not support that type of response | |
| 139 | 5. SHOULD provide an appropriate indication to the generator | |
| 140 | if the response was rejected because of (4) | |
| 141 | 6. MUST limit the length of the input reasonably | |
| 142 | 7. MUST accept otherwise arbitrary amounts of whitespace | |
| 143 | wherever a response allows it | |
| 144 | 8. MUST be able to receive and correctly process standard OTP | |
| 145 | responses | |
| 146 | ||
| 147 | A generator compliant with this specification: | |
| 148 | ||
| 149 | 1. MUST be able to generate standard OTP responses | |
| 150 | 2. MUST use standard responses unless an extended challenge | |
| 151 | has been received for the particular server AND seed | |
| 152 | 3. MUST generate the type field in lower case | |
| 153 | 4. MUST NOT send a response type for which the server has not | |
| 154 | indicated support through an extended challenge | |
| 155 | ||
| 156 | Extension set identifiers and extension type identifiers named with | |
| 157 | the prefix "x-" are reserved for private use among mutually | |
| 158 | consenting implementations. Implementations that do not recognise a | |
| 159 | particular "x-" extension MUST ignore that extension. This means that | |
| 160 | all "x-" extensions are likely to be non-interoperable with other | |
| 161 | extensions. Careful consideration should be given to the possibility | |
| 162 | of a server interacting with with a generator implementation which, | |
| 163 | although it recognizes a given "x-" extension, uses it for a | |
| 164 | different purpose. All of the remaining extension namespace is | |
| 165 | reserved to IANA, which will only officially assign the extension | |
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Metz Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 2243 OTP Extended Responses November 1997 | |
| 172 | ||
| 173 | ||
| 174 | into this namespace after the IESG approves of such an assignment. | |
| 175 | During the lifetime of the OTP WG, it is recommended that the IESG | |
| 176 | consult with the OTP WG prior to approving such an assignment. | |
| 177 | ||
| 178 | 3. The "hex" and "word" Responses | |
| 179 | ||
| 180 | There exists a very rare case in which a standard OTP response could | |
| 181 | be a valid coding in both the hexadecimal and six-word formats. An | |
| 182 | example of this is the response "ABE ACE ADA ADD BAD A." The | |
| 183 | solution to this problem mandated by the OTP specification is that | |
| 184 | compliant servers MUST attempt to parse and verify a standard | |
| 185 | response in both hexadecimal and six-word formats and must consider | |
| 186 | the authentication successful if either succeeds. | |
| 187 | ||
| 188 | This problem can be solved easily using extended responses. The "hex" | |
| 189 | response and the "word" response are two response types that encode | |
| 190 | an OTP in an extended response that explicitly describes the | |
| 191 | encoding. These responses start with a type label of "hex" for a | |
| 192 | hexadecimal OTP and "word" for a six-word coded OTP. These responses | |
| 193 | contain one argument field that contains a standard OTP response | |
| 194 | coded in the indicated format. | |
| 195 | ||
| 196 | 3.1. Syntax | |
| 197 | ||
| 198 | In UNIX manual page like syntax, the format of these responses could | |
| 199 | be described as: | |
| 200 | ||
| 201 | hex:<hexadecimal number> | |
| 202 | word:<six dictionary words> | |
| 203 | ||
| 204 | In augmented BNF syntax and with the definitions already provided, | |
| 205 | the syntax of these responses is: | |
| 206 | ||
| 207 | hex-response = "hex:" hex-64bit NL | |
| 208 | hex-64bit = 16(hex-char *LWSP-char) | |
| 209 | hex-char = ("A" / "B" / "C" / "D" / "E" / "F" / | |
| 210 | "a" / "b" / "c" / "d" / "e" / "f" / | |
| 211 | "0" / "1" / "2" / "3" / "4" / "5" / | |
| 212 | "6" / "7" / "8" / "9") | |
| 213 | ||
| 214 | word-response = "word:" word-64bit NL | |
| 215 | word-64bit = 6(otp-word 1*LWSP-char) | |
| 216 | otp-word = <any valid word in the standard OTP coding | |
| 217 | dictionary> | |
| 218 | ||
| 219 | ||
| 220 | ||
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Metz Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 2243 OTP Extended Responses November 1997 | |
| 228 | ||
| 229 | ||
| 230 | Examples of these responses are: | |
| 231 | ||
| 232 | hex:8720 33d4 6202 9172 | |
| 233 | word:VAST SAUL TAKE SODA SUCH BOLT | |
| 234 | ||
| 235 | 3.2. Requirements | |
| 236 | ||
| 237 | A server compliant with this specification: | |
| 238 | ||
| 239 | 1. MUST process all arguments in a case-insensitive manner | |
| 240 | ||
| 241 | A generator compliant with this specification: | |
| 242 | ||
| 243 | 1. SHOULD generate otp-word tokens in upper case with single | |
| 244 | spaces separating them | |
| 245 | 2. SHOULD generate hexadecimal numbers using only lower case | |
| 246 | for letters | |
| 247 | ||
| 248 | 4. The "init-hex" and "init-word" Responses | |
| 249 | ||
| 250 | The OTP specification requires that implementations provide a means | |
| 251 | for a client to re-initialize or change its OTP information with a | |
| 252 | server but does not require any specific protocol for doing it. | |
| 253 | Implementations that support the OTP extended responses described in | |
| 254 | this document MUST support the response with the "init-hex" and | |
| 255 | "init-word" type specifiers, which provide a standard way for a | |
| 256 | client to re-initialize its OTP information with a server. This | |
| 257 | response is intended to be used only by automated clients. Because of | |
| 258 | this, the recommended form of this response uses the hexadecimal | |
| 259 | encoding for binary data. It is possible for a user to type an "init- | |
| 260 | hex" or "init-word" response. | |
| 261 | ||
| 262 | 4.1. Syntax | |
| 263 | ||
| 264 | In UNIX manual page like syntax, the format of these responses could | |
| 265 | be described as: | |
| 266 | ||
| 267 | init-hex:<current-OTP>:<new-params>:<new-OTP> | |
| 268 | init-word:<current-OTP>:<new-params>:<new-OTP> | |
| 269 | ||
| 270 | In augmented BNF syntax and with the definitions already provided, | |
| 271 | the syntax of the "init-hex" response is: | |
| 272 | ||
| 273 | init-hex-response = "init-hex:" current-OTP ":" new-params ":" | |
| 274 | new-OTP NL | |
| 275 | ||
| 276 | current-OTP = hex-64bit | |
| 277 | new-OTP = hex-64bit | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Metz Standards Track [Page 5] | |
| 282 | ||
| 283 | RFC 2243 OTP Extended Responses November 1997 | |
| 284 | ||
| 285 | ||
| 286 | new-params = algorithm SPACE sequence-number SPACE seed | |
| 287 | algorithm = "md4" / "md5" / "sha1" | |
| 288 | sequence-number = 4*3DIGIT | |
| 289 | seed = 16*1(ALPHA / DIGIT) | |
| 290 | ||
| 291 | In augmented BNF syntax and with the definitions already provided, | |
| 292 | the syntax of the "init-word" response is: | |
| 293 | ||
| 294 | init-word-response = "init-word:" current-OTP ":" new-params ":" | |
| 295 | new-OTP NL | |
| 296 | ||
| 297 | current-OTP = word-64bit | |
| 298 | new-OTP = word-64bit | |
| 299 | ||
| 300 | new-params = algorithm SPACE sequence-number SPACE seed | |
| 301 | algorithm = "md4" / "md5" / "sha1" | |
| 302 | sequence-number = 4*3DIGIT | |
| 303 | seed = 16*1(ALPHA / DIGIT) | |
| 304 | ||
| 305 | Note that all appropriate fields for the "init-hex" response MUST be | |
| 306 | hexadecimally coded and that all appropriate fields for the "init- | |
| 307 | word" response MUST be six-word coded. | |
| 308 | ||
| 309 | Examples of these responses are: | |
| 310 | ||
| 311 | init-hex:f6bd 6b33 89b8 7203:md5 499 ke6118:23d1 b253 5ae0 2b7e | |
| 312 | init-hex:c9b2 12bb 6425 5a0f:md5 499 ke0986:fd17 cef1 b4df 093e | |
| 313 | ||
| 314 | init-word:MOOD SOFT POP COMB BOLO LIFE:md5 499 ke1235: | |
| 315 | ARTY WEAR TAD RUG HALO GIVE | |
| 316 | init-word:END KERN BALM NICK EROS WAVY:md5 499 ke1235: | |
| 317 | BABY FAIN OILY NIL TIDY DADE | |
| 318 | ||
| 319 | (Note that all of these responses are one line. Due to their length, | |
| 320 | they had to be split into multiple lines in order to be included | |
| 321 | here. These responses MUST NOT span more than one line in actual use) | |
| 322 | ||
| 323 | 4.2. Description of Fields | |
| 324 | ||
| 325 | The current-OTP field contains the (RFC 1938) response to the OTP | |
| 326 | challenge. The new-params field contains the parameters for the | |
| 327 | client's new requested challenge and the new-OTP field contains a | |
| 328 | response to that challenge. If the re-initialization is successful, a | |
| 329 | server MUST store the new OTP in its database as the last successful | |
| 330 | OTP received and the sequence number in the next challenge presented | |
| 331 | by the server MUST be one less than the sequence number specified in | |
| 332 | the new-params field. | |
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Metz Standards Track [Page 6] | |
| 338 | ||
| 339 | RFC 2243 OTP Extended Responses November 1997 | |
| 340 | ||
| 341 | ||
| 342 | The new-params field is hashed as a string the same way that a seed | |
| 343 | or secret pass phrase would be. All other field values are hashed in | |
| 344 | their uncoded binary forms, in network byte order and without any | |
| 345 | padding. | |
| 346 | ||
| 347 | 4.3. Requirements | |
| 348 | ||
| 349 | A server compliant with this specification: | |
| 350 | ||
| 351 | 1. SHOULD NOT allow a user to use the same value for their | |
| 352 | seed and secret pass phrase. | |
| 353 | 2. MUST disable all OTP access to any principal whose | |
| 354 | sequence number would be less than one | |
| 355 | 3. MUST decrement the sequence number if a reinitialization | |
| 356 | response includes a valid current-OTP, but the server is | |
| 357 | unable to successfully process the new-params or new-OTP for | |
| 358 | any reason. | |
| 359 | ||
| 360 | A generator compliant with this specification: | |
| 361 | ||
| 362 | 1. SHOULD NOT allow a user to use the same value for their | |
| 363 | seed and secret pass phrase | |
| 364 | 2. MUST take specific steps to prevent infinite loops of | |
| 365 | re-initialization attempts in case of failure | |
| 366 | 3. SHOULD provide the user with some indication that the | |
| 367 | re-initialization is taking place | |
| 368 | 4. SHOULD NOT do a re-initialization without the user's | |
| 369 | permission, either for that specific instance or as a | |
| 370 | configuration option | |
| 371 | 5. SHOULD NOT retry a failed re-initialization without a user's | |
| 372 | permission | |
| 373 | 6. SHOULD warn the user if the sequence number falls below ten | |
| 374 | 7. MUST refuse to generate OTPs with a sequence number below one | |
| 375 | ||
| 376 | 5. Security Considerations | |
| 377 | ||
| 378 | All of the security considerations for the OTP system also apply to | |
| 379 | the OTP system with extended responses. | |
| 380 | ||
| 381 | These extended responses, like OTP itself, do not protect the user | |
| 382 | against active attacks. The IPsec Authentication Header (RFC-1826) | |
| 383 | (or another technique with at least as much strength as IPsec AH) | |
| 384 | SHOULD be used to protect against such attacks. | |
| 385 | ||
| 386 | The consequences of a successful active attack on the re- | |
| 387 | initialization response may be more severe than simply hijacking a | |
| 388 | single session. An attacker could substitute his own response for | |
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Metz Standards Track [Page 7] | |
| 394 | ||
| 395 | RFC 2243 OTP Extended Responses November 1997 | |
| 396 | ||
| 397 | ||
| 398 | that of a legitimate user. The attacker may then be able to use the | |
| 399 | OTP system to authenticate himself as the user at will (at least | |
| 400 | until detected). | |
| 401 | ||
| 402 | Failure to implement server requirement 3 in section 4.3 opens an | |
| 403 | implementation to an attack based on replay of the current-OTP part | |
| 404 | of the response. | |
| 405 | ||
| 406 | 6. Acknowledgments | |
| 407 | ||
| 408 | Like RFC 1938, the protocol described in this document was created by | |
| 409 | contributors in the IETF OTP working group. Specific contributions | |
| 410 | were made by Neil Haller, who provided input on the overall design | |
| 411 | requirements of a re-initialization protocol, Denis Pinkas, who | |
| 412 | suggested several modifications to the originally proposed re- | |
| 413 | initialization protocol, and Phil Servita, who opened the debate with | |
| 414 | the first real protocol proposal and provided lots of specific input | |
| 415 | on the design of this and earlier protocols. The extensions to the | |
| 416 | OTP challenge were suggested by Chris Newman and John Valdes. | |
| 417 | ||
| 418 | Randall Atkinson and Ted T'so also contributed their views to | |
| 419 | discussions about details of the protocol extensions in this | |
| 420 | document. | |
| 421 | ||
| 422 | References | |
| 423 | ||
| 424 | [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet | |
| 425 | Text Messages," RFC 822, August 1982. | |
| 426 | ||
| 427 | [RFC 1825] Atkinson, R., "Security Architecture for the Internet | |
| 428 | Protocol," RFC 1825, August 1995. | |
| 429 | ||
| 430 | [RFC 1938] Haller, N. and C. Metz, "A One-Time Password System," | |
| 431 | RFC 1938, May 1996. | |
| 432 | ||
| 433 | [RFC 2119] Bradner, S., "Key words for use in RFCs to | |
| 434 | Indicate Requirement Level," RFC 2119, | |
| 435 | March 1997. | |
| 436 | ||
| 437 | Author's Address | |
| 438 | ||
| 439 | Craig Metz | |
| 440 | The Inner Net | |
| 441 | Box 10314-1936 | |
| 442 | Blacksburg, VA 24062-0314 | |
| 443 | (DSN) 354-8590 | |
| 444 | cmetz@inner.net | |
| 445 | ||
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Metz Standards Track [Page 8] | |
| 450 | ||
| 451 | RFC 2243 OTP Extended Responses November 1997 | |
| 452 | ||
| 453 | ||
| 454 | Appendix: Reference Responses | |
| 455 | ||
| 456 | The following responses were generated by a development version of | |
| 457 | the One-Time Passwords in Everything (OPIE) implementation of this | |
| 458 | specification. | |
| 459 | ||
| 460 | All of these are responses to the challenge: | |
| 461 | ||
| 462 | otp-md5 499 ke1234 ext | |
| 463 | ||
| 464 | Note that the re-initialization responses use the same secret pass | |
| 465 | phrase for new and current and a new seed of "ke1235". Also, these | |
| 466 | responses have been split for formatting purposes into multiple | |
| 467 | lines; they MUST NOT be multiple lines in actual use. | |
| 468 | ||
| 469 | The secret pass phrase for these responses is: | |
| 470 | ||
| 471 | This is a test. | |
| 472 | ||
| 473 | The OTP standard hexadecimal response is: | |
| 474 | ||
| 475 | 5bf0 75d9 959d 036f | |
| 476 | ||
| 477 | The OTP standard six-word response is: | |
| 478 | ||
| 479 | BOND FOGY DRAB NE RISE MART | |
| 480 | ||
| 481 | The OTP extended "hex" response is: | |
| 482 | ||
| 483 | hex:5Bf0 75d9 959d 036f | |
| 484 | ||
| 485 | The OTP extended "word" response is: | |
| 486 | ||
| 487 | word:BOND FOGY DRAB NE RISE MART | |
| 488 | ||
| 489 | The OTP extended "init-hex" response is: | |
| 490 | ||
| 491 | init-hex:5bf0 75d9 959d 036f:md5 499 ke1235:3712 dcb4 aa53 16c1 | |
| 492 | ||
| 493 | The OTP extended "init-word" response is: | |
| 494 | ||
| 495 | init-word:BOND FOGY DRAB NE RISE MART:md5 499 ke1235: RED HERD | |
| 496 | NOW BEAN PA BURG | |
| 497 | ||
| 498 | ||
| 499 | ||
| 500 | ||
| 501 | ||
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Metz Standards Track [Page 9] | |
| 506 | ||
| 507 | RFC 2243 OTP Extended Responses November 1997 | |
| 508 | ||
| 509 | ||
| 510 | Full Copyright Statement | |
| 511 | ||
| 512 | Copyright (C) The Internet Society (1997). All Rights Reserved. | |
| 513 | ||
| 514 | This document and translations of it may be copied and furnished to | |
| 515 | others, and derivative works that comment on or otherwise explain it | |
| 516 | or assist in its implementation may be prepared, copied, published | |
| 517 | and distributed, in whole or in part, without restriction of any | |
| 518 | kind, provided that the above copyright notice and this paragraph are | |
| 519 | included on all such copies and derivative works. However, this | |
| 520 | document itself may not be modified in any way, such as by removing | |
| 521 | the copyright notice or references to the Internet Society or other | |
| 522 | Internet organizations, except as needed for the purpose of | |
| 523 | developing Internet standards in which case the procedures for | |
| 524 | copyrights defined in the Internet Standards process must be | |
| 525 | followed, or as required to translate it into languages other than | |
| 526 | English. | |
| 527 | ||
| 528 | The limited permissions granted above are perpetual and will not be | |
| 529 | revoked by the Internet Society or its successors or assigns. | |
| 530 | ||
| 531 | This document and the information contained herein is provided on an | |
| 532 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 533 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 534 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 535 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 536 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 537 | ||
| 538 | ||
| 539 | ||
| 540 | ||
| 541 | ||
| 542 | ||
| 543 | ||
| 544 | ||
| 545 | ||
| 546 | ||
| 547 | ||
| 548 | ||
| 549 | ||
| 550 | ||
| 551 | ||
| 552 | ||
| 553 | ||
| 554 | ||
| 555 | ||
| 556 | ||
| 557 | ||
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Metz Standards Track [Page 10] | |
| 562 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group C. Newman | |
| 7 | Request for Comments: 2245 Innosoft | |
| 8 | Category: Standards Track November 1997 | |
| 9 | ||
| 10 | ||
| 11 | Anonymous SASL Mechanism | |
| 12 | ||
| 13 | Status of this Memo | |
| 14 | ||
| 15 | This document specifies an Internet standards track protocol for the | |
| 16 | Internet community, and requests discussion and suggestions for | |
| 17 | improvements. Please refer to the current edition of the "Internet | |
| 18 | Official Protocol Standards" (STD 1) for the standardization state | |
| 19 | and status of this protocol. Distribution of this memo is unlimited. | |
| 20 | ||
| 21 | Copyright Notice | |
| 22 | ||
| 23 | Copyright (C) The Internet Society (1997). All Rights Reserved. | |
| 24 | ||
| 25 | Abstract | |
| 26 | ||
| 27 | It is common practice on the Internet to permit anonymous access to | |
| 28 | various services. Traditionally, this has been done with a plain | |
| 29 | text password mechanism using "anonymous" as the user name and | |
| 30 | optional trace information, such as an email address, as the | |
| 31 | password. As plaintext login commands are not permitted in new IETF | |
| 32 | protocols, a new way to provide anonymous login is needed within the | |
| 33 | context of the SASL [SASL] framework. | |
| 34 | ||
| 35 | 1. Conventions Used in this Document | |
| 36 | ||
| 37 | The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" | |
| 38 | in this document are to be interpreted as defined in "Key words for | |
| 39 | use in RFCs to Indicate Requirement Levels" [KEYWORDS]. | |
| 40 | ||
| 41 | 2. Anonymous SASL mechanism | |
| 42 | ||
| 43 | The mechanism name associated with anonymous access is "ANONYMOUS". | |
| 44 | The mechanism consists of a single message from the client to the | |
| 45 | server. The client sends optional trace information in the form of a | |
| 46 | human readable string. The trace information should take one of | |
| 47 | three forms: an Internet email address, an opaque string which does | |
| 48 | not contain the '@' character and can be interpreted by the system | |
| 49 | administrator of the client's domain, or nothing. For privacy | |
| 50 | reasons, an Internet email address should only be used with | |
| 51 | permission from the user. | |
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Newman Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 2245 Anonymous SASL Mechanism November 1997 | |
| 60 | ||
| 61 | ||
| 62 | A server which permits anonymous access will announce support for the | |
| 63 | ANONYMOUS mechanism, and allow anyone to log in using that mechanism, | |
| 64 | usually with restricted access. | |
| 65 | ||
| 66 | The formal grammar for the client message using Augmented BNF [ABNF] | |
| 67 | follows. | |
| 68 | ||
| 69 | message = [email / token] | |
| 70 | ||
| 71 | TCHAR = %x20-3F / %x41-7E | |
| 72 | ;; any printable US-ASCII character except '@' | |
| 73 | ||
| 74 | email = addr-spec | |
| 75 | ;; as defined in [IMAIL], except with no free | |
| 76 | ;; insertion of linear-white-space, and the | |
| 77 | ;; local-part MUST either be entirely enclosed in | |
| 78 | ;; quotes or entirely unquoted | |
| 79 | ||
| 80 | token = 1*255TCHAR | |
| 81 | ||
| 82 | 3. Example | |
| 83 | ||
| 84 | ||
| 85 | Here is a sample anonymous login between an IMAP client and server. | |
| 86 | In this example, "C:" and "S:" indicate lines sent by the client and | |
| 87 | server respectively. If such lines are wrapped without a new "C:" or | |
| 88 | "S:" label, then the wrapping is for editorial clarity and is not | |
| 89 | part of the command. | |
| 90 | ||
| 91 | Note that this example uses the IMAP profile [IMAP4] of SASL. The | |
| 92 | base64 encoding of challenges and responses, as well as the "+ " | |
| 93 | preceding the responses are part of the IMAP4 profile, not part of | |
| 94 | SASL itself. Newer profiles of SASL will include the client message | |
| 95 | with the AUTHENTICATE command itself so the extra round trip below | |
| 96 | (the server response with an empty "+ ") can be eliminated. | |
| 97 | ||
| 98 | In this example, the user's opaque identification token is "sirhc". | |
| 99 | ||
| 100 | S: * OK IMAP4 server ready | |
| 101 | C: A001 CAPABILITY | |
| 102 | S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS | |
| 103 | S: A001 OK done | |
| 104 | C: A002 AUTHENTICATE ANONYMOUS | |
| 105 | S: + | |
| 106 | C: c2lyaGM= | |
| 107 | S: A003 OK Welcome, trace information has been logged. | |
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Newman Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 2245 Anonymous SASL Mechanism November 1997 | |
| 116 | ||
| 117 | ||
| 118 | 4. Security Considerations | |
| 119 | ||
| 120 | The anonymous mechanism grants access to information by anyone. For | |
| 121 | this reason it should be disabled by default so the administrator can | |
| 122 | make an explicit decision to enable it. | |
| 123 | ||
| 124 | If the anonymous user has any write privileges, a denial of service | |
| 125 | attack is possible by filling up all available space. This can be | |
| 126 | prevented by disabling all write access by anonymous users. | |
| 127 | ||
| 128 | If anonymous users have read and write access to the same area, the | |
| 129 | server can be used as a communication mechanism to anonymously | |
| 130 | exchange information. Servers which accept anonymous submissions | |
| 131 | should implement the common "drop box" model which forbids anonymous | |
| 132 | read access to the area where anonymous submissions are accepted. | |
| 133 | ||
| 134 | If the anonymous user can run many expensive operations (e.g., an | |
| 135 | IMAP SEARCH BODY command), this could enable a denial of service | |
| 136 | attack. Servers are encouraged to limit the number of anonymous | |
| 137 | users and reduce their priority or limit their resource usage. | |
| 138 | ||
| 139 | If there is no idle timeout for the anonymous user and there is a | |
| 140 | limit on the number of anonymous users, a denial of service attack is | |
| 141 | enabled. Servers should implement an idle timeout for anonymous | |
| 142 | users. | |
| 143 | ||
| 144 | The trace information is not authenticated so it can be falsified. | |
| 145 | This can be used as an attempt to get someone else in trouble for | |
| 146 | access to questionable information. Administrators trying to trace | |
| 147 | abuse need to realize this information may be falsified. | |
| 148 | ||
| 149 | A client which uses the user's correct email address as trace | |
| 150 | information without explicit permission may violate that user's | |
| 151 | privacy. Information about who accesses an anonymous archive on a | |
| 152 | sensitive subject (e.g., sexual abuse) has strong privacy needs. | |
| 153 | Clients should not send the email address without explicit permission | |
| 154 | of the user and should offer the option of supplying no trace token | |
| 155 | -- thus only exposing the source IP address and time. Anonymous | |
| 156 | proxy servers could enhance this privacy, but would have to consider | |
| 157 | the resulting potential denial of service attacks. | |
| 158 | ||
| 159 | Anonymous connections are susceptible to man in the middle attacks | |
| 160 | which view or alter the data transferred. Clients and servers are | |
| 161 | encouraged to support external integrity and encryption mechanisms. | |
| 162 | ||
| 163 | Protocols which fail to require an explicit anonymous login are more | |
| 164 | susceptible to break-ins given certain common implementation | |
| 165 | techniques. Specifically, Unix servers which offer user login may | |
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Newman Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 2245 Anonymous SASL Mechanism November 1997 | |
| 172 | ||
| 173 | ||
| 174 | initially start up as root and switch to the appropriate user id | |
| 175 | after an explicit login command. Normally such servers refuse all | |
| 176 | data access commands prior to explicit login and may enter a | |
| 177 | restricted security environment (e.g., the Unix chroot function) for | |
| 178 | anonymous users. If anonymous access is not explicitly requested, | |
| 179 | the entire data access machinery is exposed to external security | |
| 180 | attacks without the chance for explicit protective measures. | |
| 181 | Protocols which offer restricted data access should not allow | |
| 182 | anonymous data access without an explicit login step. | |
| 183 | ||
| 184 | 5. References | |
| 185 | ||
| 186 | [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
| 187 | Specifications: ABNF", RFC 2234, November 1997. | |
| 188 | ||
| 189 | [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text | |
| 190 | Messages", STD 11, RFC 822, August 1982. | |
| 191 | ||
| 192 | [IMAP4] Crispin, M., "Internet Message Access Protocol - Version | |
| 193 | 4rev1", RFC 2060, December 1996. | |
| 194 | ||
| 195 | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |
| 196 | Requirement Levels", RFC 2119, March 1997. | |
| 197 | ||
| 198 | [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", | |
| 199 | RFC 2222, October 1997. | |
| 200 | ||
| 201 | 6. Author's Address | |
| 202 | ||
| 203 | Chris Newman | |
| 204 | Innosoft International, Inc. | |
| 205 | 1050 Lakes Drive | |
| 206 | West Covina, CA 91790 USA | |
| 207 | ||
| 208 | Email: chris.newman@innosoft.com | |
| 209 | ||
| 210 | ||
| 211 | ||
| 212 | ||
| 213 | ||
| 214 | ||
| 215 | ||
| 216 | ||
| 217 | ||
| 218 | ||
| 219 | ||
| 220 | ||
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Newman Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 2245 Anonymous SASL Mechanism November 1997 | |
| 228 | ||
| 229 | ||
| 230 | 7. Full Copyright Statement | |
| 231 | ||
| 232 | Copyright (C) The Internet Society (1997). All Rights Reserved. | |
| 233 | ||
| 234 | This document and translations of it may be copied and furnished to | |
| 235 | others, and derivative works that comment on or otherwise explain it | |
| 236 | or assist in its implementation may be prepared, copied, published | |
| 237 | and distributed, in whole or in part, without restriction of any | |
| 238 | kind, provided that the above copyright notice and this paragraph are | |
| 239 | included on all such copies and derivative works. However, this | |
| 240 | document itself may not be modified in any way, such as by removing | |
| 241 | the copyright notice or references to the Internet Society or other | |
| 242 | Internet organizations, except as needed for the purpose of | |
| 243 | developing Internet standards in which case the procedures for | |
| 244 | copyrights defined in the Internet Standards process must be | |
| 245 | followed, or as required to translate it into languages other than | |
| 246 | English. | |
| 247 | ||
| 248 | The limited permissions granted above are perpetual and will not be | |
| 249 | revoked by the Internet Society or its successors or assigns. | |
| 250 | ||
| 251 | This document and the information contained herein is provided on an | |
| 252 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 253 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 254 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 255 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 256 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 257 | ||
| 258 | ||
| 259 | ||
| 260 | ||
| 261 | ||
| 262 | ||
| 263 | ||
| 264 | ||
| 265 | ||
| 266 | ||
| 267 | ||
| 268 | ||
| 269 | ||
| 270 | ||
| 271 | ||
| 272 | ||
| 273 | ||
| 274 | ||
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Newman Standards Track [Page 5] | |
| 282 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group N. Haller | |
| 7 | Request for Comments: 2289 Bellcore | |
| 8 | Obsoletes: 1938 C. Metz | |
| 9 | Category: Standards Track Kaman Sciences Corporation | |
| 10 | P. Nesser | |
| 11 | Nesser & Nesser Consulting | |
| 12 | M. Straw | |
| 13 | Bellcore | |
| 14 | February 1998 | |
| 15 | ||
| 16 | ||
| 17 | A One-Time Password System | |
| 18 | ||
| 19 | Status of this Memo | |
| 20 | ||
| 21 | This document specifies an Internet standards track protocol for the | |
| 22 | Internet community, and requests discussion and suggestions for | |
| 23 | improvements. Please refer to the current edition of the "Internet | |
| 24 | Official Protocol Standards" (STD 1) for the standardization state | |
| 25 | and status of this protocol. Distribution of this memo is unlimited. | |
| 26 | ||
| 27 | Copyright Notice | |
| 28 | ||
| 29 | Copyright (C) The Internet Society (1998). All Rights Reserved. | |
| 30 | ||
| 31 | 1.0 ABSTRACT | |
| 32 | ||
| 33 | This document describes a one-time password authentication system | |
| 34 | (OTP). The system provides authentication for system access (login) | |
| 35 | and other applications requiring authentication that is secure | |
| 36 | against passive attacks based on replaying captured reusable | |
| 37 | passwords. OTP evolved from the S/KEY (S/KEY is a trademark of | |
| 38 | Bellcore) One-Time Password System that was released by Bellcore and | |
| 39 | is described in references [3] and [5]. | |
| 40 | ||
| 41 | 2.0 OVERVIEW | |
| 42 | ||
| 43 | One form of attack on networked computing systems is eavesdropping on | |
| 44 | network connections to obtain authentication information such as the | |
| 45 | login IDs and passwords of legitimate users. Once this information is | |
| 46 | captured, it can be used at a later time to gain access to the | |
| 47 | system. One-time password systems are designed to counter this type | |
| 48 | of attack, called a "replay attack" [4]. | |
| 49 | ||
| 50 | The authentication system described in this document uses a secret | |
| 51 | pass-phrase to generate a sequence of one-time (single use) | |
| 52 | passwords. With this system, the user's secret pass-phrase never | |
| 53 | needs to cross the network at any time such as during authentication | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Haller Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 2289 A One-Time Password System February 1998 | |
| 60 | ||
| 61 | ||
| 62 | or during pass-phrase changes. Thus, it is not vulnerable to replay | |
| 63 | attacks. Added security is provided by the property that no secret | |
| 64 | information need be stored on any system, including the server being | |
| 65 | protected. | |
| 66 | ||
| 67 | The OTP system protects against external passive attacks against the | |
| 68 | authentication subsystem. It does not prevent a network eavesdropper | |
| 69 | from gaining access to private information and does not provide | |
| 70 | protection against either "social engineering" or active attacks [9]. | |
| 71 | ||
| 72 | 3.0 INTRODUCTION | |
| 73 | ||
| 74 | There are two entities in the operation of the OTP one-time password | |
| 75 | system. The generator must produce the appropriate one-time password | |
| 76 | from the user's secret pass-phrase and from information provided in | |
| 77 | the challenge from the server. The server must send a challenge that | |
| 78 | includes the appropriate generation parameters to the generator, must | |
| 79 | verify the one-time password received, must store the last valid | |
| 80 | one-time password it received, and must store the corresponding one- | |
| 81 | time password sequence number. The server must also facilitate the | |
| 82 | changing of the user's secret pass-phrase in a secure manner. | |
| 83 | ||
| 84 | The OTP system generator passes the user's secret pass-phrase, along | |
| 85 | with a seed received from the server as part of the challenge, | |
| 86 | through multiple iterations of a secure hash function to produce a | |
| 87 | one-time password. After each successful authentication, the number | |
| 88 | of secure hash function iterations is reduced by one. Thus, a unique | |
| 89 | sequence of passwords is generated. The server verifies the one-time | |
| 90 | password received from the generator by computing the secure hash | |
| 91 | function once and comparing the result with the previously accepted | |
| 92 | one-time password. This technique was first suggested by Leslie | |
| 93 | Lamport [1]. | |
| 94 | ||
| 95 | 4.0 REQUIREMENTS TERMINOLOGY | |
| 96 | ||
| 97 | In this document, the words that are used to define the significance | |
| 98 | of each particular requirement are usually capitalized. These words | |
| 99 | are: | |
| 100 | ||
| 101 | - MUST | |
| 102 | ||
| 103 | This word or the adjective "REQUIRED" means that the item is an | |
| 104 | absolute requirement of the specification. | |
| 105 | ||
| 106 | ||
| 107 | ||
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Haller Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 2289 A One-Time Password System February 1998 | |
| 116 | ||
| 117 | ||
| 118 | - SHOULD | |
| 119 | ||
| 120 | This word or the adjective "RECOMMENDED" means that there might | |
| 121 | exist valid reasons in particular circumstances to ignore this | |
| 122 | item, but the full implications should be understood and the case | |
| 123 | carefully weighed before taking a different course. | |
| 124 | ||
| 125 | - MAY | |
| 126 | ||
| 127 | This word or the adjective "OPTIONAL" means that this item is | |
| 128 | truly optional. One vendor might choose to include the item | |
| 129 | because a particular marketplace requires it or because it | |
| 130 | enhances the product, for example; another vendor may omit the | |
| 131 | same item. | |
| 132 | ||
| 133 | 5.0 SECURE HASH FUNCTION | |
| 134 | ||
| 135 | The security of the OTP system is based on the non-invertability of a | |
| 136 | secure hash function. Such a function must be tractable to compute in | |
| 137 | the forward direction, but computationally infeasible to invert. | |
| 138 | ||
| 139 | The interfaces are currently defined for three such hash algorithms, | |
| 140 | MD4 [2] and MD5 [6] by Ronald Rivest, and SHA [7] by NIST. All | |
| 141 | conforming implementations of both server and generators MUST support | |
| 142 | MD5. They SHOULD support SHA and MAY also support MD4. Clearly, the | |
| 143 | generator and server must use the same algorithm in order to | |
| 144 | interoperate. Other hash algorithms may be specified for use with | |
| 145 | this system by publishing the appropriate interfaces. | |
| 146 | ||
| 147 | The secure hash algorithms listed above have the property that they | |
| 148 | accept an input that is arbitrarily long and produce a fixed size | |
| 149 | output. The OTP system folds this output to 64 bits using the | |
| 150 | algorithms in the Appendix A. 64 bits is also the length of the one- | |
| 151 | time passwords. This is believed to be long enough to be secure and | |
| 152 | short enough to be entered manually (see below, Form of Output) when | |
| 153 | necessary. | |
| 154 | ||
| 155 | 6.0 GENERATION OF ONE-TIME PASSWORDS | |
| 156 | ||
| 157 | This section describes the generation of the one-time passwords. | |
| 158 | This process consists of an initial step in which all inputs are | |
| 159 | combined, a computation step where the secure hash function is | |
| 160 | applied a specified number of times, and an output function where the | |
| 161 | 64 bit one-time password is converted to a human readable form. | |
| 162 | ||
| 163 | Appendix C contains examples of the outputs given a collection of | |
| 164 | inputs. It provides implementors with a means of verification the | |
| 165 | use of these algorithms. | |
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Haller Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 2289 A One-Time Password System February 1998 | |
| 172 | ||
| 173 | ||
| 174 | Initial Step | |
| 175 | ||
| 176 | In principle, the user's secret pass-phrase may be of any length. To | |
| 177 | reduce the risk from techniques such as exhaustive search or | |
| 178 | dictionary attacks, character string pass-phrases MUST contain at | |
| 179 | least 10 characters (see Form of Inputs below). All implementations | |
| 180 | MUST support a pass-phrases of at least 63 characters. The secret | |
| 181 | pass-phrase is frequently, but is not required to be, textual | |
| 182 | information provided by a user. | |
| 183 | ||
| 184 | In this step, the pass phrase is concatenated with a seed that is | |
| 185 | transmitted from the server in clear text. This non-secret seed | |
| 186 | allows clients to use the same secret pass-phrase on multiple | |
| 187 | machines (using different seeds) and to safely recycle their secret | |
| 188 | pass-phrases by changing the seed. | |
| 189 | ||
| 190 | The result of the concatenation is passed through the secure hash | |
| 191 | function and then is reduced to 64 bits using one of the function | |
| 192 | dependent algorithms shown in Appendix A. | |
| 193 | ||
| 194 | Computation Step | |
| 195 | ||
| 196 | A sequence of one-time passwords is produced by applying the secure | |
| 197 | hash function multiple times to the output of the initial step | |
| 198 | (called S). That is, the first one-time password to be used is | |
| 199 | produced by passing S through the secure hash function a number of | |
| 200 | times (N) specified by the user. The next one-time password to be | |
| 201 | used is generated by passing S though the secure hash function N-1 | |
| 202 | times. An eavesdropper who has monitored the transmission of a one- | |
| 203 | time password would not be able to generate the next required | |
| 204 | password because doing so would mean inverting the hash function. | |
| 205 | ||
| 206 | Form of Inputs | |
| 207 | ||
| 208 | The secret pass-phrase is seen only by the OTP generator. To allow | |
| 209 | interchangeability of generators, all generators MUST support a | |
| 210 | secret pass-phrase of 10 to 63 characters. Implementations MAY | |
| 211 | support a longer pass-phrase, but such implementations risk the loss | |
| 212 | of interchangeability with implementations supporting only the | |
| 213 | minimum. | |
| 214 | ||
| 215 | The seed MUST consist of purely alphanumeric characters and MUST be | |
| 216 | of one to 16 characters in length. The seed is a string of characters | |
| 217 | that MUST not contain any blanks and SHOULD consist of strictly | |
| 218 | alphanumeric characters from the ISO-646 Invariant Code Set. The | |
| 219 | seed MUST be case insensitive and MUST be internally converted to | |
| 220 | lower case before it is processed. | |
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Haller Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 2289 A One-Time Password System February 1998 | |
| 228 | ||
| 229 | ||
| 230 | The sequence number and seed together constitute a larger unit of | |
| 231 | data called the challenge. The challenge gives the generator the | |
| 232 | parameters it needs to calculate the correct one-time password from | |
| 233 | the secret pass-phrase. The challenge MUST be in a standard syntax so | |
| 234 | that automated generators can recognize the challenge in context and | |
| 235 | extract these parameters. The syntax of the challenge is: | |
| 236 | ||
| 237 | otp-<algorithm identifier> <sequence integer> <seed> | |
| 238 | ||
| 239 | The three tokens MUST be separated by a white space (defined as any | |
| 240 | number of spaces and/or tabs) and the entire challenge string MUST be | |
| 241 | terminated with either a space or a new line. The string "otp-" MUST | |
| 242 | be in lower case. The algorithm identifier is case sensitive (the | |
| 243 | existing identifiers are all lower case), and the seed is case | |
| 244 | insensitive and converted before use to lower case. If additional | |
| 245 | algorithms are defined, appropriate identifiers (short, but not | |
| 246 | limited to three or four characters) must be defined. The currently | |
| 247 | defined algorithm identifiers are: | |
| 248 | ||
| 249 | md4 MD4 Message Digest | |
| 250 | md5 MD5 Message Digest | |
| 251 | sha1 NIST Secure Hash Algorithm Revision 1 | |
| 252 | ||
| 253 | An example of an OTP challenge is: otp-md5 487 dog2 | |
| 254 | ||
| 255 | Form of Output | |
| 256 | ||
| 257 | The one-time password generated by the above procedure is 64 bits in | |
| 258 | length. Entering a 64 bit number is a difficult and error prone | |
| 259 | process. Some generators insert this password into the input stream | |
| 260 | and some others make it available for system "cut and paste." Still | |
| 261 | other arrangements require the one-time password to be entered | |
| 262 | manually. The OTP system is designed to facilitate this manual entry | |
| 263 | without impeding automatic methods. The one-time password therefore | |
| 264 | MAY be converted to, and all servers MUST be capable of accepting it | |
| 265 | as, a sequence of six short (1 to 4 letter) easily typed words that | |
| 266 | only use characters from ISO-646 IVCS. Each word is chosen from a | |
| 267 | dictionary of 2048 words; at 11 bits per word, all one-time passwords | |
| 268 | may be encoded. | |
| 269 | ||
| 270 | The two extra bits in this encoding are used to store a checksum. | |
| 271 | The 64 bits of key are broken down into pairs of bits, then these | |
| 272 | pairs are summed together. The two least significant bits of this sum | |
| 273 | are encoded in the last two bits of the six word sequence with the | |
| 274 | least significant bit of the sum as the last bit encoded. All OTP | |
| 275 | generators MUST calculate this checksum and all OTP servers MUST | |
| 276 | verify this checksum explicitly as part of the operation of decoding | |
| 277 | this representation of the one-time password. | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Haller Standards Track [Page 5] | |
| 282 | ||
| 283 | RFC 2289 A One-Time Password System February 1998 | |
| 284 | ||
| 285 | ||
| 286 | Generators that produce the six-word format MUST present the words in | |
| 287 | upper case with single spaces used as separators. All servers MUST | |
| 288 | accept six-word format without regard to case and white space used as | |
| 289 | a separator. The two lines below represent the same one-time | |
| 290 | password. The first is valid as output from a generator and as input | |
| 291 | a server, the second is valid only as human input to a server. | |
| 292 | ||
| 293 | OUST COAT FOAL MUG BEAK TOTE | |
| 294 | oust coat foal mug beak tote | |
| 295 | ||
| 296 | Interoperability requires that all OTP servers and generators use | |
| 297 | the same dictionary. The standard dictionary was originally | |
| 298 | specified in the "S/KEY One Time Password System" that is described | |
| 299 | in RFC 1760 [5]. This dictionary is included in this document as | |
| 300 | Appendix D. | |
| 301 | ||
| 302 | To facilitate the implementation of smaller generators, hexadecimal | |
| 303 | output is an acceptable alternative for the presentation of the | |
| 304 | one-time password. All implementations of the server software MUST | |
| 305 | accept case-insensitive hexadecimal as well as six-word format. The | |
| 306 | hexadecimal digits may be separated by white space so servers are | |
| 307 | REQUIRED to ignore all white space. If the representation is | |
| 308 | partitioned by white space, leading zeros must be retained. | |
| 309 | Examples of hexadecimal format are: | |
| 310 | ||
| 311 | Representation Value | |
| 312 | ||
| 313 | 3503785b369cda8b 0x3503785b369cda8b | |
| 314 | e5cc a1b8 7c13 096b 0xe5cca1b87c13096b | |
| 315 | C7 48 90 F4 27 7B A1 CF 0xc74890f4277ba1cf | |
| 316 | 47 9 A68 28 4C 9D 0 1BC 0x479a68284c9d01bc | |
| 317 | ||
| 318 | In addition to accepting six-word and hexadecimal encodings of the | |
| 319 | 64 bit one-time password, servers SHOULD accept the alternate | |
| 320 | dictionary encoding described in Appendix B. The six words in this | |
| 321 | encoding MUST not overlap the set of words in the standard | |
| 322 | dictionary. To avoid ambiguity with the hexadecimal representation, | |
| 323 | words in the alternate dictionary MUST not be comprised solely of | |
| 324 | the letters A-F. Decoding words thus encoded does not require any | |
| 325 | knowledge of the alternative dictionary used so the acceptance of | |
| 326 | any alternate dictionary implies the acceptance of all alternate | |
| 327 | dictionaries. Words in the alternative dictionaries are case | |
| 328 | sensitive. Generators and servers MUST preserve the case in the | |
| 329 | processing of these words. | |
| 330 | ||
| 331 | In summary, all conforming servers MUST accept six-word input that | |
| 332 | uses the Standard Dictionary (RFC 1760 and Appendix D), MUST accept | |
| 333 | hexadecimal encoding, and SHOULD accept six-word input that uses the | |
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Haller Standards Track [Page 6] | |
| 338 | ||
| 339 | RFC 2289 A One-Time Password System February 1998 | |
| 340 | ||
| 341 | ||
| 342 | Alternative Dictionary technique (Appendix B). As there is a remote | |
| 343 | possibility that a hexadecimal encoding of a one-time password will | |
| 344 | look like a valid six-word standard dictionary encoding, all | |
| 345 | implementations MUST use the following scheme. If a six-word | |
| 346 | encoded one-time password is valid, it is accepted. Otherwise, if | |
| 347 | the one-time password can be interpreted as hexadecimal, and with | |
| 348 | that decoding it is valid, then it is accepted. | |
| 349 | ||
| 350 | 7.0 VERIFICATION OF ONE-TIME PASSWORDS | |
| 351 | ||
| 352 | An application on the server system that requires OTP authentication | |
| 353 | is expected to issue an OTP challenge as described above. Given the | |
| 354 | parameters from this challenge and the secret pass-phrase, the | |
| 355 | generator can compute (or lookup) the one-time password that is | |
| 356 | passed to the server to be verified. | |
| 357 | ||
| 358 | The server system has a database containing, for each user, the | |
| 359 | one-time password from the last successful authentication or the | |
| 360 | first OTP of a newly initialized sequence. To authenticate the user, | |
| 361 | the server decodes the one-time password received from the generator | |
| 362 | into a 64-bit key and then runs this key through the secure hash | |
| 363 | function once. If the result of this operation matches the stored | |
| 364 | previous OTP, the authentication is successful and the accepted | |
| 365 | one-time password is stored for future use. | |
| 366 | ||
| 367 | 8.0 PASS-PHRASE CHANGES | |
| 368 | ||
| 369 | Because the number of hash function applications executed by the | |
| 370 | generator decreases by one each time, at some point the user must | |
| 371 | reinitialize the system or be unable to authenticate. | |
| 372 | ||
| 373 | Although some installations may not permit users to initialize | |
| 374 | remotely, implementations MUST provide a means to do so that does | |
| 375 | not reveal the user's secret pass-phrase. One way is to provide a | |
| 376 | means to reinitialize the sequence through explicit specification | |
| 377 | of the first one-time password. | |
| 378 | ||
| 379 | When the sequence of one-time passwords is reinitialized, | |
| 380 | implementations MUST verify that the seed or the pass-phrase is | |
| 381 | changed. Installations SHOULD discourage any operation that sends | |
| 382 | the secret pass-phrase over a network in clear-text as such practice | |
| 383 | defeats the concept of a one-time password. | |
| 384 | ||
| 385 | Implementations MAY use the following technique for | |
| 386 | [re]initialization: | |
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Haller Standards Track [Page 7] | |
| 394 | ||
| 395 | RFC 2289 A One-Time Password System February 1998 | |
| 396 | ||
| 397 | ||
| 398 | o The user picks a new seed and hash count (default values may | |
| 399 | be offered). The user provides these, along with the | |
| 400 | corresponding generated one-time password, to the host system. | |
| 401 | ||
| 402 | o The user MAY also provide the corresponding generated one | |
| 403 | time password for count-1 as an error check. | |
| 404 | ||
| 405 | o The user SHOULD provide the generated one-time password for | |
| 406 | the old seed and old hash count to protect an idle terminal | |
| 407 | or workstation (this implies that when the count is 1, the | |
| 408 | user can login but cannot then change the seed or count). | |
| 409 | ||
| 410 | In the future a specific protocol may be defined for | |
| 411 | reinitialization that will permit smooth and possibly automated | |
| 412 | interoperation of all hosts and generators. | |
| 413 | ||
| 414 | 9.0 PROTECTION AGAINST RACE ATTACK | |
| 415 | ||
| 416 | All conforming server implementations MUST protect against the race | |
| 417 | condition described in this section. A defense against this attack | |
| 418 | is outlined; implementations MAY use this approach or MAY select an | |
| 419 | alternative defense. | |
| 420 | ||
| 421 | It is possible for an attacker to listen to most of a one-time | |
| 422 | password, guess the remainder, and then race the legitimate user to | |
| 423 | complete the authentication. Multiple guesses against the last word | |
| 424 | of the six-word format are likely to succeed. | |
| 425 | ||
| 426 | One possible defense is to prevent a user from starting multiple | |
| 427 | simultaneous authentication sessions. This means that once the | |
| 428 | legitimate user has initiated authentication, an attacker would be | |
| 429 | blocked until the first authentication process has completed. In | |
| 430 | this approach, a timeout is necessary to thwart a denial of service | |
| 431 | attack. | |
| 432 | ||
| 433 | 10.0 SECURITY CONSIDERATIONS | |
| 434 | ||
| 435 | This entire document discusses an authentication system that | |
| 436 | improves security by limiting the danger of eavesdropping/replay | |
| 437 | attacks that have been used against simple password systems [4]. | |
| 438 | ||
| 439 | The use of the OTP system only provides protections against passive | |
| 440 | eavesdropping/replay attacks. It does not provide for the privacy | |
| 441 | of transmitted data, and it does not provide protection against | |
| 442 | active attacks such as session hijacking that are known to be | |
| 443 | present in the current Internet [9]. The use of IP Security | |
| 444 | (IPsec), see [10], [11], and [12] is recommended to protect against | |
| 445 | TCP session hijacking. | |
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Haller Standards Track [Page 8] | |
| 450 | ||
| 451 | RFC 2289 A One-Time Password System February 1998 | |
| 452 | ||
| 453 | ||
| 454 | The success of the OTP system to protect host systems is dependent | |
| 455 | on the non-invertability of the secure hash functions used. To our | |
| 456 | knowledge, none of the hash algorithms have been broken, but it is | |
| 457 | generally believed [6] that MD4 is not as strong as MD5. If a | |
| 458 | server supports multiple hash algorithms, it is only as secure as | |
| 459 | the weakest algorithm. | |
| 460 | ||
| 461 | 11.0 ACKNOWLEDGMENTS | |
| 462 | ||
| 463 | The idea behind OTP authentication was first proposed by Leslie | |
| 464 | Lamport [1]. Bellcore's S/KEY system, from which OTP is derived, was | |
| 465 | proposed by Phil Karn, who also wrote most of the Bellcore reference | |
| 466 | implementation. | |
| 467 | ||
| 468 | 12.0 REFERENCES | |
| 469 | ||
| 470 | [1] Leslie Lamport, "Password Authentication with Insecure | |
| 471 | Communication", Communications of the ACM 24.11 (November | |
| 472 | 1981), 770-772 | |
| 473 | ||
| 474 | [2] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, | |
| 475 | April 1992. | |
| 476 | ||
| 477 | [3] Neil Haller, "The S/KEY One-Time Password System", Proceedings | |
| 478 | of the ISOC Symposium on Network and Distributed System | |
| 479 | Security, February 1994, San Diego, CA | |
| 480 | ||
| 481 | [4] Haller, N., and R. Atkinson, "On Internet Authentication", | |
| 482 | RFC 1704, October 1994. | |
| 483 | ||
| 484 | [5] Haller, N., "The S/KEY One-Time Password System", | |
| 485 | RFC 1760, February 1995. | |
| 486 | ||
| 487 | [6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |
| 488 | April 1992. | |
| 489 | ||
| 490 | [7] National Institute of Standards and Technology (NIST), | |
| 491 | "Announcing the Secure Hash Standard", FIPS 180-1, U.S. | |
| 492 | Department of Commerce, April 1995. | |
| 493 | ||
| 494 | [8] International Standard - Information Processing -- ISO 7-bit | |
| 495 | coded character set for information interchange (Invariant Code | |
| 496 | Set), ISO-646, International Standards Organization, Geneva, | |
| 497 | Switzerland, 1983 | |
| 498 | ||
| 499 | ||
| 500 | ||
| 501 | ||
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Haller Standards Track [Page 9] | |
| 506 | ||
| 507 | RFC 2289 A One-Time Password System February 1998 | |
| 508 | ||
| 509 | ||
| 510 | [9] Computer Emergency Response Team (CERT), "IP Spoofing and | |
| 511 | Hijacked Terminal Connections", CA-95:01, January 1995. | |
| 512 | Available via anonymous ftp from info.cert.org in | |
| 513 | /pub/cert_advisories. | |
| 514 | ||
| 515 | [10] Atkinson, R., "Security Architecture for the Internet Protocol", | |
| 516 | RFC 1825, August 1995. | |
| 517 | ||
| 518 | [11] Atkinson, R., "IP Authentication Header", RFC 1826, August | |
| 519 | 1995. | |
| 520 | ||
| 521 | [12] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC | |
| 522 | 1827, August 1995. | |
| 523 | ||
| 524 | ||
| 525 | ||
| 526 | ||
| 527 | ||
| 528 | ||
| 529 | ||
| 530 | ||
| 531 | ||
| 532 | ||
| 533 | ||
| 534 | ||
| 535 | ||
| 536 | ||
| 537 | ||
| 538 | ||
| 539 | ||
| 540 | ||
| 541 | ||
| 542 | ||
| 543 | ||
| 544 | ||
| 545 | ||
| 546 | ||
| 547 | ||
| 548 | ||
| 549 | ||
| 550 | ||
| 551 | ||
| 552 | ||
| 553 | ||
| 554 | ||
| 555 | ||
| 556 | ||
| 557 | ||
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Haller Standards Track [Page 10] | |
| 562 | ||
| 563 | RFC 2289 A One-Time Password System February 1998 | |
| 564 | ||
| 565 | ||
| 566 | 13.0 AUTHORS' ADDRESSES | |
| 567 | ||
| 568 | Neil Haller | |
| 569 | Bellcore | |
| 570 | MCC 1C-265B | |
| 571 | 445 South Street | |
| 572 | Morristown, NJ, 07960-6438, USA | |
| 573 | ||
| 574 | Phone: +1 201 829-4478 | |
| 575 | Fax: +1 201 829-2504 | |
| 576 | EMail: nmh@bellcore.com | |
| 577 | ||
| 578 | ||
| 579 | Craig Metz | |
| 580 | Kaman Sciences Corporation | |
| 581 | For NRL Code 5544 | |
| 582 | 4555 Overlook Avenue, S.W. | |
| 583 | Washington, DC, 20375-5337, USA | |
| 584 | ||
| 585 | Phone: +1 202 404-7122 | |
| 586 | Fax: +1 202 404-7942 | |
| 587 | EMail: cmetz@cs.nrl.navy.mil | |
| 588 | ||
| 589 | ||
| 590 | Philip J. Nesser II | |
| 591 | Nesser & Nesser Consulting | |
| 592 | 13501 100th Ave NE | |
| 593 | Suite 5202 | |
| 594 | Kirkland, WA 98034, USA | |
| 595 | ||
| 596 | Phone: +1 206 481 4303 | |
| 597 | EMail: pjnesser@martigny.ai.mit.edu | |
| 598 | ||
| 599 | ||
| 600 | Mike Straw | |
| 601 | Bellcore | |
| 602 | RRC 1A-225 | |
| 603 | 445 Hoes Lane | |
| 604 | Piscataway, NJ 08854-4182 | |
| 605 | ||
| 606 | Phone: +1 908 699-5212 | |
| 607 | EMail: mess@bellcore.com | |
| 608 | ||
| 609 | ||
| 610 | ||
| 611 | ||
| 612 | ||
| 613 | ||
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | Haller Standards Track [Page 11] | |
| 618 | ||
| 619 | RFC 2289 A One-Time Password System February 1998 | |
| 620 | ||
| 621 | ||
| 622 | Appendix A - Interfaces to Secure Hash Algorithms | |
| 623 | ||
| 624 | Original interoperability tests provided valuable insights into the | |
| 625 | subtle problems which occur when converting protocol specifications | |
| 626 | into running code. In particular, the manipulation of bit ordered | |
| 627 | data is dependent on the architecture of the hardware, specifically | |
| 628 | the way in which a computer stores multi-byte data. The method is | |
| 629 | typically called big or little "endian." A big endian machine stores | |
| 630 | data with the most significant byte first, while a little endian | |
| 631 | machine stores the least significant byte first. Thus, on a big | |
| 632 | endian machine data is stored left to right, while little endian | |
| 633 | machines store data right to left. | |
| 634 | ||
| 635 | For example, the four byte value 0x11AABBCC is stored in a big endian | |
| 636 | machine as the following series of four bytes, "0x11", "0xAA", | |
| 637 | "0xBB", and "0xCC", while on a little endian machine the value would | |
| 638 | be stored as "0xCC", "0xBB", "0xAA", and "0x11". | |
| 639 | ||
| 640 | For historical reasons, and to promote interoperability with existing | |
| 641 | implementations, it was decided that ALL hashes incorporated into the | |
| 642 | OTP protocol MUST store the output of their hash function in LITTLE | |
| 643 | ENDIAN format BEFORE the bit folding to 64 bits occurs. This is done | |
| 644 | in the implementations of MD4 and MD5 (see references [2] and [6]), | |
| 645 | while it must be explicitly done for the implementation of SHA1 (see | |
| 646 | reference [7]). | |
| 647 | ||
| 648 | Any future hash functions implemented into the OTP protocol SHOULD | |
| 649 | provide a similar reference fragment of code to allow independent | |
| 650 | implementations to operate successfully. | |
| 651 | ||
| 652 | ||
| 653 | MD4 Message Digest (see reference [2]) | |
| 654 | ||
| 655 | MD4_CTX md; | |
| 656 | unsigned char result[16]; | |
| 657 | ||
| 658 | strcpy(buf, seed); /* seed must be in lower case */ | |
| 659 | strcat(buf, passwd); | |
| 660 | MD4Init(&md); | |
| 661 | MD4Update(&md, (unsigned char *)buf, strlen(buf)); | |
| 662 | MD4Final(result, &md); | |
| 663 | ||
| 664 | /* Fold the 128 bit result to 64 bits */ | |
| 665 | for (i = 0; i < 8; i++) | |
| 666 | result[i] ^= result[i+8]; | |
| 667 | ||
| 668 | ||
| 669 | ||
| 670 | ||
| 671 | ||
| 672 | ||
| 673 | Haller Standards Track [Page 12] | |
| 674 | ||
| 675 | RFC 2289 A One-Time Password System February 1998 | |
| 676 | ||
| 677 | ||
| 678 | MD5 Message Digest (see reference [6]) | |
| 679 | ||
| 680 | MD5_CTX md; | |
| 681 | unsigned char result[16]; | |
| 682 | strcpy(buf, seed); /* seed must be in lower case */ | |
| 683 | strcat(buf, passwd); | |
| 684 | MD5Init(&md); | |
| 685 | MD5Update(&md, (unsigned char *)buf, strlen(buf)); | |
| 686 | MD5Final(result, &md); | |
| 687 | ||
| 688 | /* Fold the 128 bit result to 64 bits */ | |
| 689 | for (i = 0; i < 8; i++) | |
| 690 | result[i] ^= result[i+8]; | |
| 691 | ||
| 692 | ||
| 693 | SHA Secure Hash Algorithm (see reference [7]) | |
| 694 | ||
| 695 | SHA_INFO sha; | |
| 696 | unsigned char result[16]; | |
| 697 | strcpy(buf, seed); /* seed must be in lower case */ | |
| 698 | strcat(buf, passwd); | |
| 699 | sha_init(&sha); | |
| 700 | sha_update(&sha, (unsigned char *)buf, strlen(buf)); | |
| 701 | sha_final(&sha); /* NOTE: no result buffer */ | |
| 702 | ||
| 703 | /* Fold the 160 bit result to 64 bits */ | |
| 704 | sha.digest[0] ^= sha.digest[2]; | |
| 705 | sha.digest[1] ^= sha.digest[3]; | |
| 706 | sha.digest[0] ^= sha.digest[4]; | |
| 707 | ||
| 708 | /* | |
| 709 | * copy the resulting 64 bits to the result buffer in little endian | |
| 710 | * fashion (analogous to the way MD4Final() and MD5Final() do). | |
| 711 | */ | |
| 712 | for (i = 0, j = 0; j < 8; i++, j += 4) | |
| 713 | { | |
| 714 | result[j] = (unsigned char)(sha.digest[i] & 0xff); | |
| 715 | result[j+1] = (unsigned char)((sha.digest[i] >> 8) & 0xff); | |
| 716 | result[j+2] = (unsigned char)((sha.digest[i] >> 16) & 0xff); | |
| 717 | result[j+3] = (unsigned char)((sha.digest[i] >> 24) & 0xff); | |
| 718 | } | |
| 719 | ||
| 720 | ||
| 721 | ||
| 722 | ||
| 723 | ||
| 724 | ||
| 725 | ||
| 726 | ||
| 727 | ||
| 728 | ||
| 729 | Haller Standards Track [Page 13] | |
| 730 | ||
| 731 | RFC 2289 A One-Time Password System February 1998 | |
| 732 | ||
| 733 | ||
| 734 | Appendix B - Alternative Dictionary Algorithm | |
| 735 | ||
| 736 | The purpose of alternative dictionary encoding of the OTP one-time | |
| 737 | password is to allow the use of language specific or friendly words. | |
| 738 | As case translation is not always well defined, the alternative | |
| 739 | dictionary encoding is case sensitive. Servers SHOULD accept this | |
| 740 | encoding in addition to the standard 6-word and hexadecimal | |
| 741 | encodings. | |
| 742 | ||
| 743 | ||
| 744 | GENERATOR ENCODING USING AN ALTERNATE DICTIONARY | |
| 745 | ||
| 746 | The standard 6-word encoding uses the placement of a word in the | |
| 747 | dictionary to represent an 11-bit number. The 64-bit one-time | |
| 748 | password can then be represented by six words. | |
| 749 | ||
| 750 | An alternative dictionary of 2048 words may be created such that | |
| 751 | each word W and position of the word in the dictionary N obey the | |
| 752 | relationship: | |
| 753 | ||
| 754 | alg( W ) % 2048 == N | |
| 755 | where | |
| 756 | alg is the hash algorithm used (e.g. MD4, MD5, SHA1). | |
| 757 | ||
| 758 | In addition, no words in the standard dictionary may be chosen. | |
| 759 | ||
| 760 | The generator expands the 64-bit one-time password to 66 bits by | |
| 761 | computing parity as with the standard 6-word encoding. The six 11- | |
| 762 | bit numbers are then converted to words using the dictionary that | |
| 763 | was created such that the above relationship holds. | |
| 764 | ||
| 765 | SERVER DECODING OF ALTERNATE DICTIONARY ONE-TIME PASSWORDS | |
| 766 | ||
| 767 | The server accepting alternative dictionary encoding converts each | |
| 768 | word to an 11-bit number using the above encoding. These numbers | |
| 769 | are then used in the same way as the decoded standard dictionary | |
| 770 | words to form the 66-bit one-time password. | |
| 771 | ||
| 772 | The server does not need to have access to the alternate dictionary | |
| 773 | that was used to create the one-time password it is authenticating. | |
| 774 | This is because the decoding from word to 11-bit number does not | |
| 775 | make any use of the dictionary. As a result of the independence of | |
| 776 | the dictionary, a server accepting one alternate dictionary accept | |
| 777 | all alternate dictionaries. | |
| 778 | ||
| 779 | ||
| 780 | ||
| 781 | ||
| 782 | ||
| 783 | ||
| 784 | ||
| 785 | Haller Standards Track [Page 14] | |
| 786 | ||
| 787 | RFC 2289 A One-Time Password System February 1998 | |
| 788 | ||
| 789 | ||
| 790 | Appendix C - OTP Verification Examples | |
| 791 | ||
| 792 | This appendix provides a series of inputs and correct outputs for all | |
| 793 | three of the defined OTP cryptographic hashes, specifically MD4, MD5, | |
| 794 | and SHA1. This document is intended to be used by developers for | |
| 795 | interoperability checks when creating generators or servers. Output | |
| 796 | is provided in both hexadecimal notation and the six word encoding | |
| 797 | documented in Appendix D. | |
| 798 | ||
| 799 | GENERAL CHECKS | |
| 800 | ||
| 801 | Note that the output given for these checks is not intended to be | |
| 802 | taken literally, but describes the type of action that should be | |
| 803 | taken. | |
| 804 | ||
| 805 | Pass Phrase Length | |
| 806 | ||
| 807 | Input: | |
| 808 | Pass Phrase: Too_short | |
| 809 | Seed: iamvalid | |
| 810 | Count: 99 | |
| 811 | Hash: ANY | |
| 812 | Output: | |
| 813 | ERROR: Pass Phrase too short | |
| 814 | ||
| 815 | Input: | |
| 816 | Pass Phrase: | |
| 817 | 1234567890123456789012345678901234567890123456789012345678901234 | |
| 818 | Seed: iamvalid | |
| 819 | Count: 99 | |
| 820 | Hash: ANY | |
| 821 | Output: | |
| 822 | WARNING: Pass Phrase longer than the recommended maximum length of | |
| 823 | 63 | |
| 824 | ||
| 825 | Seed Values | |
| 826 | ||
| 827 | Input: | |
| 828 | Pass Phrase: A_Valid_Pass_Phrase | |
| 829 | Seed: Length_Okay | |
| 830 | Count: 99 | |
| 831 | Hash: ANY | |
| 832 | Output: | |
| 833 | ERROR: Seed must be purely alphanumeric | |
| 834 | ||
| 835 | Input: | |
| 836 | Pass Phrase: A_Valid_Pass_Phrase | |
| 837 | Seed: LengthOfSeventeen | |
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | Haller Standards Track [Page 15] | |
| 842 | ||
| 843 | RFC 2289 A One-Time Password System February 1998 | |
| 844 | ||
| 845 | ||
| 846 | Count: 99 | |
| 847 | Hash: ANY | |
| 848 | ||
| 849 | Output: | |
| 850 | ERROR: Seed must be between 1 and 16 characters in length | |
| 851 | ||
| 852 | Input: | |
| 853 | Pass Phrase: A_Valid_Pass_Phrase | |
| 854 | Seed: A Seed | |
| 855 | Count: 99 | |
| 856 | Hash: ANY | |
| 857 | Output: | |
| 858 | ERROR: Seed must not contain any spaces | |
| 859 | ||
| 860 | Parity Calculations | |
| 861 | ||
| 862 | Input: | |
| 863 | Pass Phrase: A_Valid_Pass_Phrase | |
| 864 | Seed: AValidSeed | |
| 865 | Count: 99 | |
| 866 | Hash: MD5 | |
| 867 | Output: | |
| 868 | Hex: 85c43ee03857765b | |
| 869 | Six Word(CORRECT): FOWL KID MASH DEAD DUAL OAF | |
| 870 | Six Word(INCORRECT PARITY): FOWL KID MASH DEAD DUAL NUT | |
| 871 | Six Word(INCORRECT PARITY): FOWL KID MASH DEAD DUAL O | |
| 872 | Six Word(INCORRECT PARITY): FOWL KID MASH DEAD DUAL OAK | |
| 873 | ||
| 874 | ||
| 875 | ||
| 876 | ||
| 877 | ||
| 878 | ||
| 879 | ||
| 880 | ||
| 881 | ||
| 882 | ||
| 883 | ||
| 884 | ||
| 885 | ||
| 886 | ||
| 887 | ||
| 888 | ||
| 889 | ||
| 890 | ||
| 891 | ||
| 892 | ||
| 893 | ||
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | Haller Standards Track [Page 16] | |
| 898 | ||
| 899 | RFC 2289 A One-Time Password System February 1998 | |
| 900 | ||
| 901 | ||
| 902 | MD4 ENCODINGS | |
| 903 | ||
| 904 | Pass Phrase Seed Cnt Hex Six Word Format | |
| 905 | ======================================================================== | |
| 906 | This is a test. TeSt 0 D185 4218 EBBB 0B51 | |
| 907 | ROME MUG FRED SCAN LIVE LACE | |
| 908 | This is a test. TeSt 1 6347 3EF0 1CD0 B444 | |
| 909 | CARD SAD MINI RYE COL KIN | |
| 910 | This is a test. TeSt 99 C5E6 1277 6E6C 237A | |
| 911 | NOTE OUT IBIS SINK NAVE MODE | |
| 912 | AbCdEfGhIjK alpha1 0 5007 6F47 EB1A DE4E | |
| 913 | AWAY SEN ROOK SALT LICE MAP | |
| 914 | AbCdEfGhIjK alpha1 1 65D2 0D19 49B5 F7AB | |
| 915 | CHEW GRIM WU HANG BUCK SAID | |
| 916 | AbCdEfGhIjK alpha1 99 D150 C82C CE6F 62D1 | |
| 917 | ROIL FREE COG HUNK WAIT COCA | |
| 918 | OTP's are good correct 0 849C 79D4 F6F5 5388 | |
| 919 | FOOL STEM DONE TOOL BECK NILE | |
| 920 | OTP's are good correct 1 8C09 92FB 2508 47B1 | |
| 921 | GIST AMOS MOOT AIDS FOOD SEEM | |
| 922 | OTP's are good correct 99 3F3B F4B4 145F D74B | |
| 923 | TAG SLOW NOV MIN WOOL KENO | |
| 924 | ||
| 925 | ||
| 926 | ||
| 927 | ||
| 928 | ||
| 929 | ||
| 930 | ||
| 931 | ||
| 932 | ||
| 933 | ||
| 934 | ||
| 935 | ||
| 936 | ||
| 937 | ||
| 938 | ||
| 939 | ||
| 940 | ||
| 941 | ||
| 942 | ||
| 943 | ||
| 944 | ||
| 945 | ||
| 946 | ||
| 947 | ||
| 948 | ||
| 949 | ||
| 950 | ||
| 951 | ||
| 952 | ||
| 953 | Haller Standards Track [Page 17] | |
| 954 | ||
| 955 | RFC 2289 A One-Time Password System February 1998 | |
| 956 | ||
| 957 | ||
| 958 | MD5 ENCODINGS | |
| 959 | ||
| 960 | Pass Phrase Seed Cnt Hex Six Word Format | |
| 961 | ======================================================================== | |
| 962 | This is a test. TeSt 0 9E87 6134 D904 99DD | |
| 963 | INCH SEA ANNE LONG AHEM TOUR | |
| 964 | This is a test. TeSt 1 7965 E054 36F5 029F | |
| 965 | EASE OIL FUM CURE AWRY AVIS | |
| 966 | This is a test. TeSt 99 50FE 1962 C496 5880 | |
| 967 | BAIL TUFT BITS GANG CHEF THY | |
| 968 | AbCdEfGhIjK alpha1 0 8706 6DD9 644B F206 | |
| 969 | FULL PEW DOWN ONCE MORT ARC | |
| 970 | AbCdEfGhIjK alpha1 1 7CD3 4C10 40AD D14B | |
| 971 | FACT HOOF AT FIST SITE KENT | |
| 972 | AbCdEfGhIjK alpha1 99 5AA3 7A81 F212 146C | |
| 973 | BODE HOP JAKE STOW JUT RAP | |
| 974 | OTP's are good correct 0 F205 7539 43DE 4CF9 | |
| 975 | ULAN NEW ARMY FUSE SUIT EYED | |
| 976 | OTP's are good correct 1 DDCD AC95 6F23 4937 | |
| 977 | SKIM CULT LOB SLAM POE HOWL | |
| 978 | OTP's are good correct 99 B203 E28F A525 BE47 | |
| 979 | LONG IVY JULY AJAR BOND LEE | |
| 980 | ||
| 981 | ||
| 982 | SHA1 ENCODINGS | |
| 983 | ||
| 984 | Pass Phrase Seed Cnt Hex Six Word Format | |
| 985 | ======================================================================== | |
| 986 | This is a test. TeSt 0 BB9E 6AE1 979D 8FF4 | |
| 987 | MILT VARY MAST OK SEES WENT | |
| 988 | This is a test. TeSt 1 63D9 3663 9734 385B | |
| 989 | CART OTTO HIVE ODE VAT NUT | |
| 990 | This is a test. TeSt 99 87FE C776 8B73 CCF9 | |
| 991 | GAFF WAIT SKID GIG SKY EYED | |
| 992 | AbCdEfGhIjK alpha1 0 AD85 F658 EBE3 83C9 | |
| 993 | LEST OR HEEL SCOT ROB SUIT | |
| 994 | AbCdEfGhIjK alpha1 1 D07C E229 B5CF 119B | |
| 995 | RITE TAKE GELD COST TUNE RECK | |
| 996 | AbCdEfGhIjK alpha1 99 27BC 7103 5AAF 3DC6 | |
| 997 | MAY STAR TIN LYON VEDA STAN | |
| 998 | OTP's are good correct 0 D51F 3E99 BF8E 6F0B | |
| 999 | RUST WELT KICK FELL TAIL FRAU | |
| 1000 | OTP's are good correct 1 82AE B52D 9437 74E4 | |
| 1001 | FLIT DOSE ALSO MEW DRUM DEFY | |
| 1002 | OTP's are good correct 99 4F29 6A74 FE15 67EC | |
| 1003 | AURA ALOE HURL WING BERG WAIT | |
| 1004 | ||
| 1005 | ||
| 1006 | ||
| 1007 | ||
| 1008 | ||
| 1009 | Haller Standards Track [Page 18] | |
| 1010 | ||
| 1011 | RFC 2289 A One-Time Password System February 1998 | |
| 1012 | ||
| 1013 | ||
| 1014 | Appendix D - Dictionary for Converting Between 6-Word and Binary Formats | |
| 1015 | ||
| 1016 | This dictionary is from the module put.c in the original Bellcore | |
| 1017 | reference distribution. | |
| 1018 | ||
| 1019 | { "A", "ABE", "ACE", "ACT", "AD", "ADA", "ADD", | |
| 1020 | "AGO", "AID", "AIM", "AIR", "ALL", "ALP", "AM", "AMY", | |
| 1021 | "AN", "ANA", "AND", "ANN", "ANT", "ANY", "APE", "APS", | |
| 1022 | "APT", "ARC", "ARE", "ARK", "ARM", "ART", "AS", "ASH", | |
| 1023 | "ASK", "AT", "ATE", "AUG", "AUK", "AVE", "AWE", "AWK", | |
| 1024 | "AWL", "AWN", "AX", "AYE", "BAD", "BAG", "BAH", "BAM", | |
| 1025 | "BAN", "BAR", "BAT", "BAY", "BE", "BED", "BEE", "BEG", | |
| 1026 | "BEN", "BET", "BEY", "BIB", "BID", "BIG", "BIN", "BIT", | |
| 1027 | "BOB", "BOG", "BON", "BOO", "BOP", "BOW", "BOY", "BUB", | |
| 1028 | "BUD", "BUG", "BUM", "BUN", "BUS", "BUT", "BUY", "BY", | |
| 1029 | "BYE", "CAB", "CAL", "CAM", "CAN", "CAP", "CAR", "CAT", | |
| 1030 | "CAW", "COD", "COG", "COL", "CON", "COO", "COP", "COT", | |
| 1031 | "COW", "COY", "CRY", "CUB", "CUE", "CUP", "CUR", "CUT", | |
| 1032 | "DAB", "DAD", "DAM", "DAN", "DAR", "DAY", "DEE", "DEL", | |
| 1033 | "DEN", "DES", "DEW", "DID", "DIE", "DIG", "DIN", "DIP", | |
| 1034 | "DO", "DOE", "DOG", "DON", "DOT", "DOW", "DRY", "DUB", | |
| 1035 | "DUD", "DUE", "DUG", "DUN", "EAR", "EAT", "ED", "EEL", | |
| 1036 | "EGG", "EGO", "ELI", "ELK", "ELM", "ELY", "EM", "END", | |
| 1037 | "EST", "ETC", "EVA", "EVE", "EWE", "EYE", "FAD", "FAN", | |
| 1038 | "FAR", "FAT", "FAY", "FED", "FEE", "FEW", "FIB", "FIG", | |
| 1039 | "FIN", "FIR", "FIT", "FLO", "FLY", "FOE", "FOG", "FOR", | |
| 1040 | "FRY", "FUM", "FUN", "FUR", "GAB", "GAD", "GAG", "GAL", | |
| 1041 | "GAM", "GAP", "GAS", "GAY", "GEE", "GEL", "GEM", "GET", | |
| 1042 | "GIG", "GIL", "GIN", "GO", "GOT", "GUM", "GUN", "GUS", | |
| 1043 | "GUT", "GUY", "GYM", "GYP", "HA", "HAD", "HAL", "HAM", | |
| 1044 | "HAN", "HAP", "HAS", "HAT", "HAW", "HAY", "HE", "HEM", | |
| 1045 | "HEN", "HER", "HEW", "HEY", "HI", "HID", "HIM", "HIP", | |
| 1046 | "HIS", "HIT", "HO", "HOB", "HOC", "HOE", "HOG", "HOP", | |
| 1047 | "HOT", "HOW", "HUB", "HUE", "HUG", "HUH", "HUM", "HUT", | |
| 1048 | "I", "ICY", "IDA", "IF", "IKE", "ILL", "INK", "INN", | |
| 1049 | "IO", "ION", "IQ", "IRA", "IRE", "IRK", "IS", "IT", | |
| 1050 | "ITS", "IVY", "JAB", "JAG", "JAM", "JAN", "JAR", "JAW", | |
| 1051 | "JAY", "JET", "JIG", "JIM", "JO", "JOB", "JOE", "JOG", | |
| 1052 | "JOT", "JOY", "JUG", "JUT", "KAY", "KEG", "KEN", "KEY", | |
| 1053 | "KID", "KIM", "KIN", "KIT", "LA", "LAB", "LAC", "LAD", | |
| 1054 | "LAG", "LAM", "LAP", "LAW", "LAY", "LEA", "LED", "LEE", | |
| 1055 | "LEG", "LEN", "LEO", "LET", "LEW", "LID", "LIE", "LIN", | |
| 1056 | "LIP", "LIT", "LO", "LOB", "LOG", "LOP", "LOS", "LOT", | |
| 1057 | "LOU", "LOW", "LOY", "LUG", "LYE", "MA", "MAC", "MAD", | |
| 1058 | "MAE", "MAN", "MAO", "MAP", "MAT", "MAW", "MAY", "ME", | |
| 1059 | "MEG", "MEL", "MEN", "MET", "MEW", "MID", "MIN", "MIT", | |
| 1060 | "MOB", "MOD", "MOE", "MOO", "MOP", "MOS", "MOT", "MOW", | |
| 1061 | "MUD", "MUG", "MUM", "MY", "NAB", "NAG", "NAN", "NAP", | |
| 1062 | ||
| 1063 | ||
| 1064 | ||
| 1065 | Haller Standards Track [Page 19] | |
| 1066 | ||
| 1067 | RFC 2289 A One-Time Password System February 1998 | |
| 1068 | ||
| 1069 | ||
| 1070 | "NAT", "NAY", "NE", "NED", "NEE", "NET", "NEW", "NIB", | |
| 1071 | "NIL", "NIP", "NIT", "NO", "NOB", "NOD", "NON", "NOR", | |
| 1072 | "NOT", "NOV", "NOW", "NU", "NUN", "NUT", "O", "OAF", | |
| 1073 | "OAK", "OAR", "OAT", "ODD", "ODE", "OF", "OFF", "OFT", | |
| 1074 | "OH", "OIL", "OK", "OLD", "ON", "ONE", "OR", "ORB", | |
| 1075 | "ORE", "ORR", "OS", "OTT", "OUR", "OUT", "OVA", "OW", | |
| 1076 | "OWE", "OWL", "OWN", "OX", "PA", "PAD", "PAL", "PAM", | |
| 1077 | "PAN", "PAP", "PAR", "PAT", "PAW", "PAY", "PEA", "PEG", | |
| 1078 | "PEN", "PEP", "PER", "PET", "PEW", "PHI", "PI", "PIE", | |
| 1079 | "PIN", "PIT", "PLY", "PO", "POD", "POE", "POP", "POT", | |
| 1080 | "POW", "PRO", "PRY", "PUB", "PUG", "PUN", "PUP", "PUT", | |
| 1081 | "QUO", "RAG", "RAM", "RAN", "RAP", "RAT", "RAW", "RAY", | |
| 1082 | "REB", "RED", "REP", "RET", "RIB", "RID", "RIG", "RIM", | |
| 1083 | "RIO", "RIP", "ROB", "ROD", "ROE", "RON", "ROT", "ROW", | |
| 1084 | "ROY", "RUB", "RUE", "RUG", "RUM", "RUN", "RYE", "SAC", | |
| 1085 | "SAD", "SAG", "SAL", "SAM", "SAN", "SAP", "SAT", "SAW", | |
| 1086 | "SAY", "SEA", "SEC", "SEE", "SEN", "SET", "SEW", "SHE", | |
| 1087 | "SHY", "SIN", "SIP", "SIR", "SIS", "SIT", "SKI", "SKY", | |
| 1088 | "SLY", "SO", "SOB", "SOD", "SON", "SOP", "SOW", "SOY", | |
| 1089 | "SPA", "SPY", "SUB", "SUD", "SUE", "SUM", "SUN", "SUP", | |
| 1090 | "TAB", "TAD", "TAG", "TAN", "TAP", "TAR", "TEA", "TED", | |
| 1091 | "TEE", "TEN", "THE", "THY", "TIC", "TIE", "TIM", "TIN", | |
| 1092 | "TIP", "TO", "TOE", "TOG", "TOM", "TON", "TOO", "TOP", | |
| 1093 | "TOW", "TOY", "TRY", "TUB", "TUG", "TUM", "TUN", "TWO", | |
| 1094 | "UN", "UP", "US", "USE", "VAN", "VAT", "VET", "VIE", | |
| 1095 | "WAD", "WAG", "WAR", "WAS", "WAY", "WE", "WEB", "WED", | |
| 1096 | "WEE", "WET", "WHO", "WHY", "WIN", "WIT", "WOK", "WON", | |
| 1097 | "WOO", "WOW", "WRY", "WU", "YAM", "YAP", "YAW", "YE", | |
| 1098 | "YEA", "YES", "YET", "YOU", "ABED", "ABEL", "ABET", "ABLE", | |
| 1099 | "ABUT", "ACHE", "ACID", "ACME", "ACRE", "ACTA", "ACTS", "ADAM", | |
| 1100 | "ADDS", "ADEN", "AFAR", "AFRO", "AGEE", "AHEM", "AHOY", "AIDA", | |
| 1101 | "AIDE", "AIDS", "AIRY", "AJAR", "AKIN", "ALAN", "ALEC", "ALGA", | |
| 1102 | "ALIA", "ALLY", "ALMA", "ALOE", "ALSO", "ALTO", "ALUM", "ALVA", | |
| 1103 | "AMEN", "AMES", "AMID", "AMMO", "AMOK", "AMOS", "AMRA", "ANDY", | |
| 1104 | "ANEW", "ANNA", "ANNE", "ANTE", "ANTI", "AQUA", "ARAB", "ARCH", | |
| 1105 | "AREA", "ARGO", "ARID", "ARMY", "ARTS", "ARTY", "ASIA", "ASKS", | |
| 1106 | "ATOM", "AUNT", "AURA", "AUTO", "AVER", "AVID", "AVIS", "AVON", | |
| 1107 | "AVOW", "AWAY", "AWRY", "BABE", "BABY", "BACH", "BACK", "BADE", | |
| 1108 | "BAIL", "BAIT", "BAKE", "BALD", "BALE", "BALI", "BALK", "BALL", | |
| 1109 | "BALM", "BAND", "BANE", "BANG", "BANK", "BARB", "BARD", "BARE", | |
| 1110 | "BARK", "BARN", "BARR", "BASE", "BASH", "BASK", "BASS", "BATE", | |
| 1111 | "BATH", "BAWD", "BAWL", "BEAD", "BEAK", "BEAM", "BEAN", "BEAR", | |
| 1112 | "BEAT", "BEAU", "BECK", "BEEF", "BEEN", "BEER", "BEET", "BELA", | |
| 1113 | "BELL", "BELT", "BEND", "BENT", "BERG", "BERN", "BERT", "BESS", | |
| 1114 | "BEST", "BETA", "BETH", "BHOY", "BIAS", "BIDE", "BIEN", "BILE", | |
| 1115 | "BILK", "BILL", "BIND", "BING", "BIRD", "BITE", "BITS", "BLAB", | |
| 1116 | "BLAT", "BLED", "BLEW", "BLOB", "BLOC", "BLOT", "BLOW", "BLUE", | |
| 1117 | "BLUM", "BLUR", "BOAR", "BOAT", "BOCA", "BOCK", "BODE", "BODY", | |
| 1118 | ||
| 1119 | ||
| 1120 | ||
| 1121 | Haller Standards Track [Page 20] | |
| 1122 | ||
| 1123 | RFC 2289 A One-Time Password System February 1998 | |
| 1124 | ||
| 1125 | ||
| 1126 | "BOGY", "BOHR", "BOIL", "BOLD", "BOLO", "BOLT", "BOMB", "BONA", | |
| 1127 | "BOND", "BONE", "BONG", "BONN", "BONY", "BOOK", "BOOM", "BOON", | |
| 1128 | "BOOT", "BORE", "BORG", "BORN", "BOSE", "BOSS", "BOTH", "BOUT", | |
| 1129 | "BOWL", "BOYD", "BRAD", "BRAE", "BRAG", "BRAN", "BRAY", "BRED", | |
| 1130 | "BREW", "BRIG", "BRIM", "BROW", "BUCK", "BUDD", "BUFF", "BULB", | |
| 1131 | "BULK", "BULL", "BUNK", "BUNT", "BUOY", "BURG", "BURL", "BURN", | |
| 1132 | "BURR", "BURT", "BURY", "BUSH", "BUSS", "BUST", "BUSY", "BYTE", | |
| 1133 | "CADY", "CAFE", "CAGE", "CAIN", "CAKE", "CALF", "CALL", "CALM", | |
| 1134 | "CAME", "CANE", "CANT", "CARD", "CARE", "CARL", "CARR", "CART", | |
| 1135 | "CASE", "CASH", "CASK", "CAST", "CAVE", "CEIL", "CELL", "CENT", | |
| 1136 | "CERN", "CHAD", "CHAR", "CHAT", "CHAW", "CHEF", "CHEN", "CHEW", | |
| 1137 | "CHIC", "CHIN", "CHOU", "CHOW", "CHUB", "CHUG", "CHUM", "CITE", | |
| 1138 | "CITY", "CLAD", "CLAM", "CLAN", "CLAW", "CLAY", "CLOD", "CLOG", | |
| 1139 | "CLOT", "CLUB", "CLUE", "COAL", "COAT", "COCA", "COCK", "COCO", | |
| 1140 | "CODA", "CODE", "CODY", "COED", "COIL", "COIN", "COKE", "COLA", | |
| 1141 | "COLD", "COLT", "COMA", "COMB", "COME", "COOK", "COOL", "COON", | |
| 1142 | "COOT", "CORD", "CORE", "CORK", "CORN", "COST", "COVE", "COWL", | |
| 1143 | "CRAB", "CRAG", "CRAM", "CRAY", "CREW", "CRIB", "CROW", "CRUD", | |
| 1144 | "CUBA", "CUBE", "CUFF", "CULL", "CULT", "CUNY", "CURB", "CURD", | |
| 1145 | "CURE", "CURL", "CURT", "CUTS", "DADE", "DALE", "DAME", "DANA", | |
| 1146 | "DANE", "DANG", "DANK", "DARE", "DARK", "DARN", "DART", "DASH", | |
| 1147 | "DATA", "DATE", "DAVE", "DAVY", "DAWN", "DAYS", "DEAD", "DEAF", | |
| 1148 | "DEAL", "DEAN", "DEAR", "DEBT", "DECK", "DEED", "DEEM", "DEER", | |
| 1149 | "DEFT", "DEFY", "DELL", "DENT", "DENY", "DESK", "DIAL", "DICE", | |
| 1150 | "DIED", "DIET", "DIME", "DINE", "DING", "DINT", "DIRE", "DIRT", | |
| 1151 | "DISC", "DISH", "DISK", "DIVE", "DOCK", "DOES", "DOLE", "DOLL", | |
| 1152 | "DOLT", "DOME", "DONE", "DOOM", "DOOR", "DORA", "DOSE", "DOTE", | |
| 1153 | "DOUG", "DOUR", "DOVE", "DOWN", "DRAB", "DRAG", "DRAM", "DRAW", | |
| 1154 | "DREW", "DRUB", "DRUG", "DRUM", "DUAL", "DUCK", "DUCT", "DUEL", | |
| 1155 | "DUET", "DUKE", "DULL", "DUMB", "DUNE", "DUNK", "DUSK", "DUST", | |
| 1156 | "DUTY", "EACH", "EARL", "EARN", "EASE", "EAST", "EASY", "EBEN", | |
| 1157 | "ECHO", "EDDY", "EDEN", "EDGE", "EDGY", "EDIT", "EDNA", "EGAN", | |
| 1158 | "ELAN", "ELBA", "ELLA", "ELSE", "EMIL", "EMIT", "EMMA", "ENDS", | |
| 1159 | "ERIC", "EROS", "EVEN", "EVER", "EVIL", "EYED", "FACE", "FACT", | |
| 1160 | "FADE", "FAIL", "FAIN", "FAIR", "FAKE", "FALL", "FAME", "FANG", | |
| 1161 | "FARM", "FAST", "FATE", "FAWN", "FEAR", "FEAT", "FEED", "FEEL", | |
| 1162 | "FEET", "FELL", "FELT", "FEND", "FERN", "FEST", "FEUD", "FIEF", | |
| 1163 | "FIGS", "FILE", "FILL", "FILM", "FIND", "FINE", "FINK", "FIRE", | |
| 1164 | "FIRM", "FISH", "FISK", "FIST", "FITS", "FIVE", "FLAG", "FLAK", | |
| 1165 | "FLAM", "FLAT", "FLAW", "FLEA", "FLED", "FLEW", "FLIT", "FLOC", | |
| 1166 | "FLOG", "FLOW", "FLUB", "FLUE", "FOAL", "FOAM", "FOGY", "FOIL", | |
| 1167 | "FOLD", "FOLK", "FOND", "FONT", "FOOD", "FOOL", "FOOT", "FORD", | |
| 1168 | "FORE", "FORK", "FORM", "FORT", "FOSS", "FOUL", "FOUR", "FOWL", | |
| 1169 | "FRAU", "FRAY", "FRED", "FREE", "FRET", "FREY", "FROG", "FROM", | |
| 1170 | "FUEL", "FULL", "FUME", "FUND", "FUNK", "FURY", "FUSE", "FUSS", | |
| 1171 | "GAFF", "GAGE", "GAIL", "GAIN", "GAIT", "GALA", "GALE", "GALL", | |
| 1172 | "GALT", "GAME", "GANG", "GARB", "GARY", "GASH", "GATE", "GAUL", | |
| 1173 | "GAUR", "GAVE", "GAWK", "GEAR", "GELD", "GENE", "GENT", "GERM", | |
| 1174 | ||
| 1175 | ||
| 1176 | ||
| 1177 | Haller Standards Track [Page 21] | |
| 1178 | ||
| 1179 | RFC 2289 A One-Time Password System February 1998 | |
| 1180 | ||
| 1181 | ||
| 1182 | "GETS", "GIBE", "GIFT", "GILD", "GILL", "GILT", "GINA", "GIRD", | |
| 1183 | "GIRL", "GIST", "GIVE", "GLAD", "GLEE", "GLEN", "GLIB", "GLOB", | |
| 1184 | "GLOM", "GLOW", "GLUE", "GLUM", "GLUT", "GOAD", "GOAL", "GOAT", | |
| 1185 | "GOER", "GOES", "GOLD", "GOLF", "GONE", "GONG", "GOOD", "GOOF", | |
| 1186 | "GORE", "GORY", "GOSH", "GOUT", "GOWN", "GRAB", "GRAD", "GRAY", | |
| 1187 | "GREG", "GREW", "GREY", "GRID", "GRIM", "GRIN", "GRIT", "GROW", | |
| 1188 | "GRUB", "GULF", "GULL", "GUNK", "GURU", "GUSH", "GUST", "GWEN", | |
| 1189 | "GWYN", "HAAG", "HAAS", "HACK", "HAIL", "HAIR", "HALE", "HALF", | |
| 1190 | "HALL", "HALO", "HALT", "HAND", "HANG", "HANK", "HANS", "HARD", | |
| 1191 | "HARK", "HARM", "HART", "HASH", "HAST", "HATE", "HATH", "HAUL", | |
| 1192 | "HAVE", "HAWK", "HAYS", "HEAD", "HEAL", "HEAR", "HEAT", "HEBE", | |
| 1193 | "HECK", "HEED", "HEEL", "HEFT", "HELD", "HELL", "HELM", "HERB", | |
| 1194 | "HERD", "HERE", "HERO", "HERS", "HESS", "HEWN", "HICK", "HIDE", | |
| 1195 | "HIGH", "HIKE", "HILL", "HILT", "HIND", "HINT", "HIRE", "HISS", | |
| 1196 | "HIVE", "HOBO", "HOCK", "HOFF", "HOLD", "HOLE", "HOLM", "HOLT", | |
| 1197 | "HOME", "HONE", "HONK", "HOOD", "HOOF", "HOOK", "HOOT", "HORN", | |
| 1198 | "HOSE", "HOST", "HOUR", "HOVE", "HOWE", "HOWL", "HOYT", "HUCK", | |
| 1199 | "HUED", "HUFF", "HUGE", "HUGH", "HUGO", "HULK", "HULL", "HUNK", | |
| 1200 | "HUNT", "HURD", "HURL", "HURT", "HUSH", "HYDE", "HYMN", "IBIS", | |
| 1201 | "ICON", "IDEA", "IDLE", "IFFY", "INCA", "INCH", "INTO", "IONS", | |
| 1202 | "IOTA", "IOWA", "IRIS", "IRMA", "IRON", "ISLE", "ITCH", "ITEM", | |
| 1203 | "IVAN", "JACK", "JADE", "JAIL", "JAKE", "JANE", "JAVA", "JEAN", | |
| 1204 | "JEFF", "JERK", "JESS", "JEST", "JIBE", "JILL", "JILT", "JIVE", | |
| 1205 | "JOAN", "JOBS", "JOCK", "JOEL", "JOEY", "JOHN", "JOIN", "JOKE", | |
| 1206 | "JOLT", "JOVE", "JUDD", "JUDE", "JUDO", "JUDY", "JUJU", "JUKE", | |
| 1207 | "JULY", "JUNE", "JUNK", "JUNO", "JURY", "JUST", "JUTE", "KAHN", | |
| 1208 | "KALE", "KANE", "KANT", "KARL", "KATE", "KEEL", "KEEN", "KENO", | |
| 1209 | "KENT", "KERN", "KERR", "KEYS", "KICK", "KILL", "KIND", "KING", | |
| 1210 | "KIRK", "KISS", "KITE", "KLAN", "KNEE", "KNEW", "KNIT", "KNOB", | |
| 1211 | "KNOT", "KNOW", "KOCH", "KONG", "KUDO", "KURD", "KURT", "KYLE", | |
| 1212 | "LACE", "LACK", "LACY", "LADY", "LAID", "LAIN", "LAIR", "LAKE", | |
| 1213 | "LAMB", "LAME", "LAND", "LANE", "LANG", "LARD", "LARK", "LASS", | |
| 1214 | "LAST", "LATE", "LAUD", "LAVA", "LAWN", "LAWS", "LAYS", "LEAD", | |
| 1215 | "LEAF", "LEAK", "LEAN", "LEAR", "LEEK", "LEER", "LEFT", "LEND", | |
| 1216 | "LENS", "LENT", "LEON", "LESK", "LESS", "LEST", "LETS", "LIAR", | |
| 1217 | "LICE", "LICK", "LIED", "LIEN", "LIES", "LIEU", "LIFE", "LIFT", | |
| 1218 | "LIKE", "LILA", "LILT", "LILY", "LIMA", "LIMB", "LIME", "LIND", | |
| 1219 | "LINE", "LINK", "LINT", "LION", "LISA", "LIST", "LIVE", "LOAD", | |
| 1220 | "LOAF", "LOAM", "LOAN", "LOCK", "LOFT", "LOGE", "LOIS", "LOLA", | |
| 1221 | "LONE", "LONG", "LOOK", "LOON", "LOOT", "LORD", "LORE", "LOSE", | |
| 1222 | "LOSS", "LOST", "LOUD", "LOVE", "LOWE", "LUCK", "LUCY", "LUGE", | |
| 1223 | "LUKE", "LULU", "LUND", "LUNG", "LURA", "LURE", "LURK", "LUSH", | |
| 1224 | "LUST", "LYLE", "LYNN", "LYON", "LYRA", "MACE", "MADE", "MAGI", | |
| 1225 | "MAID", "MAIL", "MAIN", "MAKE", "MALE", "MALI", "MALL", "MALT", | |
| 1226 | "MANA", "MANN", "MANY", "MARC", "MARE", "MARK", "MARS", "MART", | |
| 1227 | "MARY", "MASH", "MASK", "MASS", "MAST", "MATE", "MATH", "MAUL", | |
| 1228 | "MAYO", "MEAD", "MEAL", "MEAN", "MEAT", "MEEK", "MEET", "MELD", | |
| 1229 | "MELT", "MEMO", "MEND", "MENU", "MERT", "MESH", "MESS", "MICE", | |
| 1230 | ||
| 1231 | ||
| 1232 | ||
| 1233 | Haller Standards Track [Page 22] | |
| 1234 | ||
| 1235 | RFC 2289 A One-Time Password System February 1998 | |
| 1236 | ||
| 1237 | ||
| 1238 | "MIKE", "MILD", "MILE", "MILK", "MILL", "MILT", "MIMI", "MIND", | |
| 1239 | "MINE", "MINI", "MINK", "MINT", "MIRE", "MISS", "MIST", "MITE", | |
| 1240 | "MITT", "MOAN", "MOAT", "MOCK", "MODE", "MOLD", "MOLE", "MOLL", | |
| 1241 | "MOLT", "MONA", "MONK", "MONT", "MOOD", "MOON", "MOOR", "MOOT", | |
| 1242 | "MORE", "MORN", "MORT", "MOSS", "MOST", "MOTH", "MOVE", "MUCH", | |
| 1243 | "MUCK", "MUDD", "MUFF", "MULE", "MULL", "MURK", "MUSH", "MUST", | |
| 1244 | "MUTE", "MUTT", "MYRA", "MYTH", "NAGY", "NAIL", "NAIR", "NAME", | |
| 1245 | "NARY", "NASH", "NAVE", "NAVY", "NEAL", "NEAR", "NEAT", "NECK", | |
| 1246 | "NEED", "NEIL", "NELL", "NEON", "NERO", "NESS", "NEST", "NEWS", | |
| 1247 | "NEWT", "NIBS", "NICE", "NICK", "NILE", "NINA", "NINE", "NOAH", | |
| 1248 | "NODE", "NOEL", "NOLL", "NONE", "NOOK", "NOON", "NORM", "NOSE", | |
| 1249 | "NOTE", "NOUN", "NOVA", "NUDE", "NULL", "NUMB", "OATH", "OBEY", | |
| 1250 | "OBOE", "ODIN", "OHIO", "OILY", "OINT", "OKAY", "OLAF", "OLDY", | |
| 1251 | "OLGA", "OLIN", "OMAN", "OMEN", "OMIT", "ONCE", "ONES", "ONLY", | |
| 1252 | "ONTO", "ONUS", "ORAL", "ORGY", "OSLO", "OTIS", "OTTO", "OUCH", | |
| 1253 | "OUST", "OUTS", "OVAL", "OVEN", "OVER", "OWLY", "OWNS", "QUAD", | |
| 1254 | "QUIT", "QUOD", "RACE", "RACK", "RACY", "RAFT", "RAGE", "RAID", | |
| 1255 | "RAIL", "RAIN", "RAKE", "RANK", "RANT", "RARE", "RASH", "RATE", | |
| 1256 | "RAVE", "RAYS", "READ", "REAL", "REAM", "REAR", "RECK", "REED", | |
| 1257 | "REEF", "REEK", "REEL", "REID", "REIN", "RENA", "REND", "RENT", | |
| 1258 | "REST", "RICE", "RICH", "RICK", "RIDE", "RIFT", "RILL", "RIME", | |
| 1259 | "RING", "RINK", "RISE", "RISK", "RITE", "ROAD", "ROAM", "ROAR", | |
| 1260 | "ROBE", "ROCK", "RODE", "ROIL", "ROLL", "ROME", "ROOD", "ROOF", | |
| 1261 | "ROOK", "ROOM", "ROOT", "ROSA", "ROSE", "ROSS", "ROSY", "ROTH", | |
| 1262 | "ROUT", "ROVE", "ROWE", "ROWS", "RUBE", "RUBY", "RUDE", "RUDY", | |
| 1263 | "RUIN", "RULE", "RUNG", "RUNS", "RUNT", "RUSE", "RUSH", "RUSK", | |
| 1264 | "RUSS", "RUST", "RUTH", "SACK", "SAFE", "SAGE", "SAID", "SAIL", | |
| 1265 | "SALE", "SALK", "SALT", "SAME", "SAND", "SANE", "SANG", "SANK", | |
| 1266 | "SARA", "SAUL", "SAVE", "SAYS", "SCAN", "SCAR", "SCAT", "SCOT", | |
| 1267 | "SEAL", "SEAM", "SEAR", "SEAT", "SEED", "SEEK", "SEEM", "SEEN", | |
| 1268 | "SEES", "SELF", "SELL", "SEND", "SENT", "SETS", "SEWN", "SHAG", | |
| 1269 | "SHAM", "SHAW", "SHAY", "SHED", "SHIM", "SHIN", "SHOD", "SHOE", | |
| 1270 | "SHOT", "SHOW", "SHUN", "SHUT", "SICK", "SIDE", "SIFT", "SIGH", | |
| 1271 | "SIGN", "SILK", "SILL", "SILO", "SILT", "SINE", "SING", "SINK", | |
| 1272 | "SIRE", "SITE", "SITS", "SITU", "SKAT", "SKEW", "SKID", "SKIM", | |
| 1273 | "SKIN", "SKIT", "SLAB", "SLAM", "SLAT", "SLAY", "SLED", "SLEW", | |
| 1274 | "SLID", "SLIM", "SLIT", "SLOB", "SLOG", "SLOT", "SLOW", "SLUG", | |
| 1275 | "SLUM", "SLUR", "SMOG", "SMUG", "SNAG", "SNOB", "SNOW", "SNUB", | |
| 1276 | "SNUG", "SOAK", "SOAR", "SOCK", "SODA", "SOFA", "SOFT", "SOIL", | |
| 1277 | "SOLD", "SOME", "SONG", "SOON", "SOOT", "SORE", "SORT", "SOUL", | |
| 1278 | "SOUR", "SOWN", "STAB", "STAG", "STAN", "STAR", "STAY", "STEM", | |
| 1279 | "STEW", "STIR", "STOW", "STUB", "STUN", "SUCH", "SUDS", "SUIT", | |
| 1280 | "SULK", "SUMS", "SUNG", "SUNK", "SURE", "SURF", "SWAB", "SWAG", | |
| 1281 | "SWAM", "SWAN", "SWAT", "SWAY", "SWIM", "SWUM", "TACK", "TACT", | |
| 1282 | "TAIL", "TAKE", "TALE", "TALK", "TALL", "TANK", "TASK", "TATE", | |
| 1283 | "TAUT", "TEAL", "TEAM", "TEAR", "TECH", "TEEM", "TEEN", "TEET", | |
| 1284 | "TELL", "TEND", "TENT", "TERM", "TERN", "TESS", "TEST", "THAN", | |
| 1285 | "THAT", "THEE", "THEM", "THEN", "THEY", "THIN", "THIS", "THUD", | |
| 1286 | ||
| 1287 | ||
| 1288 | ||
| 1289 | Haller Standards Track [Page 23] | |
| 1290 | ||
| 1291 | RFC 2289 A One-Time Password System February 1998 | |
| 1292 | ||
| 1293 | ||
| 1294 | "THUG", "TICK", "TIDE", "TIDY", "TIED", "TIER", "TILE", "TILL", | |
| 1295 | "TILT", "TIME", "TINA", "TINE", "TINT", "TINY", "TIRE", "TOAD", | |
| 1296 | "TOGO", "TOIL", "TOLD", "TOLL", "TONE", "TONG", "TONY", "TOOK", | |
| 1297 | "TOOL", "TOOT", "TORE", "TORN", "TOTE", "TOUR", "TOUT", "TOWN", | |
| 1298 | "TRAG", "TRAM", "TRAY", "TREE", "TREK", "TRIG", "TRIM", "TRIO", | |
| 1299 | "TROD", "TROT", "TROY", "TRUE", "TUBA", "TUBE", "TUCK", "TUFT", | |
| 1300 | "TUNA", "TUNE", "TUNG", "TURF", "TURN", "TUSK", "TWIG", "TWIN", | |
| 1301 | "TWIT", "ULAN", "UNIT", "URGE", "USED", "USER", "USES", "UTAH", | |
| 1302 | "VAIL", "VAIN", "VALE", "VARY", "VASE", "VAST", "VEAL", "VEDA", | |
| 1303 | "VEIL", "VEIN", "VEND", "VENT", "VERB", "VERY", "VETO", "VICE", | |
| 1304 | "VIEW", "VINE", "VISE", "VOID", "VOLT", "VOTE", "WACK", "WADE", | |
| 1305 | "WAGE", "WAIL", "WAIT", "WAKE", "WALE", "WALK", "WALL", "WALT", | |
| 1306 | "WAND", "WANE", "WANG", "WANT", "WARD", "WARM", "WARN", "WART", | |
| 1307 | "WASH", "WAST", "WATS", "WATT", "WAVE", "WAVY", "WAYS", "WEAK", | |
| 1308 | "WEAL", "WEAN", "WEAR", "WEED", "WEEK", "WEIR", "WELD", "WELL", | |
| 1309 | "WELT", "WENT", "WERE", "WERT", "WEST", "WHAM", "WHAT", "WHEE", | |
| 1310 | "WHEN", "WHET", "WHOA", "WHOM", "WICK", "WIFE", "WILD", "WILL", | |
| 1311 | "WIND", "WINE", "WING", "WINK", "WINO", "WIRE", "WISE", "WISH", | |
| 1312 | "WITH", "WOLF", "WONT", "WOOD", "WOOL", "WORD", "WORE", "WORK", | |
| 1313 | "WORM", "WORN", "WOVE", "WRIT", "WYNN", "YALE", "YANG", "YANK", | |
| 1314 | "YARD", "YARN", "YAWL", "YAWN", "YEAH", "YEAR", "YELL", "YOGA", | |
| 1315 | "YOKE" }; | |
| 1316 | ||
| 1317 | ||
| 1318 | ||
| 1319 | ||
| 1320 | ||
| 1321 | ||
| 1322 | ||
| 1323 | ||
| 1324 | ||
| 1325 | ||
| 1326 | ||
| 1327 | ||
| 1328 | ||
| 1329 | ||
| 1330 | ||
| 1331 | ||
| 1332 | ||
| 1333 | ||
| 1334 | ||
| 1335 | ||
| 1336 | ||
| 1337 | ||
| 1338 | ||
| 1339 | ||
| 1340 | ||
| 1341 | ||
| 1342 | ||
| 1343 | ||
| 1344 | ||
| 1345 | Haller Standards Track [Page 24] | |
| 1346 | ||
| 1347 | RFC 2289 A One-Time Password System February 1998 | |
| 1348 | ||
| 1349 | ||
| 1350 | Full Copyright Statement | |
| 1351 | ||
| 1352 | Copyright (C) The Internet Society (1998). All Rights Reserved. | |
| 1353 | ||
| 1354 | This document and translations of it may be copied and furnished to | |
| 1355 | others, and derivative works that comment on or otherwise explain it | |
| 1356 | or assist in its implementation may be prepared, copied, published | |
| 1357 | and distributed, in whole or in part, without restriction of any | |
| 1358 | kind, provided that the above copyright notice and this paragraph are | |
| 1359 | included on all such copies and derivative works. However, this | |
| 1360 | document itself may not be modified in any way, such as by removing | |
| 1361 | the copyright notice or references to the Internet Society or other | |
| 1362 | Internet organizations, except as needed for the purpose of | |
| 1363 | developing Internet standards in which case the procedures for | |
| 1364 | copyrights defined in the Internet Standards process must be | |
| 1365 | followed, or as required to translate it into languages other than | |
| 1366 | English. | |
| 1367 | ||
| 1368 | The limited permissions granted above are perpetual and will not be | |
| 1369 | revoked by the Internet Society or its successors or assigns. | |
| 1370 | ||
| 1371 | This document and the information contained herein is provided on an | |
| 1372 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 1373 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 1374 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 1375 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 1376 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 1377 | ||
| 1378 | ||
| 1379 | ||
| 1380 | ||
| 1381 | ||
| 1382 | ||
| 1383 | ||
| 1384 | ||
| 1385 | ||
| 1386 | ||
| 1387 | ||
| 1388 | ||
| 1389 | ||
| 1390 | ||
| 1391 | ||
| 1392 | ||
| 1393 | ||
| 1394 | ||
| 1395 | ||
| 1396 | ||
| 1397 | ||
| 1398 | ||
| 1399 | ||
| 1400 | ||
| 1401 | Haller Standards Track [Page 25] | |
| 1402 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group C. Newman | |
| 7 | Request for Comments: 2444 Innosoft | |
| 8 | Updates: 2222 October 1998 | |
| 9 | Category: Standards Track | |
| 10 | ||
| 11 | ||
| 12 | The One-Time-Password SASL Mechanism | |
| 13 | ||
| 14 | Status of this Memo | |
| 15 | ||
| 16 | This document specifies an Internet standards track protocol for the | |
| 17 | Internet community, and requests discussion and suggestions for | |
| 18 | improvements. Please refer to the current edition of the "Internet | |
| 19 | Official Protocol Standards" (STD 1) for the standardization state | |
| 20 | and status of this protocol. Distribution of this memo is unlimited. | |
| 21 | ||
| 22 | Copyright Notice | |
| 23 | ||
| 24 | Copyright (C) The Internet Society (1998). All Rights Reserved. | |
| 25 | ||
| 26 | Abstract | |
| 27 | ||
| 28 | OTP [OTP] provides a useful authentication mechanism for situations | |
| 29 | where there is limited client or server trust. Currently, OTP is | |
| 30 | added to protocols in an ad-hoc fashion with heuristic parsing. This | |
| 31 | specification defines an OTP SASL [SASL] mechanism so it can be | |
| 32 | easily and formally integrated into many application protocols. | |
| 33 | ||
| 34 | 1. How to Read This Document | |
| 35 | ||
| 36 | The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", | |
| 37 | "RECOMMENDED" and "MAY" in this document are to be interpreted as | |
| 38 | defined in "Key words for use in RFCs to Indicate Requirement Levels" | |
| 39 | [KEYWORDS]. | |
| 40 | ||
| 41 | This memo assumes the reader is familiar with OTP [OTP], OTP extended | |
| 42 | responses [OTP-EXT] and SASL [SASL]. | |
| 43 | ||
| 44 | 2. Intended Use | |
| 45 | ||
| 46 | The OTP SASL mechanism replaces the SKEY SASL mechanism [SASL]. OTP | |
| 47 | is a good choice for usage scenarios where the client is untrusted | |
| 48 | (e.g., a kiosk client), as a one-time password will only give the | |
| 49 | client a single opportunity to act on behalf of the user. OTP is | |
| 50 | also a good choice for situations where interactive logins are | |
| 51 | permitted to the server, as a compromised OTP authentication database | |
| 52 | is only subject to dictionary attacks, unlike authentication | |
| 53 | databases for other simple mechanisms such as CRAM-MD5 [CRAM-MD5]. | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Newman Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 2444 OTP SASL Mechanism October 1998 | |
| 60 | ||
| 61 | ||
| 62 | It is important to note that each use of the OTP mechanism causes the | |
| 63 | authentication database entry for a user to be updated. | |
| 64 | ||
| 65 | This SASL mechanism provides a formal way to integrate OTP into | |
| 66 | SASL-enabled protocols including IMAP [IMAP4], ACAP [ACAP], POP3 | |
| 67 | [POP-AUTH] and LDAPv3 [LDAPv3]. | |
| 68 | ||
| 69 | 3. Profiling OTP for SASL | |
| 70 | ||
| 71 | OTP [OTP] and OTP extended responses [OTP-EXT] offer a number of | |
| 72 | options. However, for authentication to succeed, the client and | |
| 73 | server need compatible option sets. This specification defines a | |
| 74 | single SASL mechanism: OTP. The following rules apply to this | |
| 75 | mechanism: | |
| 76 | ||
| 77 | o The extended response syntax MUST be used. | |
| 78 | ||
| 79 | o Servers MUST support the following four OTP extended responses: | |
| 80 | "hex", "word", "init-hex" and "init-word". Servers MUST support | |
| 81 | the "word" and "init-word" responses for the standard dictionary | |
| 82 | and SHOULD support alternate dictionaries. Servers MUST NOT | |
| 83 | require use of any additional OTP extensions or options. | |
| 84 | ||
| 85 | o Clients SHOULD support display of the OTP challenge to the user | |
| 86 | and entry of an OTP in multi-word format. Clients MAY also | |
| 87 | support direct entry of the pass phrase and compute the "hex" or | |
| 88 | "word" response. | |
| 89 | ||
| 90 | o Clients MUST indicate when authentication fails due to the | |
| 91 | sequence number getting too low and SHOULD offer the user the | |
| 92 | option to reset the sequence using the "init-hex" or "init-word" | |
| 93 | response. | |
| 94 | ||
| 95 | Support for the MD5 algorithm is REQUIRED, and support for the SHA1 | |
| 96 | algorithm is RECOMMENDED. | |
| 97 | ||
| 98 | 4. OTP Authentication Mechanism | |
| 99 | ||
| 100 | The mechanism does not provide any security layer. | |
| 101 | ||
| 102 | The client begins by sending a message to the server containing the | |
| 103 | following two pieces of information. | |
| 104 | ||
| 105 | (1) An authorization identity. When the empty string is used, this | |
| 106 | defaults to the authentication identity. This is used by system | |
| 107 | administrators or proxy servers to login with a different user | |
| 108 | identity. This field may be up to 255 octets and is terminated by a | |
| 109 | NUL (0) octet. US-ASCII printable characters are preferred, although | |
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Newman Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 2444 OTP SASL Mechanism October 1998 | |
| 116 | ||
| 117 | ||
| 118 | UTF-8 [UTF-8] printable characters are permitted to support | |
| 119 | international names. Use of character sets other than US-ASCII and | |
| 120 | UTF-8 is forbidden. | |
| 121 | ||
| 122 | (2) An authentication identity. The identity whose pass phrase will | |
| 123 | be used. This field may be up to 255 octets. US-ASCII printable | |
| 124 | characters are preferred, although UTF-8 [UTF-8] printable characters | |
| 125 | are permitted to support international names. Use of character sets | |
| 126 | other than US-ASCII and UTF-8 is forbidden. | |
| 127 | ||
| 128 | The server responds by sending a message containing the OTP challenge | |
| 129 | as described in OTP [OTP] and OTP extended responses [OTP-EXT]. | |
| 130 | ||
| 131 | If a client sees an unknown hash algorithm name it will not be able | |
| 132 | to process a pass phrase input by the user. In this situation the | |
| 133 | client MAY prompt for the six-word format, issue the cancel sequence | |
| 134 | as specified by the SASL profile for the protocol in use and try a | |
| 135 | different SASL mechanism, or close the connection and refuse to | |
| 136 | authenticate. As a result of this behavior, a server is restricted | |
| 137 | to one OTP hash algorithm per user. | |
| 138 | ||
| 139 | On success, the client generates an extended response in the "hex", | |
| 140 | "word", "init-hex" or "init-word" format. The client is not required | |
| 141 | to terminate the response with a space or a newline and SHOULD NOT | |
| 142 | include unnecessary whitespace. | |
| 143 | ||
| 144 | Servers MUST tolerate input of arbitrary length, but MAY fail the | |
| 145 | authentication if the length of client input exceeds reasonable size. | |
| 146 | ||
| 147 | 5. Examples | |
| 148 | ||
| 149 | In these example, "C:" represents lines sent from the client to the | |
| 150 | server and "S:" represents lines sent from the server to the client. | |
| 151 | The user name is "tim" and no authorization identity is provided. | |
| 152 | The "<NUL>" below represents an ASCII NUL octet. | |
| 153 | ||
| 154 | The following is an example of the OTP mechanism using the ACAP | |
| 155 | [ACAP] profile of SASL. The pass phrase used in this example is: | |
| 156 | This is a test. | |
| 157 | ||
| 158 | C: a001 AUTHENTICATE "OTP" {4} | |
| 159 | C: <NUL>tim | |
| 160 | S: + "otp-md5 499 ke1234 ext" | |
| 161 | C: "hex:5bf075d9959d036f" | |
| 162 | S: a001 OK "AUTHENTICATE completed" | |
| 163 | ||
| 164 | ||
| 165 | ||
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Newman Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 2444 OTP SASL Mechanism October 1998 | |
| 172 | ||
| 173 | ||
| 174 | Here is the same example using the six-words response: | |
| 175 | ||
| 176 | C: a001 AUTHENTICATE "OTP" {4} | |
| 177 | C: <NUL>tim | |
| 178 | S: + "otp-md5 499 ke1234 ext" | |
| 179 | C: "word:BOND FOGY DRAB NE RISE MART" | |
| 180 | S: a001 OK "AUTHENTICATE completed" | |
| 181 | ||
| 182 | Here is the same example using the OTP-SHA1 mechanism: | |
| 183 | ||
| 184 | C: a001 AUTHENTICATE "OTP" {4} | |
| 185 | C: <NUL>tim | |
| 186 | S: + "otp-sha1 499 ke1234 ext" | |
| 187 | C: "hex:c90fc02cc488df5e" | |
| 188 | S: a001 OK "AUTHENTICATE completed" | |
| 189 | ||
| 190 | Here is the same example with the init-hex extended response | |
| 191 | ||
| 192 | C: a001 AUTHENTICATE "OTP" {4} | |
| 193 | C: <NUL>tim | |
| 194 | S: + "otp-md5 499 ke1234 ext" | |
| 195 | C: "init-hex:5bf075d9959d036f:md5 499 ke1235:3712dcb4aa5316c1" | |
| 196 | S: a001 OK "OTP sequence reset, authentication complete" | |
| 197 | ||
| 198 | The following is an example of the OTP mechanism using the IMAP | |
| 199 | [IMAP4] profile of SASL. The pass phrase used in this example is: | |
| 200 | this is a test | |
| 201 | ||
| 202 | C: a001 AUTHENTICATE OTP | |
| 203 | S: + | |
| 204 | C: AHRpbQ== | |
| 205 | S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA== | |
| 206 | C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE= | |
| 207 | S: a001 OK AUTHENTICATE completed | |
| 208 | ||
| 209 | Note that the lack of an initial client response and the base64 | |
| 210 | encoding are characteristics of the IMAP profile of SASL. The server | |
| 211 | challenge is "otp-md5 123 ke1234 ext" and the client response is | |
| 212 | "hex:11d4c147e227c1f1". | |
| 213 | ||
| 214 | 6. Security Considerations | |
| 215 | ||
| 216 | This specification introduces no security considerations beyond those | |
| 217 | those described in SASL [SASL], OTP [OTP] and OTP extended responses | |
| 218 | [OTP-EXT]. A brief summary of these considerations follows: | |
| 219 | ||
| 220 | This mechanism does not provide session privacy, server | |
| 221 | authentication or protection from active attacks. | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Newman Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 2444 OTP SASL Mechanism October 1998 | |
| 228 | ||
| 229 | ||
| 230 | This mechanism is subject to passive dictionary attacks. The | |
| 231 | severity of this attack can be reduced by choosing pass phrases well. | |
| 232 | ||
| 233 | The server authentication database necessary for use with OTP need | |
| 234 | not be plaintext-equivalent. | |
| 235 | ||
| 236 | Server implementations MUST protect against the race attack [OTP]. | |
| 237 | ||
| 238 | 7. Multinational Considerations | |
| 239 | ||
| 240 | As remote access is a crucial service, users are encouraged to | |
| 241 | restrict user names and pass phrases to the US-ASCII character set. | |
| 242 | However, if characters outside the US-ASCII chracter set are used in | |
| 243 | user names and pass phrases, then they are interpreted according to | |
| 244 | UTF-8 [UTF-8]. | |
| 245 | ||
| 246 | Server support for alternate dictionaries is strongly RECOMMENDED to | |
| 247 | permit use of the six-word format with non-English words. | |
| 248 | ||
| 249 | 8. IANA Considerations | |
| 250 | ||
| 251 | Here is the registration template for the OTP SASL mechanism: | |
| 252 | ||
| 253 | SASL mechanism name: OTP | |
| 254 | Security Considerations: See section 6 of this memo | |
| 255 | Published specification: this memo | |
| 256 | Person & email address to contact for futher information: | |
| 257 | see author's address section below | |
| 258 | Intended usage: COMMON | |
| 259 | Author/Change controller: see author's address section below | |
| 260 | ||
| 261 | This memo also amends the SKEY SASL mechanism registration [SASL] by | |
| 262 | changing its intended usage to OBSOLETE. | |
| 263 | ||
| 264 | 9. References | |
| 265 | ||
| 266 | [ACAP] Newman, C. and J. Myers, "ACAP -- Application | |
| 267 | Configuration Access Protocol", RFC 2244, November 1997. | |
| 268 | ||
| 269 | [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP | |
| 270 | AUTHorize Extension for Simple Challenge/Response", RFC | |
| 271 | 2195, September 1997. | |
| 272 | ||
| 273 | [IMAP4] Crispin, M., "Internet Message Access Protocol - Version | |
| 274 | 4rev1", RFC 2060, December 1996. | |
| 275 | ||
| 276 | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |
| 277 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Newman Standards Track [Page 5] | |
| 282 | ||
| 283 | RFC 2444 OTP SASL Mechanism October 1998 | |
| 284 | ||
| 285 | ||
| 286 | [LDAPv3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory | |
| 287 | Access Protocol (v3)", RFC 2251, December 1997. | |
| 288 | ||
| 289 | [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, | |
| 290 | April 1992. | |
| 291 | ||
| 292 | [OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time | |
| 293 | Password System", RFC 2289, February 1998. | |
| 294 | ||
| 295 | [OTP-EXT] Metz, C., "OTP Extended Responses", RFC 2243, November | |
| 296 | 1997. | |
| 297 | ||
| 298 | [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, | |
| 299 | December 1994. | |
| 300 | ||
| 301 | [SASL] Myers, J., "Simple Authentication and Security Layer | |
| 302 | (SASL)", RFC 2222, October 1997. | |
| 303 | ||
| 304 | [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO | |
| 305 | 10646", RFC 2279, January 1998. | |
| 306 | ||
| 307 | 10. Author's Address | |
| 308 | ||
| 309 | Chris Newman | |
| 310 | Innosoft International, Inc. | |
| 311 | 1050 Lakes Drive | |
| 312 | West Covina, CA 91790 USA | |
| 313 | ||
| 314 | EMail: chris.newman@innosoft.com | |
| 315 | ||
| 316 | ||
| 317 | ||
| 318 | ||
| 319 | ||
| 320 | ||
| 321 | ||
| 322 | ||
| 323 | ||
| 324 | ||
| 325 | ||
| 326 | ||
| 327 | ||
| 328 | ||
| 329 | ||
| 330 | ||
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Newman Standards Track [Page 6] | |
| 338 | ||
| 339 | RFC 2444 OTP SASL Mechanism October 1998 | |
| 340 | ||
| 341 | ||
| 342 | 11. Full Copyright Statement | |
| 343 | ||
| 344 | Copyright (C) The Internet Society (1998). All Rights Reserved. | |
| 345 | ||
| 346 | This document and translations of it may be copied and furnished to | |
| 347 | others, and derivative works that comment on or otherwise explain it | |
| 348 | or assist in its implementation may be prepared, copied, published | |
| 349 | and distributed, in whole or in part, without restriction of any | |
| 350 | kind, provided that the above copyright notice and this paragraph are | |
| 351 | included on all such copies and derivative works. However, this | |
| 352 | document itself may not be modified in any way, such as by removing | |
| 353 | the copyright notice or references to the Internet Society or other | |
| 354 | Internet organizations, except as needed for the purpose of | |
| 355 | developing Internet standards in which case the procedures for | |
| 356 | copyrights defined in the Internet Standards process must be | |
| 357 | followed, or as required to translate it into languages other than | |
| 358 | English. | |
| 359 | ||
| 360 | The limited permissions granted above are perpetual and will not be | |
| 361 | revoked by the Internet Society or its successors or assigns. | |
| 362 | ||
| 363 | This document and the information contained herein is provided on an | |
| 364 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 365 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 366 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 367 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 368 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 369 | ||
| 370 | ||
| 371 | ||
| 372 | ||
| 373 | ||
| 374 | ||
| 375 | ||
| 376 | ||
| 377 | ||
| 378 | ||
| 379 | ||
| 380 | ||
| 381 | ||
| 382 | ||
| 383 | ||
| 384 | ||
| 385 | ||
| 386 | ||
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Newman Standards Track [Page 7] | |
| 394 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group C. Newman | |
| 7 | Request for Comments: 2595 Innosoft | |
| 8 | Category: Standards Track June 1999 | |
| 9 | ||
| 10 | ||
| 11 | Using TLS with IMAP, POP3 and ACAP | |
| 12 | ||
| 13 | ||
| 14 | Status of this Memo | |
| 15 | ||
| 16 | This document specifies an Internet standards track protocol for the | |
| 17 | Internet community, and requests discussion and suggestions for | |
| 18 | improvements. Please refer to the current edition of the "Internet | |
| 19 | Official Protocol Standards" (STD 1) for the standardization state | |
| 20 | and status of this protocol. Distribution of this memo is unlimited. | |
| 21 | ||
| 22 | Copyright Notice | |
| 23 | ||
| 24 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
| 25 | ||
| 26 | 1. Motivation | |
| 27 | ||
| 28 | The TLS protocol (formerly known as SSL) provides a way to secure an | |
| 29 | application protocol from tampering and eavesdropping. The option of | |
| 30 | using such security is desirable for IMAP, POP and ACAP due to common | |
| 31 | connection eavesdropping and hijacking attacks [AUTH]. Although | |
| 32 | advanced SASL authentication mechanisms can provide a lightweight | |
| 33 | version of this service, TLS is complimentary to simple | |
| 34 | authentication-only SASL mechanisms or deployed clear-text password | |
| 35 | login commands. | |
| 36 | ||
| 37 | Many sites have a high investment in authentication infrastructure | |
| 38 | (e.g., a large database of a one-way-function applied to user | |
| 39 | passwords), so a privacy layer which is not tightly bound to user | |
| 40 | authentication can protect against network eavesdropping attacks | |
| 41 | without requiring a new authentication infrastructure and/or forcing | |
| 42 | all users to change their password. Recognizing that such sites will | |
| 43 | desire simple password authentication in combination with TLS | |
| 44 | encryption, this specification defines the PLAIN SASL mechanism for | |
| 45 | use with protocols which lack a simple password authentication | |
| 46 | command such as ACAP and SMTP. (Note there is a separate RFC for the | |
| 47 | STARTTLS command in SMTP [SMTPTLS].) | |
| 48 | ||
| 49 | There is a strong desire in the IETF to eliminate the transmission of | |
| 50 | clear-text passwords over unencrypted channels. While SASL can be | |
| 51 | used for this purpose, TLS provides an additional tool with different | |
| 52 | deployability characteristics. A server supporting both TLS with | |
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Newman Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 60 | ||
| 61 | ||
| 62 | simple passwords and a challenge/response SASL mechanism is likely to | |
| 63 | interoperate with a wide variety of clients without resorting to | |
| 64 | unencrypted clear-text passwords. | |
| 65 | ||
| 66 | The STARTTLS command rectifies a number of the problems with using a | |
| 67 | separate port for a "secure" protocol variant. Some of these are | |
| 68 | mentioned in section 7. | |
| 69 | ||
| 70 | 1.1. Conventions Used in this Document | |
| 71 | ||
| 72 | The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", | |
| 73 | "MAY", and "OPTIONAL" in this document are to be interpreted as | |
| 74 | described in "Key words for use in RFCs to Indicate Requirement | |
| 75 | Levels" [KEYWORDS]. | |
| 76 | ||
| 77 | Terms related to authentication are defined in "On Internet | |
| 78 | Authentication" [AUTH]. | |
| 79 | ||
| 80 | Formal syntax is defined using ABNF [ABNF]. | |
| 81 | ||
| 82 | In examples, "C:" and "S:" indicate lines sent by the client and | |
| 83 | server respectively. | |
| 84 | ||
| 85 | 2. Basic Interoperability and Security Requirements | |
| 86 | ||
| 87 | The following requirements apply to all implementations of the | |
| 88 | STARTTLS extension for IMAP, POP3 and ACAP. | |
| 89 | ||
| 90 | 2.1. Cipher Suite Requirements | |
| 91 | ||
| 92 | Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher | |
| 93 | suite is REQUIRED. This is important as it assures that any two | |
| 94 | compliant implementations can be configured to interoperate. | |
| 95 | ||
| 96 | All other cipher suites are OPTIONAL. | |
| 97 | ||
| 98 | 2.2. Privacy Operational Mode Security Requirements | |
| 99 | ||
| 100 | Both clients and servers SHOULD have a privacy operational mode which | |
| 101 | refuses authentication unless successful activation of an encryption | |
| 102 | layer (such as that provided by TLS) occurs prior to or at the time | |
| 103 | of authentication and which will terminate the connection if that | |
| 104 | encryption layer is deactivated. Implementations are encouraged to | |
| 105 | have flexibility with respect to the minimal encryption strength or | |
| 106 | cipher suites permitted. A minimalist approach to this | |
| 107 | recommendation would be an operational mode where the | |
| 108 | TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to | |
| 109 | permitting authentication. | |
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Newman Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 116 | ||
| 117 | ||
| 118 | Clients MAY have an operational mode which uses encryption only when | |
| 119 | it is advertised by the server, but authentication continues | |
| 120 | regardless. For backwards compatibility, servers SHOULD have an | |
| 121 | operational mode where only the authentication mechanisms required by | |
| 122 | the relevant base protocol specification are needed to successfully | |
| 123 | authenticate. | |
| 124 | ||
| 125 | 2.3. Clear-Text Password Requirements | |
| 126 | ||
| 127 | Clients and servers which implement STARTTLS MUST be configurable to | |
| 128 | refuse all clear-text login commands or mechanisms (including both | |
| 129 | standards-track and nonstandard mechanisms) unless an encryption | |
| 130 | layer of adequate strength is active. Servers which allow | |
| 131 | unencrypted clear-text logins SHOULD be configurable to refuse | |
| 132 | clear-text logins both for the entire server, and on a per-user | |
| 133 | basis. | |
| 134 | ||
| 135 | 2.4. Server Identity Check | |
| 136 | ||
| 137 | During the TLS negotiation, the client MUST check its understanding | |
| 138 | of the server hostname against the server's identity as presented in | |
| 139 | the server Certificate message, in order to prevent man-in-the-middle | |
| 140 | attacks. Matching is performed according to these rules: | |
| 141 | ||
| 142 | - The client MUST use the server hostname it used to open the | |
| 143 | connection as the value to compare against the server name as | |
| 144 | expressed in the server certificate. The client MUST NOT use any | |
| 145 | form of the server hostname derived from an insecure remote source | |
| 146 | (e.g., insecure DNS lookup). CNAME canonicalization is not done. | |
| 147 | ||
| 148 | - If a subjectAltName extension of type dNSName is present in the | |
| 149 | certificate, it SHOULD be used as the source of the server's | |
| 150 | identity. | |
| 151 | ||
| 152 | - Matching is case-insensitive. | |
| 153 | ||
| 154 | - A "*" wildcard character MAY be used as the left-most name | |
| 155 | component in the certificate. For example, *.example.com would | |
| 156 | match a.example.com, foo.example.com, etc. but would not match | |
| 157 | example.com. | |
| 158 | ||
| 159 | - If the certificate contains multiple names (e.g. more than one | |
| 160 | dNSName field), then a match with any one of the fields is | |
| 161 | considered acceptable. | |
| 162 | ||
| 163 | If the match fails, the client SHOULD either ask for explicit user | |
| 164 | confirmation, or terminate the connection and indicate the server's | |
| 165 | identity is suspect. | |
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Newman Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 172 | ||
| 173 | ||
| 174 | 2.5. TLS Security Policy Check | |
| 175 | ||
| 176 | Both the client and server MUST check the result of the STARTTLS | |
| 177 | command and subsequent TLS negotiation to see whether acceptable | |
| 178 | authentication or privacy was achieved. Ignoring this step | |
| 179 | completely invalidates using TLS for security. The decision about | |
| 180 | whether acceptable authentication or privacy was achieved is made | |
| 181 | locally, is implementation-dependent, and is beyond the scope of this | |
| 182 | document. | |
| 183 | ||
| 184 | 3. IMAP STARTTLS extension | |
| 185 | ||
| 186 | When the TLS extension is present in IMAP, "STARTTLS" is listed as a | |
| 187 | capability in response to the CAPABILITY command. This extension | |
| 188 | adds a single command, "STARTTLS" to the IMAP protocol which is used | |
| 189 | to begin a TLS negotiation. | |
| 190 | ||
| 191 | 3.1. STARTTLS Command | |
| 192 | ||
| 193 | Arguments: none | |
| 194 | ||
| 195 | Responses: no specific responses for this command | |
| 196 | ||
| 197 | Result: OK - begin TLS negotiation | |
| 198 | BAD - command unknown or arguments invalid | |
| 199 | ||
| 200 | A TLS negotiation begins immediately after the CRLF at the end of | |
| 201 | the tagged OK response from the server. Once a client issues a | |
| 202 | STARTTLS command, it MUST NOT issue further commands until a | |
| 203 | server response is seen and the TLS negotiation is complete. | |
| 204 | ||
| 205 | The STARTTLS command is only valid in non-authenticated state. | |
| 206 | The server remains in non-authenticated state, even if client | |
| 207 | credentials are supplied during the TLS negotiation. The SASL | |
| 208 | [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS | |
| 209 | client credentials are successfully exchanged, but servers | |
| 210 | supporting the STARTTLS command are not required to support the | |
| 211 | EXTERNAL mechanism. | |
| 212 | ||
| 213 | Once TLS has been started, the client MUST discard cached | |
| 214 | information about server capabilities and SHOULD re-issue the | |
| 215 | CAPABILITY command. This is necessary to protect against | |
| 216 | man-in-the-middle attacks which alter the capabilities list prior | |
| 217 | to STARTTLS. The server MAY advertise different capabilities | |
| 218 | after STARTTLS. | |
| 219 | ||
| 220 | The formal syntax for IMAP is amended as follows: | |
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Newman Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 228 | ||
| 229 | ||
| 230 | command_any =/ "STARTTLS" | |
| 231 | ||
| 232 | Example: C: a001 CAPABILITY | |
| 233 | S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED | |
| 234 | S: a001 OK CAPABILITY completed | |
| 235 | C: a002 STARTTLS | |
| 236 | S: a002 OK Begin TLS negotiation now | |
| 237 | <TLS negotiation, further commands are under TLS layer> | |
| 238 | C: a003 CAPABILITY | |
| 239 | S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL | |
| 240 | S: a003 OK CAPABILITY completed | |
| 241 | C: a004 LOGIN joe password | |
| 242 | S: a004 OK LOGIN completed | |
| 243 | ||
| 244 | 3.2. IMAP LOGINDISABLED capability | |
| 245 | ||
| 246 | The current IMAP protocol specification (RFC 2060) requires the | |
| 247 | implementation of the LOGIN command which uses clear-text passwords. | |
| 248 | Many sites may choose to disable this command unless encryption is | |
| 249 | active for security reasons. An IMAP server MAY advertise that the | |
| 250 | LOGIN command is disabled by including the LOGINDISABLED capability | |
| 251 | in the capability response. Such a server will respond with a tagged | |
| 252 | "NO" response to any attempt to use the LOGIN command. | |
| 253 | ||
| 254 | An IMAP server which implements STARTTLS MUST implement support for | |
| 255 | the LOGINDISABLED capability on unencrypted connections. | |
| 256 | ||
| 257 | An IMAP client which complies with this specification MUST NOT issue | |
| 258 | the LOGIN command if this capability is present. | |
| 259 | ||
| 260 | This capability is useful to prevent clients compliant with this | |
| 261 | specification from sending an unencrypted password in an environment | |
| 262 | subject to passive attacks. It has no impact on an environment | |
| 263 | subject to active attacks as a man-in-the-middle attacker can remove | |
| 264 | this capability. Therefore this does not relieve clients of the need | |
| 265 | to follow the privacy mode recommendation in section 2.2. | |
| 266 | ||
| 267 | Servers advertising this capability will fail to interoperate with | |
| 268 | many existing compliant IMAP clients and will be unable to prevent | |
| 269 | those clients from disclosing the user's password. | |
| 270 | ||
| 271 | 4. POP3 STARTTLS extension | |
| 272 | ||
| 273 | The POP3 STARTTLS extension adds the STLS command to POP3 servers. | |
| 274 | If this is implemented, the POP3 extension mechanism [POP3EXT] MUST | |
| 275 | also be implemented to avoid the need for client probing of multiple | |
| 276 | commands. The capability name "STLS" indicates this command is | |
| 277 | present and permitted in the current state. | |
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Newman Standards Track [Page 5] | |
| 282 | ||
| 283 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 284 | ||
| 285 | ||
| 286 | STLS | |
| 287 | ||
| 288 | Arguments: none | |
| 289 | ||
| 290 | Restrictions: | |
| 291 | Only permitted in AUTHORIZATION state. | |
| 292 | ||
| 293 | Discussion: | |
| 294 | A TLS negotiation begins immediately after the CRLF at the | |
| 295 | end of the +OK response from the server. A -ERR response | |
| 296 | MAY result if a security layer is already active. Once a | |
| 297 | client issues a STLS command, it MUST NOT issue further | |
| 298 | commands until a server response is seen and the TLS | |
| 299 | negotiation is complete. | |
| 300 | ||
| 301 | The STLS command is only permitted in AUTHORIZATION state | |
| 302 | and the server remains in AUTHORIZATION state, even if | |
| 303 | client credentials are supplied during the TLS negotiation. | |
| 304 | The AUTH command [POP-AUTH] with the EXTERNAL mechanism | |
| 305 | [SASL] MAY be used to authenticate once TLS client | |
| 306 | credentials are successfully exchanged, but servers | |
| 307 | supporting the STLS command are not required to support the | |
| 308 | EXTERNAL mechanism. | |
| 309 | ||
| 310 | Once TLS has been started, the client MUST discard cached | |
| 311 | information about server capabilities and SHOULD re-issue | |
| 312 | the CAPA command. This is necessary to protect against | |
| 313 | man-in-the-middle attacks which alter the capabilities list | |
| 314 | prior to STLS. The server MAY advertise different | |
| 315 | capabilities after STLS. | |
| 316 | ||
| 317 | Possible Responses: | |
| 318 | +OK -ERR | |
| 319 | ||
| 320 | Examples: | |
| 321 | C: STLS | |
| 322 | S: +OK Begin TLS negotiation | |
| 323 | <TLS negotiation, further commands are under TLS layer> | |
| 324 | ... | |
| 325 | C: STLS | |
| 326 | S: -ERR Command not permitted when TLS active | |
| 327 | ||
| 328 | ||
| 329 | ||
| 330 | ||
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Newman Standards Track [Page 6] | |
| 338 | ||
| 339 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 340 | ||
| 341 | ||
| 342 | 5. ACAP STARTTLS extension | |
| 343 | ||
| 344 | When the TLS extension is present in ACAP, "STARTTLS" is listed as a | |
| 345 | capability in the ACAP greeting. No arguments to this capability are | |
| 346 | defined at this time. This extension adds a single command, | |
| 347 | "STARTTLS" to the ACAP protocol which is used to begin a TLS | |
| 348 | negotiation. | |
| 349 | ||
| 350 | 5.1. STARTTLS Command | |
| 351 | ||
| 352 | Arguments: none | |
| 353 | ||
| 354 | Responses: no specific responses for this command | |
| 355 | ||
| 356 | Result: OK - begin TLS negotiation | |
| 357 | BAD - command unknown or arguments invalid | |
| 358 | ||
| 359 | A TLS negotiation begins immediately after the CRLF at the end of | |
| 360 | the tagged OK response from the server. Once a client issues a | |
| 361 | STARTTLS command, it MUST NOT issue further commands until a | |
| 362 | server response is seen and the TLS negotiation is complete. | |
| 363 | ||
| 364 | The STARTTLS command is only valid in non-authenticated state. | |
| 365 | The server remains in non-authenticated state, even if client | |
| 366 | credentials are supplied during the TLS negotiation. The SASL | |
| 367 | [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS | |
| 368 | client credentials are successfully exchanged, but servers | |
| 369 | supporting the STARTTLS command are not required to support the | |
| 370 | EXTERNAL mechanism. | |
| 371 | ||
| 372 | After the TLS layer is established, the server MUST re-issue an | |
| 373 | untagged ACAP greeting. This is necessary to protect against | |
| 374 | man-in-the-middle attacks which alter the capabilities list prior | |
| 375 | to STARTTLS. The client MUST discard cached capability | |
| 376 | information and replace it with the information from the new ACAP | |
| 377 | greeting. The server MAY advertise different capabilities after | |
| 378 | STARTTLS. | |
| 379 | ||
| 380 | The formal syntax for ACAP is amended as follows: | |
| 381 | ||
| 382 | command_any =/ "STARTTLS" | |
| 383 | ||
| 384 | Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) | |
| 385 | C: a002 STARTTLS | |
| 386 | S: a002 OK "Begin TLS negotiation now" | |
| 387 | <TLS negotiation, further commands are under TLS layer> | |
| 388 | S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") | |
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Newman Standards Track [Page 7] | |
| 394 | ||
| 395 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 396 | ||
| 397 | ||
| 398 | 6. PLAIN SASL mechanism | |
| 399 | ||
| 400 | Clear-text passwords are simple, interoperate with almost all | |
| 401 | existing operating system authentication databases, and are useful | |
| 402 | for a smooth transition to a more secure password-based | |
| 403 | authentication mechanism. The drawback is that they are unacceptable | |
| 404 | for use over an unencrypted network connection. | |
| 405 | ||
| 406 | This defines the "PLAIN" SASL mechanism for use with ACAP and other | |
| 407 | protocols with no clear-text login command. The PLAIN SASL mechanism | |
| 408 | MUST NOT be advertised or used unless a strong encryption layer (such | |
| 409 | as the provided by TLS) is active or backwards compatibility dictates | |
| 410 | otherwise. | |
| 411 | ||
| 412 | The mechanism consists of a single message from the client to the | |
| 413 | server. The client sends the authorization identity (identity to | |
| 414 | login as), followed by a US-ASCII NUL character, followed by the | |
| 415 | authentication identity (identity whose password will be used), | |
| 416 | followed by a US-ASCII NUL character, followed by the clear-text | |
| 417 | password. The client may leave the authorization identity empty to | |
| 418 | indicate that it is the same as the authentication identity. | |
| 419 | ||
| 420 | The server will verify the authentication identity and password with | |
| 421 | the system authentication database and verify that the authentication | |
| 422 | credentials permit the client to login as the authorization identity. | |
| 423 | If both steps succeed, the user is logged in. | |
| 424 | ||
| 425 | The server MAY also use the password to initialize any new | |
| 426 | authentication database, such as one suitable for CRAM-MD5 | |
| 427 | [CRAM-MD5]. | |
| 428 | ||
| 429 | Non-US-ASCII characters are permitted as long as they are represented | |
| 430 | in UTF-8 [UTF-8]. Use of non-visible characters or characters which | |
| 431 | a user may be unable to enter on some keyboards is discouraged. | |
| 432 | ||
| 433 | The formal grammar for the client message using Augmented BNF [ABNF] | |
| 434 | follows. | |
| 435 | ||
| 436 | message = [authorize-id] NUL authenticate-id NUL password | |
| 437 | authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets | |
| 438 | authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets | |
| 439 | password = 1*UTF8-SAFE ; MUST accept up to 255 octets | |
| 440 | NUL = %x00 | |
| 441 | UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / | |
| 442 | UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 | |
| 443 | UTF8-1 = %x80-BF | |
| 444 | UTF8-2 = %xC0-DF UTF8-1 | |
| 445 | UTF8-3 = %xE0-EF 2UTF8-1 | |
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Newman Standards Track [Page 8] | |
| 450 | ||
| 451 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 452 | ||
| 453 | ||
| 454 | UTF8-4 = %xF0-F7 3UTF8-1 | |
| 455 | UTF8-5 = %xF8-FB 4UTF8-1 | |
| 456 | UTF8-6 = %xFC-FD 5UTF8-1 | |
| 457 | ||
| 458 | Here is an example of how this might be used to initialize a CRAM-MD5 | |
| 459 | authentication database for ACAP: | |
| 460 | ||
| 461 | Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) | |
| 462 | C: a001 AUTHENTICATE "CRAM-MD5" | |
| 463 | S: + "<1896.697170952@postoffice.reston.mci.net>" | |
| 464 | C: "tim b913a602c7eda7a495b4e6e7334d3890" | |
| 465 | S: a001 NO (TRANSITION-NEEDED) | |
| 466 | "Please change your password, or use TLS to login" | |
| 467 | C: a002 STARTTLS | |
| 468 | S: a002 OK "Begin TLS negotiation now" | |
| 469 | <TLS negotiation, further commands are under TLS layer> | |
| 470 | S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") | |
| 471 | C: a003 AUTHENTICATE "PLAIN" {21+} | |
| 472 | C: <NUL>tim<NUL>tanstaaftanstaaf | |
| 473 | S: a003 OK CRAM-MD5 password initialized | |
| 474 | ||
| 475 | Note: In this example, <NUL> represents a single ASCII NUL octet. | |
| 476 | ||
| 477 | 7. imaps and pop3s ports | |
| 478 | ||
| 479 | Separate "imaps" and "pop3s" ports were registered for use with SSL. | |
| 480 | Use of these ports is discouraged in favor of the STARTTLS or STLS | |
| 481 | commands. | |
| 482 | ||
| 483 | A number of problems have been observed with separate ports for | |
| 484 | "secure" variants of protocols. This is an attempt to enumerate some | |
| 485 | of those problems. | |
| 486 | ||
| 487 | - Separate ports lead to a separate URL scheme which intrudes into | |
| 488 | the user interface in inappropriate ways. For example, many web | |
| 489 | pages use language like "click here if your browser supports SSL." | |
| 490 | This is a decision the browser is often more capable of making than | |
| 491 | the user. | |
| 492 | ||
| 493 | - Separate ports imply a model of either "secure" or "not secure." | |
| 494 | This can be misleading in a number of ways. First, the "secure" | |
| 495 | port may not in fact be acceptably secure as an export-crippled | |
| 496 | cipher suite might be in use. This can mislead users into a false | |
| 497 | sense of security. Second, the normal port might in fact be | |
| 498 | secured by using a SASL mechanism which includes a security layer. | |
| 499 | Thus the separate port distinction makes the complex topic of | |
| 500 | security policy even more confusing. One common result of this | |
| 501 | confusion is that firewall administrators are often misled into | |
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Newman Standards Track [Page 9] | |
| 506 | ||
| 507 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 508 | ||
| 509 | ||
| 510 | permitting the "secure" port and blocking the standard port. This | |
| 511 | could be a poor choice given the common use of SSL with a 40-bit | |
| 512 | key encryption layer and plain-text password authentication is less | |
| 513 | secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. | |
| 514 | ||
| 515 | - Use of separate ports for SSL has caused clients to implement only | |
| 516 | two security policies: use SSL or don't use SSL. The desirable | |
| 517 | security policy "use TLS when available" would be cumbersome with | |
| 518 | the separate port model, but is simple with STARTTLS. | |
| 519 | ||
| 520 | - Port numbers are a limited resource. While they are not yet in | |
| 521 | short supply, it is unwise to set a precedent that could double (or | |
| 522 | worse) the speed of their consumption. | |
| 523 | ||
| 524 | ||
| 525 | 8. IANA Considerations | |
| 526 | ||
| 527 | This constitutes registration of the "STARTTLS" and "LOGINDISABLED" | |
| 528 | IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP]. | |
| 529 | ||
| 530 | The registration for the POP3 "STLS" capability follows: | |
| 531 | ||
| 532 | CAPA tag: STLS | |
| 533 | Arguments: none | |
| 534 | Added commands: STLS | |
| 535 | Standard commands affected: May enable USER/PASS as a side-effect. | |
| 536 | CAPA command SHOULD be re-issued after successful completion. | |
| 537 | Announced states/Valid states: AUTHORIZATION state only. | |
| 538 | Specification reference: this memo | |
| 539 | ||
| 540 | The registration for the ACAP "STARTTLS" capability follows: | |
| 541 | ||
| 542 | Capability name: STARTTLS | |
| 543 | Capability keyword: STARTTLS | |
| 544 | Capability arguments: none | |
| 545 | Published Specification(s): this memo | |
| 546 | Person and email address for further information: | |
| 547 | see author's address section below | |
| 548 | ||
| 549 | The registration for the PLAIN SASL mechanism follows: | |
| 550 | ||
| 551 | SASL mechanism name: PLAIN | |
| 552 | Security Considerations: See section 9 of this memo | |
| 553 | Published specification: this memo | |
| 554 | Person & email address to contact for further information: | |
| 555 | see author's address section below | |
| 556 | Intended usage: COMMON | |
| 557 | Author/Change controller: see author's address section below | |
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Newman Standards Track [Page 10] | |
| 562 | ||
| 563 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 564 | ||
| 565 | ||
| 566 | 9. Security Considerations | |
| 567 | ||
| 568 | TLS only provides protection for data sent over a network connection. | |
| 569 | Messages transferred over IMAP or POP3 are still available to server | |
| 570 | administrators and usually subject to eavesdropping, tampering and | |
| 571 | forgery when transmitted through SMTP or NNTP. TLS is no substitute | |
| 572 | for an end-to-end message security mechanism using MIME security | |
| 573 | multiparts [MIME-SEC]. | |
| 574 | ||
| 575 | A man-in-the-middle attacker can remove STARTTLS from the capability | |
| 576 | list or generate a failure response to the STARTTLS command. In | |
| 577 | order to detect such an attack, clients SHOULD warn the user when | |
| 578 | session privacy is not active and/or be configurable to refuse to | |
| 579 | proceed without an acceptable level of security. | |
| 580 | ||
| 581 | A man-in-the-middle attacker can always cause a down-negotiation to | |
| 582 | the weakest authentication mechanism or cipher suite available. For | |
| 583 | this reason, implementations SHOULD be configurable to refuse weak | |
| 584 | mechanisms or cipher suites. | |
| 585 | ||
| 586 | Any protocol interactions prior to the TLS handshake are performed in | |
| 587 | the clear and can be modified by a man-in-the-middle attacker. For | |
| 588 | this reason, clients MUST discard cached information about server | |
| 589 | capabilities advertised prior to the start of the TLS handshake. | |
| 590 | ||
| 591 | Clients are encouraged to clearly indicate when the level of | |
| 592 | encryption active is known to be vulnerable to attack using modern | |
| 593 | hardware (such as encryption keys with 56 bits of entropy or less). | |
| 594 | ||
| 595 | The LOGINDISABLED IMAP capability (discussed in section 3.2) only | |
| 596 | reduces the potential for passive attacks, it provides no protection | |
| 597 | against active attacks. The responsibility remains with the client | |
| 598 | to avoid sending a password over a vulnerable channel. | |
| 599 | ||
| 600 | The PLAIN mechanism relies on the TLS encryption layer for security. | |
| 601 | When used without TLS, it is vulnerable to a common network | |
| 602 | eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used | |
| 603 | unless a suitable TLS encryption layer is active or backwards | |
| 604 | compatibility dictates otherwise. | |
| 605 | ||
| 606 | When the PLAIN mechanism is used, the server gains the ability to | |
| 607 | impersonate the user to all services with the same password | |
| 608 | regardless of any encryption provided by TLS or other network privacy | |
| 609 | mechanisms. While many other authentication mechanisms have similar | |
| 610 | weaknesses, stronger SASL mechanisms such as Kerberos address this | |
| 611 | issue. Clients are encouraged to have an operational mode where all | |
| 612 | mechanisms which are likely to reveal the user's password to the | |
| 613 | server are disabled. | |
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | Newman Standards Track [Page 11] | |
| 618 | ||
| 619 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 620 | ||
| 621 | ||
| 622 | The security considerations for TLS apply to STARTTLS and the | |
| 623 | security considerations for SASL apply to the PLAIN mechanism. | |
| 624 | Additional security requirements are discussed in section 2. | |
| 625 | ||
| 626 | 10. References | |
| 627 | ||
| 628 | [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
| 629 | Specifications: ABNF", RFC 2234, November 1997. | |
| 630 | ||
| 631 | [ACAP] Newman, C. and J. Myers, "ACAP -- Application | |
| 632 | Configuration Access Protocol", RFC 2244, November 1997. | |
| 633 | ||
| 634 | [AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", | |
| 635 | RFC 1704, October 1994. | |
| 636 | ||
| 637 | [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP | |
| 638 | AUTHorize Extension for Simple Challenge/Response", RFC | |
| 639 | 2195, September 1997. | |
| 640 | ||
| 641 | [IMAP] Crispin, M., "Internet Message Access Protocol - Version | |
| 642 | 4rev1", RFC 2060, December 1996. | |
| 643 | ||
| 644 | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |
| 645 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
| 646 | ||
| 647 | [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, | |
| 648 | "Security Multiparts for MIME: Multipart/Signed and | |
| 649 | Multipart/Encrypted", RFC 1847, October 1995. | |
| 650 | ||
| 651 | [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | |
| 652 | STD 53, RFC 1939, May 1996. | |
| 653 | ||
| 654 | [POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension | |
| 655 | Mechanism", RFC 2449, November 1998. | |
| 656 | ||
| 657 | [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, | |
| 658 | December 1994. | |
| 659 | ||
| 660 | [SASL] Myers, J., "Simple Authentication and Security Layer | |
| 661 | (SASL)", RFC 2222, October 1997. | |
| 662 | ||
| 663 | [SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over | |
| 664 | TLS", RFC 2487, January 1999. | |
| 665 | ||
| 666 | [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | |
| 667 | RFC 2246, January 1999. | |
| 668 | ||
| 669 | ||
| 670 | ||
| 671 | ||
| 672 | ||
| 673 | Newman Standards Track [Page 12] | |
| 674 | ||
| 675 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 676 | ||
| 677 | ||
| 678 | [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO | |
| 679 | 10646", RFC 2279, January 1998. | |
| 680 | ||
| 681 | ||
| 682 | 11. Author's Address | |
| 683 | ||
| 684 | Chris Newman | |
| 685 | Innosoft International, Inc. | |
| 686 | 1050 Lakes Drive | |
| 687 | West Covina, CA 91790 USA | |
| 688 | ||
| 689 | EMail: chris.newman@innosoft.com | |
| 690 | ||
| 691 | ||
| 692 | A. Appendix -- Compliance Checklist | |
| 693 | ||
| 694 | An implementation is not compliant if it fails to satisfy one or more | |
| 695 | of the MUST requirements for the protocols it implements. An | |
| 696 | implementation that satisfies all the MUST and all the SHOULD | |
| 697 | requirements for its protocols is said to be "unconditionally | |
| 698 | compliant"; one that satisfies all the MUST requirements but not all | |
| 699 | the SHOULD requirements for its protocols is said to be | |
| 700 | "conditionally compliant". | |
| 701 | ||
| 702 | Rules Section | |
| 703 | ----- ------- | |
| 704 | Mandatory-to-implement Cipher Suite 2.1 | |
| 705 | SHOULD have mode where encryption required 2.2 | |
| 706 | server SHOULD have mode where TLS not required 2.2 | |
| 707 | MUST be configurable to refuse all clear-text login | |
| 708 | commands or mechanisms 2.3 | |
| 709 | server SHOULD be configurable to refuse clear-text | |
| 710 | login commands on entire server and on per-user basis 2.3 | |
| 711 | client MUST check server identity 2.4 | |
| 712 | client MUST use hostname used to open connection 2.4 | |
| 713 | client MUST NOT use hostname from insecure remote lookup 2.4 | |
| 714 | client SHOULD support subjectAltName of dNSName type 2.4 | |
| 715 | client SHOULD ask for confirmation or terminate on fail 2.4 | |
| 716 | MUST check result of STARTTLS for acceptable privacy 2.5 | |
| 717 | client MUST NOT issue commands after STARTTLS | |
| 718 | until server response and negotiation done 3.1,4,5.1 | |
| 719 | client MUST discard cached information 3.1,4,5.1,9 | |
| 720 | client SHOULD re-issue CAPABILITY/CAPA command 3.1,4 | |
| 721 | IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2 | |
| 722 | IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2 | |
| 723 | POP server MUST implement POP3 extensions 4 | |
| 724 | ACAP server MUST re-issue ACAP greeting 5.1 | |
| 725 | ||
| 726 | ||
| 727 | ||
| 728 | ||
| 729 | Newman Standards Track [Page 13] | |
| 730 | ||
| 731 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 732 | ||
| 733 | ||
| 734 | client SHOULD warn when session privacy not active and/or | |
| 735 | refuse to proceed without acceptable security level 9 | |
| 736 | SHOULD be configurable to refuse weak mechanisms or | |
| 737 | cipher suites 9 | |
| 738 | ||
| 739 | The PLAIN mechanism is an optional part of this specification. | |
| 740 | However if it is implemented the following rules apply: | |
| 741 | ||
| 742 | Rules Section | |
| 743 | ----- ------- | |
| 744 | MUST NOT use PLAIN unless strong encryption active | |
| 745 | or backwards compatibility dictates otherwise 6,9 | |
| 746 | MUST use UTF-8 encoding for characters in PLAIN 6 | |
| 747 | ||
| 748 | ||
| 749 | ||
| 750 | ||
| 751 | ||
| 752 | ||
| 753 | ||
| 754 | ||
| 755 | ||
| 756 | ||
| 757 | ||
| 758 | ||
| 759 | ||
| 760 | ||
| 761 | ||
| 762 | ||
| 763 | ||
| 764 | ||
| 765 | ||
| 766 | ||
| 767 | ||
| 768 | ||
| 769 | ||
| 770 | ||
| 771 | ||
| 772 | ||
| 773 | ||
| 774 | ||
| 775 | ||
| 776 | ||
| 777 | ||
| 778 | ||
| 779 | ||
| 780 | ||
| 781 | ||
| 782 | ||
| 783 | ||
| 784 | ||
| 785 | Newman Standards Track [Page 14] | |
| 786 | ||
| 787 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
| 788 | ||
| 789 | ||
| 790 | Full Copyright Statement | |
| 791 | ||
| 792 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
| 793 | ||
| 794 | This document and translations of it may be copied and furnished to | |
| 795 | others, and derivative works that comment on or otherwise explain it | |
| 796 | or assist in its implementation may be prepared, copied, published | |
| 797 | and distributed, in whole or in part, without restriction of any | |
| 798 | kind, provided that the above copyright notice and this paragraph are | |
| 799 | included on all such copies and derivative works. However, this | |
| 800 | document itself may not be modified in any way, such as by removing | |
| 801 | the copyright notice or references to the Internet Society or other | |
| 802 | Internet organizations, except as needed for the purpose of | |
| 803 | developing Internet standards in which case the procedures for | |
| 804 | copyrights defined in the Internet Standards process must be | |
| 805 | followed, or as required to translate it into languages other than | |
| 806 | English. | |
| 807 | ||
| 808 | The limited permissions granted above are perpetual and will not be | |
| 809 | revoked by the Internet Society or its successors or assigns. | |
| 810 | ||
| 811 | This document and the information contained herein is provided on an | |
| 812 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 813 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 814 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 815 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 816 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 817 | ||
| 818 | Acknowledgement | |
| 819 | ||
| 820 | Funding for the RFC Editor function is currently provided by the | |
| 821 | Internet Society. | |
| 822 | ||
| 823 | ||
| 824 | ||
| 825 | ||
| 826 | ||
| 827 | ||
| 828 | ||
| 829 | ||
| 830 | ||
| 831 | ||
| 832 | ||
| 833 | ||
| 834 | ||
| 835 | ||
| 836 | ||
| 837 | ||
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | Newman Standards Track [Page 15] | |
| 842 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group P. Leach | |
| 7 | Request for Comments: 2831 Microsoft | |
| 8 | Category: Standards Track C. Newman | |
| 9 | Innosoft | |
| 10 | May 2000 | |
| 11 | ||
| 12 | ||
| 13 | Using Digest Authentication as a SASL Mechanism | |
| 14 | ||
| 15 | Status of this Memo | |
| 16 | ||
| 17 | This document specifies an Internet standards track protocol for the | |
| 18 | Internet community, and requests discussion and suggestions for | |
| 19 | improvements. Please refer to the current edition of the "Internet | |
| 20 | Official Protocol Standards" (STD 1) for the standardization state | |
| 21 | and status of this protocol. Distribution of this memo is unlimited. | |
| 22 | ||
| 23 | Copyright Notice | |
| 24 | ||
| 25 | Copyright (C) The Internet Society (2000). All Rights Reserved. | |
| 26 | ||
| 27 | Abstract | |
| 28 | ||
| 29 | This specification defines how HTTP Digest Authentication [Digest] | |
| 30 | can be used as a SASL [RFC 2222] mechanism for any protocol that has | |
| 31 | a SASL profile. It is intended both as an improvement over CRAM-MD5 | |
| 32 | [RFC 2195] and as a convenient way to support a single authentication | |
| 33 | mechanism for web, mail, LDAP, and other protocols. | |
| 34 | ||
| 35 | Table of Contents | |
| 36 | ||
| 37 | 1 INTRODUCTION.....................................................2 | |
| 38 | 1.1 CONVENTIONS AND NOTATION......................................2 | |
| 39 | 1.2 REQUIREMENTS..................................................3 | |
| 40 | 2 AUTHENTICATION...................................................3 | |
| 41 | 2.1 INITIAL AUTHENTICATION........................................3 | |
| 42 | 2.1.1 Step One...................................................3 | |
| 43 | 2.1.2 Step Two...................................................6 | |
| 44 | 2.1.3 Step Three................................................12 | |
| 45 | 2.2 SUBSEQUENT AUTHENTICATION....................................12 | |
| 46 | 2.2.1 Step one..................................................13 | |
| 47 | 2.2.2 Step Two..................................................13 | |
| 48 | 2.3 INTEGRITY PROTECTION.........................................13 | |
| 49 | 2.4 CONFIDENTIALITY PROTECTION...................................14 | |
| 50 | 3 SECURITY CONSIDERATIONS.........................................15 | |
| 51 | 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........15 | |
| 52 | 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................16 | |
| 53 | 3.3 REPLAY ATTACKS...............................................16 | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Leach & Newman Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 60 | ||
| 61 | ||
| 62 | 3.4 ONLINE DICTIONARY ATTACKS....................................16 | |
| 63 | 3.5 OFFLINE DICTIONARY ATTACKS...................................16 | |
| 64 | 3.6 MAN IN THE MIDDLE............................................17 | |
| 65 | 3.7 CHOSEN PLAINTEXT ATTACKS.....................................17 | |
| 66 | 3.8 SPOOFING BY COUNTERFEIT SERVERS..............................17 | |
| 67 | 3.9 STORING PASSWORDS............................................17 | |
| 68 | 3.10 MULTIPLE REALMS.............................................18 | |
| 69 | 3.11 SUMMARY.....................................................18 | |
| 70 | 4 EXAMPLE.........................................................18 | |
| 71 | 5 REFERENCES......................................................20 | |
| 72 | 6 AUTHORS' ADDRESSES..............................................21 | |
| 73 | 7 ABNF............................................................21 | |
| 74 | 7.1 AUGMENTED BNF................................................21 | |
| 75 | 7.2 BASIC RULES..................................................23 | |
| 76 | 8 SAMPLE CODE.....................................................25 | |
| 77 | 9 FULL COPYRIGHT STATEMENT........................................27 | |
| 78 | ||
| 79 | 1 Introduction | |
| 80 | ||
| 81 | This specification describes the use of HTTP Digest Access | |
| 82 | Authentication as a SASL mechanism. The authentication type | |
| 83 | associated with the Digest SASL mechanism is "DIGEST-MD5". | |
| 84 | ||
| 85 | This specification is intended to be upward compatible with the | |
| 86 | "md5-sess" algorithm of HTTP/1.1 Digest Access Authentication | |
| 87 | specified in [Digest]. The only difference in the "md5-sess" | |
| 88 | algorithm is that some directives not needed in a SASL mechanism have | |
| 89 | had their values defaulted. | |
| 90 | ||
| 91 | There is one new feature for use as a SASL mechanism: integrity | |
| 92 | protection on application protocol messages after an authentication | |
| 93 | exchange. | |
| 94 | ||
| 95 | Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext | |
| 96 | attacks, and permits the use of third party authentication servers, | |
| 97 | mutual authentication, and optimized reauthentication if a client has | |
| 98 | recently authenticated to a server. | |
| 99 | ||
| 100 | 1.1 Conventions and Notation | |
| 101 | ||
| 102 | This specification uses the same ABNF notation and lexical | |
| 103 | conventions as HTTP/1.1 specification; see appendix A. | |
| 104 | ||
| 105 | Let { a, b, ... } be the concatenation of the octet strings a, b, ... | |
| 106 | ||
| 107 | Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s. | |
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Leach & Newman Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 116 | ||
| 117 | ||
| 118 | Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string | |
| 119 | k, a colon and the string s. | |
| 120 | ||
| 121 | Let HEX(n) be the representation of the 16 octet MD5 hash n as a | |
| 122 | string of 32 hex digits (with alphabetic characters always in lower | |
| 123 | case, since MD5 is case sensitive). | |
| 124 | ||
| 125 | Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet | |
| 126 | string s using the octet string k as a key. | |
| 127 | ||
| 128 | The value of a quoted string constant as an octet string does not | |
| 129 | include any terminating null character. | |
| 130 | ||
| 131 | 1.2 Requirements | |
| 132 | ||
| 133 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
| 134 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
| 135 | document are to be interpreted as described in RFC 2119 [RFC 2119]. | |
| 136 | ||
| 137 | An implementation is not compliant if it fails to satisfy one or more | |
| 138 | of the MUST level requirements for the protocols it implements. An | |
| 139 | implementation that satisfies all the MUST level and all the SHOULD | |
| 140 | level requirements for its protocols is said to be "unconditionally | |
| 141 | compliant"; one that satisfies all the MUST level requirements but | |
| 142 | not all the SHOULD level requirements for its protocols is said to be | |
| 143 | "conditionally compliant." | |
| 144 | ||
| 145 | 2 Authentication | |
| 146 | ||
| 147 | The following sections describe how to use Digest as a SASL | |
| 148 | authentication mechanism. | |
| 149 | ||
| 150 | 2.1 Initial Authentication | |
| 151 | ||
| 152 | If the client has not recently authenticated to the server, then it | |
| 153 | must perform "initial authentication", as defined in this section. If | |
| 154 | it has recently authenticated, then a more efficient form is | |
| 155 | available, defined in the next section. | |
| 156 | ||
| 157 | 2.1.1 Step One | |
| 158 | ||
| 159 | The server starts by sending a challenge. The data encoded in the | |
| 160 | challenge contains a string formatted according to the rules for a | |
| 161 | "digest-challenge" defined as follows: | |
| 162 | ||
| 163 | ||
| 164 | ||
| 165 | ||
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Leach & Newman Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 172 | ||
| 173 | ||
| 174 | digest-challenge = | |
| 175 | 1#( realm | nonce | qop-options | stale | maxbuf | charset | |
| 176 | algorithm | cipher-opts | auth-param ) | |
| 177 | ||
| 178 | realm = "realm" "=" <"> realm-value <"> | |
| 179 | realm-value = qdstr-val | |
| 180 | nonce = "nonce" "=" <"> nonce-value <"> | |
| 181 | nonce-value = qdstr-val | |
| 182 | qop-options = "qop" "=" <"> qop-list <"> | |
| 183 | qop-list = 1#qop-value | |
| 184 | qop-value = "auth" | "auth-int" | "auth-conf" | | |
| 185 | token | |
| 186 | stale = "stale" "=" "true" | |
| 187 | maxbuf = "maxbuf" "=" maxbuf-value | |
| 188 | maxbuf-value = 1*DIGIT | |
| 189 | charset = "charset" "=" "utf-8" | |
| 190 | algorithm = "algorithm" "=" "md5-sess" | |
| 191 | cipher-opts = "cipher" "=" <"> 1#cipher-value <"> | |
| 192 | cipher-value = "3des" | "des" | "rc4-40" | "rc4" | | |
| 193 | "rc4-56" | token | |
| 194 | auth-param = token "=" ( token | quoted-string ) | |
| 195 | ||
| 196 | The meanings of the values of the directives used above are as | |
| 197 | follows: | |
| 198 | ||
| 199 | realm | |
| 200 | Mechanistically, a string which can enable users to know which | |
| 201 | username and password to use, in case they might have different | |
| 202 | ones for different servers. Conceptually, it is the name of a | |
| 203 | collection of accounts that might include the user's account. This | |
| 204 | string should contain at least the name of the host performing the | |
| 205 | authentication and might additionally indicate the collection of | |
| 206 | users who might have access. An example might be | |
| 207 | "registered_users@gotham.news.example.com". This directive is | |
| 208 | optional; if not present, the client SHOULD solicit it from the | |
| 209 | user or be able to compute a default; a plausible default might be | |
| 210 | the realm supplied by the user when they logged in to the client | |
| 211 | system. Multiple realm directives are allowed, in which case the | |
| 212 | user or client must choose one as the realm for which to supply to | |
| 213 | username and password. | |
| 214 | ||
| 215 | nonce | |
| 216 | A server-specified data string which MUST be different each time a | |
| 217 | digest-challenge is sent as part of initial authentication. It is | |
| 218 | recommended that this string be base64 or hexadecimal data. Note | |
| 219 | that since the string is passed as a quoted string, the | |
| 220 | double-quote character is not allowed unless escaped (see section | |
| 221 | 7.2). The contents of the nonce are implementation dependent. The | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Leach & Newman Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 228 | ||
| 229 | ||
| 230 | security of the implementation depends on a good choice. It is | |
| 231 | RECOMMENDED that it contain at least 64 bits of entropy. The nonce | |
| 232 | is opaque to the client. This directive is required and MUST | |
| 233 | appear exactly once; if not present, or if multiple instances are | |
| 234 | present, the client should abort the authentication exchange. | |
| 235 | ||
| 236 | qop-options | |
| 237 | A quoted string of one or more tokens indicating the "quality of | |
| 238 | protection" values supported by the server. The value "auth" | |
| 239 | indicates authentication; the value "auth-int" indicates | |
| 240 | authentication with integrity protection; the value "auth-conf" | |
| 241 | indicates authentication with integrity protection and encryption. | |
| 242 | This directive is optional; if not present it defaults to "auth". | |
| 243 | The client MUST ignore unrecognized options; if the client | |
| 244 | recognizes no option, it should abort the authentication exchange. | |
| 245 | ||
| 246 | stale | |
| 247 | The "stale" directive is not used in initial authentication. See | |
| 248 | the next section for its use in subsequent authentications. This | |
| 249 | directive may appear at most once; if multiple instances are | |
| 250 | present, the client should abort the authentication exchange. | |
| 251 | ||
| 252 | maxbuf | |
| 253 | A number indicating the size of the largest buffer the server is | |
| 254 | able to receive when using "auth-int" or "auth-conf". If this | |
| 255 | directive is missing, the default value is 65536. This directive | |
| 256 | may appear at most once; if multiple instances are present, the | |
| 257 | client should abort the authentication exchange. | |
| 258 | ||
| 259 | charset | |
| 260 | This directive, if present, specifies that the server supports | |
| 261 | UTF-8 encoding for the username and password. If not present, the | |
| 262 | username and password must be encoded in ISO 8859-1 (of which | |
| 263 | US-ASCII is a subset). The directive is needed for backwards | |
| 264 | compatibility with HTTP Digest, which only supports ISO 8859-1. | |
| 265 | This directive may appear at most once; if multiple instances are | |
| 266 | present, the client should abort the authentication exchange. | |
| 267 | ||
| 268 | algorithm | |
| 269 | This directive is required for backwards compatibility with HTTP | |
| 270 | Digest., which supports other algorithms. . This directive is | |
| 271 | required and MUST appear exactly once; if not present, or if | |
| 272 | multiple instances are present, the client should abort the | |
| 273 | authentication exchange. | |
| 274 | ||
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Leach & Newman Standards Track [Page 5] | |
| 282 | ||
| 283 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 284 | ||
| 285 | ||
| 286 | cipher-opts | |
| 287 | A list of ciphers that the server supports. This directive must be | |
| 288 | present exactly once if "auth-conf" is offered in the | |
| 289 | "qop-options" directive, in which case the "3des" and "des" modes | |
| 290 | are mandatory-to-implement. The client MUST ignore unrecognized | |
| 291 | options; if the client recognizes no option, it should abort the | |
| 292 | authentication exchange. | |
| 293 | ||
| 294 | des | |
| 295 | the Data Encryption Standard (DES) cipher [FIPS] in cipher | |
| 296 | block chaining (CBC) mode with a 56 bit key. | |
| 297 | ||
| 298 | 3des | |
| 299 | the "triple DES" cipher in CBC mode with EDE with the same key | |
| 300 | for each E stage (aka "two keys mode") for a total key length | |
| 301 | of 112 bits. | |
| 302 | ||
| 303 | rc4, rc4-40, rc4-56 | |
| 304 | the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, | |
| 305 | respectively. | |
| 306 | ||
| 307 | auth-param This construct allows for future extensions; it may appear | |
| 308 | more than once. The client MUST ignore any unrecognized | |
| 309 | directives. | |
| 310 | ||
| 311 | For use as a SASL mechanism, note that the following changes are made | |
| 312 | to "digest-challenge" from HTTP: the following Digest options (called | |
| 313 | "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent, | |
| 314 | and MUST be ignored if received): | |
| 315 | ||
| 316 | opaque | |
| 317 | domain | |
| 318 | ||
| 319 | The size of a digest-challenge MUST be less than 2048 bytes. | |
| 320 | ||
| 321 | 2.1.2 Step Two | |
| 322 | ||
| 323 | The client makes note of the "digest-challenge" and then responds | |
| 324 | with a string formatted and computed according to the rules for a | |
| 325 | "digest-response" defined as follows: | |
| 326 | ||
| 327 | ||
| 328 | ||
| 329 | ||
| 330 | ||
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Leach & Newman Standards Track [Page 6] | |
| 338 | ||
| 339 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 340 | ||
| 341 | ||
| 342 | digest-response = 1#( username | realm | nonce | cnonce | | |
| 343 | nonce-count | qop | digest-uri | response | | |
| 344 | maxbuf | charset | cipher | authzid | | |
| 345 | auth-param ) | |
| 346 | ||
| 347 | username = "username" "=" <"> username-value <"> | |
| 348 | username-value = qdstr-val | |
| 349 | cnonce = "cnonce" "=" <"> cnonce-value <"> | |
| 350 | cnonce-value = qdstr-val | |
| 351 | nonce-count = "nc" "=" nc-value | |
| 352 | nc-value = 8LHEX | |
| 353 | qop = "qop" "=" qop-value | |
| 354 | digest-uri = "digest-uri" "=" <"> digest-uri-value <"> | |
| 355 | digest-uri-value = serv-type "/" host [ "/" serv-name ] | |
| 356 | serv-type = 1*ALPHA | |
| 357 | host = 1*( ALPHA | DIGIT | "-" | "." ) | |
| 358 | serv-name = host | |
| 359 | response = "response" "=" response-value | |
| 360 | response-value = 32LHEX | |
| 361 | LHEX = "0" | "1" | "2" | "3" | | |
| 362 | "4" | "5" | "6" | "7" | | |
| 363 | "8" | "9" | "a" | "b" | | |
| 364 | "c" | "d" | "e" | "f" | |
| 365 | cipher = "cipher" "=" cipher-value | |
| 366 | authzid = "authzid" "=" <"> authzid-value <"> | |
| 367 | authzid-value = qdstr-val | |
| 368 | ||
| 369 | ||
| 370 | username | |
| 371 | The user's name in the specified realm, encoded according to the | |
| 372 | value of the "charset" directive. This directive is required and | |
| 373 | MUST be present exactly once; otherwise, authentication fails. | |
| 374 | ||
| 375 | realm | |
| 376 | The realm containing the user's account. This directive is | |
| 377 | required if the server provided any realms in the | |
| 378 | "digest-challenge", in which case it may appear exactly once and | |
| 379 | its value SHOULD be one of those realms. If the directive is | |
| 380 | missing, "realm-value" will set to the empty string when computing | |
| 381 | A1 (see below for details). | |
| 382 | ||
| 383 | nonce | |
| 384 | The server-specified data string received in the preceding | |
| 385 | digest-challenge. This directive is required and MUST be present | |
| 386 | exactly once; otherwise, authentication fails. | |
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Leach & Newman Standards Track [Page 7] | |
| 394 | ||
| 395 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 396 | ||
| 397 | ||
| 398 | cnonce | |
| 399 | A client-specified data string which MUST be different each time a | |
| 400 | digest-response is sent as part of initial authentication. The | |
| 401 | cnonce-value is an opaque quoted string value provided by the | |
| 402 | client and used by both client and server to avoid chosen | |
| 403 | plaintext attacks, and to provide mutual authentication. The | |
| 404 | security of the implementation depends on a good choice. It is | |
| 405 | RECOMMENDED that it contain at least 64 bits of entropy. This | |
| 406 | directive is required and MUST be present exactly once; otherwise, | |
| 407 | authentication fails. | |
| 408 | ||
| 409 | nonce-count | |
| 410 | The nc-value is the hexadecimal count of the number of requests | |
| 411 | (including the current request) that the client has sent with the | |
| 412 | nonce value in this request. For example, in the first request | |
| 413 | sent in response to a given nonce value, the client sends | |
| 414 | "nc=00000001". The purpose of this directive is to allow the | |
| 415 | server to detect request replays by maintaining its own copy of | |
| 416 | this count - if the same nc-value is seen twice, then the request | |
| 417 | is a replay. See the description below of the construction of | |
| 418 | the response value. This directive may appear at most once; if | |
| 419 | multiple instances are present, the client should abort the | |
| 420 | authentication exchange. | |
| 421 | ||
| 422 | qop | |
| 423 | Indicates what "quality of protection" the client accepted. If | |
| 424 | present, it may appear exactly once and its value MUST be one of | |
| 425 | the alternatives in qop-options. If not present, it defaults to | |
| 426 | "auth". These values affect the computation of the response. Note | |
| 427 | that this is a single token, not a quoted list of alternatives. | |
| 428 | ||
| 429 | serv-type | |
| 430 | Indicates the type of service, such as "www" for web service, | |
| 431 | "ftp" for FTP service, "smtp" for mail delivery service, etc. The | |
| 432 | service name as defined in the SASL profile for the protocol see | |
| 433 | section 4 of [RFC 2222], registered in the IANA registry of | |
| 434 | "service" elements for the GSSAPI host-based service name form | |
| 435 | [RFC 2078]. | |
| 436 | ||
| 437 | host | |
| 438 | The DNS host name or IP address for the service requested. The | |
| 439 | DNS host name must be the fully-qualified canonical name of the | |
| 440 | host. The DNS host name is the preferred form; see notes on server | |
| 441 | processing of the digest-uri. | |
| 442 | ||
| 443 | ||
| 444 | ||
| 445 | ||
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Leach & Newman Standards Track [Page 8] | |
| 450 | ||
| 451 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 452 | ||
| 453 | ||
| 454 | serv-name | |
| 455 | Indicates the name of the service if it is replicated. The service | |
| 456 | is considered to be replicated if the client's service-location | |
| 457 | process involves resolution using standard DNS lookup operations, | |
| 458 | and if these operations involve DNS records (such as SRV, or MX) | |
| 459 | which resolve one DNS name into a set of other DNS names. In this | |
| 460 | case, the initial name used by the client is the "serv-name", and | |
| 461 | the final name is the "host" component. For example, the incoming | |
| 462 | mail service for "example.com" may be replicated through the use | |
| 463 | of MX records stored in the DNS, one of which points at an SMTP | |
| 464 | server called "mail3.example.com"; it's "serv-name" would be | |
| 465 | "example.com", it's "host" would be "mail3.example.com". If the | |
| 466 | service is not replicated, or the serv-name is identical to the | |
| 467 | host, then the serv-name component MUST be omitted. | |
| 468 | ||
| 469 | digest-uri | |
| 470 | Indicates the principal name of the service with which the client | |
| 471 | wishes to connect, formed from the serv-type, host, and serv-name. | |
| 472 | For example, the FTP service on "ftp.example.com" would have a | |
| 473 | "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from | |
| 474 | the example above would have a "digest-uri" value of | |
| 475 | "smtp/mail3.example.com/example.com". | |
| 476 | ||
| 477 | Servers SHOULD check that the supplied value is correct. This will | |
| 478 | detect accidental connection to the incorrect server. It is also so | |
| 479 | that clients will be trained to provide values that will work with | |
| 480 | implementations that use a shared back-end authentication service | |
| 481 | that can provide server authentication. | |
| 482 | ||
| 483 | The serv-type component should match the service being offered. The | |
| 484 | host component should match one of the host names of the host on | |
| 485 | which the service is running, or it's IP address. Servers SHOULD NOT | |
| 486 | normally support the IP address form, because server authentication | |
| 487 | by IP address is not very useful; they should only do so if the DNS | |
| 488 | is unavailable or unreliable. The serv-name component should match | |
| 489 | one of the service's configured service names. | |
| 490 | ||
| 491 | This directive may appear at most once; if multiple instances are | |
| 492 | present, the client should abort the authentication exchange. | |
| 493 | ||
| 494 | Note: In the HTTP use of Digest authentication, the digest-uri is the | |
| 495 | URI (usually a URL) of the resource requested -- hence the name of | |
| 496 | the directive. | |
| 497 | ||
| 498 | response | |
| 499 | A string of 32 hex digits computed as defined below, which proves | |
| 500 | that the user knows a password. This directive is required and | |
| 501 | MUST be present exactly once; otherwise, authentication fails. | |
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Leach & Newman Standards Track [Page 9] | |
| 506 | ||
| 507 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 508 | ||
| 509 | ||
| 510 | maxbuf | |
| 511 | A number indicating the size of the largest buffer the client is | |
| 512 | able to receive. If this directive is missing, the default value | |
| 513 | is 65536. This directive may appear at most once; if multiple | |
| 514 | instances are present, the server should abort the authentication | |
| 515 | exchange. | |
| 516 | ||
| 517 | charset | |
| 518 | This directive, if present, specifies that the client has used | |
| 519 | UTF-8 encoding for the username and password. If not present, the | |
| 520 | username and password must be encoded in ISO 8859-1 (of which | |
| 521 | US-ASCII is a subset). The client should send this directive only | |
| 522 | if the server has indicated it supports UTF-8. The directive is | |
| 523 | needed for backwards compatibility with HTTP Digest, which only | |
| 524 | supports ISO 8859-1. | |
| 525 | ||
| 526 | LHEX | |
| 527 | 32 hex digits, where the alphabetic characters MUST be lower case, | |
| 528 | because MD5 is not case insensitive. | |
| 529 | ||
| 530 | cipher | |
| 531 | The cipher chosen by the client. This directive MUST appear | |
| 532 | exactly once if "auth-conf" is negotiated; if required and not | |
| 533 | present, authentication fails. | |
| 534 | ||
| 535 | authzid | |
| 536 | The "authorization ID" as per RFC 2222, encoded in UTF-8. This | |
| 537 | directive is optional. If present, and the authenticating user has | |
| 538 | sufficient privilege, and the server supports it, then after | |
| 539 | authentication the server will use this identity for making all | |
| 540 | accesses and access checks. If the client specifies it, and the | |
| 541 | server does not support it, then the response-value will be | |
| 542 | incorrect, and authentication will fail. | |
| 543 | ||
| 544 | The size of a digest-response MUST be less than 4096 bytes. | |
| 545 | ||
| 546 | 2.1.2.1 Response-value | |
| 547 | ||
| 548 | The definition of "response-value" above indicates the encoding for | |
| 549 | its value -- 32 lower case hex characters. The following definitions | |
| 550 | show how the value is computed. | |
| 551 | ||
| 552 | Although qop-value and components of digest-uri-value may be | |
| 553 | case-insensitive, the case which the client supplies in step two is | |
| 554 | preserved for the purpose of computing and verifying the | |
| 555 | response-value. | |
| 556 | ||
| 557 | response-value = | |
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Leach & Newman Standards Track [Page 10] | |
| 562 | ||
| 563 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 564 | ||
| 565 | ||
| 566 | HEX( KD ( HEX(H(A1)), | |
| 567 | { nonce-value, ":" nc-value, ":", | |
| 568 | cnonce-value, ":", qop-value, ":", HEX(H(A2)) })) | |
| 569 | ||
| 570 | If authzid is specified, then A1 is | |
| 571 | ||
| 572 | ||
| 573 | A1 = { H( { username-value, ":", realm-value, ":", passwd } ), | |
| 574 | ":", nonce-value, ":", cnonce-value, ":", authzid-value } | |
| 575 | ||
| 576 | If authzid is not specified, then A1 is | |
| 577 | ||
| 578 | ||
| 579 | A1 = { H( { username-value, ":", realm-value, ":", passwd } ), | |
| 580 | ":", nonce-value, ":", cnonce-value } | |
| 581 | ||
| 582 | where | |
| 583 | ||
| 584 | passwd = *OCTET | |
| 585 | ||
| 586 | The "username-value", "realm-value" and "passwd" are encoded | |
| 587 | according to the value of the "charset" directive. If "charset=UTF-8" | |
| 588 | is present, and all the characters of either "username-value" or | |
| 589 | "passwd" are in the ISO 8859-1 character set, then it must be | |
| 590 | converted to ISO 8859-1 before being hashed. This is so that | |
| 591 | authentication databases that store the hashed username, realm and | |
| 592 | password (which is common) can be shared compatibly with HTTP, which | |
| 593 | specifies ISO 8859-1. A sample implementation of this conversion is | |
| 594 | in section 8. | |
| 595 | ||
| 596 | If the "qop" directive's value is "auth", then A2 is: | |
| 597 | ||
| 598 | A2 = { "AUTHENTICATE:", digest-uri-value } | |
| 599 | ||
| 600 | If the "qop" value is "auth-int" or "auth-conf" then A2 is: | |
| 601 | ||
| 602 | A2 = { "AUTHENTICATE:", digest-uri-value, | |
| 603 | ":00000000000000000000000000000000" } | |
| 604 | ||
| 605 | Note that "AUTHENTICATE:" must be in upper case, and the second | |
| 606 | string constant is a string with a colon followed by 32 zeros. | |
| 607 | ||
| 608 | These apparently strange values of A2 are for compatibility with | |
| 609 | HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and | |
| 610 | the hash of the entity body to zero in the HTTP digest calculation of | |
| 611 | A2. | |
| 612 | ||
| 613 | Also, in the HTTP usage of Digest, several directives in the | |
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | Leach & Newman Standards Track [Page 11] | |
| 618 | ||
| 619 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 620 | ||
| 621 | ||
| 622 | "digest-challenge" sent by the server have to be returned by the | |
| 623 | client in the "digest-response". These are: | |
| 624 | ||
| 625 | opaque | |
| 626 | algorithm | |
| 627 | ||
| 628 | These directives are not needed when Digest is used as a SASL | |
| 629 | mechanism (i.e., MUST NOT be sent, and MUST be ignored if received). | |
| 630 | ||
| 631 | 2.1.3 Step Three | |
| 632 | ||
| 633 | The server receives and validates the "digest-response". The server | |
| 634 | checks that the nonce-count is "00000001". If it supports subsequent | |
| 635 | authentication (see section 2.2), it saves the value of the nonce and | |
| 636 | the nonce-count. It sends a message formatted as follows: | |
| 637 | ||
| 638 | response-auth = "rspauth" "=" response-value | |
| 639 | ||
| 640 | where response-value is calculated as above, using the values sent in | |
| 641 | step two, except that if qop is "auth", then A2 is | |
| 642 | ||
| 643 | A2 = { ":", digest-uri-value } | |
| 644 | ||
| 645 | And if qop is "auth-int" or "auth-conf" then A2 is | |
| 646 | ||
| 647 | A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" } | |
| 648 | ||
| 649 | Compared to its use in HTTP, the following Digest directives in the | |
| 650 | "digest-response" are unused: | |
| 651 | ||
| 652 | nextnonce | |
| 653 | qop | |
| 654 | cnonce | |
| 655 | nonce-count | |
| 656 | ||
| 657 | 2.2 Subsequent Authentication | |
| 658 | ||
| 659 | If the client has previously authenticated to the server, and | |
| 660 | remembers the values of username, realm, nonce, nonce-count, cnonce, | |
| 661 | and qop that it used in that authentication, and the SASL profile for | |
| 662 | a protocol permits an initial client response, then it MAY perform | |
| 663 | "subsequent authentication", as defined in this section. | |
| 664 | ||
| 665 | ||
| 666 | ||
| 667 | ||
| 668 | ||
| 669 | ||
| 670 | ||
| 671 | ||
| 672 | ||
| 673 | Leach & Newman Standards Track [Page 12] | |
| 674 | ||
| 675 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 676 | ||
| 677 | ||
| 678 | 2.2.1 Step one | |
| 679 | ||
| 680 | The client uses the values from the previous authentication and sends | |
| 681 | an initial response with a string formatted and computed according to | |
| 682 | the rules for a "digest-response", as defined above, but with a | |
| 683 | nonce-count one greater than used in the last "digest-response". | |
| 684 | ||
| 685 | 2.2.2 Step Two | |
| 686 | ||
| 687 | The server receives the "digest-response". If the server does not | |
| 688 | support subsequent authentication, then it sends a | |
| 689 | "digest-challenge", and authentication proceeds as in initial | |
| 690 | authentication. If the server has no saved nonce and nonce-count from | |
| 691 | a previous authentication, then it sends a "digest-challenge", and | |
| 692 | authentication proceeds as in initial authentication. Otherwise, the | |
| 693 | server validates the "digest-response", checks that the nonce-count | |
| 694 | is one greater than that used in the previous authentication using | |
| 695 | that nonce, and saves the new value of nonce-count. | |
| 696 | ||
| 697 | If the response is invalid, then the server sends a | |
| 698 | "digest-challenge", and authentication proceeds as in initial | |
| 699 | authentication (and should be configurable to log an authentication | |
| 700 | failure in some sort of security audit log, since the failure may be | |
| 701 | a symptom of an attack). The nonce-count MUST NOT be incremented in | |
| 702 | this case: to do so would allow a denial of service attack by sending | |
| 703 | an out-of-order nonce-count. | |
| 704 | ||
| 705 | If the response is valid, the server MAY choose to deem that | |
| 706 | authentication has succeeded. However, if it has been too long since | |
| 707 | the previous authentication, or for any other reason, the server MAY | |
| 708 | send a new "digest-challenge" with a new value for nonce. The | |
| 709 | challenge MAY contain a "stale" directive with value "true", which | |
| 710 | says that the client may respond to the challenge using the password | |
| 711 | it used in the previous response; otherwise, the client must solicit | |
| 712 | the password anew from the user. This permits the server to make sure | |
| 713 | that the user has presented their password recently. (The directive | |
| 714 | name refers to the previous nonce being stale, not to the last use of | |
| 715 | the password.) Except for the handling of "stale", after sending the | |
| 716 | "digest-challenge" authentication proceeds as in the case of initial | |
| 717 | authentication. | |
| 718 | ||
| 719 | 2.3 Integrity Protection | |
| 720 | ||
| 721 | If the server offered "qop=auth-int" and the client responded | |
| 722 | "qop=auth-int", then subsequent messages, up to but not including the | |
| 723 | next subsequent authentication, between the client and the server | |
| 724 | ||
| 725 | ||
| 726 | ||
| 727 | ||
| 728 | ||
| 729 | Leach & Newman Standards Track [Page 13] | |
| 730 | ||
| 731 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 732 | ||
| 733 | ||
| 734 | MUST be integrity protected. Using as a base session key the value of | |
| 735 | H(A1) as defined above the client and server calculate a pair of | |
| 736 | message integrity keys as follows. | |
| 737 | ||
| 738 | The key for integrity protecting messages from client to server is: | |
| 739 | ||
| 740 | Kic = MD5({H(A1), | |
| 741 | "Digest session key to client-to-server signing key magic constant"}) | |
| 742 | ||
| 743 | The key for integrity protecting messages from server to client is: | |
| 744 | ||
| 745 | Kis = MD5({H(A1), | |
| 746 | "Digest session key to server-to-client signing key magic constant"}) | |
| 747 | ||
| 748 | where MD5 is as specified in [RFC 1321]. If message integrity is | |
| 749 | negotiated, a MAC block for each message is appended to the message. | |
| 750 | The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC | |
| 751 | 2104] of the message, a 2-byte message type number in network byte | |
| 752 | order with value 1, and the 4-byte sequence number in network byte | |
| 753 | order. The message type is to allow for future extensions such as | |
| 754 | rekeying. | |
| 755 | ||
| 756 | MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001, | |
| 757 | SeqNum) | |
| 758 | ||
| 759 | where Ki is Kic for messages sent by the client and Kis for those | |
| 760 | sent by the server. The sequence number is initialized to zero, and | |
| 761 | incremented by one for each message sent. | |
| 762 | ||
| 763 | Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the | |
| 764 | received value; the message is discarded if they differ. | |
| 765 | ||
| 766 | 2.4 Confidentiality Protection | |
| 767 | ||
| 768 | If the server sent a "cipher-opts" directive and the client responded | |
| 769 | with a "cipher" directive, then subsequent messages between the | |
| 770 | client and the server MUST be confidentiality protected. Using as a | |
| 771 | base session key the value of H(A1) as defined above the client and | |
| 772 | server calculate a pair of message integrity keys as follows. | |
| 773 | ||
| 774 | The key for confidentiality protecting messages from client to server | |
| 775 | is: | |
| 776 | ||
| 777 | Kcc = MD5({H(A1)[0..n], | |
| 778 | "Digest H(A1) to client-to-server sealing key magic constant"}) | |
| 779 | ||
| 780 | The key for confidentiality protecting messages from server to client | |
| 781 | is: | |
| 782 | ||
| 783 | ||
| 784 | ||
| 785 | Leach & Newman Standards Track [Page 14] | |
| 786 | ||
| 787 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 788 | ||
| 789 | ||
| 790 | Kcs = MD5({H(A1)[0..n], | |
| 791 | "Digest H(A1) to server-to-client sealing key magic constant"}) | |
| 792 | ||
| 793 | where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; | |
| 794 | for "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*" | |
| 795 | ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is the first | |
| 796 | 7 bytes; the key for "3des" is the first 14 bytes. The IV for "des" | |
| 797 | and "3des" is the last 8 bytes of Kcc or Kcs. | |
| 798 | ||
| 799 | If message confidentiality is negotiated, each message is encrypted | |
| 800 | with the chosen cipher and a MAC block is appended to the message. | |
| 801 | ||
| 802 | The MAC block is a variable length padding prefix followed by 16 | |
| 803 | bytes formatted as follows: the first 10 bytes of the HMAC-MD5 [RFC | |
| 804 | 2104] of the message, a 2-byte message type number in network byte | |
| 805 | order with value 1, and the 4-byte sequence number in network byte | |
| 806 | order. If the blocksize of the chosen cipher is not 1 byte, the | |
| 807 | padding prefix is one or more octets each containing the number of | |
| 808 | padding bytes, such that total length of the encrypted part of the | |
| 809 | message is a multiple of the blocksize. The padding and first 10 | |
| 810 | bytes of the MAC block are encrypted along with the message. | |
| 811 | ||
| 812 | SEAL(Ki, Kc, SeqNum, msg) = | |
| 813 | {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001, | |
| 814 | SeqNum} | |
| 815 | ||
| 816 | where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for | |
| 817 | messages sent by the client and Kis and Kcs for those sent by the | |
| 818 | server. The sequence number is initialized to zero, and incremented | |
| 819 | by one for each message sent. | |
| 820 | ||
| 821 | Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is | |
| 822 | computed and compared with the received value; the message is | |
| 823 | discarded if they differ. | |
| 824 | ||
| 825 | 3 Security Considerations | |
| 826 | ||
| 827 | 3.1 Authentication of Clients using Digest Authentication | |
| 828 | ||
| 829 | Digest Authentication does not provide a strong authentication | |
| 830 | mechanism, when compared to public key based mechanisms, for example. | |
| 831 | However, since it prevents chosen plaintext attacks, it is stronger | |
| 832 | than (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], | |
| 833 | POP and IMAP (see RFC 2195 [9]). It is intended to replace the much | |
| 834 | weaker and even more dangerous use of plaintext passwords; however, | |
| 835 | since it is still a password based mechanism it avoids some of the | |
| 836 | potential deployabilty issues with public-key, OTP or similar | |
| 837 | mechanisms. | |
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | Leach & Newman Standards Track [Page 15] | |
| 842 | ||
| 843 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 844 | ||
| 845 | ||
| 846 | Digest Authentication offers no confidentiality protection beyond | |
| 847 | protecting the actual password. All of the rest of the challenge and | |
| 848 | response are available to an eavesdropper, including the user's name | |
| 849 | and authentication realm. | |
| 850 | ||
| 851 | 3.2 Comparison of Digest with Plaintext Passwords | |
| 852 | ||
| 853 | The greatest threat to the type of transactions for which these | |
| 854 | protocols are used is network snooping. This kind of transaction | |
| 855 | might involve, for example, online access to a mail service whose use | |
| 856 | is restricted to paying subscribers. With plaintext password | |
| 857 | authentication an eavesdropper can obtain the password of the user. | |
| 858 | This not only permits him to access anything in the database, but, | |
| 859 | often worse, will permit access to anything else the user protects | |
| 860 | with the same password. | |
| 861 | ||
| 862 | 3.3 Replay Attacks | |
| 863 | ||
| 864 | Replay attacks are defeated if the client or the server chooses a | |
| 865 | fresh nonce for each authentication, as this specification requires. | |
| 866 | ||
| 867 | 3.4 Online dictionary attacks | |
| 868 | ||
| 869 | If the attacker can eavesdrop, then it can test any overheard | |
| 870 | nonce/response pairs against a (potentially very large) list of | |
| 871 | common words. Such a list is usually much smaller than the total | |
| 872 | number of possible passwords. The cost of computing the response for | |
| 873 | each password on the list is paid once for each challenge. | |
| 874 | ||
| 875 | The server can mitigate this attack by not allowing users to select | |
| 876 | passwords that are in a dictionary. | |
| 877 | ||
| 878 | 3.5 Offline dictionary attacks | |
| 879 | ||
| 880 | If the attacker can choose the challenge, then it can precompute the | |
| 881 | possible responses to that challenge for a list of common words. Such | |
| 882 | a list is usually much smaller than the total number of possible | |
| 883 | passwords. The cost of computing the response for each password on | |
| 884 | the list is paid just once. | |
| 885 | ||
| 886 | Offline dictionary attacks are defeated if the client chooses a fresh | |
| 887 | nonce for each authentication, as this specification requires. | |
| 888 | ||
| 889 | ||
| 890 | ||
| 891 | ||
| 892 | ||
| 893 | ||
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | Leach & Newman Standards Track [Page 16] | |
| 898 | ||
| 899 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 900 | ||
| 901 | ||
| 902 | 3.6 Man in the Middle | |
| 903 | ||
| 904 | Digest authentication is vulnerable to "man in the middle" (MITM) | |
| 905 | attacks. Clearly, a MITM would present all the problems of | |
| 906 | eavesdropping. But it also offers some additional opportunities to | |
| 907 | the attacker. | |
| 908 | ||
| 909 | A possible man-in-the-middle attack would be to substitute a weaker | |
| 910 | qop scheme for the one(s) sent by the server; the server will not be | |
| 911 | able to detect this attack. For this reason, the client should always | |
| 912 | use the strongest scheme that it understands from the choices | |
| 913 | offered, and should never choose a scheme that does not meet its | |
| 914 | minimum requirements. | |
| 915 | ||
| 916 | 3.7 Chosen plaintext attacks | |
| 917 | ||
| 918 | A chosen plaintext attack is where a MITM or a malicious server can | |
| 919 | arbitrarily choose the challenge that the client will use to compute | |
| 920 | the response. The ability to choose the challenge is known to make | |
| 921 | cryptanalysis much easier [8]. | |
| 922 | ||
| 923 | However, Digest does not permit the attack to choose the challenge as | |
| 924 | long as the client chooses a fresh nonce for each authentication, as | |
| 925 | this specification requires. | |
| 926 | ||
| 927 | 3.8 Spoofing by Counterfeit Servers | |
| 928 | ||
| 929 | If a user can be led to believe that she is connecting to a host | |
| 930 | containing information protected by a password she knows, when in | |
| 931 | fact she is connecting to a hostile server, then the hostile server | |
| 932 | can obtain challenge/response pairs where it was able to partly | |
| 933 | choose the challenge. There is no known way that this can be | |
| 934 | exploited. | |
| 935 | ||
| 936 | 3.9 Storing passwords | |
| 937 | ||
| 938 | Digest authentication requires that the authenticating agent (usually | |
| 939 | the server) store some data derived from the user's name and password | |
| 940 | in a "password file" associated with a given realm. Normally this | |
| 941 | might contain pairs consisting of username and H({ username-value, | |
| 942 | ":", realm-value, ":", passwd }), which is adequate to compute H(A1) | |
| 943 | as described above without directly exposing the user's password. | |
| 944 | ||
| 945 | The security implications of this are that if this password file is | |
| 946 | compromised, then an attacker gains immediate access to documents on | |
| 947 | the server using this realm. Unlike, say a standard UNIX password | |
| 948 | file, this information need not be decrypted in order to access | |
| 949 | documents in the server realm associated with this file. On the other | |
| 950 | ||
| 951 | ||
| 952 | ||
| 953 | Leach & Newman Standards Track [Page 17] | |
| 954 | ||
| 955 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 956 | ||
| 957 | ||
| 958 | hand, decryption, or more likely a brute force attack, would be | |
| 959 | necessary to obtain the user's password. This is the reason that the | |
| 960 | realm is part of the digested data stored in the password file. It | |
| 961 | means that if one Digest authentication password file is compromised, | |
| 962 | it does not automatically compromise others with the same username | |
| 963 | and password (though it does expose them to brute force attack). | |
| 964 | ||
| 965 | There are two important security consequences of this. First the | |
| 966 | password file must be protected as if it contained plaintext | |
| 967 | passwords, because for the purpose of accessing documents in its | |
| 968 | realm, it effectively does. | |
| 969 | ||
| 970 | A second consequence of this is that the realm string should be | |
| 971 | unique among all realms that any single user is likely to use. In | |
| 972 | particular a realm string should include the name of the host doing | |
| 973 | the authentication. | |
| 974 | ||
| 975 | 3.10 Multiple realms | |
| 976 | ||
| 977 | Use of multiple realms may mean both that compromise of a the | |
| 978 | security database for a single realm does not compromise all | |
| 979 | security, and that there are more things to protect in order to keep | |
| 980 | the whole system secure. | |
| 981 | ||
| 982 | 3.11 Summary | |
| 983 | ||
| 984 | By modern cryptographic standards Digest Authentication is weak, | |
| 985 | compared to (say) public key based mechanisms. But for a large range | |
| 986 | of purposes it is valuable as a replacement for plaintext passwords. | |
| 987 | Its strength may vary depending on the implementation. | |
| 988 | ||
| 989 | 4 Example | |
| 990 | ||
| 991 | This example shows the use of the Digest SASL mechanism with the | |
| 992 | IMAP4 AUTHENTICATE command [RFC 2060]. | |
| 993 | ||
| 994 | In this example, "C:" and "S:" represent a line sent by the client or | |
| 995 | server respectively including a CRLF at the end. Linebreaks and | |
| 996 | indentation within a "C:" or "S:" are editorial and not part of the | |
| 997 | protocol. The password in this example was "secret". Note that the | |
| 998 | base64 encoding of the challenges and responses is part of the IMAP4 | |
| 999 | AUTHENTICATE command, not part of the Digest specification itself. | |
| 1000 | ||
| 1001 | S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9 | |
| 1002 | C: c CAPABILITY | |
| 1003 | S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA | |
| 1004 | UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN | |
| 1005 | S: c OK Completed | |
| 1006 | ||
| 1007 | ||
| 1008 | ||
| 1009 | Leach & Newman Standards Track [Page 18] | |
| 1010 | ||
| 1011 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 1012 | ||
| 1013 | ||
| 1014 | C: a AUTHENTICATE DIGEST-MD5 | |
| 1015 | S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 | |
| 1016 | RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh | |
| 1017 | cnNldD11dGYtOA== | |
| 1018 | C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 | |
| 1019 | QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw | |
| 1020 | MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im | |
| 1021 | ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw | |
| 1022 | ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= | |
| 1023 | S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== | |
| 1024 | C: | |
| 1025 | S: a OK User logged in | |
| 1026 | --- | |
| 1027 | ||
| 1028 | The base64-decoded version of the SASL exchange is: | |
| 1029 | ||
| 1030 | S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth", | |
| 1031 | algorithm=md5-sess,charset=utf-8 | |
| 1032 | C: charset=utf-8,username="chris",realm="elwood.innosoft.com", | |
| 1033 | nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk", | |
| 1034 | digest-uri="imap/elwood.innosoft.com", | |
| 1035 | response=d388dad90d4bbd760a152321f2143af7,qop=auth | |
| 1036 | S: rspauth=ea40f60335c427b5527b84dbabcdfffd | |
| 1037 | ||
| 1038 | The password in this example was "secret". | |
| 1039 | ||
| 1040 | This example shows the use of the Digest SASL mechanism with the | |
| 1041 | ACAP, using the same notational conventions and password as in the | |
| 1042 | previous example. Note that ACAP does not base64 encode and uses | |
| 1043 | fewer round trips that IMAP4. | |
| 1044 | ||
| 1045 | S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5" | |
| 1046 | "DIGEST-MD5" "PLAIN") | |
| 1047 | C: a AUTHENTICATE "DIGEST-MD5" | |
| 1048 | S: + {94} | |
| 1049 | S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth", | |
| 1050 | algorithm=md5-sess,charset=utf-8 | |
| 1051 | C: {206} | |
| 1052 | C: charset=utf-8,username="chris",realm="elwood.innosoft.com", | |
| 1053 | nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m", | |
| 1054 | digest-uri="acap/elwood.innosoft.com", | |
| 1055 | response=6084c6db3fede7352c551284490fd0fc,qop=auth | |
| 1056 | S: a OK (SASL {40} | |
| 1057 | S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE | |
| 1058 | Completed" | |
| 1059 | --- | |
| 1060 | ||
| 1061 | ||
| 1062 | ||
| 1063 | ||
| 1064 | ||
| 1065 | Leach & Newman Standards Track [Page 19] | |
| 1066 | ||
| 1067 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 1068 | ||
| 1069 | ||
| 1070 | The server uses the values of all the directives, plus knowledge of | |
| 1071 | the users password (or the hash of the user's name, server's realm | |
| 1072 | and the user's password) to verify the computations above. If they | |
| 1073 | check, then the user has authenticated. | |
| 1074 | ||
| 1075 | 5 References | |
| 1076 | ||
| 1077 | [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest | |
| 1078 | Access Authentication", RFC 2617, June 1999. | |
| 1079 | ||
| 1080 | [ISO-8859] ISO-8859. International Standard--Information Processing-- | |
| 1081 | 8-bit Single-Byte Coded Graphic Character Sets -- | |
| 1082 | Part 1: Latin alphabet No. 1, ISO-8859-1:1987. | |
| 1083 | Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. | |
| 1084 | Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. | |
| 1085 | Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. | |
| 1086 | Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. | |
| 1087 | Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. | |
| 1088 | Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. | |
| 1089 | Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. | |
| 1090 | Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. | |
| 1091 | ||
| 1092 | [RFC 822] Crocker, D., "Standard for The Format of ARPA Internet | |
| 1093 | Text Messages," STD 11, RFC 822, August 1982. | |
| 1094 | ||
| 1095 | [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |
| 1096 | April 1992. | |
| 1097 | ||
| 1098 | [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | |
| 1099 | Part Three: Message Header Extensions for Non-ASCII Text", | |
| 1100 | RFC 2047, November 1996. | |
| 1101 | ||
| 1102 | [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the | |
| 1103 | location of services (DNS SRV)", RFC 2052, October 1996. | |
| 1104 | ||
| 1105 | [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version | |
| 1106 | 4rev1", RFC 2060, December 1996. | |
| 1107 | ||
| 1108 | [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- | |
| 1109 | Hashing for Message Authentication", RFC 2104, February | |
| 1110 | 1997. | |
| 1111 | ||
| 1112 | [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP | |
| 1113 | AUTHorize Extension for Simple Challenge/Response", RFC | |
| 1114 | 2195, September 1997. | |
| 1115 | ||
| 1116 | ||
| 1117 | ||
| 1118 | ||
| 1119 | ||
| 1120 | ||
| 1121 | Leach & Newman Standards Track [Page 20] | |
| 1122 | ||
| 1123 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 1124 | ||
| 1125 | ||
| 1126 | [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | |
| 1127 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
| 1128 | ||
| 1129 | [RFC 2222] Myers, J., "Simple Authentication and Security Layer | |
| 1130 | (SASL)", RFC 2222, October 1997. | |
| 1131 | ||
| 1132 | [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard | |
| 1133 | Code for Information Interchange. Standard ANSI X3.4-1986, | |
| 1134 | ANSI, 1986. | |
| 1135 | ||
| 1136 | 6 Authors' Addresses | |
| 1137 | ||
| 1138 | Paul Leach | |
| 1139 | Microsoft | |
| 1140 | 1 Microsoft Way | |
| 1141 | Redmond, WA 98052 | |
| 1142 | ||
| 1143 | EMail: paulle@microsoft.com | |
| 1144 | ||
| 1145 | ||
| 1146 | Chris Newman | |
| 1147 | Innosoft International, Inc. | |
| 1148 | 1050 Lakes Drive | |
| 1149 | West Covina, CA 91790 USA | |
| 1150 | ||
| 1151 | EMail: chris.newman@innosoft.com | |
| 1152 | ||
| 1153 | 7 ABNF | |
| 1154 | ||
| 1155 | What follows is the definition of the notation as is used in the | |
| 1156 | HTTP/1.1 specification (RFC 2616) and the HTTP authentication | |
| 1157 | specification (RFC 2617); it is reproduced here for ease of | |
| 1158 | reference. Since it is intended that a single Digest implementation | |
| 1159 | can support both HTTP and SASL-based protocols, the same notation is | |
| 1160 | used in both to facilitate comparison and prevention of unwanted | |
| 1161 | differences. Since it is cut-and-paste from the HTTP specifications, | |
| 1162 | not all productions may be used in this specification. It is also not | |
| 1163 | quite legal ABNF; again, the errors were copied from the HTTP | |
| 1164 | specifications. | |
| 1165 | ||
| 1166 | 7.1 Augmented BNF | |
| 1167 | ||
| 1168 | All of the mechanisms specified in this document are described in | |
| 1169 | both prose and an augmented Backus-Naur Form (BNF) similar to that | |
| 1170 | used by RFC 822 [RFC 822]. Implementers will need to be familiar with | |
| 1171 | the notation in order to understand this specification. | |
| 1172 | ||
| 1173 | ||
| 1174 | ||
| 1175 | ||
| 1176 | ||
| 1177 | Leach & Newman Standards Track [Page 21] | |
| 1178 | ||
| 1179 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 1180 | ||
| 1181 | ||
| 1182 | The augmented BNF includes the following constructs: | |
| 1183 | ||
| 1184 | name = definition | |
| 1185 | The name of a rule is simply the name itself (without any | |
| 1186 | enclosing "<" and ">") and is separated from its definition by the | |
| 1187 | equal "=" character. White space is only significant in that | |
| 1188 | indentation of continuation lines is used to indicate a rule | |
| 1189 | definition that spans more than one line. Certain basic rules are | |
| 1190 | in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle | |
| 1191 | brackets are used within definitions whenever their presence will | |
| 1192 | facilitate discerning the use of rule names. | |
| 1193 | ||
| 1194 | "literal" | |
| 1195 | Quotation marks surround literal text. Unless stated otherwise, | |
| 1196 | the text is case-insensitive. | |
| 1197 | ||
| 1198 | rule1 | rule2 | |
| 1199 | Elements separated by a bar ("|") are alternatives, e.g., "yes | | |
| 1200 | no" will accept yes or no. | |
| 1201 | ||
| 1202 | (rule1 rule2) | |
| 1203 | Elements enclosed in parentheses are treated as a single element. | |
| 1204 | Thus, "(elem (foo | bar) elem)" allows the token sequences | |
| 1205 | "elem foo elem" and "elem bar elem". | |
| 1206 | ||
| 1207 | *rule | |
| 1208 | The character "*" preceding an element indicates repetition. The | |
| 1209 | full form is "<n>*<m>element" indicating at least <n> and at most | |
| 1210 | <m> occurrences of element. Default values are 0 and infinity so | |
| 1211 | that "*(element)" allows any number, including zero; "1*element" | |
| 1212 | requires at least one; and "1*2element" allows one or two. | |
| 1213 | ||
| 1214 | [rule] | |
| 1215 | Square brackets enclose optional elements; "[foo bar]" is | |
| 1216 | equivalent to "*1(foo bar)". | |
| 1217 | ||
| 1218 | N rule | |
| 1219 | Specific repetition: "<n>(element)" is equivalent to | |
| 1220 | "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). | |
| 1221 | Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three | |
| 1222 | alphabetic characters. | |
| 1223 | ||
| 1224 | #rule | |
| 1225 | A construct "#" is defined, similar to "*", for defining lists of | |
| 1226 | elements. The full form is "<n>#<m>element" indicating at least | |
| 1227 | <n> and at most <m> elements, each separated by one or more commas | |
| 1228 | (",") and OPTIONAL linear white space (LWS). This makes the usual | |
| 1229 | form of lists very easy; a rule such as | |
| 1230 | ||
| 1231 | ||
| 1232 | ||
| 1233 | Leach & Newman Standards Track [Page 22] | |
| 1234 | ||
| 1235 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 1236 | ||
| 1237 | ||
| 1238 | ( *LWS element *( *LWS "," *LWS element )) | |
| 1239 | can be shown as | |
| 1240 | 1#element | |
| 1241 | Wherever this construct is used, null elements are allowed, but do | |
| 1242 | not contribute to the count of elements present. That is, | |
| 1243 | "(element), , (element) " is permitted, but counts as only two | |
| 1244 | elements. Therefore, where at least one element is required, at | |
| 1245 | least one non-null element MUST be present. Default values are 0 | |
| 1246 | and infinity so that "#element" allows any number, including zero; | |
| 1247 | "1#element" requires at least one; and "1#2element" allows one or | |
| 1248 | two. | |
| 1249 | ||
| 1250 | ; comment | |
| 1251 | A semi-colon, set off some distance to the right of rule text, | |
| 1252 | starts a comment that continues to the end of line. This is a | |
| 1253 | simple way of including useful notes in parallel with the | |
| 1254 | specifications. | |
| 1255 | ||
| 1256 | implied *LWS | |
| 1257 | The grammar described by this specification is word-based. Except | |
| 1258 | where noted otherwise, linear white space (LWS) can be included | |
| 1259 | between any two adjacent words (token or quoted-string), and | |
| 1260 | between adjacent words and separators, without changing the | |
| 1261 | interpretation of a field. At least one delimiter (LWS and/or | |
| 1262 | separators) MUST exist between any two tokens (for the definition | |
| 1263 | of "token" below), since they would otherwise be interpreted as a | |
| 1264 | single token. | |
| 1265 | ||
| 1266 | 7.2 Basic Rules | |
| 1267 | ||
| 1268 | The following rules are used throughout this specification to | |
| 1269 | describe basic parsing constructs. The US-ASCII coded character set | |
| 1270 | is defined by ANSI X3.4-1986 [USASCII]. | |
| 1271 | ||
| 1272 | OCTET = <any 8-bit sequence of data> | |
| 1273 | CHAR = <any US-ASCII character (octets 0 - 127)> | |
| 1274 | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> | |
| 1275 | LOALPHA = <any US-ASCII lowercase letter "a".."z"> | |
| 1276 | ALPHA = UPALPHA | LOALPHA | |
| 1277 | DIGIT = <any US-ASCII digit "0".."9"> | |
| 1278 | CTL = <any US-ASCII control character | |
| 1279 | (octets 0 - 31) and DEL (127)> | |
| 1280 | CR = <US-ASCII CR, carriage return (13)> | |
| 1281 | LF = <US-ASCII LF, linefeed (10)> | |
| 1282 | SP = <US-ASCII SP, space (32)> | |
| 1283 | HT = <US-ASCII HT, horizontal-tab (9)> | |
| 1284 | <"> = <US-ASCII double-quote mark (34)> | |
| 1285 | CRLF = CR LF | |
| 1286 | ||
| 1287 | ||
| 1288 | ||
| 1289 | Leach & Newman Standards Track [Page 23] | |
| 1290 | ||
| 1291 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 1292 | ||
| 1293 | ||
| 1294 | ||
| 1295 | All linear white space, including folding, has the same semantics as | |
| 1296 | SP. A recipient MAY replace any linear white space with a single SP | |
| 1297 | before interpreting the field value or forwarding the message | |
| 1298 | downstream. | |
| 1299 | ||
| 1300 | LWS = [CRLF] 1*( SP | HT ) | |
| 1301 | ||
| 1302 | The TEXT rule is only used for descriptive field contents and values | |
| 1303 | that are not intended to be interpreted by the message parser. Words | |
| 1304 | of *TEXT MAY contain characters from character sets other than | |
| 1305 | ISO-8859-1 [ISO 8859] only when encoded according to the rules of RFC | |
| 1306 | 2047 [RFC 2047]. | |
| 1307 | ||
| 1308 | TEXT = <any OCTET except CTLs, | |
| 1309 | but including LWS> | |
| 1310 | ||
| 1311 | A CRLF is allowed in the definition of TEXT only as part of a header | |
| 1312 | field continuation. It is expected that the folding LWS will be | |
| 1313 | replaced with a single SP before interpretation of the TEXT value. | |
| 1314 | ||
| 1315 | Hexadecimal numeric characters are used in several protocol elements. | |
| 1316 | ||
| 1317 | HEX = "A" | "B" | "C" | "D" | "E" | "F" | |
| 1318 | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | |
| 1319 | ||
| 1320 | Many HTTP/1.1 header field values consist of words separated by LWS | |
| 1321 | or special characters. These special characters MUST be in a quoted | |
| 1322 | string to be used within a parameter value. | |
| 1323 | ||
| 1324 | token = 1*<any CHAR except CTLs or separators> | |
| 1325 | separators = "(" | ")" | "<" | ">" | "@" | |
| 1326 | | "," | ";" | ":" | "\" | <"> | |
| 1327 | | "/" | "[" | "]" | "?" | "=" | |
| 1328 | | "{" | "}" | SP | HT | |
| 1329 | ||
| 1330 | A string of text is parsed as a single word if it is quoted using | |
| 1331 | double-quote marks. | |
| 1332 | ||
| 1333 | quoted-string = ( <"> qdstr-val <"> ) | |
| 1334 | qdstr-val = *( qdtext | quoted-pair ) | |
| 1335 | qdtext = <any TEXT except <">> | |
| 1336 | ||
| 1337 | Note that LWS is NOT implicit between the double-quote marks (<">) | |
| 1338 | surrounding a qdstr-val and the qdstr-val; any LWS will be considered | |
| 1339 | part of the qdstr-val. This is also the case for quotation marks | |
| 1340 | surrounding any other construct. | |
| 1341 | ||
| 1342 | ||
| 1343 | ||
| 1344 | ||
| 1345 | Leach & Newman Standards Track [Page 24] | |
| 1346 | ||
| 1347 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 1348 | ||
| 1349 | ||
| 1350 | The backslash character ("\") MAY be used as a single-character | |
| 1351 | quoting mechanism only within qdstr-val and comment constructs. | |
| 1352 | ||
| 1353 | quoted-pair = "\" CHAR | |
| 1354 | ||
| 1355 | The value of this construct is CHAR. Note that an effect of this rule | |
| 1356 | is that backslash must be quoted. | |
| 1357 | ||
| 1358 | 8 Sample Code | |
| 1359 | ||
| 1360 | The sample implementation in [Digest] also applies to DIGEST-MD5. | |
| 1361 | ||
| 1362 | The following code implements the conversion from UTF-8 to 8859-1 if | |
| 1363 | necessary. | |
| 1364 | ||
| 1365 | /* if the string is entirely in the 8859-1 subset of UTF-8, then | |
| 1366 | * translate to 8859-1 prior to MD5 | |
| 1367 | */ | |
| 1368 | void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base, | |
| 1369 | int len) | |
| 1370 | { | |
| 1371 | const unsigned char *scan, *end; | |
| 1372 | unsigned char cbuf; | |
| 1373 | ||
| 1374 | end = base + len; | |
| 1375 | for (scan = base; scan < end; ++scan) { | |
| 1376 | if (*scan > 0xC3) break; /* abort if outside 8859-1 */ | |
| 1377 | if (*scan >= 0xC0 && *scan <= 0xC3) { | |
| 1378 | if (++scan == end || *scan < 0x80 || *scan > 0xBF) | |
| 1379 | break; | |
| 1380 | } | |
| 1381 | } | |
| 1382 | /* if we found a character outside 8859-1, don't alter string | |
| 1383 | */ | |
| 1384 | if (scan < end) { | |
| 1385 | MD5Update(ctx, base, len); | |
| 1386 | return; | |
| 1387 | } | |
| 1388 | ||
| 1389 | /* convert to 8859-1 prior to applying hash | |
| 1390 | */ | |
| 1391 | do { | |
| 1392 | for (scan = base; scan < end && *scan < 0xC0; ++scan) | |
| 1393 | ; | |
| 1394 | if (scan != base) MD5Update(ctx, base, scan - base); | |
| 1395 | if (scan + 1 >= end) break; | |
| 1396 | cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f); | |
| 1397 | MD5Update(ctx, &cbuf, 1); | |
| 1398 | ||
| 1399 | ||
| 1400 | ||
| 1401 | Leach & Newman Standards Track [Page 25] | |
| 1402 | ||
| 1403 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 1404 | ||
| 1405 | ||
| 1406 | base = scan + 2; | |
| 1407 | } while (base < end); | |
| 1408 | } | |
| 1409 | ||
| 1410 | ||
| 1411 | ||
| 1412 | ||
| 1413 | ||
| 1414 | ||
| 1415 | ||
| 1416 | ||
| 1417 | ||
| 1418 | ||
| 1419 | ||
| 1420 | ||
| 1421 | ||
| 1422 | ||
| 1423 | ||
| 1424 | ||
| 1425 | ||
| 1426 | ||
| 1427 | ||
| 1428 | ||
| 1429 | ||
| 1430 | ||
| 1431 | ||
| 1432 | ||
| 1433 | ||
| 1434 | ||
| 1435 | ||
| 1436 | ||
| 1437 | ||
| 1438 | ||
| 1439 | ||
| 1440 | ||
| 1441 | ||
| 1442 | ||
| 1443 | ||
| 1444 | ||
| 1445 | ||
| 1446 | ||
| 1447 | ||
| 1448 | ||
| 1449 | ||
| 1450 | ||
| 1451 | ||
| 1452 | ||
| 1453 | ||
| 1454 | ||
| 1455 | ||
| 1456 | ||
| 1457 | Leach & Newman Standards Track [Page 26] | |
| 1458 | ||
| 1459 | RFC 2831 Digest SASL Mechanism May 2000 | |
| 1460 | ||
| 1461 | ||
| 1462 | 9 Full Copyright Statement | |
| 1463 | ||
| 1464 | Copyright (C) The Internet Society (2000). All Rights Reserved. | |
| 1465 | ||
| 1466 | This document and translations of it may be copied and furnished to | |
| 1467 | others, and derivative works that comment on or otherwise explain it | |
| 1468 | or assist in its implementation may be prepared, copied, published | |
| 1469 | and distributed, in whole or in part, without restriction of any | |
| 1470 | kind, provided that the above copyright notice and this paragraph are | |
| 1471 | included on all such copies and derivative works. However, this | |
| 1472 | document itself may not be modified in any way, such as by removing | |
| 1473 | the copyright notice or references to the Internet Society or other | |
| 1474 | Internet organizations, except as needed for the purpose of | |
| 1475 | developing Internet standards in which case the procedures for | |
| 1476 | copyrights defined in the Internet Standards process must be | |
| 1477 | followed, or as required to translate it into languages other than | |
| 1478 | English. | |
| 1479 | ||
| 1480 | The limited permissions granted above are perpetual and will not be | |
| 1481 | revoked by the Internet Society or its successors or assigns. | |
| 1482 | ||
| 1483 | This document and the information contained herein is provided on an | |
| 1484 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 1485 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 1486 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 1487 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 1488 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 1489 | ||
| 1490 | Acknowledgement | |
| 1491 | ||
| 1492 | Funding for the RFC Editor function is currently provided by the | |
| 1493 | Internet Society. | |
| 1494 | ||
| 1495 | ||
| 1496 | ||
| 1497 | ||
| 1498 | ||
| 1499 | ||
| 1500 | ||
| 1501 | ||
| 1502 | ||
| 1503 | ||
| 1504 | ||
| 1505 | ||
| 1506 | ||
| 1507 | ||
| 1508 | ||
| 1509 | ||
| 1510 | ||
| 1511 | ||
| 1512 | ||
| 1513 | Leach & Newman Standards Track [Page 27] | |
| 1514 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group T. Wu | |
| 7 | Request for Comments: 2945 Stanford University | |
| 8 | Category: Standards Track September 2000 | |
| 9 | ||
| 10 | ||
| 11 | The SRP Authentication and Key Exchange System | |
| 12 | ||
| 13 | Status of this Memo | |
| 14 | ||
| 15 | This document specifies an Internet standards track protocol for the | |
| 16 | Internet community, and requests discussion and suggestions for | |
| 17 | improvements. Please refer to the current edition of the "Internet | |
| 18 | Official Protocol Standards" (STD 1) for the standardization state | |
| 19 | and status of this protocol. Distribution of this memo is unlimited. | |
| 20 | ||
| 21 | Copyright Notice | |
| 22 | ||
| 23 | Copyright (C) The Internet Society (2000). All Rights Reserved. | |
| 24 | ||
| 25 | Abstract | |
| 26 | ||
| 27 | This document describes a cryptographically strong network | |
| 28 | authentication mechanism known as the Secure Remote Password (SRP) | |
| 29 | protocol. This mechanism is suitable for negotiating secure | |
| 30 | connections using a user-supplied password, while eliminating the | |
| 31 | security problems traditionally associated with reusable passwords. | |
| 32 | This system also performs a secure key exchange in the process of | |
| 33 | authentication, allowing security layers (privacy and/or integrity | |
| 34 | protection) to be enabled during the session. Trusted key servers | |
| 35 | and certificate infrastructures are not required, and clients are not | |
| 36 | required to store or manage any long-term keys. SRP offers both | |
| 37 | security and deployment advantages over existing challenge-response | |
| 38 | techniques, making it an ideal drop-in replacement where secure | |
| 39 | password authentication is needed. | |
| 40 | ||
| 41 | 1. Introduction | |
| 42 | ||
| 43 | The lack of a secure authentication mechanism that is also easy to | |
| 44 | use has been a long-standing problem with the vast majority of | |
| 45 | Internet protocols currently in use. The problem is two-fold: Users | |
| 46 | like to use passwords that they can remember, but most password-based | |
| 47 | authentication systems offer little protection against even passive | |
| 48 | attackers, especially if weak and easily-guessed passwords are used. | |
| 49 | ||
| 50 | Eavesdropping on a TCP/IP network can be carried out very easily and | |
| 51 | very effectively against protocols that transmit passwords in the | |
| 52 | clear. Even so-called "challenge-response" techniques like the one | |
| 53 | described in [RFC 2095] and [RFC 1760], which are designed to defeat | |
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Wu Standards Track [Page 1] | |
| 58 | ||
| 59 | RFC 2945 SRP Authentication & Key Exchange System September 2000 | |
| 60 | ||
| 61 | ||
| 62 | simple sniffing attacks, can be compromised by what is known as a | |
| 63 | "dictionary attack". This occurs when an attacker captures the | |
| 64 | messages exchanged during a legitimate run of the protocol and uses | |
| 65 | that information to verify a series of guessed passwords taken from a | |
| 66 | precompiled "dictionary" of common passwords. This works because | |
| 67 | users often choose simple, easy-to-remember passwords, which | |
| 68 | invariably are also easy to guess. | |
| 69 | ||
| 70 | Many existing mechanisms also require the password database on the | |
| 71 | host to be kept secret because the password P or some private hash | |
| 72 | h(P) is stored there and would compromise security if revealed. That | |
| 73 | approach often degenerates into "security through obscurity" and goes | |
| 74 | against the UNIX convention of keeping a "public" password file whose | |
| 75 | contents can be revealed without destroying system security. | |
| 76 | ||
| 77 | SRP meets the strictest requirements laid down in [RFC 1704] for a | |
| 78 | non-disclosing authentication protocol. It offers complete | |
| 79 | protection against both passive and active attacks, and accomplishes | |
| 80 | this efficiently using a single Diffie-Hellman-style round of | |
| 81 | computation, making it feasible to use in both interactive and non- | |
| 82 | interactive authentication for a wide range of Internet protocols. | |
| 83 | Since it retains its security when used with low-entropy passwords, | |
| 84 | it can be seamlessly integrated into existing user applications. | |
| 85 | ||
| 86 | 2. Conventions and Terminology | |
| 87 | ||
| 88 | The protocol described by this document is sometimes referred to as | |
| 89 | "SRP-3" for historical purposes. This particular protocol is | |
| 90 | described in [SRP] and is believed to have very good logical and | |
| 91 | cryptographic resistance to both eavesdropping and active attacks. | |
| 92 | ||
| 93 | This document does not attempt to describe SRP in the context of any | |
| 94 | particular Internet protocol; instead it describes an abstract | |
| 95 | protocol that can be easily fitted to a particular application. For | |
| 96 | example, the specific format of messages (including padding) is not | |
| 97 | specified. Those issues have been left to the protocol implementor | |
| 98 | to decide. | |
| 99 | ||
| 100 | The one implementation issue worth specifying here is the mapping | |
| 101 | between strings and integers. Internet protocols are byte-oriented, | |
| 102 | while SRP performs algebraic operations on its messages, so it is | |
| 103 | logical to define at least one method by which integers can be | |
| 104 | converted into a string of bytes and vice versa. | |
| 105 | ||
| 106 | An n-byte string S can be converted to an integer as follows: | |
| 107 | ||
| 108 | i = S[n-1] + 256 * S[n-2] + 256^2 * S[n-3] + ... + 256^(n-1) * S[0] | |
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Wu Standards Track [Page 2] | |
| 114 | ||
| 115 | RFC 2945 SRP Authentication & Key Exchange System September 2000 | |
| 116 | ||
| 117 | ||
| 118 | where i is the integer and S[x] is the value of the x'th byte of S. | |
| 119 | In human terms, the string of bytes is the integer expressed in base | |
| 120 | 256, with the most significant digit first. When converting back to | |
| 121 | a string, S[0] must be non-zero (padding is considered to be a | |
| 122 | separate, independent process). This conversion method is suitable | |
| 123 | for file storage, in-memory representation, and network transmission | |
| 124 | of large integer values. Unless otherwise specified, this mapping | |
| 125 | will be assumed. | |
| 126 | ||
| 127 | If implementations require padding a string that represents an | |
| 128 | integer value, it is recommended that they use zero bytes and add | |
| 129 | them to the beginning of the string. The conversion back to integer | |
| 130 | automatically discards leading zero bytes, making this padding scheme | |
| 131 | less prone to error. | |
| 132 | ||
| 133 | The SHA hash function, when used in this document, refers to the | |
| 134 | SHA-1 message digest algorithm described in [SHA1]. | |
| 135 | ||
| 136 | 3. The SRP-SHA1 mechanism | |
| 137 | ||
| 138 | This section describes an implementation of the SRP authentication | |
| 139 | and key-exchange protocol that employs the SHA hash function to | |
| 140 | generate session keys and authentication proofs. | |
| 141 | ||
| 142 | The host stores user passwords as triplets of the form | |
| 143 | ||
| 144 | { <username>, <password verifier>, <salt> } | |
| 145 | ||
| 146 | Password entries are generated as follows: | |
| 147 | ||
| 148 | <salt> = random() | |
| 149 | x = SHA(<salt> | SHA(<username> | ":" | <raw password>)) | |
| 150 | <password verifier> = v = g^x % N | |
| 151 | ||
| 152 | The | symbol indicates string concatenation, the ^ operator is the | |
| 153 | exponentiation operation, and the % operator is the integer remainder | |
| 154 | operation. Most implementations perform the exponentiation and | |
| 155 | remainder in a single stage to avoid generating unwieldy intermediate | |
| 156 | results. Note that the 160-bit output of SHA is implicitly converted | |
| 157 | to an integer before it is operated upon. | |
| 158 | ||
| 159 | Authentication is generally initiated by the client. | |
| 160 | ||
| 161 | Client Host | |
| 162 | -------- ------ | |
| 163 | U = <username> --> | |
| 164 | <-- s = <salt from passwd file> | |
| 165 | ||
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Wu Standards Track [Page 3] | |
| 170 | ||
| 171 | RFC 2945 SRP Authentication & Key Exchange System September 2000 | |
| 172 | ||
| 173 | ||
| 174 | Upon identifying himself to the host, the client will receive the | |
| 175 | salt stored on the host under his username. | |
| 176 | ||
| 177 | a = random() | |
| 178 | A = g^a % N --> | |
| 179 | v = <stored password verifier> | |
| 180 | b = random() | |
| 181 | <-- B = (v + g^b) % N | |
| 182 | ||
| 183 | p = <raw password> | |
| 184 | x = SHA(s | SHA(U | ":" | p)) | |
| 185 | ||
| 186 | S = (B - g^x) ^ (a + u * x) % N S = (A * v^u) ^ b % N | |
| 187 | K = SHA_Interleave(S) K = SHA_Interleave(S) | |
| 188 | (this function is described | |
| 189 | in the next section) | |
| 190 | ||
| 191 | The client generates a random number, raises g to that power modulo | |
| 192 | the field prime, and sends the result to the host. The host does the | |
| 193 | same thing and also adds the public verifier before sending it to the | |
| 194 | client. Both sides then construct the shared session key based on | |
| 195 | the respective formulae. | |
| 196 | ||
| 197 | The parameter u is a 32-bit unsigned integer which takes its value | |
| 198 | from the first 32 bits of the SHA1 hash of B, MSB first. | |
| 199 | ||
| 200 | The client MUST abort authentication if B % N is zero. | |
| 201 | ||
| 202 | The host MUST abort the authentication attempt if A % N is zero. The | |
| 203 | host MUST send B after receiving A from the client, never before. | |
| 204 | ||
| 205 | At this point, the client and server should have a common session key | |
| 206 | that is secure (i.e. not known to an outside party). To finish | |
| 207 | authentication, they must prove to each other that their keys are | |
| 208 | identical. | |
| 209 | ||
| 210 | M = H(H(N) XOR H(g) | H(U) | s | A | B | K) | |
| 211 | --> | |
| 212 | <-- H(A | M | K) | |
| 213 | ||
| 214 | The server will calculate M using its own K and compare it against | |
| 215 | the client's response. If they do not match, the server MUST abort | |
| 216 | and signal an error before it attempts to answer the client's | |
| 217 | challenge. Not doing so could compromise the security of the user's | |
| 218 | password. | |
| 219 | ||
| 220 | ||
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Wu Standards Track [Page 4] | |
| 226 | ||
| 227 | RFC 2945 SRP Authentication & Key Exchange System September 2000 | |
| 228 | ||
| 229 | ||
| 230 | If the server receives a correct response, it issues its own proof to | |
| 231 | the client. The client will compute the expected response using its | |
| 232 | own K to verify the authenticity of the server. If the client | |
| 233 | responded correctly, the server MUST respond with its hash value. | |
| 234 | ||
| 235 | The transactions in this protocol description do not necessarily have | |
| 236 | a one-to-one correspondence with actual protocol messages. This | |
| 237 | description is only intended to illustrate the relationships between | |
| 238 | the different parameters and how they are computed. It is possible, | |
| 239 | for example, for an implementation of the SRP-SHA1 mechanism to | |
| 240 | consolidate some of the flows as follows: | |
| 241 | ||
| 242 | Client Host | |
| 243 | -------- ------ | |
| 244 | U, A --> | |
| 245 | <-- s, B | |
| 246 | H(H(N) XOR H(g) | H(U) | s | A | B | K) | |
| 247 | --> | |
| 248 | <-- H(A | M | K) | |
| 249 | ||
| 250 | The values of N and g used in this protocol must be agreed upon by | |
| 251 | the two parties in question. They can be set in advance, or the host | |
| 252 | can supply them to the client. In the latter case, the host should | |
| 253 | send the parameters in the first message along with the salt. For | |
| 254 | maximum security, N should be a safe prime (i.e. a number of the form | |
| 255 | N = 2q + 1, where q is also prime). Also, g should be a generator | |
| 256 | modulo N (see [SRP] for details), which means that for any X where 0 | |
| 257 | < X < N, there exists a value x for which g^x % N == X. | |
| 258 | ||
| 259 | 3.1. Interleaved SHA | |
| 260 | ||
| 261 | The SHA_Interleave function used in SRP-SHA1 is used to generate a | |
| 262 | session key that is twice as long as the 160-bit output of SHA1. To | |
| 263 | compute this function, remove all leading zero bytes from the input. | |
| 264 | If the length of the resulting string is odd, also remove the first | |
| 265 | byte. Call the resulting string T. Extract the even-numbered bytes | |
| 266 | into a string E and the odd-numbered bytes into a string F, i.e. | |
| 267 | ||
| 268 | E = T[0] | T[2] | T[4] | ... | |
| 269 | F = T[1] | T[3] | T[5] | ... | |
| 270 | ||
| 271 | Both E and F should be exactly half the length of T. Hash each one | |
| 272 | with regular SHA1, i.e. | |
| 273 | ||
| 274 | G = SHA(E) | |
| 275 | H = SHA(F) | |
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Wu Standards Track [Page 5] | |
| 282 | ||
| 283 | RFC 2945 SRP Authentication & Key Exchange System September 2000 | |
| 284 | ||
| 285 | ||
| 286 | Interleave the two hashes back together to form the output, i.e. | |
| 287 | ||
| 288 | result = G[0] | H[0] | G[1] | H[1] | ... | G[19] | H[19] | |
| 289 | ||
| 290 | The result will be 40 bytes (320 bits) long. | |
| 291 | ||
| 292 | 3.2. Other Hash Algorithms | |
| 293 | ||
| 294 | SRP can be used with hash functions other than SHA. If the hash | |
| 295 | function produces an output of a different length than SHA (20 | |
| 296 | bytes), it may change the length of some of the messages in the | |
| 297 | protocol, but the fundamental operation will be unaffected. | |
| 298 | ||
| 299 | Earlier versions of the SRP mechanism used the MD5 hash function, | |
| 300 | described in [RFC 1321]. Keyed hash transforms are also recommended | |
| 301 | for use with SRP; one possible construction uses HMAC [RFC 2104], | |
| 302 | using K to key the hash in each direction instead of concatenating it | |
| 303 | with the other parameters. | |
| 304 | ||
| 305 | Any hash function used with SRP should produce an output of at least | |
| 306 | 16 bytes and have the property that small changes in the input cause | |
| 307 | significant nonlinear changes in the output. [SRP] covers these | |
| 308 | issues in more depth. | |
| 309 | ||
| 310 | 4. Security Considerations | |
| 311 | ||
| 312 | This entire memo discusses an authentication and key-exchange system | |
| 313 | that protects passwords and exchanges keys across an untrusted | |
| 314 | network. This system improves security by eliminating the need to | |
| 315 | send cleartext passwords over the network and by enabling encryption | |
| 316 | through its secure key-exchange mechanism. | |
| 317 | ||
| 318 | The private values for a and b correspond roughly to the private | |
| 319 | values in a Diffie-Hellman exchange and have similar constraints of | |
| 320 | length and entropy. Implementations may choose to increase the | |
| 321 | length of the parameter u, as long as both client and server agree, | |
| 322 | but it is not recommended that it be shorter than 32 bits. | |
| 323 | ||
| 324 | SRP has been designed not only to counter the threat of casual | |
| 325 | password-sniffing, but also to prevent a determined attacker equipped | |
| 326 | with a dictionary of passwords from guessing at passwords using | |
| 327 | captured network traffic. The SRP protocol itself also resists | |
| 328 | active network attacks, and implementations can use the securely | |
| 329 | exchanged keys to protect the session against hijacking and provide | |
| 330 | confidentiality. | |
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Wu Standards Track [Page 6] | |
| 338 | ||
| 339 | RFC 2945 SRP Authentication & Key Exchange System September 2000 | |
| 340 | ||
| 341 | ||
| 342 | SRP also has the added advantage of permitting the host to store | |
| 343 | passwords in a form that is not directly useful to an attacker. Even | |
| 344 | if the host's password database were publicly revealed, the attacker | |
| 345 | would still need an expensive dictionary search to obtain any | |
| 346 | passwords. The exponential computation required to validate a guess | |
| 347 | in this case is much more time-consuming than the hash currently used | |
| 348 | by most UNIX systems. Hosts are still advised, though, to try their | |
| 349 | best to keep their password files secure. | |
| 350 | ||
| 351 | 5. References | |
| 352 | ||
| 353 | [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |
| 354 | April 1992. | |
| 355 | ||
| 356 | [RFC 1704] Haller, N. and R. Atkinson, "On Internet Authentication", | |
| 357 | RFC 1704, October 1994. | |
| 358 | ||
| 359 | [RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC | |
| 360 | 1760, Feburary 1995. | |
| 361 | ||
| 362 | [RFC 2095] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP | |
| 363 | AUTHorize Extension for Simple Challenge/Response", RFC | |
| 364 | 2095, January 1997. | |
| 365 | ||
| 366 | [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- | |
| 367 | Hashing for Message Authentication", RFC 2104, February | |
| 368 | 1997. | |
| 369 | ||
| 370 | [SHA1] National Institute of Standards and Technology (NIST), | |
| 371 | "Announcing the Secure Hash Standard", FIPS 180-1, U.S. | |
| 372 | Department of Commerce, April 1995. | |
| 373 | ||
| 374 | [SRP] T. Wu, "The Secure Remote Password Protocol", In | |
| 375 | Proceedings of the 1998 Internet Society Symposium on | |
| 376 | Network and Distributed Systems Security, San Diego, CA, | |
| 377 | pp. 97-111. | |
| 378 | ||
| 379 | 6. Author's Address | |
| 380 | ||
| 381 | Thomas Wu | |
| 382 | Stanford University | |
| 383 | Stanford, CA 94305 | |
| 384 | ||
| 385 | EMail: tjw@cs.Stanford.EDU | |
| 386 | ||
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Wu Standards Track [Page 7] | |
| 394 | ||
| 395 | RFC 2945 SRP Authentication & Key Exchange System September 2000 | |
| 396 | ||
| 397 | ||
| 398 | 7. Full Copyright Statement | |
| 399 | ||
| 400 | Copyright (C) The Internet Society (2000). All Rights Reserved. | |
| 401 | ||
| 402 | This document and translations of it may be copied and furnished to | |
| 403 | others, and derivative works that comment on or otherwise explain it | |
| 404 | or assist in its implementation may be prepared, copied, published | |
| 405 | and distributed, in whole or in part, without restriction of any | |
| 406 | kind, provided that the above copyright notice and this paragraph are | |
| 407 | included on all such copies and derivative works. However, this | |
| 408 | document itself may not be modified in any way, such as by removing | |
| 409 | the copyright notice or references to the Internet Society or other | |
| 410 | Internet organizations, except as needed for the purpose of | |
| 411 | developing Internet standards in which case the procedures for | |
| 412 | copyrights defined in the Internet Standards process must be | |
| 413 | followed, or as required to translate it into languages other than | |
| 414 | English. | |
| 415 | ||
| 416 | The limited permissions granted above are perpetual and will not be | |
| 417 | revoked by the Internet Society or its successors or assigns. | |
| 418 | ||
| 419 | This document and the information contained herein is provided on an | |
| 420 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 421 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 422 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 423 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 424 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 425 | ||
| 426 | Acknowledgement | |
| 427 | ||
| 428 | Funding for the RFC Editor function is currently provided by the | |
| 429 | Internet Society. | |
| 430 | ||
| 431 | ||
| 432 | ||
| 433 | ||
| 434 | ||
| 435 | ||
| 436 | ||
| 437 | ||
| 438 | ||
| 439 | ||
| 440 | ||
| 441 | ||
| 442 | ||
| 443 | ||
| 444 | ||
| 445 | ||
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Wu Standards Track [Page 8] | |
| 450 |
| 0 | ||
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Network Working Group D. Eastlake, 3rd | |
| 7 | Request for Comments: 3174 Motorola | |
| 8 | Category: Informational P. Jones | |
| 9 | Cisco Systems | |
| 10 | September 2001 | |
| 11 | ||
| 12 | ||
| 13 | US Secure Hash Algorithm 1 (SHA1) | |
| 14 | ||
| 15 | Status of this Memo | |
| 16 | ||
| 17 | This memo provides information for the Internet community. It does | |
| 18 | not specify an Internet standard of any kind. Distribution of this | |
| 19 | memo is unlimited. | |
| 20 | ||
| 21 | Copyright Notice | |
| 22 | ||
| 23 | Copyright (C) The Internet Society (2001). All Rights Reserved. | |
| 24 | ||
| 25 | Abstract | |
| 26 | ||
| 27 | The purpose of this document is to make the SHA-1 (Secure Hash | |
| 28 | Algorithm 1) hash algorithm conveniently available to the Internet | |
| 29 | community. The United States of America has adopted the SHA-1 hash | |
| 30 | algorithm described herein as a Federal Information Processing | |
| 31 | Standard. Most of the text herein was taken by the authors from FIPS | |
| 32 | 180-1. Only the C code implementation is "original". | |
| 33 | ||
| 34 | Acknowledgements | |
| 35 | ||
| 36 | Most of the text herein was taken from [FIPS 180-1]. Only the C code | |
| 37 | implementation is "original" but its style is similar to the | |
| 38 | previously published MD4 and MD5 RFCs [RFCs 1320, 1321]. | |
| 39 | ||
| 40 | The SHA-1 is based on principles similar to those used by Professor | |
| 41 | Ronald L. Rivest of MIT when designing the MD4 message digest | |
| 42 | algorithm [MD4] and is modeled after that algorithm [RFC 1320]. | |
| 43 | ||
| 44 | Useful comments from the following, which have been incorporated | |
| 45 | herein, are gratefully acknowledged: | |
| 46 | ||
| 47 | Tony Hansen | |
| 48 | Garrett Wollman | |
| 49 | ||
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Eastlake & Jones Informational [Page 1] | |
| 58 | ||
| 59 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 60 | ||
| 61 | ||
| 62 | Table of Contents | |
| 63 | ||
| 64 | 1. Overview of Contents........................................... 2 | |
| 65 | 2. Definitions of Bit Strings and Integers........................ 3 | |
| 66 | 3. Operations on Words............................................ 3 | |
| 67 | 4. Message Padding................................................ 4 | |
| 68 | 5. Functions and Constants Used................................... 6 | |
| 69 | 6. Computing the Message Digest................................... 6 | |
| 70 | 6.1 Method 1...................................................... 6 | |
| 71 | 6.2 Method 2...................................................... 7 | |
| 72 | 7. C Code......................................................... 8 | |
| 73 | 7.1 .h file....................................................... 8 | |
| 74 | 7.2 .c file....................................................... 10 | |
| 75 | 7.3 Test Driver................................................... 18 | |
| 76 | 8. Security Considerations........................................ 20 | |
| 77 | References........................................................ 21 | |
| 78 | Authors' Addresses................................................ 21 | |
| 79 | Full Copyright Statement.......................................... 22 | |
| 80 | ||
| 81 | 1. Overview of Contents | |
| 82 | ||
| 83 | NOTE: The text below is mostly taken from [FIPS 180-1] and assertions | |
| 84 | therein of the security of SHA-1 are made by the US Government, the | |
| 85 | author of [FIPS 180-1], and not by the authors of this document. | |
| 86 | ||
| 87 | This document specifies a Secure Hash Algorithm, SHA-1, for computing | |
| 88 | a condensed representation of a message or a data file. When a | |
| 89 | message of any length < 2^64 bits is input, the SHA-1 produces a | |
| 90 | 160-bit output called a message digest. The message digest can then, | |
| 91 | for example, be input to a signature algorithm which generates or | |
| 92 | verifies the signature for the message. Signing the message digest | |
| 93 | rather than the message often improves the efficiency of the process | |
| 94 | because the message digest is usually much smaller in size than the | |
| 95 | message. The same hash algorithm must be used by the verifier of a | |
| 96 | digital signature as was used by the creator of the digital | |
| 97 | signature. Any change to the message in transit will, with very high | |
| 98 | probability, result in a different message digest, and the signature | |
| 99 | will fail to verify. | |
| 100 | ||
| 101 | The SHA-1 is called secure because it is computationally infeasible | |
| 102 | to find a message which corresponds to a given message digest, or to | |
| 103 | find two different messages which produce the same message digest. | |
| 104 | Any change to a message in transit will, with very high probability, | |
| 105 | result in a different message digest, and the signature will fail to | |
| 106 | verify. | |
| 107 | ||
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | Eastlake & Jones Informational [Page 2] | |
| 114 | ||
| 115 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 116 | ||
| 117 | ||
| 118 | Section 2 below defines the terminology and functions used as | |
| 119 | building blocks to form SHA-1. | |
| 120 | ||
| 121 | 2. Definitions of Bit Strings and Integers | |
| 122 | ||
| 123 | The following terminology related to bit strings and integers will be | |
| 124 | used: | |
| 125 | ||
| 126 | a. A hex digit is an element of the set {0, 1, ... , 9, A, ... , F}. | |
| 127 | A hex digit is the representation of a 4-bit string. Examples: 7 | |
| 128 | = 0111, A = 1010. | |
| 129 | ||
| 130 | b. A word equals a 32-bit string which may be represented as a | |
| 131 | sequence of 8 hex digits. To convert a word to 8 hex digits each | |
| 132 | 4-bit string is converted to its hex equivalent as described in | |
| 133 | (a) above. Example: | |
| 134 | ||
| 135 | 1010 0001 0000 0011 1111 1110 0010 0011 = A103FE23. | |
| 136 | ||
| 137 | c. An integer between 0 and 2^32 - 1 inclusive may be represented as | |
| 138 | a word. The least significant four bits of the integer are | |
| 139 | represented by the right-most hex digit of the word | |
| 140 | representation. Example: the integer 291 = 2^8+2^5+2^1+2^0 = | |
| 141 | 256+32+2+1 is represented by the hex word, 00000123. | |
| 142 | ||
| 143 | If z is an integer, 0 <= z < 2^64, then z = (2^32)x + y where 0 <= | |
| 144 | x < 2^32 and 0 <= y < 2^32. Since x and y can be represented as | |
| 145 | words X and Y, respectively, z can be represented as the pair of | |
| 146 | words (X,Y). | |
| 147 | ||
| 148 | d. block = 512-bit string. A block (e.g., B) may be represented as a | |
| 149 | sequence of 16 words. | |
| 150 | ||
| 151 | 3. Operations on Words | |
| 152 | ||
| 153 | The following logical operators will be applied to words: | |
| 154 | ||
| 155 | a. Bitwise logical word operations | |
| 156 | ||
| 157 | X AND Y = bitwise logical "and" of X and Y. | |
| 158 | ||
| 159 | X OR Y = bitwise logical "inclusive-or" of X and Y. | |
| 160 | ||
| 161 | X XOR Y = bitwise logical "exclusive-or" of X and Y. | |
| 162 | ||
| 163 | NOT X = bitwise logical "complement" of X. | |
| 164 | ||
| 165 | ||
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | Eastlake & Jones Informational [Page 3] | |
| 170 | ||
| 171 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 172 | ||
| 173 | ||
| 174 | Example: | |
| 175 | ||
| 176 | 01101100101110011101001001111011 | |
| 177 | XOR 01100101110000010110100110110111 | |
| 178 | -------------------------------- | |
| 179 | = 00001001011110001011101111001100 | |
| 180 | ||
| 181 | b. The operation X + Y is defined as follows: words X and Y | |
| 182 | represent integers x and y, where 0 <= x < 2^32 and 0 <= y < 2^32. | |
| 183 | For positive integers n and m, let n mod m be the remainder upon | |
| 184 | dividing n by m. Compute | |
| 185 | ||
| 186 | z = (x + y) mod 2^32. | |
| 187 | ||
| 188 | Then 0 <= z < 2^32. Convert z to a word, Z, and define Z = X + | |
| 189 | Y. | |
| 190 | ||
| 191 | c. The circular left shift operation S^n(X), where X is a word and n | |
| 192 | is an integer with 0 <= n < 32, is defined by | |
| 193 | ||
| 194 | S^n(X) = (X << n) OR (X >> 32-n). | |
| 195 | ||
| 196 | In the above, X << n is obtained as follows: discard the left-most | |
| 197 | n bits of X and then pad the result with n zeroes on the right | |
| 198 | (the result will still be 32 bits). X >> n is obtained by | |
| 199 | discarding the right-most n bits of X and then padding the result | |
| 200 | with n zeroes on the left. Thus S^n(X) is equivalent to a | |
| 201 | circular shift of X by n positions to the left. | |
| 202 | ||
| 203 | 4. Message Padding | |
| 204 | ||
| 205 | SHA-1 is used to compute a message digest for a message or data file | |
| 206 | that is provided as input. The message or data file should be | |
| 207 | considered to be a bit string. The length of the message is the | |
| 208 | number of bits in the message (the empty message has length 0). If | |
| 209 | the number of bits in a message is a multiple of 8, for compactness | |
| 210 | we can represent the message in hex. The purpose of message padding | |
| 211 | is to make the total length of a padded message a multiple of 512. | |
| 212 | SHA-1 sequentially processes blocks of 512 bits when computing the | |
| 213 | message digest. The following specifies how this padding shall be | |
| 214 | performed. As a summary, a "1" followed by m "0"s followed by a 64- | |
| 215 | bit integer are appended to the end of the message to produce a | |
| 216 | padded message of length 512 * n. The 64-bit integer is the length | |
| 217 | of the original message. The padded message is then processed by the | |
| 218 | SHA-1 as n 512-bit blocks. | |
| 219 | ||
| 220 | ||
| 221 | ||
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | Eastlake & Jones Informational [Page 4] | |
| 226 | ||
| 227 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 228 | ||
| 229 | ||
| 230 | Suppose a message has length l < 2^64. Before it is input to the | |
| 231 | SHA-1, the message is padded on the right as follows: | |
| 232 | ||
| 233 | a. "1" is appended. Example: if the original message is "01010000", | |
| 234 | this is padded to "010100001". | |
| 235 | ||
| 236 | b. "0"s are appended. The number of "0"s will depend on the original | |
| 237 | length of the message. The last 64 bits of the last 512-bit block | |
| 238 | are reserved | |
| 239 | ||
| 240 | for the length l of the original message. | |
| 241 | ||
| 242 | Example: Suppose the original message is the bit string | |
| 243 | ||
| 244 | 01100001 01100010 01100011 01100100 01100101. | |
| 245 | ||
| 246 | After step (a) this gives | |
| 247 | ||
| 248 | 01100001 01100010 01100011 01100100 01100101 1. | |
| 249 | ||
| 250 | Since l = 40, the number of bits in the above is 41 and 407 "0"s | |
| 251 | are appended, making the total now 448. This gives (in hex) | |
| 252 | ||
| 253 | 61626364 65800000 00000000 00000000 | |
| 254 | 00000000 00000000 00000000 00000000 | |
| 255 | 00000000 00000000 00000000 00000000 | |
| 256 | 00000000 00000000. | |
| 257 | ||
| 258 | c. Obtain the 2-word representation of l, the number of bits in the | |
| 259 | original message. If l < 2^32 then the first word is all zeroes. | |
| 260 | Append these two words to the padded message. | |
| 261 | ||
| 262 | Example: Suppose the original message is as in (b). Then l = 40 | |
| 263 | (note that l is computed before any padding). The two-word | |
| 264 | representation of 40 is hex 00000000 00000028. Hence the final | |
| 265 | padded message is hex | |
| 266 | ||
| 267 | 61626364 65800000 00000000 00000000 | |
| 268 | 00000000 00000000 00000000 00000000 | |
| 269 | 00000000 00000000 00000000 00000000 | |
| 270 | 00000000 00000000 00000000 00000028. | |
| 271 | ||
| 272 | The padded message will contain 16 * n words for some n > 0. | |
| 273 | The padded message is regarded as a sequence of n blocks M(1) , | |
| 274 | M(2), first characters (or bits) of the message. | |
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | Eastlake & Jones Informational [Page 5] | |
| 282 | ||
| 283 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 284 | ||
| 285 | ||
| 286 | 5. Functions and Constants Used | |
| 287 | ||
| 288 | A sequence of logical functions f(0), f(1),..., f(79) is used in | |
| 289 | SHA-1. Each f(t), 0 <= t <= 79, operates on three 32-bit words B, C, | |
| 290 | D and produces a 32-bit word as output. f(t;B,C,D) is defined as | |
| 291 | follows: for words B, C, D, | |
| 292 | ||
| 293 | f(t;B,C,D) = (B AND C) OR ((NOT B) AND D) ( 0 <= t <= 19) | |
| 294 | ||
| 295 | f(t;B,C,D) = B XOR C XOR D (20 <= t <= 39) | |
| 296 | ||
| 297 | f(t;B,C,D) = (B AND C) OR (B AND D) OR (C AND D) (40 <= t <= 59) | |
| 298 | ||
| 299 | f(t;B,C,D) = B XOR C XOR D (60 <= t <= 79). | |
| 300 | ||
| 301 | A sequence of constant words K(0), K(1), ... , K(79) is used in the | |
| 302 | SHA-1. In hex these are given by | |
| 303 | ||
| 304 | K(t) = 5A827999 ( 0 <= t <= 19) | |
| 305 | ||
| 306 | K(t) = 6ED9EBA1 (20 <= t <= 39) | |
| 307 | ||
| 308 | K(t) = 8F1BBCDC (40 <= t <= 59) | |
| 309 | ||
| 310 | K(t) = CA62C1D6 (60 <= t <= 79). | |
| 311 | ||
| 312 | 6. Computing the Message Digest | |
| 313 | ||
| 314 | The methods given in 6.1 and 6.2 below yield the same message digest. | |
| 315 | Although using method 2 saves sixty-four 32-bit words of storage, it | |
| 316 | is likely to lengthen execution time due to the increased complexity | |
| 317 | of the address computations for the { W[t] } in step (c). There are | |
| 318 | other computation methods which give identical results. | |
| 319 | ||
| 320 | 6.1 Method 1 | |
| 321 | ||
| 322 | The message digest is computed using the message padded as described | |
| 323 | in section 4. The computation is described using two buffers, each | |
| 324 | consisting of five 32-bit words, and a sequence of eighty 32-bit | |
| 325 | words. The words of the first 5-word buffer are labeled A,B,C,D,E. | |
| 326 | The words of the second 5-word buffer are labeled H0, H1, H2, H3, H4. | |
| 327 | The words of the 80-word sequence are labeled W(0), W(1),..., W(79). | |
| 328 | A single word buffer TEMP is also employed. | |
| 329 | ||
| 330 | To generate the message digest, the 16-word blocks M(1), M(2),..., | |
| 331 | M(n) defined in section 4 are processed in order. The processing of | |
| 332 | each M(i) involves 80 steps. | |
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | Eastlake & Jones Informational [Page 6] | |
| 338 | ||
| 339 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 340 | ||
| 341 | ||
| 342 | Before processing any blocks, the H's are initialized as follows: in | |
| 343 | hex, | |
| 344 | ||
| 345 | H0 = 67452301 | |
| 346 | ||
| 347 | H1 = EFCDAB89 | |
| 348 | ||
| 349 | H2 = 98BADCFE | |
| 350 | ||
| 351 | H3 = 10325476 | |
| 352 | ||
| 353 | H4 = C3D2E1F0. | |
| 354 | ||
| 355 | Now M(1), M(2), ... , M(n) are processed. To process M(i), we | |
| 356 | proceed as follows: | |
| 357 | ||
| 358 | a. Divide M(i) into 16 words W(0), W(1), ... , W(15), where W(0) | |
| 359 | is the left-most word. | |
| 360 | ||
| 361 | b. For t = 16 to 79 let | |
| 362 | ||
| 363 | W(t) = S^1(W(t-3) XOR W(t-8) XOR W(t-14) XOR W(t-16)). | |
| 364 | ||
| 365 | c. Let A = H0, B = H1, C = H2, D = H3, E = H4. | |
| 366 | ||
| 367 | d. For t = 0 to 79 do | |
| 368 | ||
| 369 | TEMP = S^5(A) + f(t;B,C,D) + E + W(t) + K(t); | |
| 370 | ||
| 371 | E = D; D = C; C = S^30(B); B = A; A = TEMP; | |
| 372 | ||
| 373 | e. Let H0 = H0 + A, H1 = H1 + B, H2 = H2 + C, H3 = H3 + D, H4 = H4 | |
| 374 | + E. | |
| 375 | ||
| 376 | After processing M(n), the message digest is the 160-bit string | |
| 377 | represented by the 5 words | |
| 378 | ||
| 379 | H0 H1 H2 H3 H4. | |
| 380 | ||
| 381 | 6.2 Method 2 | |
| 382 | ||
| 383 | The method above assumes that the sequence W(0), ... , W(79) is | |
| 384 | implemented as an array of eighty 32-bit words. This is efficient | |
| 385 | from the standpoint of minimization of execution time, since the | |
| 386 | addresses of W(t-3), ... ,W(t-16) in step (b) are easily computed. | |
| 387 | If space is at a premium, an alternative is to regard { W(t) } as a | |
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | Eastlake & Jones Informational [Page 7] | |
| 394 | ||
| 395 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 396 | ||
| 397 | ||
| 398 | circular queue, which may be implemented using an array of sixteen | |
| 399 | 32-bit words W[0], ... W[15]. In this case, in hex let | |
| 400 | ||
| 401 | MASK = 0000000F. Then processing of M(i) is as follows: | |
| 402 | ||
| 403 | a. Divide M(i) into 16 words W[0], ... , W[15], where W[0] is the | |
| 404 | left-most word. | |
| 405 | ||
| 406 | b. Let A = H0, B = H1, C = H2, D = H3, E = H4. | |
| 407 | ||
| 408 | c. For t = 0 to 79 do | |
| 409 | ||
| 410 | s = t AND MASK; | |
| 411 | ||
| 412 | if (t >= 16) W[s] = S^1(W[(s + 13) AND MASK] XOR W[(s + 8) AND | |
| 413 | MASK] XOR W[(s + 2) AND MASK] XOR W[s]); | |
| 414 | ||
| 415 | TEMP = S^5(A) + f(t;B,C,D) + E + W[s] + K(t); | |
| 416 | ||
| 417 | E = D; D = C; C = S^30(B); B = A; A = TEMP; | |
| 418 | ||
| 419 | d. Let H0 = H0 + A, H1 = H1 + B, H2 = H2 + C, H3 = H3 + D, H4 = H4 | |
| 420 | + E. | |
| 421 | ||
| 422 | 7. C Code | |
| 423 | ||
| 424 | Below is a demonstration implementation of SHA-1 in C. Section 7.1 | |
| 425 | contains the header file, 7.2 the C code, and 7.3 a test driver. | |
| 426 | ||
| 427 | 7.1 .h file | |
| 428 | ||
| 429 | /* | |
| 430 | * sha1.h | |
| 431 | * | |
| 432 | * Description: | |
| 433 | * This is the header file for code which implements the Secure | |
| 434 | * Hashing Algorithm 1 as defined in FIPS PUB 180-1 published | |
| 435 | * April 17, 1995. | |
| 436 | * | |
| 437 | * Many of the variable names in this code, especially the | |
| 438 | * single character names, were used because those were the names | |
| 439 | * used in the publication. | |
| 440 | * | |
| 441 | * Please read the file sha1.c for more information. | |
| 442 | * | |
| 443 | */ | |
| 444 | ||
| 445 | ||
| 446 | ||
| 447 | ||
| 448 | ||
| 449 | Eastlake & Jones Informational [Page 8] | |
| 450 | ||
| 451 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 452 | ||
| 453 | ||
| 454 | #ifndef _SHA1_H_ | |
| 455 | #define _SHA1_H_ | |
| 456 | ||
| 457 | #include <stdint.h> | |
| 458 | /* | |
| 459 | * If you do not have the ISO standard stdint.h header file, then you | |
| 460 | * must typdef the following: | |
| 461 | * name meaning | |
| 462 | * uint32_t unsigned 32 bit integer | |
| 463 | * uint8_t unsigned 8 bit integer (i.e., unsigned char) | |
| 464 | * int_least16_t integer of >= 16 bits | |
| 465 | * | |
| 466 | */ | |
| 467 | ||
| 468 | #ifndef _SHA_enum_ | |
| 469 | #define _SHA_enum_ | |
| 470 | enum | |
| 471 | { | |
| 472 | shaSuccess = 0, | |
| 473 | shaNull, /* Null pointer parameter */ | |
| 474 | shaInputTooLong, /* input data too long */ | |
| 475 | shaStateError /* called Input after Result */ | |
| 476 | }; | |
| 477 | #endif | |
| 478 | #define SHA1HashSize 20 | |
| 479 | ||
| 480 | /* | |
| 481 | * This structure will hold context information for the SHA-1 | |
| 482 | * hashing operation | |
| 483 | */ | |
| 484 | typedef struct SHA1Context | |
| 485 | { | |
| 486 | uint32_t Intermediate_Hash[SHA1HashSize/4]; /* Message Digest */ | |
| 487 | ||
| 488 | uint32_t Length_Low; /* Message length in bits */ | |
| 489 | uint32_t Length_High; /* Message length in bits */ | |
| 490 | ||
| 491 | /* Index into message block array */ | |
| 492 | int_least16_t Message_Block_Index; | |
| 493 | uint8_t Message_Block[64]; /* 512-bit message blocks */ | |
| 494 | ||
| 495 | int Computed; /* Is the digest computed? */ | |
| 496 | int Corrupted; /* Is the message digest corrupted? */ | |
| 497 | } SHA1Context; | |
| 498 | ||
| 499 | /* | |
| 500 | * Function Prototypes | |
| 501 | */ | |
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | Eastlake & Jones Informational [Page 9] | |
| 506 | ||
| 507 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 508 | ||
| 509 | ||
| 510 | int SHA1Reset( SHA1Context *); | |
| 511 | int SHA1Input( SHA1Context *, | |
| 512 | const uint8_t *, | |
| 513 | unsigned int); | |
| 514 | int SHA1Result( SHA1Context *, | |
| 515 | uint8_t Message_Digest[SHA1HashSize]); | |
| 516 | ||
| 517 | #endif | |
| 518 | ||
| 519 | 7.2 .c file | |
| 520 | ||
| 521 | /* | |
| 522 | * sha1.c | |
| 523 | * | |
| 524 | * Description: | |
| 525 | * This file implements the Secure Hashing Algorithm 1 as | |
| 526 | * defined in FIPS PUB 180-1 published April 17, 1995. | |
| 527 | * | |
| 528 | * The SHA-1, produces a 160-bit message digest for a given | |
| 529 | * data stream. It should take about 2**n steps to find a | |
| 530 | * message with the same digest as a given message and | |
| 531 | * 2**(n/2) to find any two messages with the same digest, | |
| 532 | * when n is the digest size in bits. Therefore, this | |
| 533 | * algorithm can serve as a means of providing a | |
| 534 | * "fingerprint" for a message. | |
| 535 | * | |
| 536 | * Portability Issues: | |
| 537 | * SHA-1 is defined in terms of 32-bit "words". This code | |
| 538 | * uses <stdint.h> (included via "sha1.h" to define 32 and 8 | |
| 539 | * bit unsigned integer types. If your C compiler does not | |
| 540 | * support 32 bit unsigned integers, this code is not | |
| 541 | * appropriate. | |
| 542 | * | |
| 543 | * Caveats: | |
| 544 | * SHA-1 is designed to work with messages less than 2^64 bits | |
| 545 | * long. Although SHA-1 allows a message digest to be generated | |
| 546 | * for messages of any number of bits less than 2^64, this | |
| 547 | * implementation only works with messages with a length that is | |
| 548 | * a multiple of the size of an 8-bit character. | |
| 549 | * | |
| 550 | */ | |
| 551 | ||
| 552 | ||
| 553 | ||
| 554 | ||
| 555 | ||
| 556 | ||
| 557 | ||
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | Eastlake & Jones Informational [Page 10] | |
| 562 | ||
| 563 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 564 | ||
| 565 | ||
| 566 | #include "sha1.h" | |
| 567 | ||
| 568 | /* | |
| 569 | * Define the SHA1 circular left shift macro | |
| 570 | */ | |
| 571 | #define SHA1CircularShift(bits,word) \ | |
| 572 | (((word) << (bits)) | ((word) >> (32-(bits)))) | |
| 573 | ||
| 574 | /* Local Function Prototyptes */ | |
| 575 | void SHA1PadMessage(SHA1Context *); | |
| 576 | void SHA1ProcessMessageBlock(SHA1Context *); | |
| 577 | ||
| 578 | /* | |
| 579 | * SHA1Reset | |
| 580 | * | |
| 581 | * Description: | |
| 582 | * This function will initialize the SHA1Context in preparation | |
| 583 | * for computing a new SHA1 message digest. | |
| 584 | * | |
| 585 | * Parameters: | |
| 586 | * context: [in/out] | |
| 587 | * The context to reset. | |
| 588 | * | |
| 589 | * Returns: | |
| 590 | * sha Error Code. | |
| 591 | * | |
| 592 | */ | |
| 593 | int SHA1Reset(SHA1Context *context) | |
| 594 | { | |
| 595 | if (!context) | |
| 596 | { | |
| 597 | return shaNull; | |
| 598 | } | |
| 599 | ||
| 600 | context->Length_Low = 0; | |
| 601 | context->Length_High = 0; | |
| 602 | context->Message_Block_Index = 0; | |
| 603 | ||
| 604 | context->Intermediate_Hash[0] = 0x67452301; | |
| 605 | context->Intermediate_Hash[1] = 0xEFCDAB89; | |
| 606 | context->Intermediate_Hash[2] = 0x98BADCFE; | |
| 607 | context->Intermediate_Hash[3] = 0x10325476; | |
| 608 | context->Intermediate_Hash[4] = 0xC3D2E1F0; | |
| 609 | ||
| 610 | context->Computed = 0; | |
| 611 | context->Corrupted = 0; | |
| 612 | ||
| 613 | ||
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | Eastlake & Jones Informational [Page 11] | |
| 618 | ||
| 619 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 620 | ||
| 621 | ||
| 622 | return shaSuccess; | |
| 623 | } | |
| 624 | ||
| 625 | /* | |
| 626 | * SHA1Result | |
| 627 | * | |
| 628 | * Description: | |
| 629 | * This function will return the 160-bit message digest into the | |
| 630 | * Message_Digest array provided by the caller. | |
| 631 | * NOTE: The first octet of hash is stored in the 0th element, | |
| 632 | * the last octet of hash in the 19th element. | |
| 633 | * | |
| 634 | * Parameters: | |
| 635 | * context: [in/out] | |
| 636 | * The context to use to calculate the SHA-1 hash. | |
| 637 | * Message_Digest: [out] | |
| 638 | * Where the digest is returned. | |
| 639 | * | |
| 640 | * Returns: | |
| 641 | * sha Error Code. | |
| 642 | * | |
| 643 | */ | |
| 644 | int SHA1Result( SHA1Context *context, | |
| 645 | uint8_t Message_Digest[SHA1HashSize]) | |
| 646 | { | |
| 647 | int i; | |
| 648 | ||
| 649 | if (!context || !Message_Digest) | |
| 650 | { | |
| 651 | return shaNull; | |
| 652 | } | |
| 653 | ||
| 654 | if (context->Corrupted) | |
| 655 | { | |
| 656 | return context->Corrupted; | |
| 657 | } | |
| 658 | ||
| 659 | if (!context->Computed) | |
| 660 | { | |
| 661 | SHA1PadMessage(context); | |
| 662 | for(i=0; i<64; ++i) | |
| 663 | { | |
| 664 | /* message may be sensitive, clear it out */ | |
| 665 | context->Message_Block[i] = 0; | |
| 666 | } | |
| 667 | context->Length_Low = 0; /* and clear length */ | |
| 668 | context->Length_High = 0; | |
| 669 | context->Computed = 1; | |
| 670 | ||
| 671 | ||
| 672 | ||
| 673 | Eastlake & Jones Informational [Page 12] | |
| 674 | ||
| 675 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 676 | ||
| 677 | ||
| 678 | } | |
| 679 | ||
| 680 | for(i = 0; i < SHA1HashSize; ++i) | |
| 681 | { | |
| 682 | Message_Digest[i] = context->Intermediate_Hash[i>>2] | |
| 683 | >> 8 * ( 3 - ( i & 0x03 ) ); | |
| 684 | } | |
| 685 | ||
| 686 | return shaSuccess; | |
| 687 | } | |
| 688 | ||
| 689 | /* | |
| 690 | * SHA1Input | |
| 691 | * | |
| 692 | * Description: | |
| 693 | * This function accepts an array of octets as the next portion | |
| 694 | * of the message. | |
| 695 | * | |
| 696 | * Parameters: | |
| 697 | * context: [in/out] | |
| 698 | * The SHA context to update | |
| 699 | * message_array: [in] | |
| 700 | * An array of characters representing the next portion of | |
| 701 | * the message. | |
| 702 | * length: [in] | |
| 703 | * The length of the message in message_array | |
| 704 | * | |
| 705 | * Returns: | |
| 706 | * sha Error Code. | |
| 707 | * | |
| 708 | */ | |
| 709 | int SHA1Input( SHA1Context *context, | |
| 710 | const uint8_t *message_array, | |
| 711 | unsigned length) | |
| 712 | { | |
| 713 | if (!length) | |
| 714 | { | |
| 715 | return shaSuccess; | |
| 716 | } | |
| 717 | ||
| 718 | if (!context || !message_array) | |
| 719 | { | |
| 720 | return shaNull; | |
| 721 | } | |
| 722 | ||
| 723 | if (context->Computed) | |
| 724 | { | |
| 725 | context->Corrupted = shaStateError; | |
| 726 | ||
| 727 | ||
| 728 | ||
| 729 | Eastlake & Jones Informational [Page 13] | |
| 730 | ||
| 731 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 732 | ||
| 733 | ||
| 734 | return shaStateError; | |
| 735 | } | |
| 736 | ||
| 737 | if (context->Corrupted) | |
| 738 | { | |
| 739 | return context->Corrupted; | |
| 740 | } | |
| 741 | while(length-- && !context->Corrupted) | |
| 742 | { | |
| 743 | context->Message_Block[context->Message_Block_Index++] = | |
| 744 | (*message_array & 0xFF); | |
| 745 | ||
| 746 | context->Length_Low += 8; | |
| 747 | if (context->Length_Low == 0) | |
| 748 | { | |
| 749 | context->Length_High++; | |
| 750 | if (context->Length_High == 0) | |
| 751 | { | |
| 752 | /* Message is too long */ | |
| 753 | context->Corrupted = 1; | |
| 754 | } | |
| 755 | } | |
| 756 | ||
| 757 | if (context->Message_Block_Index == 64) | |
| 758 | { | |
| 759 | SHA1ProcessMessageBlock(context); | |
| 760 | } | |
| 761 | ||
| 762 | message_array++; | |
| 763 | } | |
| 764 | ||
| 765 | return shaSuccess; | |
| 766 | } | |
| 767 | ||
| 768 | /* | |
| 769 | * SHA1ProcessMessageBlock | |
| 770 | * | |
| 771 | * Description: | |
| 772 | * This function will process the next 512 bits of the message | |
| 773 | * stored in the Message_Block array. | |
| 774 | * | |
| 775 | * Parameters: | |
| 776 | * None. | |
| 777 | * | |
| 778 | * Returns: | |
| 779 | * Nothing. | |
| 780 | * | |
| 781 | * Comments: | |
| 782 | ||
| 783 | ||
| 784 | ||
| 785 | Eastlake & Jones Informational [Page 14] | |
| 786 | ||
| 787 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 788 | ||
| 789 | ||
| 790 | * Many of the variable names in this code, especially the | |
| 791 | * single character names, were used because those were the | |
| 792 | * names used in the publication. | |
| 793 | * | |
| 794 | * | |
| 795 | */ | |
| 796 | void SHA1ProcessMessageBlock(SHA1Context *context) | |
| 797 | { | |
| 798 | const uint32_t K[] = { /* Constants defined in SHA-1 */ | |
| 799 | 0x5A827999, | |
| 800 | 0x6ED9EBA1, | |
| 801 | 0x8F1BBCDC, | |
| 802 | 0xCA62C1D6 | |
| 803 | }; | |
| 804 | int t; /* Loop counter */ | |
| 805 | uint32_t temp; /* Temporary word value */ | |
| 806 | uint32_t W[80]; /* Word sequence */ | |
| 807 | uint32_t A, B, C, D, E; /* Word buffers */ | |
| 808 | ||
| 809 | /* | |
| 810 | * Initialize the first 16 words in the array W | |
| 811 | */ | |
| 812 | for(t = 0; t < 16; t++) | |
| 813 | { | |
| 814 | W[t] = context->Message_Block[t * 4] << 24; | |
| 815 | W[t] |= context->Message_Block[t * 4 + 1] << 16; | |
| 816 | W[t] |= context->Message_Block[t * 4 + 2] << 8; | |
| 817 | W[t] |= context->Message_Block[t * 4 + 3]; | |
| 818 | } | |
| 819 | ||
| 820 | for(t = 16; t < 80; t++) | |
| 821 | { | |
| 822 | W[t] = SHA1CircularShift(1,W[t-3] ^ W[t-8] ^ W[t-14] ^ W[t-16]); | |
| 823 | } | |
| 824 | ||
| 825 | A = context->Intermediate_Hash[0]; | |
| 826 | B = context->Intermediate_Hash[1]; | |
| 827 | C = context->Intermediate_Hash[2]; | |
| 828 | D = context->Intermediate_Hash[3]; | |
| 829 | E = context->Intermediate_Hash[4]; | |
| 830 | ||
| 831 | for(t = 0; t < 20; t++) | |
| 832 | { | |
| 833 | temp = SHA1CircularShift(5,A) + | |
| 834 | ((B & C) | ((~B) & D)) + E + W[t] + K[0]; | |
| 835 | E = D; | |
| 836 | D = C; | |
| 837 | C = SHA1CircularShift(30,B); | |
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | Eastlake & Jones Informational [Page 15] | |
| 842 | ||
| 843 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 844 | ||
| 845 | ||
| 846 | B = A; | |
| 847 | A = temp; | |
| 848 | } | |
| 849 | ||
| 850 | for(t = 20; t < 40; t++) | |
| 851 | { | |
| 852 | temp = SHA1CircularShift(5,A) + (B ^ C ^ D) + E + W[t] + K[1]; | |
| 853 | E = D; | |
| 854 | D = C; | |
| 855 | C = SHA1CircularShift(30,B); | |
| 856 | B = A; | |
| 857 | A = temp; | |
| 858 | } | |
| 859 | ||
| 860 | for(t = 40; t < 60; t++) | |
| 861 | { | |
| 862 | temp = SHA1CircularShift(5,A) + | |
| 863 | ((B & C) | (B & D) | (C & D)) + E + W[t] + K[2]; | |
| 864 | E = D; | |
| 865 | D = C; | |
| 866 | C = SHA1CircularShift(30,B); | |
| 867 | B = A; | |
| 868 | A = temp; | |
| 869 | } | |
| 870 | ||
| 871 | for(t = 60; t < 80; t++) | |
| 872 | { | |
| 873 | temp = SHA1CircularShift(5,A) + (B ^ C ^ D) + E + W[t] + K[3]; | |
| 874 | E = D; | |
| 875 | D = C; | |
| 876 | C = SHA1CircularShift(30,B); | |
| 877 | B = A; | |
| 878 | A = temp; | |
| 879 | } | |
| 880 | ||
| 881 | context->Intermediate_Hash[0] += A; | |
| 882 | context->Intermediate_Hash[1] += B; | |
| 883 | context->Intermediate_Hash[2] += C; | |
| 884 | context->Intermediate_Hash[3] += D; | |
| 885 | context->Intermediate_Hash[4] += E; | |
| 886 | ||
| 887 | context->Message_Block_Index = 0; | |
| 888 | } | |
| 889 | ||
| 890 | ||
| 891 | /* | |
| 892 | * SHA1PadMessage | |
| 893 | * | |
| 894 | ||
| 895 | ||
| 896 | ||
| 897 | Eastlake & Jones Informational [Page 16] | |
| 898 | ||
| 899 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 900 | ||
| 901 | ||
| 902 | * Description: | |
| 903 | * According to the standard, the message must be padded to an even | |
| 904 | * 512 bits. The first padding bit must be a '1'. The last 64 | |
| 905 | * bits represent the length of the original message. All bits in | |
| 906 | * between should be 0. This function will pad the message | |
| 907 | * according to those rules by filling the Message_Block array | |
| 908 | * accordingly. It will also call the ProcessMessageBlock function | |
| 909 | * provided appropriately. When it returns, it can be assumed that | |
| 910 | * the message digest has been computed. | |
| 911 | * | |
| 912 | * Parameters: | |
| 913 | * context: [in/out] | |
| 914 | * The context to pad | |
| 915 | * ProcessMessageBlock: [in] | |
| 916 | * The appropriate SHA*ProcessMessageBlock function | |
| 917 | * Returns: | |
| 918 | * Nothing. | |
| 919 | * | |
| 920 | */ | |
| 921 | ||
| 922 | void SHA1PadMessage(SHA1Context *context) | |
| 923 | { | |
| 924 | /* | |
| 925 | * Check to see if the current message block is too small to hold | |
| 926 | * the initial padding bits and length. If so, we will pad the | |
| 927 | * block, process it, and then continue padding into a second | |
| 928 | * block. | |
| 929 | */ | |
| 930 | if (context->Message_Block_Index > 55) | |
| 931 | { | |
| 932 | context->Message_Block[context->Message_Block_Index++] = 0x80; | |
| 933 | while(context->Message_Block_Index < 64) | |
| 934 | { | |
| 935 | context->Message_Block[context->Message_Block_Index++] = 0; | |
| 936 | } | |
| 937 | ||
| 938 | SHA1ProcessMessageBlock(context); | |
| 939 | ||
| 940 | while(context->Message_Block_Index < 56) | |
| 941 | { | |
| 942 | context->Message_Block[context->Message_Block_Index++] = 0; | |
| 943 | } | |
| 944 | } | |
| 945 | else | |
| 946 | { | |
| 947 | context->Message_Block[context->Message_Block_Index++] = 0x80; | |
| 948 | while(context->Message_Block_Index < 56) | |
| 949 | { | |
| 950 | ||
| 951 | ||
| 952 | ||
| 953 | Eastlake & Jones Informational [Page 17] | |
| 954 | ||
| 955 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 956 | ||
| 957 | ||
| 958 | context->Message_Block[context->Message_Block_Index++] = 0; | |
| 959 | } | |
| 960 | } | |
| 961 | ||
| 962 | /* | |
| 963 | * Store the message length as the last 8 octets | |
| 964 | */ | |
| 965 | context->Message_Block[56] = context->Length_High >> 24; | |
| 966 | context->Message_Block[57] = context->Length_High >> 16; | |
| 967 | context->Message_Block[58] = context->Length_High >> 8; | |
| 968 | context->Message_Block[59] = context->Length_High; | |
| 969 | context->Message_Block[60] = context->Length_Low >> 24; | |
| 970 | context->Message_Block[61] = context->Length_Low >> 16; | |
| 971 | context->Message_Block[62] = context->Length_Low >> 8; | |
| 972 | context->Message_Block[63] = context->Length_Low; | |
| 973 | ||
| 974 | SHA1ProcessMessageBlock(context); | |
| 975 | } | |
| 976 | ||
| 977 | 7.3 Test Driver | |
| 978 | ||
| 979 | The following code is a main program test driver to exercise the code | |
| 980 | in sha1.c. | |
| 981 | ||
| 982 | /* | |
| 983 | * sha1test.c | |
| 984 | * | |
| 985 | * Description: | |
| 986 | * This file will exercise the SHA-1 code performing the three | |
| 987 | * tests documented in FIPS PUB 180-1 plus one which calls | |
| 988 | * SHA1Input with an exact multiple of 512 bits, plus a few | |
| 989 | * error test checks. | |
| 990 | * | |
| 991 | * Portability Issues: | |
| 992 | * None. | |
| 993 | * | |
| 994 | */ | |
| 995 | ||
| 996 | #include <stdint.h> | |
| 997 | #include <stdio.h> | |
| 998 | #include <string.h> | |
| 999 | #include "sha1.h" | |
| 1000 | ||
| 1001 | /* | |
| 1002 | * Define patterns for testing | |
| 1003 | */ | |
| 1004 | #define TEST1 "abc" | |
| 1005 | #define TEST2a "abcdbcdecdefdefgefghfghighijhi" | |
| 1006 | ||
| 1007 | ||
| 1008 | ||
| 1009 | Eastlake & Jones Informational [Page 18] | |
| 1010 | ||
| 1011 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 1012 | ||
| 1013 | ||
| 1014 | #define TEST2b "jkijkljklmklmnlmnomnopnopq" | |
| 1015 | #define TEST2 TEST2a TEST2b | |
| 1016 | #define TEST3 "a" | |
| 1017 | #define TEST4a "01234567012345670123456701234567" | |
| 1018 | #define TEST4b "01234567012345670123456701234567" | |
| 1019 | /* an exact multiple of 512 bits */ | |
| 1020 | #define TEST4 TEST4a TEST4b | |
| 1021 | char *testarray[4] = | |
| 1022 | { | |
| 1023 | TEST1, | |
| 1024 | TEST2, | |
| 1025 | TEST3, | |
| 1026 | TEST4 | |
| 1027 | }; | |
| 1028 | long int repeatcount[4] = { 1, 1, 1000000, 10 }; | |
| 1029 | char *resultarray[4] = | |
| 1030 | { | |
| 1031 | "A9 99 3E 36 47 06 81 6A BA 3E 25 71 78 50 C2 6C 9C D0 D8 9D", | |
| 1032 | "84 98 3E 44 1C 3B D2 6E BA AE 4A A1 F9 51 29 E5 E5 46 70 F1", | |
| 1033 | "34 AA 97 3C D4 C4 DA A4 F6 1E EB 2B DB AD 27 31 65 34 01 6F", | |
| 1034 | "DE A3 56 A2 CD DD 90 C7 A7 EC ED C5 EB B5 63 93 4F 46 04 52" | |
| 1035 | }; | |
| 1036 | ||
| 1037 | int main() | |
| 1038 | { | |
| 1039 | SHA1Context sha; | |
| 1040 | int i, j, err; | |
| 1041 | uint8_t Message_Digest[20]; | |
| 1042 | ||
| 1043 | /* | |
| 1044 | * Perform SHA-1 tests | |
| 1045 | */ | |
| 1046 | for(j = 0; j < 4; ++j) | |
| 1047 | { | |
| 1048 | printf( "\nTest %d: %d, '%s'\n", | |
| 1049 | j+1, | |
| 1050 | repeatcount[j], | |
| 1051 | testarray[j]); | |
| 1052 | ||
| 1053 | err = SHA1Reset(&sha); | |
| 1054 | if (err) | |
| 1055 | { | |
| 1056 | fprintf(stderr, "SHA1Reset Error %d.\n", err ); | |
| 1057 | break; /* out of for j loop */ | |
| 1058 | } | |
| 1059 | ||
| 1060 | for(i = 0; i < repeatcount[j]; ++i) | |
| 1061 | { | |
| 1062 | ||
| 1063 | ||
| 1064 | ||
| 1065 | Eastlake & Jones Informational [Page 19] | |
| 1066 | ||
| 1067 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 1068 | ||
| 1069 | ||
| 1070 | err = SHA1Input(&sha, | |
| 1071 | (const unsigned char *) testarray[j], | |
| 1072 | strlen(testarray[j])); | |
| 1073 | if (err) | |
| 1074 | { | |
| 1075 | fprintf(stderr, "SHA1Input Error %d.\n", err ); | |
| 1076 | break; /* out of for i loop */ | |
| 1077 | } | |
| 1078 | } | |
| 1079 | ||
| 1080 | err = SHA1Result(&sha, Message_Digest); | |
| 1081 | if (err) | |
| 1082 | { | |
| 1083 | fprintf(stderr, | |
| 1084 | "SHA1Result Error %d, could not compute message digest.\n", | |
| 1085 | err ); | |
| 1086 | } | |
| 1087 | else | |
| 1088 | { | |
| 1089 | printf("\t"); | |
| 1090 | for(i = 0; i < 20 ; ++i) | |
| 1091 | { | |
| 1092 | printf("%02X ", Message_Digest[i]); | |
| 1093 | } | |
| 1094 | printf("\n"); | |
| 1095 | } | |
| 1096 | printf("Should match:\n"); | |
| 1097 | printf("\t%s\n", resultarray[j]); | |
| 1098 | } | |
| 1099 | ||
| 1100 | /* Test some error returns */ | |
| 1101 | err = SHA1Input(&sha,(const unsigned char *) testarray[1], 1); | |
| 1102 | printf ("\nError %d. Should be %d.\n", err, shaStateError ); | |
| 1103 | err = SHA1Reset(0); | |
| 1104 | printf ("\nError %d. Should be %d.\n", err, shaNull ); | |
| 1105 | return 0; | |
| 1106 | } | |
| 1107 | ||
| 1108 | 8. Security Considerations | |
| 1109 | ||
| 1110 | This document is intended to provide convenient open source access by | |
| 1111 | the Internet community to the United States of America Federal | |
| 1112 | Information Processing Standard Secure Hash Function SHA-1 [FIPS | |
| 1113 | 180-1]. No independent assertion of the security of this hash | |
| 1114 | function by the authors for any particular use is intended. | |
| 1115 | ||
| 1116 | ||
| 1117 | ||
| 1118 | ||
| 1119 | ||
| 1120 | ||
| 1121 | Eastlake & Jones Informational [Page 20] | |
| 1122 | ||
| 1123 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 1124 | ||
| 1125 | ||
| 1126 | References | |
| 1127 | ||
| 1128 | [FIPS 180-1] "Secure Hash Standard", United States of American, | |
| 1129 | National Institute of Science and Technology, Federal | |
| 1130 | Information Processing Standard (FIPS) 180-1, April | |
| 1131 | 1993. | |
| 1132 | ||
| 1133 | [MD4] "The MD4 Message Digest Algorithm," Advances in | |
| 1134 | Cryptology - CRYPTO '90 Proceedings, Springer-Verlag, | |
| 1135 | 1991, pp. 303-311. | |
| 1136 | ||
| 1137 | [RFC 1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC | |
| 1138 | 1320, April 1992. | |
| 1139 | ||
| 1140 | [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC | |
| 1141 | 1321, April 1992. | |
| 1142 | ||
| 1143 | [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness | |
| 1144 | Requirements for Security", RFC 1750, December 1994. | |
| 1145 | ||
| 1146 | Authors' Addresses | |
| 1147 | ||
| 1148 | Donald E. Eastlake, 3rd | |
| 1149 | Motorola | |
| 1150 | 155 Beaver Street | |
| 1151 | Milford, MA 01757 USA | |
| 1152 | ||
| 1153 | Phone: +1 508-634-2066 (h) | |
| 1154 | +1 508-261-5434 (w) | |
| 1155 | Fax: +1 508-261-4777 | |
| 1156 | EMail: Donald.Eastlake@motorola.com | |
| 1157 | ||
| 1158 | ||
| 1159 | Paul E. Jones | |
| 1160 | Cisco Systems, Inc. | |
| 1161 | 7025 Kit Creek Road | |
| 1162 | Research Triangle Park, NC 27709 USA | |
| 1163 | ||
| 1164 | Phone: +1 919 392 6948 | |
| 1165 | EMail: paulej@packetizer.com | |
| 1166 | ||
| 1167 | ||
| 1168 | ||
| 1169 | ||
| 1170 | ||
| 1171 | ||
| 1172 | ||
| 1173 | ||
| 1174 | ||
| 1175 | ||
| 1176 | ||
| 1177 | Eastlake & Jones Informational [Page 21] | |
| 1178 | ||
| 1179 | RFC 3174 US Secure Hash Algorithm 1 (SHA1) September 2001 | |
| 1180 | ||
| 1181 | ||
| 1182 | Full Copyright Statement | |
| 1183 | ||
| 1184 | Copyright (C) The Internet Society (2001). All Rights Reserved. | |
| 1185 | ||
| 1186 | This document and translations of it may be copied and furnished to | |
| 1187 | others, and derivative works that comment on or otherwise explain it | |
| 1188 | or assist in its implementation may be prepared, copied, published | |
| 1189 | and distributed, in whole or in part, without restriction of any | |
| 1190 | kind, provided that the above copyright notice and this paragraph are | |
| 1191 | included on all such copies and derivative works. However, this | |
| 1192 | document itself may not be modified in any way, such as by removing | |
| 1193 | the copyright notice or references to the Internet Society or other | |
| 1194 | Internet organizations, except as needed for the purpose of | |
| 1195 | developing Internet standards in which case the procedures for | |
| 1196 | copyrights defined in the Internet Standards process must be | |
| 1197 | followed, or as required to translate it into languages other than | |
| 1198 | English. | |
| 1199 | ||
| 1200 | The limited permissions granted above are perpetual and will not be | |
| 1201 | revoked by the Internet Society or its successors or assigns. | |
| 1202 | ||
| 1203 | This document and the information contained herein is provided on an | |
| 1204 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
| 1205 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
| 1206 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
| 1207 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
| 1208 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
| 1209 | ||
| 1210 | Acknowledgement | |
| 1211 | ||
| 1212 | Funding for the RFC Editor function is currently provided by the | |
| 1213 | Internet Society. | |
| 1214 | ||
| 1215 | ||
| 1216 | ||
| 1217 | ||
| 1218 | ||
| 1219 | ||
| 1220 | ||
| 1221 | ||
| 1222 | ||
| 1223 | ||
| 1224 | ||
| 1225 | ||
| 1226 | ||
| 1227 | ||
| 1228 | ||
| 1229 | ||
| 1230 | ||
| 1231 | ||
| 1232 | ||
| 1233 | Eastlake & Jones Informational [Page 22] | |
| 1234 |
| 22 | 22 | <li>SleepyCat include files and libraries are required to buil SASLDB plugin, |
| 23 | 23 | saslpasswd2.exe and sasldblistusers2.exe. We have tested SleepyCat 4.1.X-4.4.X. |
| 24 | 24 | |
| 25 | <li>If you are building directly from CVS, you'll need the <a | |
| 25 | <li>If you are building directly from GIT, you'll need the <a | |
| 26 | 26 | href="http://www.cygwin.com/">Cygwin</a> Unix-compatibility |
| 27 | 27 | environment to create the <tt>_init.c</tt> files needed for dynamic |
| 28 | 28 | loading. Cygwin is <em>not</em> required for building from our tar |
| 32 | 32 | |
| 33 | 33 | <h2>Step by step</h2> |
| 34 | 34 | |
| 35 | These directions assume that you've untarred the library or used CVS | |
| 35 | These directions assume that you've untarred the library or used GIT | |
| 36 | 36 | and the sources are in <tt>C:\SASL</tt>. |
| 37 | 37 | |
| 38 | <h3>preparing to build (cvs only!)</h3> | |
| 38 | <h3>preparing to build (GIT only!)</h3> | |
| 39 | 39 | |
| 40 | 40 | Start a cygwin shell and create the dynamic loading stubs: |
| 41 | 41 | |
| 33 | 33 | * as extern. (Technically, we don't even have to do that.) */ |
| 34 | 34 | #ifdef WIN32 |
| 35 | 35 | # ifdef LIBSASL_EXPORTS |
| 36 | # define LIBSASL_API __declspec(dllexport) | |
| 36 | # define LIBSASL_API extern __declspec(dllexport) | |
| 37 | 37 | # else /* LIBSASL_EXPORTS */ |
| 38 | # define LIBSASL_API __declspec(dllimport) | |
| 38 | # define LIBSASL_API extern __declspec(dllimport) | |
| 39 | 39 | # endif /* LIBSASL_EXPORTS */ |
| 40 | 40 | #else /* WIN32 */ |
| 41 | 41 | # define LIBSASL_API extern |
| 42 | 42 | #endif /* WIN32 */ |
| 43 | 43 | |
| 44 | /* Same as above, but used during a variable declaration. Only Unix definition | |
| 45 | * is different, as we can't assign an initial value to an extern variable */ | |
| 44 | /* Same as above, but used during a variable declaration. */ | |
| 46 | 45 | #ifdef WIN32 |
| 47 | 46 | # ifdef LIBSASL_EXPORTS |
| 48 | # define LIBSASL_VAR __declspec(dllexport) | |
| 47 | # define LIBSASL_VAR extern __declspec(dllexport) | |
| 49 | 48 | # else /* LIBSASL_EXPORTS */ |
| 50 | # define LIBSASL_VAR __declspec(dllimport) | |
| 49 | # define LIBSASL_VAR extern __declspec(dllimport) | |
| 51 | 50 | # endif /* LIBSASL_EXPORTS */ |
| 52 | 51 | #else /* WIN32 */ |
| 53 | # define LIBSASL_VAR | |
| 52 | # define LIBSASL_VAR extern | |
| 54 | 53 | #endif /* WIN32 */ |
| 55 | 54 | |
| 56 | 55 | /* the resulting structure for property values |
| 123 | 123 | /* Keep in sync with win32/common.mak */ |
| 124 | 124 | #define SASL_VERSION_MAJOR 2 |
| 125 | 125 | #define SASL_VERSION_MINOR 1 |
| 126 | #define SASL_VERSION_STEP 25 | |
| 126 | #define SASL_VERSION_STEP 26 | |
| 127 | 127 | |
| 128 | 128 | /* A convenience macro: same as was defined in the OpenLDAP LDAPDB */ |
| 129 | 129 | #define SASL_VERSION_FULL ((SASL_VERSION_MAJOR << 16) |\ |
| 224 | 224 | |
| 225 | 225 | /* memory allocation functions which may optionally be replaced: |
| 226 | 226 | */ |
| 227 | typedef void *sasl_malloc_t(unsigned long); | |
| 228 | typedef void *sasl_calloc_t(unsigned long, unsigned long); | |
| 229 | typedef void *sasl_realloc_t(void *, unsigned long); | |
| 227 | typedef void *sasl_malloc_t(size_t); | |
| 228 | typedef void *sasl_calloc_t(size_t, size_t); | |
| 229 | typedef void *sasl_realloc_t(void *, size_t); | |
| 230 | 230 | typedef void sasl_free_t(void *); |
| 231 | 231 | |
| 232 | 232 | LIBSASL_API void sasl_set_alloc(sasl_malloc_t *, |
| 632 | 632 | /* One of the following two is required */ |
| 633 | 633 | #define SASL_CU_AUTHID 0x01 |
| 634 | 634 | #define SASL_CU_AUTHZID 0x02 |
| 635 | ||
| 635 | 636 | /* Combine the following with SASL_CU_AUTHID, if you don't want |
| 636 | to fail if auxprop returned SASL_NOUSER */ | |
| 637 | to fail if auxprop returned SASL_NOUSER/SASL_NOMECH. | |
| 638 | This flag has no effect on SASL_CU_AUTHZID. */ | |
| 637 | 639 | #define SASL_CU_EXTERNALLY_VERIFIED 0x04 |
| 638 | 640 | |
| 639 | 641 | #define SASL_CU_OVERRIDE 0x08 /* mapped to SASL_AUXPROP_OVERRIDE */ |
| 81 | 81 | |
| 82 | 82 | LIBSASL_API int sasl_config_init(const char *filename); |
| 83 | 83 | |
| 84 | LIBSASL_API void sasl_config_done(void); | |
| 85 | ||
| 84 | 86 | #ifdef WIN32 |
| 85 | 87 | /* Just in case a different DLL defines this as well */ |
| 86 | 88 | #if defined(NEED_GETOPT) |
| 0 | ||
| 1 | Internet Draft Rob Weltman | |
| 2 | Netscape Communications Corp. | |
| 3 | Rosanna Lee | |
| 4 | draft-weltman-java-sasl-02.txt Sun Microsystems | |
| 5 | Rob Earhart | |
| 6 | Carnegie Mellon | |
| 7 | June 4, 1999 | |
| 8 | ||
| 9 | ||
| 10 | The Java SASL Application Program Interface | |
| 11 | ||
| 12 | ||
| 13 | Status of this Memo | |
| 14 | ||
| 15 | This document is an Internet-Draft and is in full conformance with | |
| 16 | all provisions of Section 10 of RFC2026. | |
| 17 | ||
| 18 | Internet-Drafts are working documents of the Internet Task Force | |
| 19 | (IETF), its areas, and its working groups. Note that other groups | |
| 20 | may also distribute working documents as Internet-Drafts. | |
| 21 | ||
| 22 | Internet-Drafts are draft documents valid for a maximum of six | |
| 23 | months and may be updated, replaced, or obsoleted by other documents | |
| 24 | at any time. It is inappropriate to use Internet Drafts as | |
| 25 | reference material or to cite them other than as "work in progress." | |
| 26 | ||
| 27 | The list of current Internet-Drafts can be accessed at | |
| 28 | http://www.ietf.org/ietf/1id-abstracts.txt | |
| 29 | ||
| 30 | The list of Internet-Draft Shadow Directories can be accessed at | |
| 31 | http://www.ietf.org/shadow.html. | |
| 32 | ||
| 33 | ||
| 34 | ||
| 35 | Abstract | |
| 36 | ||
| 37 | This document defines a client-side and a server-side Java language | |
| 38 | interface for using the Simple Authentication and Security Layer | |
| 39 | (SASL) mechanisms for adding authentication support to connection- | |
| 40 | based protocols. The interface promotes sharing of SASL mechanism | |
| 41 | drivers and security layers between applications using different | |
| 42 | protocols. It complements but does not replace [SASL], which defines | |
| 43 | and exemplifies use of the SASL protocol in a language-independent | |
| 44 | way. | |
| 45 | ||
| 46 | ||
| 47 | ||
| 48 | ||
| 49 | ||
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | Expires 12/99 [Page 1] | |
| 58 | ||
| 59 | JAVA SASL API June 1999 | |
| 60 | ||
| 61 | ||
| 62 | 1 Overview of the SASL classes..........................5 | |
| 63 | 1.1 Interfaces .......................................5 | |
| 64 | 1.2 Classes .......................................5 | |
| 65 | 2 Overview of SASL API Use..............................6 | |
| 66 | 3 The java SASL classes.................................7 | |
| 67 | 3.1 public class Sasl.....................................7 | |
| 68 | 3.1.1 createSaslClient.................................7 | |
| 69 | 3.1.2 setSaslClientFactory.............................9 | |
| 70 | 3.1.3 createSaslServer.................................9 | |
| 71 | 3.1.4 setSaslServerFactory............................10 | |
| 72 | 3.2 public interface SaslClient..........................11 | |
| 73 | 3.2.1 createInitialResponse...........................11 | |
| 74 | 3.2.2 evaluateChallenge...............................11 | |
| 75 | 3.2.3 isComplete......................................11 | |
| 76 | 3.2.4 getSecurityLayer................................11 | |
| 77 | 3.2.5 getMechanismName................................12 | |
| 78 | 3.3 public interface SaslClientFactory...................12 | |
| 79 | 3.3.1 createSaslClient................................12 | |
| 80 | 3.3.2 getMechanismNames...............................13 | |
| 81 | 3.4 public interface SaslServer..........................13 | |
| 82 | 3.4.1 evaluateResponse................................13 | |
| 83 | 3.4.2 isComplete......................................14 | |
| 84 | 3.4.3 getSecurityLayer................................14 | |
| 85 | 3.4.4 getMechanismName................................14 | |
| 86 | 3.4.5 getAuthorizationID..............................14 | |
| 87 | 3.5 public interface SaslServerFactory...................15 | |
| 88 | 3.5.1 createSaslServer................................15 | |
| 89 | 3.5.2 getMechanismNames...............................16 | |
| 90 | 3.6 public class SaslException...........................16 | |
| 91 | 3.6.1 Constructors....................................16 | |
| 92 | 3.6.2 getException....................................17 | |
| 93 | 3.6.3 printStackTrace.................................17 | |
| 94 | 3.7 public interface SecurityLayer.......................17 | |
| 95 | 3.7.1 encode......................................17 | |
| 96 | 3.7.2 decode......................................18 | |
| 97 | 4 Security Considerations..............................19 | |
| 98 | 5 Bibliography ......................................19 | |
| 99 | 6 Authors' Addresses...................................19 | |
| 100 | 7 Acknowledgements.....................................19 | |
| 101 | 8 Appendix A - Sample java LDAP program using SASL.....20 | |
| 102 | 9 Appendix B - Changes from java-sasl-01.txt...........24 | |
| 103 | ||
| 104 | ||
| 105 | ||
| 106 | ||
| 107 | ||
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | ||
| 114 | ||
| 115 | ||
| 116 | ||
| 117 | Expires 12/99 [Page 2] | |
| 118 | ||
| 119 | JAVA SASL API June 1999 | |
| 120 | ||
| 121 | Introduction | |
| 122 | ||
| 123 | ||
| 124 | See [SASL], section 3, for an introduction to and overview of the | |
| 125 | SASL framework for authentication and negotiation of a security | |
| 126 | layer. The following presents an outline of the concepts. | |
| 127 | ||
| 128 | --------------- ------------------- ----------------- | |
| 129 | | Application |-----| Protocol Driver |------| MD5 | | |
| 130 | --------------- ------------------- | ----------------- | |
| 131 | | | |
| 132 | | ----------------- | |
| 133 | |--| Kerberos v5 | | |
| 134 | | ----------------- | |
| 135 | | | |
| 136 | | ----------------- | |
| 137 | |--| PKCS-11 | | |
| 138 | | ----------------- | |
| 139 | | | |
| 140 | | | |
| 141 | | | |
| 142 | | - - - - - - - - - | |
| 143 | |--| xxxYYYxxx | | |
| 144 | - - - - - - - - - | |
| 145 | ||
| 146 | An application chooses a Protocol Driver specific to the protocol it | |
| 147 | wants to use, and specifies one or more acceptable mechanisms. The | |
| 148 | Protocol Driver controls the socket, and knows the format/packaging | |
| 149 | of bytes sent down and received from the socket, but does not know | |
| 150 | how to authenticate or to encrypt/ decrypt the bytes. It uses one of | |
| 151 | the Mechanism Drivers to help it perform authentication. The | |
| 152 | Protocol Driver examines each byte string received from the server | |
| 153 | during the authentication in a protocol-specific way to determine if | |
| 154 | the authentication process has been completed. If not, the byte | |
| 155 | string is passed to the Mechanism Driver to be interpreted as a | |
| 156 | server challenge; the Mechanism Driver returns an appropriate | |
| 157 | response, which the Protocol Driver can encode in a protocol- | |
| 158 | specific way and return to the server. | |
| 159 | ||
| 160 | If the Protocol Driver concludes from the byte string received from | |
| 161 | the server that authentication is complete, it may query the | |
| 162 | Mechanism Driver if it considers the authentication process | |
| 163 | complete, in order to thwart early completion messages inserted by | |
| 164 | an intruder. | |
| 165 | ||
| 166 | On completed authentication, the Protocol Driver may receive from | |
| 167 | the Mechanism Driver a Security Layer object. From this point on, | |
| 168 | any data exchanged throught the socket is passed to the Security | |
| 169 | Layer object for encoding/decoding. | |
| 170 | ||
| 171 | A complication here is that some authentication methods may require | |
| 172 | additional user/application input. That means that a Mechanism | |
| 173 | Driver may need to call up to an application during the | |
| 174 | authentication process. To satisfy this requirement, the application | |
| 175 | ||
| 176 | ||
| 177 | Expires 12/99 [Page 3] | |
| 178 | ||
| 179 | JAVA SASL API June 1999 | |
| 180 | ||
| 181 | can supply a javax.security.auth.callback.CallbackHandler instance | |
| 182 | [JAAS] that can be used by the Mechanism Driver to prompt the user | |
| 183 | for additional input. | |
| 184 | ||
| 185 | Protocol Drivers are protocol-dependent, and may be built in to a | |
| 186 | protocol package or an application. There is a generalized framework | |
| 187 | for registering and finding Mechanism Drivers. The framework uses a | |
| 188 | factory to produce an appropriate Mechanism Driver. The factory may | |
| 189 | be preconfigured, explicitly specified by the caller, specified as a | |
| 190 | list of packages by the caller, or be identified based on a list of | |
| 191 | packages in the System properties. | |
| 192 | ||
| 193 | The Mechanism Drivers are protocol-independent, and don't deal | |
| 194 | directly with network connections, just byte arrays, so they can be | |
| 195 | implemented in a generalizable way for all protocols. | |
| 196 | ||
| 197 | A Security Layer Driver typically inherits a state object from the | |
| 198 | Mechanism Driver, where parameters and resolutions reached during | |
| 199 | authentication have been stored. | |
| 200 | ||
| 201 | Different Mechanism Drivers may require different parameters to | |
| 202 | carry out the authentication process. This is handled by passing a | |
| 203 | java.util.Hashtable object as an argument to instantiation methods. | |
| 204 | ||
| 205 | In the following discussion, 'client' refers to the client-side | |
| 206 | protocol driver that is using the SASL mechanism while 'server' | |
| 207 | refers to the server-side protocol driver that is using the SASL | |
| 208 | mechanism. | |
| 209 | ||
| 210 | In the Java SASL environment, the SaslClient interface represents | |
| 211 | the client's view of the Mechanism Driver, while the SaslServer | |
| 212 | interface represents the server's view. | |
| 213 | ||
| 214 | --------------- --------------- | |
| 215 | | Application |--+ +--| Server | | |
| 216 | --------------- | | --------------- | |
| 217 | | | | |
| 218 | ------------------- ------------------- | |
| 219 | | Protocol Driver |--+ <- - - - -> +--| Protocol Driver | | |
| 220 | ------------------- | | ------------------- | |
| 221 | | | | |
| 222 | ------------------- ------------------- | |
| 223 | | SaslClient | | SaslServer | | |
| 224 | ------------------- ------------------- | |
| 225 | | | | |
| 226 | ----------------- | | ----------------- | |
| 227 | | MD5 |----| |---| MD5 | | |
| 228 | ----------------- | | ----------------- | |
| 229 | | | | |
| 230 | ----------------- | | ----------------- | |
| 231 | | Kerberos v5 |----| |---| Kerberos v5 | | |
| 232 | ----------------- | | ----------------- | |
| 233 | | | | |
| 234 | ----------------- | | ----------------- | |
| 235 | ||
| 236 | ||
| 237 | Expires 12/99 [Page 4] | |
| 238 | ||
| 239 | JAVA SASL API June 1999 | |
| 240 | ||
| 241 | | PKCS-11 |----| |---| PKCS-11 | | |
| 242 | ----------------- | | ----------------- | |
| 243 | | | | |
| 244 | - - - - - - - - - | | - - - - - - - - - | |
| 245 | | xxxYYYxxx |----+ +---| xxxYYYxxx | | |
| 246 | - - - - - - - - - - - - - - - - - - | |
| 247 | ||
| 248 | A client using the Java SASL API may communicate with any server | |
| 249 | implementing the SASL protocol, and a server may use the API to | |
| 250 | process authentication requests from any client using the SASL | |
| 251 | protocol. It is not required that both sides use the same language | |
| 252 | bindings. | |
| 253 | ||
| 254 | 1 Overview of the SASL classes | |
| 255 | ||
| 256 | ||
| 257 | 1.1 Interfaces | |
| 258 | ||
| 259 | ||
| 260 | SaslClient Performs SASL authentication as a | |
| 261 | client. | |
| 262 | ||
| 263 | SaslClientFactory An interface for creating instances of | |
| 264 | SaslClient. It is not normally accessed | |
| 265 | directly by a client, which will use the | |
| 266 | Sasl static methods instead. However, a | |
| 267 | particular environment may provide and | |
| 268 | install a new or different | |
| 269 | SaslClientFactory. | |
| 270 | ||
| 271 | SaslServer Performs SASL authentication as a | |
| 272 | server. | |
| 273 | ||
| 274 | SaslServerFactory An interface for creating instances of | |
| 275 | SaslServer. It is not normally accessed | |
| 276 | directly by a server, which will use the | |
| 277 | Sasl static methods instead. However, a | |
| 278 | particular environment may provide and | |
| 279 | install a new or different | |
| 280 | SaslServerFactory. | |
| 281 | ||
| 282 | SecurityLayer An interface for encoding and decoding | |
| 283 | data. | |
| 284 | ||
| 285 | ||
| 286 | 1.2 Classes | |
| 287 | ||
| 288 | ||
| 289 | Sasl A static class for creating SASL clients | |
| 290 | and servers. It transparently locates | |
| 291 | and uses any available | |
| 292 | SaslClientFactory/SaslServerFactory | |
| 293 | instances. | |
| 294 | ||
| 295 | ||
| 296 | ||
| 297 | Expires 12/99 [Page 5] | |
| 298 | ||
| 299 | JAVA SASL API June 1999 | |
| 300 | ||
| 301 | SaslException Exception thrown on errors and failures | |
| 302 | in the authentication process. | |
| 303 | ||
| 304 | ||
| 305 | 2 Overview of SASL API Use | |
| 306 | ||
| 307 | An application generally uses the SASL API as follows: | |
| 308 | ||
| 309 | - Pass a list of acceptable or known Mechanisms to | |
| 310 | Sasl.createSaslClient. The method returns an object | |
| 311 | implementing SaslClient on success. | |
| 312 | ||
| 313 | - Create an object implementing the client authentication | |
| 314 | callback interfaces, which can provide credentials when | |
| 315 | required by the SaslClient. | |
| 316 | ||
| 317 | - Have the SaslClient object begin the authentication process by | |
| 318 | providing an initial server response, if the protocol supports | |
| 319 | an initial response. | |
| 320 | ||
| 321 | - Responses/challenges are exchanged with the server. If a | |
| 322 | response indicates authentication has completed, SaslClient is | |
| 323 | queried for validation, and a SecurityLayer object may be | |
| 324 | obtained from it. If not, the SaslClient is queried for an | |
| 325 | appropriate next response to the server. This continues until | |
| 326 | authentication has completed. | |
| 327 | ||
| 328 | - For the rest of the session, messages to the server are encoded | |
| 329 | first by the Security Layer (if one has been provided by | |
| 330 | SaslClient), and messages from the server are decoded by it | |
| 331 | before processing in the application. | |
| 332 | ||
| 333 | ||
| 334 | A server generally uses the SASL API as follows: | |
| 335 | ||
| 336 | - It receives a request from the client requesting authentication | |
| 337 | for a particular SASL mechanism, accompanied by an optional | |
| 338 | an initial response. | |
| 339 | ||
| 340 | - It processes the initial response and generates a challenge | |
| 341 | specific for the SASL mechanism to be sent back to the client | |
| 342 | if the response is processed successfully. If the response is | |
| 343 | not processed successfully, it sends an error to the client and | |
| 344 | terminates the authentication session. | |
| 345 | ||
| 346 | - Responses/challenges are exchanged with the client. If the | |
| 347 | server cannot successful process a response, the server sends | |
| 348 | an error to the client and terminates the authentication. If | |
| 349 | the server has completed the authentication and has no more | |
| 350 | challenges to send, it sends a success indication to the | |
| 351 | client. | |
| 352 | ||
| 353 | - If the authentication has completed successfully, the server | |
| 354 | extracts the authorization ID of the client from the SaslServer | |
| 355 | ||
| 356 | ||
| 357 | Expires 12/99 [Page 6] | |
| 358 | ||
| 359 | JAVA SASL API June 1999 | |
| 360 | ||
| 361 | instance (if appropriate) to be used for subsequent access | |
| 362 | control checks. | |
| 363 | ||
| 364 | - For the rest of the session, messages to and from the client | |
| 365 | are encoded and decoded by the Security Layer, if one has been | |
| 366 | provided by SaslServer. | |
| 367 | ||
| 368 | The following sections describe the SASL classes in more detail. | |
| 369 | ||
| 370 | ||
| 371 | 3 The Java SASL classes | |
| 372 | ||
| 373 | ||
| 374 | 3.1 public class Sasl | |
| 375 | ||
| 376 | A class capable of providing a SaslClient or SaslServer. | |
| 377 | ||
| 378 | ||
| 379 | 3.1.1 createSaslClient | |
| 380 | ||
| 381 | public static SaslClient | |
| 382 | createSaslClient(String[] mechanisms, | |
| 383 | String authorizationID, | |
| 384 | String protocol, | |
| 385 | String serverName, | |
| 386 | Hashtable props, | |
| 387 | javax.security.auth.callback.CallbackHandler cbh) | |
| 388 | throws SaslException | |
| 389 | ||
| 390 | Creates a SaslClient using the parameters supplied. It returns null | |
| 391 | if no SaslClient can be created using the parameters supplied. | |
| 392 | Throws SaslException if it cannot create a SaslClient because of an | |
| 393 | error. | |
| 394 | ||
| 395 | The algorithm for selection is as follows: | |
| 396 | ||
| 397 | 1.If a factory has been installed via setSaslClientFactory(), try | |
| 398 | it first. If non-null answer produced, return it. | |
| 399 | 2.Use the packages listed in the javax.security.sasl.client.pkgs | |
| 400 | property from props to load in a factory and try to create a | |
| 401 | SaslClient, by looking for a class named ClientFactory. Repeat | |
| 402 | this for each package on the list until a non-null answer is | |
| 403 | produced. If non-null answer produced, return it. | |
| 404 | 3.Repeat previous step using the javax.security.sasl.client.pkgs | |
| 405 | System property. | |
| 406 | 4.If no non-null answer produced, return null. | |
| 407 | ||
| 408 | Parameters are: | |
| 409 | ||
| 410 | mechanisms The non-null list of mechanism names to try. Each | |
| 411 | is the IANA-registered name of a SASL mechanism. | |
| 412 | (e.g. "GSSAPI", "CRAM-MD5"). | |
| 413 | ||
| 414 | ||
| 415 | ||
| 416 | ||
| 417 | Expires 12/99 [Page 7] | |
| 418 | ||
| 419 | JAVA SASL API June 1999 | |
| 420 | ||
| 421 | authorizationIDThe possibly null protocol-dependent | |
| 422 | identification to be used for authorization, e.g. | |
| 423 | user name or distinguished name. When the SASL | |
| 424 | authentication completes successfully, the entity | |
| 425 | named by authorizationId is granted access. If | |
| 426 | null, access is granted to a protocol-dependent | |
| 427 | default (for example, in LDAP this is the DN in | |
| 428 | the bind request). | |
| 429 | ||
| 430 | protocol The non-null string name of the protocol for | |
| 431 | which the authentication is being performed, e.g | |
| 432 | "pop", "ldap". | |
| 433 | ||
| 434 | serverName The non-null fully qualified host name of the | |
| 435 | server to authenticate to. | |
| 436 | ||
| 437 | props The possibly null additional configuration | |
| 438 | properties for the session, e.g. | |
| 439 | ||
| 440 | javax.security.sasl.encryption.minimum Minimum key length; | |
| 441 | default "0" (no | |
| 442 | session | |
| 443 | protection). "1" | |
| 444 | means integrity | |
| 445 | protection only. | |
| 446 | ||
| 447 | javax.security.sasl.encryption.maximum Maximum key length; | |
| 448 | default "256". | |
| 449 | ||
| 450 | javax.security.sasl.server.authentication "true" if | |
| 451 | server must | |
| 452 | authenticate to | |
| 453 | client; default | |
| 454 | "false". | |
| 455 | ||
| 456 | javax.security.sasl.ip.local IP address in | |
| 457 | dotted decimal | |
| 458 | format, for | |
| 459 | kerberos v4; no | |
| 460 | default. | |
| 461 | ||
| 462 | javax.security.sasl.ip.remote IP address in | |
| 463 | dotted decimal | |
| 464 | format, for | |
| 465 | kerberos v4; no | |
| 466 | default. | |
| 467 | ||
| 468 | javax.security.sasl.maxbuffer Maximum size of | |
| 469 | security layer | |
| 470 | frames; default "0" | |
| 471 | (client will | |
| 472 | not use the | |
| 473 | security layer). | |
| 474 | ||
| 475 | ||
| 476 | ||
| 477 | Expires 12/99 [Page 8] | |
| 478 | ||
| 479 | JAVA SASL API June 1999 | |
| 480 | ||
| 481 | javax.security.sasl.client.pkgs A space-separated | |
| 482 | list of package | |
| 483 | names to use when | |
| 484 | locating a | |
| 485 | SaslClientFactory. | |
| 486 | ||
| 487 | cbh The possibly null callback handler to used by the | |
| 488 | SASL mechanisms to get further information from | |
| 489 | the application/library to complete the | |
| 490 | authentication. For example, a SASL mechanism | |
| 491 | might require the authentication ID and password | |
| 492 | from the caller. The authentication ID may be | |
| 493 | requested with a NameCallback, and the password | |
| 494 | with a PasswordCallback. | |
| 495 | ||
| 496 | ||
| 497 | 3.1.2 setSaslClientFactory | |
| 498 | ||
| 499 | public static void | |
| 500 | setSaslClientFactory(SaslClientFactory fac) | |
| 501 | ||
| 502 | Sets the default SaslClientFactory to use. This method sets fac to | |
| 503 | be the default factory. It can only be called with a non-null value | |
| 504 | once per VM. If a factory has been set already, this method throws | |
| 505 | IllegalStateException. | |
| 506 | ||
| 507 | Parameters are: | |
| 508 | ||
| 509 | fac The possibly null factory to set. If null, it | |
| 510 | doesn't do anything. | |
| 511 | ||
| 512 | ||
| 513 | ||
| 514 | 3.1.3 createSaslServer | |
| 515 | ||
| 516 | public static SaslServer | |
| 517 | createSaslServer(String mechanism, | |
| 518 | String protocol, | |
| 519 | String serverName, | |
| 520 | Hashtable props, | |
| 521 | javax.security.auth.callback.CallbackHandler cbh) | |
| 522 | throws SaslException | |
| 523 | ||
| 524 | This method creates a SaslServer for the specified mechanism. It | |
| 525 | returns null if no SaslServer can be created for the specified | |
| 526 | mechanism. | |
| 527 | ||
| 528 | The algorithm for selection is as follows: | |
| 529 | ||
| 530 | 1.If a factory has been installed via setSaslServerFactory(), try | |
| 531 | it first. If non-null answer produced, return it. | |
| 532 | 2.Use the packages listed in the javax.security.sasl.server.pkgs | |
| 533 | property in props, if present, to load in a factory and try to | |
| 534 | create a SaslServer, by looking for a class named | |
| 535 | ||
| 536 | ||
| 537 | Expires 12/99 [Page 9] | |
| 538 | ||
| 539 | JAVA SASL API June 1999 | |
| 540 | ||
| 541 | ServerFactory. Repeat this for each package on the list until a | |
| 542 | non-null answer is produced. If non-null answer produced, | |
| 543 | return it. | |
| 544 | 3.Use the packages listed in the javax.security.sasl.server.pkgs | |
| 545 | System property to load in a factory and try to create a | |
| 546 | SaslServer. Repeat this for each package on the list until a | |
| 547 | non-null answer is produced. If non-null answer produced, | |
| 548 | return it. | |
| 549 | 4.If no non-null answer produced, return null. | |
| 550 | ||
| 551 | Parameters are: | |
| 552 | ||
| 553 | mechanism A non-null IANA-registered name of a SASL | |
| 554 | mechanism (e.g. "GSSAPI", "CRAM-MD5"). | |
| 555 | ||
| 556 | protocol The non-null string name of the protocol for | |
| 557 | which the authentication is being performed, e.g | |
| 558 | "pop", "ldap". | |
| 559 | ||
| 560 | serverName The non-null fully qualified host name of the | |
| 561 | server to authenticate to. | |
| 562 | ||
| 563 | props The possibly null properties to be used by the | |
| 564 | SASL mechanisms to configure the authentication | |
| 565 | exchange. See Sasl.createSaslClient for examples | |
| 566 | of properties. | |
| 567 | ||
| 568 | cbh The possibly null callback handler to used by the | |
| 569 | SASL mechanisms to get further information from | |
| 570 | the application/library to complete the | |
| 571 | authentication. For example, a SASL mechanism | |
| 572 | might require the authentication ID and password | |
| 573 | from the caller. The authentication ID may be | |
| 574 | requested with a NameCallback, and the password | |
| 575 | with a PasswordCallback. | |
| 576 | ||
| 577 | ||
| 578 | 3.1.4 setSaslServerFactory | |
| 579 | ||
| 580 | public static void | |
| 581 | setSaslServerFactory(SaslServerFactory fac) | |
| 582 | ||
| 583 | Sets the default SaslServerFactory to use. This method sets fac to | |
| 584 | be the default factory. It can only be called with a non-null value | |
| 585 | once per VM. If a factory has been set already, this method throws | |
| 586 | IllegalStateException. | |
| 587 | ||
| 588 | Parameters are: | |
| 589 | ||
| 590 | fac The possibly null factory to set. If null, it | |
| 591 | doesn't do anything. | |
| 592 | ||
| 593 | ||
| 594 | ||
| 595 | ||
| 596 | ||
| 597 | Expires 12/99 [Page 10] | |
| 598 | ||
| 599 | JAVA SASL API June 1999 | |
| 600 | ||
| 601 | 3.2 public interface SaslClient | |
| 602 | ||
| 603 | An object implementing this interface can negotiate authentication | |
| 604 | using one of the IANA-registered mechanisms. | |
| 605 | ||
| 606 | ||
| 607 | 3.2.1 createInitialResponse | |
| 608 | ||
| 609 | public byte[] | |
| 610 | createInitialResponse() throws SaslException | |
| 611 | ||
| 612 | This method prepares a byte array to use for the initial response to | |
| 613 | start the authentication process. A SaslException is thrown if the | |
| 614 | driver cannot initiate authentication. The return value may be | |
| 615 | null, indicating there is no initial response to send to the server. | |
| 616 | ||
| 617 | ||
| 618 | 3.2.2 evaluateChallenge | |
| 619 | ||
| 620 | public byte[] | |
| 621 | evaluateChallenge(byte[] challenge) | |
| 622 | throws SaslException | |
| 623 | ||
| 624 | If a challenge is received from the server during the authentication | |
| 625 | process, this method is called to prepare an appropriate next | |
| 626 | response to submit to the server. The response is null if the | |
| 627 | challenge accompanied a "SUCCESS" status and the challenge only | |
| 628 | contains data for the client to update its state and no response | |
| 629 | needs to be sent to the server. A SaslException is thrown if an | |
| 630 | error occurred while processing the challenge or generating a | |
| 631 | response. | |
| 632 | ||
| 633 | Parameters are: | |
| 634 | ||
| 635 | challenge The non-null challenge received from the server. | |
| 636 | ||
| 637 | ||
| 638 | 3.2.3 isComplete | |
| 639 | ||
| 640 | public boolean | |
| 641 | isComplete() | |
| 642 | ||
| 643 | This method may be called at any time to determine if the | |
| 644 | authentication process is finished. Typically, the protocol driver | |
| 645 | will not do this until it has received something from the server | |
| 646 | which indicates (in a protocol-specific manner) that the process has | |
| 647 | completed. | |
| 648 | ||
| 649 | 3.2.4 getSecurityLayer | |
| 650 | ||
| 651 | public SecurityLayer | |
| 652 | getSecurityLayer() throws SaslException | |
| 653 | ||
| 654 | ||
| 655 | ||
| 656 | ||
| 657 | Expires 12/99 [Page 11] | |
| 658 | ||
| 659 | JAVA SASL API June 1999 | |
| 660 | ||
| 661 | Once authentication is complete, this method may be called to obtain | |
| 662 | an object capable of encoding/decoding data content for the rest of | |
| 663 | the session. An exception is thrown if authentication is not yet | |
| 664 | complete. It may return null if the mechanism does not define a | |
| 665 | security layer, or if none was negotiated. | |
| 666 | ||
| 667 | ||
| 668 | 3.2.5 getMechanismName | |
| 669 | ||
| 670 | public String | |
| 671 | getMechanismName() | |
| 672 | ||
| 673 | Report the IANA-registered name of the mechanism used by this | |
| 674 | client, e.g. "GSSAPI" or "CRAM-MD5". | |
| 675 | ||
| 676 | ||
| 677 | ||
| 678 | 3.3 public interface SaslClientFactory | |
| 679 | ||
| 680 | An object implementing this interface can provide a SaslClient. | |
| 681 | Implementations must be thread-safe and handle multiple simultaneous | |
| 682 | requests. | |
| 683 | ||
| 684 | ||
| 685 | 3.3.1 createSaslClient | |
| 686 | ||
| 687 | public SaslClient | |
| 688 | createSaslClient(String[] mechanisms, | |
| 689 | String authorizationID, | |
| 690 | String protocol, | |
| 691 | String serverName, | |
| 692 | Hashtable props, | |
| 693 | javax.security.auth.callback.CallbackHandler cbh) | |
| 694 | throws SaslException | |
| 695 | ||
| 696 | Creates a SaslClient using the parameters supplied. It returns null | |
| 697 | if no SaslClient can be created using the parameters supplied. | |
| 698 | Throws SaslException if it cannot create a SaslClient because of an | |
| 699 | error. | |
| 700 | ||
| 701 | Returns a possibly null SaslClient created using the parameters | |
| 702 | supplied. If null, this factory cannot produce a SaslClient using | |
| 703 | the parameters supplied. | |
| 704 | ||
| 705 | Parameters are: | |
| 706 | ||
| 707 | mechanisms The non-null list of mechanism names to try. Each | |
| 708 | is the IANA-registered name of a SASL mechanism. | |
| 709 | (e.g. "GSSAPI", "CRAM-MD5"). | |
| 710 | ||
| 711 | authorizationID The possibly null protocol-dependent | |
| 712 | identification to be used for authorization, e.g. | |
| 713 | user name or distinguished name. When the SASL | |
| 714 | authentication completes successfully, the entity | |
| 715 | ||
| 716 | ||
| 717 | Expires 12/99 [Page 12] | |
| 718 | ||
| 719 | JAVA SASL API June 1999 | |
| 720 | ||
| 721 | named by authorizationId is granted access. If | |
| 722 | null, access is granted to a protocol-dependent | |
| 723 | default (for example, in LDAP this is the DN in | |
| 724 | the bind request). | |
| 725 | ||
| 726 | protocol The non-null string name of the protocol for | |
| 727 | which the authentication is being performed, e.g | |
| 728 | "pop", "ldap". | |
| 729 | ||
| 730 | serverName The non-null fully qualified host name of the | |
| 731 | server to authenticate to. | |
| 732 | ||
| 733 | props The possibly null properties to be used by the | |
| 734 | SASL mechanisms to configure the authentication | |
| 735 | exchange. See Sasl.createSaslClient for examples | |
| 736 | of properties. | |
| 737 | ||
| 738 | cbh The possibly null callback handler to used by the | |
| 739 | SASL mechanisms to get further information from | |
| 740 | the application/library to complete the | |
| 741 | authentication. For example, a SASL mechanism | |
| 742 | might require the authentication ID and password | |
| 743 | from the caller. The authentication ID may be | |
| 744 | requested with a NameCallback, and the password | |
| 745 | with a PasswordCallback. | |
| 746 | ||
| 747 | ||
| 748 | ||
| 749 | 3.3.2 getMechanismNames | |
| 750 | ||
| 751 | public String[] | |
| 752 | getMechanismNames() | |
| 753 | ||
| 754 | Returns a non-null array of names of mechanisms supported by this | |
| 755 | factory. | |
| 756 | ||
| 757 | ||
| 758 | 3.4 public interface SaslServer | |
| 759 | ||
| 760 | An object implementing this interface can negotiate authentication | |
| 761 | using one of the IANA-registered mechanisms. | |
| 762 | ||
| 763 | ||
| 764 | 3.4.1 evaluateResponse | |
| 765 | ||
| 766 | public byte[] | |
| 767 | evaluateResponse(byte[] response) | |
| 768 | throws SaslException | |
| 769 | ||
| 770 | If a response is received from the client during the authentication | |
| 771 | process, this method is called to prepare an appropriate next | |
| 772 | challenge to submit to the client. The challenge is null if the | |
| 773 | authentication has succeeded and no more challenge data is to be | |
| 774 | sent to the client. It is non-null if the authentication must be | |
| 775 | ||
| 776 | ||
| 777 | Expires 12/99 [Page 13] | |
| 778 | ||
| 779 | JAVA SASL API June 1999 | |
| 780 | ||
| 781 | continued by sending a challenge to the client, or if the | |
| 782 | authentication has succeeded but challenge data needs to be | |
| 783 | processed by the client. A SaslException is thrown if an error | |
| 784 | occurred while processing the response or generating a challenge. | |
| 785 | isComplete() should be called after each call to evaluateResponse(), | |
| 786 | to determine if any further response is needed from the client. The | |
| 787 | protocol driver will send an indication (in a protocol-specific | |
| 788 | manner) as to whether the authentication has succeeded, failed, or | |
| 789 | should be continued, and any accompanying challenge data. | |
| 790 | ||
| 791 | Parameters are: | |
| 792 | ||
| 793 | response Non-null response received from client. | |
| 794 | ||
| 795 | ||
| 796 | 3.4.2 isComplete | |
| 797 | ||
| 798 | public boolean | |
| 799 | isComplete() | |
| 800 | ||
| 801 | This method may be called at any time to determine if the | |
| 802 | authentication process is finished. This method is typically called | |
| 803 | after each invocation of evaluateResponse() to determine whether the | |
| 804 | authentication has completed successfully or should be continued. | |
| 805 | ||
| 806 | ||
| 807 | 3.4.3 getSecurityLayer | |
| 808 | ||
| 809 | public SecurityLayer | |
| 810 | getSecurityLayer() throws SaslException | |
| 811 | ||
| 812 | Once authentication is complete, this method may be called to obtain | |
| 813 | an object capable of encoding/decoding data content for the rest of | |
| 814 | the session. An exception is thrown if authentication is not yet | |
| 815 | complete. It may return null if the mechanism does not define a | |
| 816 | security layer, or if none was negotiated. | |
| 817 | ||
| 818 | ||
| 819 | 3.4.4 getMechanismName | |
| 820 | ||
| 821 | public String | |
| 822 | getMechanismName() | |
| 823 | ||
| 824 | Returns the non-null IANA-registered name of the mechanism used by | |
| 825 | this server, e.g. "GSSAPI" or "CRAM-MD5". | |
| 826 | ||
| 827 | ||
| 828 | 3.4.5 getAuthorizationID | |
| 829 | ||
| 830 | public String | |
| 831 | getAuthorizationID() | |
| 832 | ||
| 833 | Report the authorization ID in effect for the client of this | |
| 834 | session. If null, a protocol-dependent default is assumed. | |
| 835 | ||
| 836 | ||
| 837 | Expires 12/99 [Page 14] | |
| 838 | ||
| 839 | JAVA SASL API June 1999 | |
| 840 | ||
| 841 | ||
| 842 | ||
| 843 | ||
| 844 | 3.5 public interface SaslServerFactory | |
| 845 | ||
| 846 | An object implementing this interface can provide a SaslServer. | |
| 847 | Implementations must be thread-safe and handle multiple simultaneous | |
| 848 | requests. | |
| 849 | ||
| 850 | ||
| 851 | 3.5.1 createSaslServer | |
| 852 | ||
| 853 | public SaslServer | |
| 854 | createSaslServer(String mechanism, | |
| 855 | String protocol, | |
| 856 | String serverName, | |
| 857 | Hashtable props, | |
| 858 | javax.security.auth.callback.CallbackHandler cbh) | |
| 859 | throws SaslException | |
| 860 | ||
| 861 | Creates a SaslServer using the mechanism supplied. It returns null | |
| 862 | if no SaslClient can be created using the parameters supplied. | |
| 863 | Throws SaslException if it cannot create a SaslClient because of an | |
| 864 | error. | |
| 865 | ||
| 866 | Returns a possibly null SaslServer which supports the specified | |
| 867 | mechanism. If null, this factory cannot produce a SaslServer for the | |
| 868 | specified mechanism. | |
| 869 | ||
| 870 | Parameters are: | |
| 871 | ||
| 872 | mechanism The non-null IANA-registered name of a SASL | |
| 873 | mechanism (e.g. "GSSAPI", "CRAM-MD5"). | |
| 874 | ||
| 875 | protocol The non-null string name of the protocol for | |
| 876 | which the authentication is being performed, e.g | |
| 877 | "pop", "ldap". | |
| 878 | ||
| 879 | serverName The non-null fully qualified host name of the | |
| 880 | server. | |
| 881 | ||
| 882 | props The possibly null properties to be used by the | |
| 883 | SASL mechanisms to configure the authentication | |
| 884 | exchange. See Sasl.createSaslClient for examples | |
| 885 | of properties. | |
| 886 | ||
| 887 | cbh The possibly null callback handler to used by the | |
| 888 | SASL mechanisms to get further information from | |
| 889 | the application/library to complete the | |
| 890 | authentication. For example, a SASL mechanism | |
| 891 | might require the authentication ID and password | |
| 892 | from the caller. The authentication ID may be | |
| 893 | requested with a NameCallback, and the password | |
| 894 | with a PasswordCallback. | |
| 895 | ||
| 896 | ||
| 897 | Expires 12/99 [Page 15] | |
| 898 | ||
| 899 | JAVA SASL API June 1999 | |
| 900 | ||
| 901 | ||
| 902 | ||
| 903 | 3.5.2 getMechanismNames | |
| 904 | ||
| 905 | public String[] | |
| 906 | getMechanismNames() | |
| 907 | ||
| 908 | Returns a non-null array of names of mechanisms supported by this | |
| 909 | factory. | |
| 910 | ||
| 911 | ||
| 912 | 3.6 public class SaslException | |
| 913 | extends IOException | |
| 914 | ||
| 915 | Exception thrown on errors and failures in authentication. | |
| 916 | ||
| 917 | ||
| 918 | 3.6.1 Constructors | |
| 919 | ||
| 920 | public SaslException() | |
| 921 | ||
| 922 | Constructs a new instance of SaslException. The root exception and | |
| 923 | the detailed message are null. | |
| 924 | ||
| 925 | ||
| 926 | public SaslException(String message) | |
| 927 | ||
| 928 | ||
| 929 | Constructs a default exception with a detailed message and no root | |
| 930 | exception. | |
| 931 | ||
| 932 | ||
| 933 | public SaslException(String messag, | |
| 934 | Throwable ex) | |
| 935 | ||
| 936 | Constructs a new instance of SaslException with a detailed message | |
| 937 | and a root exception. For example, a SaslException might result from | |
| 938 | a problem with the callback handler, which might throw a | |
| 939 | NoSuchCallbackException if it does not support the requested | |
| 940 | callback, or throw an IOException if it had problems obtaining data | |
| 941 | for the callback. The SaslException's root exception would be then | |
| 942 | be the exception thrown by the callback handler. | |
| 943 | ||
| 944 | ||
| 945 | Parameters are: | |
| 946 | ||
| 947 | message Possibly null additional detail about the | |
| 948 | exception. | |
| 949 | ||
| 950 | ex A possibly null root exception that caused this | |
| 951 | exception. | |
| 952 | ||
| 953 | ||
| 954 | ||
| 955 | ||
| 956 | ||
| 957 | Expires 12/99 [Page 16] | |
| 958 | ||
| 959 | JAVA SASL API June 1999 | |
| 960 | ||
| 961 | 3.6.2 getException | |
| 962 | ||
| 963 | public Throwable | |
| 964 | getException() | |
| 965 | ||
| 966 | Returns the possibly null root exception that caused this exception. | |
| 967 | ||
| 968 | ||
| 969 | 3.6.3 printStackTrace | |
| 970 | ||
| 971 | public void | |
| 972 | printStackTrace() | |
| 973 | ||
| 974 | Prints this exception's stack trace to System.err. If this | |
| 975 | exception has a root exception, the stack trace of the root | |
| 976 | exception is printed to System.err instead. | |
| 977 | ||
| 978 | public void | |
| 979 | printStackTrace(PrintStream ps) | |
| 980 | ||
| 981 | Prints this exception's stack trace to a print stream. If this | |
| 982 | exception has a root exception, the stack trace of the root | |
| 983 | exception is printed to the print stream instead. | |
| 984 | ||
| 985 | public void | |
| 986 | printStackTrace(PrintWriter pw) | |
| 987 | ||
| 988 | Prints this exception's stack trace to a print writer. If this | |
| 989 | exception has a root exception, the stack trace of the root | |
| 990 | exception is printed to the print writer instead. | |
| 991 | ||
| 992 | Parameters are: | |
| 993 | ||
| 994 | ps The non-null print stream to which to print. | |
| 995 | ||
| 996 | pw The non-null print writer to which to print. | |
| 997 | ||
| 998 | ||
| 999 | 3.7 public interface SecurityLayer | |
| 1000 | ||
| 1001 | An object implementing this interface translates buffers back and | |
| 1002 | forth during a session, after the authentication process has | |
| 1003 | completed, to provide a security layer. The security layer may | |
| 1004 | provide data integrity and/or session privacy. | |
| 1005 | ||
| 1006 | ||
| 1007 | 3.7.1 encode | |
| 1008 | ||
| 1009 | public byte[] | |
| 1010 | encode(byte[] inVals, int offset, int count) throws SASLException | |
| 1011 | ||
| 1012 | Take a protocol-dependent byte array and encode it (encrypt, for | |
| 1013 | example) for sending to the server. | |
| 1014 | ||
| 1015 | ||
| 1016 | ||
| 1017 | Expires 12/99 [Page 17] | |
| 1018 | ||
| 1019 | JAVA SASL API June 1999 | |
| 1020 | ||
| 1021 | ||
| 1022 | Parameters are: | |
| 1023 | ||
| 1024 | inVals A request to be encoded before sending to the | |
| 1025 | server. | |
| 1026 | ||
| 1027 | offset The inclusive starting offset in the byte array | |
| 1028 | inVals to use. 0 <= offset < inVals.length. | |
| 1029 | ||
| 1030 | count The number of bytes in inVals to use. | |
| 1031 | 0 <= count < inVals.length-offset. | |
| 1032 | ||
| 1033 | ||
| 1034 | 3.7.2 decode | |
| 1035 | ||
| 1036 | public byte[] | |
| 1037 | decode(byte[] outVals, int offset, int count) throws SASLException | |
| 1038 | ||
| 1039 | Take an encoded byte array received from the server and decode it. | |
| 1040 | ||
| 1041 | Parameters are: | |
| 1042 | ||
| 1043 | outVals A response received from the server, to be | |
| 1044 | decoded. | |
| 1045 | ||
| 1046 | offset The inclusive starting offset in the byte array | |
| 1047 | outVals to use. 0 <= offset < outVals.length. | |
| 1048 | ||
| 1049 | count The number of bytes in outVals to use. | |
| 1050 | 0 <= count < outVals.length-offset. | |
| 1051 | ||
| 1052 | ||
| 1053 | ||
| 1054 | ||
| 1055 | ||
| 1056 | ||
| 1057 | ||
| 1058 | ||
| 1059 | ||
| 1060 | ||
| 1061 | ||
| 1062 | ||
| 1063 | ||
| 1064 | ||
| 1065 | ||
| 1066 | ||
| 1067 | ||
| 1068 | ||
| 1069 | ||
| 1070 | ||
| 1071 | ||
| 1072 | ||
| 1073 | ||
| 1074 | ||
| 1075 | ||
| 1076 | ||
| 1077 | Expires 12/99 [Page 18] | |
| 1078 | ||
| 1079 | JAVA SASL API June 1999 | |
| 1080 | ||
| 1081 | 4 Security Considerations | |
| 1082 | ||
| 1083 | When SASL authentication is performed over unsecured connections, it | |
| 1084 | is possible for an active attacker to spoof the server's protocol- | |
| 1085 | specific indication that authentication is complete. Clients should | |
| 1086 | protect against this attack by verifying the completion of | |
| 1087 | authentication with the mechanism driver by calling the driver's | |
| 1088 | isComplete() method. | |
| 1089 | ||
| 1090 | Additional security considerations are discussed in [SASL]. | |
| 1091 | ||
| 1092 | ||
| 1093 | 5 Bibliography | |
| 1094 | ||
| 1095 | [JAAS] Java Software, Sun Microsystems, Inc., "Java Authentication | |
| 1096 | and Authorization Service," http://java.sun.com/security/jaas, | |
| 1097 | March 1999. | |
| 1098 | ||
| 1099 | [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)", | |
| 1100 | RFC 2222, October 1997 | |
| 1101 | ||
| 1102 | ||
| 1103 | 6 Authors' Addresses | |
| 1104 | ||
| 1105 | Rob Weltman | |
| 1106 | Netscape Communications Corp. | |
| 1107 | 501 E. Middlefield Rd. | |
| 1108 | Mail Stop MV-029 | |
| 1109 | Mountain View, CA 94043-4042 | |
| 1110 | USA | |
| 1111 | Email: rweltman@netscape.com | |
| 1112 | ||
| 1113 | Rosanna Lee | |
| 1114 | Sun Microsystems | |
| 1115 | Mail Stop UCUP02-206 | |
| 1116 | 901 San Antonio Road | |
| 1117 | Palo Alto, CA 94303 | |
| 1118 | USA | |
| 1119 | Email: rosanna.lee@eng.sun.com | |
| 1120 | ||
| 1121 | Rob Earhart | |
| 1122 | Carnegie Mellon | |
| 1123 | 5000 Forbes Ave. | |
| 1124 | Pittsburgh, PA 15213-3890 | |
| 1125 | USA | |
| 1126 | Email: earhart@cmu.edu | |
| 1127 | ||
| 1128 | ||
| 1129 | 7 Acknowledgements | |
| 1130 | ||
| 1131 | Scott Seligman of Sun Microsystems, Inc. contributed to the | |
| 1132 | architecture and API proposed in this document. | |
| 1133 | ||
| 1134 | ||
| 1135 | ||
| 1136 | ||
| 1137 | Expires 12/99 [Page 19] | |
| 1138 | ||
| 1139 | JAVA SASL API June 1999 | |
| 1140 | ||
| 1141 | 8 Appendix A - Sample java LDAP program using SASL | |
| 1142 | ||
| 1143 | /**************************************************************** | |
| 1144 | It might look like this in LDAP. The Protocol Driver is | |
| 1145 | implemented as part of the authenticate method of | |
| 1146 | LDAPConnection. | |
| 1147 | ****************************************************************/ | |
| 1148 | ||
| 1149 | public class LDAPConnection { | |
| 1150 | public void authenticate( String dn, | |
| 1151 | String[] mechs, | |
| 1152 | Hashtable props, | |
| 1153 | CallbackHandler cbh ) | |
| 1154 | throws SaslException { | |
| 1155 | ||
| 1156 | // Create SASL client to use for authentication | |
| 1157 | SaslClient saslClnt = Sasl.createSaslClient( | |
| 1158 | mechs, dn, "ldap", getHost(), props, cbh); | |
| 1159 | ||
| 1160 | if (saslClnt == null) { | |
| 1161 | throw new SaslException("SASL client not available"); | |
| 1162 | } | |
| 1163 | ||
| 1164 | String mechName = saslClnt.getMechanismName(); | |
| 1165 | byte[] response = saslClnt.createInitialResponse(); | |
| 1166 | ||
| 1167 | // Create a bind request message, including the initial | |
| 1168 | ||
| 1169 | // response (if any), and send it off | |
| 1170 | ||
| 1171 | LDAPSASLBindResponse msg = | |
| 1172 | ||
| 1173 | writeRequest( new LDAPSASLBindRequest( dn, mechName, | |
| 1174 | ||
| 1175 | response ) ); | |
| 1176 | ||
| 1177 | // Get the server challenge | |
| 1178 | LDAPSASLBindResponse msg = (LDAPSASLBindResponse)readResponse(); | |
| 1179 | // Authentication done? | |
| 1180 | while (!saslClnt.isComplete() && | |
| 1181 | msg.getStatus() == LDAP_SASL_BIND_IN_PROGRESS) { | |
| 1182 | // No, get an appropriate next response and send it off | |
| 1183 | byte[] challenge = msg.getChallenge(); | |
| 1184 | response = saslClnt.evaluateChallenge( challenge ); | |
| 1185 | // May be a success message with no further challenge | |
| 1186 | if ( response != null ) { | |
| 1187 | // Wrap the response in another bind request and | |
| 1188 | // send it off | |
| 1189 | writeRequest( new LDAPSASLBindRequest( dn, | |
| 1190 | mechName, response ) ); | |
| 1191 | msg = (LDAPSASLBindResponse)readResponse(); | |
| 1192 | } | |
| 1193 | } | |
| 1194 | // Make sure authentication REALLY is complete | |
| 1195 | if ( !driver.isComplete() ) { | |
| 1196 | /* Authentication session hijacked! */ | |
| 1197 | throw new SaslException( "SASL session hijacked!" ); | |
| 1198 | } | |
| 1199 | // Get the negotiated security layer, if any | |
| 1200 | ||
| 1201 | ||
| 1202 | Expires 12/99 [Page 20] | |
| 1203 | ||
| 1204 | JAVA SASL API June 1999 | |
| 1205 | ||
| 1206 | security = saslClnt.getSecurityLayer(); | |
| 1207 | ||
| 1208 | } | |
| 1209 | ||
| 1210 | ||
| 1211 | ||
| 1212 | ||
| 1213 | ||
| 1214 | ||
| 1215 | ||
| 1216 | ||
| 1217 | ||
| 1218 | ||
| 1219 | ||
| 1220 | ||
| 1221 | ||
| 1222 | ||
| 1223 | ||
| 1224 | ||
| 1225 | ||
| 1226 | ||
| 1227 | ||
| 1228 | ||
| 1229 | ||
| 1230 | ||
| 1231 | ||
| 1232 | ||
| 1233 | ||
| 1234 | ||
| 1235 | ||
| 1236 | ||
| 1237 | ||
| 1238 | ||
| 1239 | ||
| 1240 | ||
| 1241 | ||
| 1242 | ||
| 1243 | ||
| 1244 | ||
| 1245 | ||
| 1246 | ||
| 1247 | ||
| 1248 | ||
| 1249 | ||
| 1250 | ||
| 1251 | ||
| 1252 | ||
| 1253 | ||
| 1254 | ||
| 1255 | ||
| 1256 | ||
| 1257 | ||
| 1258 | ||
| 1259 | ||
| 1260 | ||
| 1261 | ||
| 1262 | Expires 12/99 [Page 21] | |
| 1263 | ||
| 1264 | JAVA SASL API June 1999 | |
| 1265 | ||
| 1266 | /**************************************************************** | |
| 1267 | This might be in an application | |
| 1268 | ****************************************************************/ | |
| 1269 | ||
| 1270 | /** | |
| 1271 | * A sample callback handler. This implementation is created by | |
| 1272 | * using the input that it will return. Other implementations are | |
| 1273 | * typically more sophisticated and might prompt the user on demand | |
| 1274 | * in order to satisfy the callbacks. | |
| 1275 | */ | |
| 1276 | class SimpleCallbackHandler implements CallbackHandler { | |
| 1277 | private char[] passwd; | |
| 1278 | private String authenticationID; | |
| 1279 | ||
| 1280 | SimpleCallbackHandler(String principal, Object cred) | |
| 1281 | throws IOException { | |
| 1282 | authenticationID = principal; | |
| 1283 | ||
| 1284 | if (cred instanceof String) { | |
| 1285 | passwd = ((String)cred).toCharArray(); | |
| 1286 | } else if (cred instanceof char[]) { | |
| 1287 | passwd = (char[])((char[])cred).clone(); | |
| 1288 | } else if (cred instanceof byte[]) { | |
| 1289 | // PasswordCallback expects char[]; assume UTF-8 | |
| 1290 | // encoding | |
| 1291 | String orig = new String((byte[])cred, "UTF8"); | |
| 1292 | passwd = orig.toCharArray(); | |
| 1293 | } else { | |
| 1294 | throw new IOException("Unsupported password format: " + | |
| 1295 | cred); | |
| 1296 | } | |
| 1297 | } | |
| 1298 | ||
| 1299 | public void invokeCallback(Callback[] callbacks) | |
| 1300 | throws java.io.IOException, UnsupportedCallbackException { | |
| 1301 | for (int i = 0; i < callbacks.length; i++) { | |
| 1302 | if (callbacks[i] instanceof NameCallback) { | |
| 1303 | ((NameCallback)callbacks[i]).setName( | |
| 1304 | authenticationID); | |
| 1305 | ||
| 1306 | } else if (callbacks[i] instanceof PasswordCallback) { | |
| 1307 | ((PasswordCallback)callbacks[i]).setPassword( | |
| 1308 | passwd); | |
| 1309 | } else { | |
| 1310 | throw new | |
| 1311 | UnsupportedCallbackException(callbacks[i]); | |
| 1312 | } | |
| 1313 | } | |
| 1314 | } | |
| 1315 | } | |
| 1316 | ||
| 1317 | ||
| 1318 | ||
| 1319 | ||
| 1320 | ||
| 1321 | ||
| 1322 | Expires 12/99 [Page 22] | |
| 1323 | ||
| 1324 | JAVA SASL API June 1999 | |
| 1325 | ||
| 1326 | /*************************************************************** | |
| 1327 | And so the application code to do authentication | |
| 1328 | ***************************************************************/ | |
| 1329 | ||
| 1330 | // Set up all SASL parameters; some may have reasonable defaults | |
| 1331 | Hashtable props = new Hashtable(); | |
| 1332 | props.add("javax.security.sasl.encryption.minimum", "40"); | |
| 1333 | props.add("javax.security.sasl.encryption.maximum", "128"); | |
| 1334 | props.add("javax.security.sasl.server_authentication", "true"); | |
| 1335 | props.add("javax.security.sasl.maxbuffer", "4096"); | |
| 1336 | // The following two for kerberos v4, only | |
| 1337 | //props.add("javax.security.sasl.ip.local", "192.68.1.10"); | |
| 1338 | //props.add("javax.security.sasl.ip.remote", "192.68.1.50"); | |
| 1339 | ||
| 1340 | // What we want to authenticate as | |
| 1341 | String dn = "cn=Directory Manager"; | |
| 1342 | ||
| 1343 | // Create an object for possible use by the authentication | |
| 1344 | // process | |
| 1345 | SimpleCallbackHandler cbh = new SimpleCallbackHandler(); | |
| 1346 | ||
| 1347 | try { | |
| 1348 | // Note: cbh methods may be called during authentication | |
| 1349 | // Note: "connection" includes the SASL Protocol Driver | |
| 1350 | // functionality, and it will internally manage a Mechanism | |
| 1351 | // Driver for GSSAPI, and then a Security Layer object for | |
| 1352 | // data translation | |
| 1353 | String[] mechNames = { "GSSAPI" }; | |
| 1354 | connection.authenticate( dn, mechNames, props, cbh ); | |
| 1355 | } catch ( SaslException e ) { | |
| 1356 | // Abort, return, maybe try some other authentication | |
| 1357 | } | |
| 1358 | ||
| 1359 | // Okay. From here on, everything goes through security, but the | |
| 1360 | // methods have the same signatures as if we were not using SASL | |
| 1361 | ||
| 1362 | ||
| 1363 | ||
| 1364 | ||
| 1365 | ||
| 1366 | ||
| 1367 | ||
| 1368 | ||
| 1369 | ||
| 1370 | ||
| 1371 | ||
| 1372 | ||
| 1373 | ||
| 1374 | ||
| 1375 | ||
| 1376 | ||
| 1377 | ||
| 1378 | ||
| 1379 | ||
| 1380 | ||
| 1381 | ||
| 1382 | Expires 12/99 [Page 23] | |
| 1383 | ||
| 1384 | JAVA SASL API June 1999 | |
| 1385 | ||
| 1386 | 9 Appendix B - Changes from draft-weltman-java-sasl-01.txt | |
| 1387 | ||
| 1388 | The class hierarchy defined in this document is entirely different | |
| 1389 | from that defined in the previous document. | |
| 1390 | ||
| 1391 | For callback handling, the newly released | |
| 1392 | javax.security.auth.callback package is used. | |
| 1393 | ||
| 1394 | ||
| 1395 | ||
| 1396 | ||
| 1397 | ||
| 1398 | ||
| 1399 | ||
| 1400 | ||
| 1401 | ||
| 1402 | ||
| 1403 | ||
| 1404 | ||
| 1405 | ||
| 1406 | ||
| 1407 | ||
| 1408 | ||
| 1409 | ||
| 1410 | ||
| 1411 | ||
| 1412 | ||
| 1413 | ||
| 1414 | ||
| 1415 | ||
| 1416 | ||
| 1417 | ||
| 1418 | ||
| 1419 | ||
| 1420 | ||
| 1421 | ||
| 1422 | ||
| 1423 | ||
| 1424 | ||
| 1425 | ||
| 1426 | ||
| 1427 | ||
| 1428 | ||
| 1429 | ||
| 1430 | ||
| 1431 | ||
| 1432 | ||
| 1433 | ||
| 1434 | ||
| 1435 | ||
| 1436 | ||
| 1437 | ||
| 1438 | ||
| 1439 | ||
| 1440 | ||
| 1441 | ||
| 1442 | Expires 12/99 [Page 24] | |
| 1443 | ⏎ |
| 40 | 40 | # |
| 41 | 41 | |
| 42 | 42 | # Library version info - here at the top, for sanity |
| 43 | sasl_version = 2:25:0 | |
| 43 | # See <http://www.gnu.org/software/libtool/manual/libtool.html#Versioning> | |
| 44 | # CURRENT:REVISION:AGE | |
| 45 | sasl_version = 3:0:0 | |
| 44 | 46 | |
| 45 | INCLUDES=-I$(top_srcdir)/include -I$(top_srcdir)/plugins -I$(top_builddir)/include -I$(top_srcdir)/sasldb | |
| 47 | INCLUDES=-DLIBSASL_EXPORTS=1 -I$(top_srcdir)/include -I$(top_srcdir)/plugins -I$(top_builddir)/include -I$(top_srcdir)/sasldb | |
| 46 | 48 | |
| 47 | 49 | EXTRA_DIST = windlopen.c staticopen.h NTMakefile |
| 48 | 50 | EXTRA_LIBRARIES = libsasl2.a |
| 316 | 316 | top_srcdir = @top_srcdir@ |
| 317 | 317 | |
| 318 | 318 | # Library version info - here at the top, for sanity |
| 319 | sasl_version = 2:25:0 | |
| 320 | INCLUDES = -I$(top_srcdir)/include -I$(top_srcdir)/plugins -I$(top_builddir)/include -I$(top_srcdir)/sasldb | |
| 319 | # See <http://www.gnu.org/software/libtool/manual/libtool.html#Versioning> | |
| 320 | # CURRENT:REVISION:AGE | |
| 321 | sasl_version = 3:0:0 | |
| 322 | INCLUDES = -DLIBSASL_EXPORTS=1 -I$(top_srcdir)/include -I$(top_srcdir)/plugins -I$(top_builddir)/include -I$(top_srcdir)/sasldb | |
| 321 | 323 | EXTRA_DIST = windlopen.c staticopen.h NTMakefile |
| 322 | 324 | EXTRA_LIBRARIES = libsasl2.a |
| 323 | 325 | noinst_LIBRARIES = @SASL_STATIC_LIBS@ |
| 52 | 52 | IF EXIST $@.manifest mt -manifest $@.manifest -outputresource:$@;2 |
| 53 | 53 | |
| 54 | 54 | plugin_common.c: ..\plugins\plugin_common.c plugin_common.h |
| 55 | copy ..\plugins\plugin_common.c . | |
| 55 | xcopy /D /Y ..\plugins\plugin_common.c . | |
| 56 | 56 | |
| 57 | 57 | plugin_common.h: ..\plugins\plugin_common.h |
| 58 | copy ..\plugins\plugin_common.h . | |
| 58 | xcopy /D /Y ..\plugins\plugin_common.h . | |
| 59 | 59 | |
| 60 | 60 | auxprop.obj checkpw.obj client.obj common.obj external.obj plugin_common.obj server.obj seterror.obj: ..\include\saslplug.h |
| 61 | 61 | |
| 75 | 75 | |
| 76 | 76 | $(libsasl_res): NTMakefile |
| 77 | 77 | rc /fo"$(libsasl_res)" << |
| 78 | #include "afxres.h" | |
| 78 | #include "windows.h" | |
| 79 | 79 | |
| 80 | 80 | VS_VERSION_INFO VERSIONINFO |
| 81 | 81 | FILEVERSION $(SASL_VERSION_MAJOR),$(SASL_VERSION_MINOR),$(SASL_VERSION_STEP),0 |
| 98 | 98 | VALUE "FileDescription", "CMU SASL API v2\0" |
| 99 | 99 | VALUE "FileVersion", "$(SASL_VERSION_MAJOR).$(SASL_VERSION_MINOR).$(SASL_VERSION_STEP).0\0" |
| 100 | 100 | VALUE "InternalName", "libsasl\0" |
| 101 | VALUE "LegalCopyright", "Copyright (c) Carnegie Mellon University 2002-2011\0" | |
| 101 | VALUE "LegalCopyright", "Copyright (c) Carnegie Mellon University 2002-2012\0" | |
| 102 | 102 | VALUE "OriginalFilename", "libsasl.dll\0" |
| 103 | 103 | VALUE "ProductName", "Carnegie Mellon University SASL\0" |
| 104 | 104 | VALUE "ProductVersion", "$(SASL_VERSION_MAJOR).$(SASL_VERSION_MINOR).$(SASL_VERSION_STEP)-0" |
| 240 | 240 | } |
| 241 | 241 | } |
| 242 | 242 | |
| 243 | if (result == SASL_NOUSER && (flags & SASL_CU_EXTERNALLY_VERIFIED)) { | |
| 243 | if ((flags & SASL_CU_EXTERNALLY_VERIFIED) && (result == SASL_NOUSER || result == SASL_NOMECH)) { | |
| 244 | 244 | /* The called has explicitly told us that the authentication identity |
| 245 | was already verified. So a failure to retrieve any associated properties | |
| 245 | was already verified or will be verified independently. | |
| 246 | So a failure to retrieve any associated properties | |
| 246 | 247 | is not an error. For example the caller is using Kerberos to verify user, |
| 247 | 248 | but the LDAPDB/SASLDB auxprop plugin doesn't contain any auxprops for |
| 248 | the user. */ | |
| 249 | the user. | |
| 250 | Another case is PLAIN/LOGIN not using auxprop to verify user passwords. */ | |
| 249 | 251 | result = SASL_OK; |
| 250 | 252 | } |
| 251 | 253 | } |
| 315 | 317 | &out_version, &plug, plugname); |
| 316 | 318 | |
| 317 | 319 | if(result != SASL_OK) { |
| 318 | _sasl_log(NULL, SASL_LOG_ERR, "canonuserfunc error %i\n",result); | |
| 320 | _sasl_log(NULL, SASL_LOG_ERR, "%s_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): %z\n", | |
| 321 | plugname, result); | |
| 319 | 322 | return result; |
| 320 | 323 | } |
| 321 | 324 | |
| 322 | 325 | if(!plug->canon_user_server && !plug->canon_user_client) { |
| 323 | 326 | /* We need at least one of these implemented */ |
| 324 | 327 | _sasl_log(NULL, SASL_LOG_ERR, |
| 325 | "canonuser plugin without either client or server side"); | |
| 328 | "canonuser plugin '%s' without either client or server side", plugname); | |
| 326 | 329 | return SASL_BADPROT; |
| 327 | 330 | } |
| 328 | 331 | |
| 59 | 59 | #include "saslint.h" |
| 60 | 60 | |
| 61 | 61 | static cmech_list_t *cmechlist; /* global var which holds the list */ |
| 62 | sasl_global_callbacks_t global_callbacks_client; | |
| 62 | static sasl_global_callbacks_t global_callbacks_client; | |
| 63 | 63 | static int _sasl_client_active = 0; |
| 64 | 64 | |
| 65 | 65 | static int init_mechlist() |
| 194 | 194 | if (result != SASL_OK) |
| 195 | 195 | { |
| 196 | 196 | _sasl_log(NULL, SASL_LOG_WARN, |
| 197 | "entry_point failed in sasl_client_add_plugin for %s", | |
| 198 | plugname); | |
| 197 | "sasl_client_add_plugin(): entry_point(): failed for plugname %s: %z", | |
| 198 | plugname, result); | |
| 199 | 199 | return result; |
| 200 | 200 | } |
| 201 | 201 | |
| 751 | 751 | |
| 752 | 752 | /* for each mechanism in client's list */ |
| 753 | 753 | for (m = c_conn->mech_list; m != NULL; m = m->next) { |
| 754 | int myflags, plus; | |
| 754 | unsigned myflags; | |
| 755 | int plus; | |
| 755 | 756 | |
| 756 | 757 | if (!_sasl_is_equal_mech(name, m->m.plug->mech_name, name_len, &plus)) { |
| 757 | 758 | continue; |
| 765 | 766 | if (minssf > m->m.plug->max_ssf) |
| 766 | 767 | break; |
| 767 | 768 | |
| 768 | /* Does it meet our security properties? */ | |
| 769 | 769 | myflags = conn->props.security_flags; |
| 770 | ||
| 771 | /* if there's an external layer this is no longer plaintext */ | |
| 770 | ||
| 771 | /* if there's an external layer with a better SSF then this is no | |
| 772 | * longer considered a plaintext mechanism | |
| 773 | */ | |
| 772 | 774 | if ((conn->props.min_ssf <= conn->external.ssf) && |
| 773 | 775 | (conn->external.ssf > 1)) { |
| 774 | 776 | myflags &= ~SASL_SEC_NOPLAINTEXT; |
| 775 | 777 | } |
| 776 | 778 | |
| 779 | /* Does it meet our security properties? */ | |
| 777 | 780 | if (((myflags ^ m->m.plug->security_flags) & myflags) != 0) { |
| 778 | 781 | break; |
| 779 | 782 | } |
| 0 | 0 | /* common.c - Functions that are common to server and clinet |
| 1 | 1 | * Rob Siemborski |
| 2 | 2 | * Tim Martin |
| 3 | * $Id: common.c,v 1.133 2011/09/01 14:12:53 mel Exp $ | |
| 3 | * $Id: common.c,v 1.134 2011/09/22 14:40:30 mel Exp $ | |
| 4 | 4 | */ |
| 5 | 5 | /* |
| 6 | 6 | * Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved. |
| 88 | 88 | static const char build_ident[] = "$Build: libsasl " PACKAGE "-" VERSION " $"; |
| 89 | 89 | |
| 90 | 90 | /* It turns out to be convenient to have a shared sasl_utils_t */ |
| 91 | LIBSASL_VAR const sasl_utils_t *sasl_global_utils = NULL; | |
| 91 | const sasl_utils_t *sasl_global_utils = NULL; | |
| 92 | 92 | |
| 93 | 93 | /* Should be a null-terminated array that lists the available mechanisms */ |
| 94 | 94 | static char **global_mech_list = NULL; |
| 841 | 841 | if (result!=SASL_OK) return; |
| 842 | 842 | |
| 843 | 843 | /* *pconn might have become NULL by now */ |
| 844 | if (! (*pconn)) return; | |
| 844 | if (! (*pconn)) | |
| 845 | { | |
| 846 | sasl_MUTEX_UNLOCK(free_mutex); | |
| 847 | return; | |
| 848 | } | |
| 845 | 849 | |
| 846 | 850 | (*pconn)->destroy_conn(*pconn); |
| 847 | 851 | sasl_FREE(*pconn); |
| 0 | 0 | /* SASL Config file API |
| 1 | 1 | * Rob Siemborski |
| 2 | 2 | * Tim Martin (originally in Cyrus distribution) |
| 3 | * $Id: config.c,v 1.18 2009/02/14 14:01:24 mel Exp $ | |
| 3 | * $Id: config.c,v 1.19 2011/11/08 17:22:40 murch Exp $ | |
| 4 | 4 | */ |
| 5 | 5 | /* |
| 6 | 6 | * Copyright (c) 1998-2009 Carnegie Mellon University. All rights reserved. |
| 54 | 54 | char *value; |
| 55 | 55 | }; |
| 56 | 56 | |
| 57 | static struct configlist *configlist; | |
| 58 | static int nconfiglist; | |
| 57 | static struct configlist *configlist = NULL; | |
| 58 | static int nconfiglist = 0; | |
| 59 | 59 | |
| 60 | 60 | #define CONFIGLISTGROWSIZE 100 |
| 61 | 61 | |
| 89 | 89 | p++; |
| 90 | 90 | } |
| 91 | 91 | if (*p != ':') { |
| 92 | fclose(infile); | |
| 92 | 93 | return SASL_FAIL; |
| 93 | 94 | } |
| 94 | 95 | *p++ = '\0'; |
| 96 | 97 | while (*p && isspace((int) *p)) p++; |
| 97 | 98 | |
| 98 | 99 | if (!*p) { |
| 100 | fclose(infile); | |
| 99 | 101 | return SASL_FAIL; |
| 100 | 102 | } |
| 101 | 103 | |
| 110 | 112 | alloced += CONFIGLISTGROWSIZE; |
| 111 | 113 | configlist=sasl_REALLOC((char *)configlist, |
| 112 | 114 | alloced * sizeof(struct configlist)); |
| 113 | if (configlist==NULL) return SASL_NOMEM; | |
| 115 | if (configlist == NULL) { | |
| 116 | fclose(infile); | |
| 117 | return SASL_NOMEM; | |
| 118 | } | |
| 114 | 119 | } |
| 115 | 120 | |
| 116 | 121 | result = _sasl_strdup(key, |
| 117 | 122 | &(configlist[nconfiglist].key), |
| 118 | 123 | NULL); |
| 119 | if (result!=SASL_OK) return result; | |
| 124 | if (result != SASL_OK) { | |
| 125 | fclose(infile); | |
| 126 | return result; | |
| 127 | } | |
| 120 | 128 | result = _sasl_strdup(p, |
| 121 | 129 | &(configlist[nconfiglist].value), |
| 122 | 130 | NULL); |
| 123 | if (result!=SASL_OK) return result; | |
| 131 | if (result != SASL_OK) { | |
| 132 | fclose(infile); | |
| 133 | return result; | |
| 134 | } | |
| 124 | 135 | |
| 125 | 136 | nconfiglist++; |
| 126 | 137 | } |
| 140 | 151 | } |
| 141 | 152 | return def; |
| 142 | 153 | } |
| 154 | ||
| 155 | void sasl_config_done(void) | |
| 156 | { | |
| 157 | int opt; | |
| 158 | ||
| 159 | for (opt = 0; opt < nconfiglist; opt++) { | |
| 160 | if (configlist[opt].key) sasl_FREE(configlist[opt].key); | |
| 161 | if (configlist[opt].value) sasl_FREE(configlist[opt].value); | |
| 162 | } | |
| 163 | ||
| 164 | sasl_FREE(configlist); | |
| 165 | configlist = NULL; | |
| 166 | nconfiglist = 0; | |
| 167 | } | |
| 117 | 117 | const char *appname; |
| 118 | 118 | } sasl_global_callbacks_t; |
| 119 | 119 | |
| 120 | extern sasl_global_callbacks_t global_callbacks; | |
| 121 | ||
| 122 | 120 | typedef struct _sasl_external_properties |
| 123 | 121 | { |
| 124 | 122 | sasl_ssf_t ssf; |
| 0 | 0 | /* saslutil.c |
| 1 | 1 | * Rob Siemborski |
| 2 | 2 | * Tim Martin |
| 3 | * $Id: saslutil.c,v 1.51 2010/12/01 14:25:53 mel Exp $ | |
| 3 | * $Id: saslutil.c,v 1.52 2011/09/22 14:43:01 mel Exp $ | |
| 4 | 4 | */ |
| 5 | 5 | /* |
| 6 | 6 | * Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved. |
| 435 | 435 | srandom(*foo); |
| 436 | 436 | } |
| 437 | 437 | #endif /* HAVE_JRAND48 */ |
| 438 | #else if defined(WIN32) | |
| 438 | #elif defined(WIN32) | |
| 439 | 439 | { |
| 440 | 440 | unsigned int *foo = (unsigned int *)rpool->pool; |
| 441 | 441 | srand(*foo); |
| 448 | 448 | void sasl_rand (sasl_rand_t *rpool, char *buf, unsigned len) |
| 449 | 449 | { |
| 450 | 450 | unsigned int lup; |
| 451 | #if defined(WIN32) | |
| 451 | #if defined(WIN32) && !defined(__MINGW32__) | |
| 452 | 452 | unsigned int randomValue; |
| 453 | 453 | #endif |
| 454 | 454 | |
| 459 | 459 | randinit(rpool); |
| 460 | 460 | |
| 461 | 461 | for (lup = 0; lup < len; lup++) { |
| 462 | #if defined(WIN32) | |
| 462 | #if defined(__MINGW32__) | |
| 463 | buf[lup] = (char) (rand() >> 8); | |
| 464 | #elif defined(WIN32) | |
| 463 | 465 | if (rand_s(&randomValue) != 0) { |
| 464 | 466 | randomValue = rand(); |
| 465 | 467 | } |
| 554 | 556 | NULL, /* don't care abour service/port */ |
| 555 | 557 | &hints, |
| 556 | 558 | &result) != 0) { |
| 557 | /* errno on Unix, WSASetLastError on Windows are already done by the function */ | |
| 558 | return (-1); | |
| 559 | } | |
| 560 | ||
| 561 | if (abort_if_no_fqdn && (result == NULL || result->ai_canonname == NULL)) { | |
| 559 | if (abort_if_no_fqdn) { | |
| 560 | /* errno on Unix, WSASetLastError on Windows are already done by the function */ | |
| 561 | return (-1); | |
| 562 | } else { | |
| 563 | goto LOWERCASE; | |
| 564 | } | |
| 565 | } | |
| 566 | ||
| 567 | if (result == NULL || result->ai_canonname == NULL) { | |
| 562 | 568 | freeaddrinfo (result); |
| 569 | if (abort_if_no_fqdn) { | |
| 563 | 570 | #ifdef WIN32 |
| 564 | WSASetLastError (WSANO_DATA); | |
| 571 | WSASetLastError (WSANO_DATA); | |
| 565 | 572 | #elif defined(ENODATA) |
| 566 | errno = ENODATA; | |
| 573 | errno = ENODATA; | |
| 567 | 574 | #elif defined(EADDRNOTAVAIL) |
| 568 | errno = EADDRNOTAVAIL; | |
| 569 | #endif | |
| 570 | return (-1); | |
| 571 | } | |
| 572 | ||
| 573 | if (abort_if_no_fqdn && strchr (result->ai_canonname, '.') == NULL) { | |
| 575 | errno = EADDRNOTAVAIL; | |
| 576 | #endif | |
| 577 | return (-1); | |
| 578 | } else { | |
| 579 | goto LOWERCASE; | |
| 580 | } | |
| 581 | } | |
| 582 | ||
| 583 | if (strchr (result->ai_canonname, '.') == NULL) { | |
| 574 | 584 | freeaddrinfo (result); |
| 585 | if (abort_if_no_fqdn) { | |
| 575 | 586 | #ifdef WIN32 |
| 576 | WSASetLastError (WSANO_DATA); | |
| 587 | WSASetLastError (WSANO_DATA); | |
| 577 | 588 | #elif defined(ENODATA) |
| 578 | errno = ENODATA; | |
| 589 | errno = ENODATA; | |
| 579 | 590 | #elif defined(EADDRNOTAVAIL) |
| 580 | errno = EADDRNOTAVAIL; | |
| 581 | #endif | |
| 582 | return (-1); | |
| 591 | errno = EADDRNOTAVAIL; | |
| 592 | #endif | |
| 593 | return (-1); | |
| 594 | } else { | |
| 595 | goto LOWERCASE; | |
| 596 | } | |
| 583 | 597 | } |
| 584 | 598 | |
| 585 | 599 | |
| 0 | 0 | /* SASL server API implementation |
| 1 | 1 | * Rob Siemborski |
| 2 | 2 | * Tim Martin |
| 3 | * $Id: server.c,v 1.176 2011/09/01 16:33:10 mel Exp $ | |
| 3 | * $Id: server.c,v 1.177 2011/11/08 17:22:40 murch Exp $ | |
| 4 | 4 | */ |
| 5 | 5 | /* |
| 6 | 6 | * Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved. |
| 89 | 89 | |
| 90 | 90 | static mech_list_t *mechlist = NULL; /* global var which holds the list */ |
| 91 | 91 | |
| 92 | sasl_global_callbacks_t global_callbacks; | |
| 92 | static sasl_global_callbacks_t global_callbacks; | |
| 93 | 93 | |
| 94 | 94 | /* set the password for a user |
| 95 | 95 | * conn -- SASL connection |
| 439 | 439 | if ((result != SASL_OK) && (result != SASL_NOUSER) |
| 440 | 440 | && (result != SASL_CONTINUE)) { |
| 441 | 441 | _sasl_log(NULL, SASL_LOG_DEBUG, |
| 442 | "server add_plugin entry_point error %z\n", result); | |
| 442 | "%s_client_plug_init() failed in sasl_server_add_plugin(): %z\n", | |
| 443 | plugname, result); | |
| 443 | 444 | return result; |
| 444 | 445 | } |
| 445 | 446 | |
| 448 | 449 | { |
| 449 | 450 | _sasl_log(NULL, |
| 450 | 451 | SASL_LOG_ERR, |
| 451 | "version mismatch on plugin: %d expected, but %d reported", | |
| 452 | "version mismatch on sasl_server_add_plugin for '%s': %d expected, but %d reported", | |
| 453 | plugname, | |
| 452 | 454 | SASL_SERVER_PLUG_VERSION, |
| 453 | 455 | version); |
| 454 | 456 | return SASL_BADVERS; |
| 562 | 564 | |
| 563 | 565 | global_callbacks.callbacks = NULL; |
| 564 | 566 | global_callbacks.appname = NULL; |
| 567 | ||
| 568 | sasl_config_done(); | |
| 565 | 569 | |
| 566 | 570 | return SASL_OK; |
| 567 | 571 | } |
| 0 | libdir = @libdir@ | |
| 1 | ||
| 2 | Name: Cyrus SASL | |
| 3 | Description: Cyrus SASL implementation | |
| 4 | URL: http://www.cyrussasl.org/ | |
| 5 | Version: @VERSION@ | |
| 6 | Libs: -L${libdir} -lsasl2 | |
| 7 | Libs.private: @LIB_DOOR@ @SASL_DL_LIB@ @LIBS@ |
| 40 | 40 | * $ ⏎ |
| 41 | 41 | */ ⏎ |
| 42 | 42 | ⏎ |
| 43 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/CredentialsCache/CredentialsCache.h,v 1.2 2001/12/04 02:05:36 rjs3 Exp $ */ ⏎ | |
| 43 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/CredentialsCache/CredentialsCache.h,v 1.2 2001/12/04 02:05:36 rjs3 Exp $ */ ⏎ | |
| 44 | 44 | ⏎ |
| 45 | 45 | /* ⏎ |
| 46 | 46 | * Declarations for Credentials Cache API Library ⏎ |
| 1 | 1 | * KClient 3.0 API declarations ⏎ |
| 2 | 2 | * See KClient30-API.html ⏎ |
| 3 | 3 | * ⏎ |
| 4 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KClient/KClient.h,v 1.2 2001/12/04 02:05:38 rjs3 Exp $ ⏎ | |
| 4 | * $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KClient/KClient.h,v 1.2 2001/12/04 02:05:38 rjs3 Exp $ ⏎ | |
| 5 | 5 | */ ⏎ |
| 6 | 6 | ⏎ |
| 7 | 7 | #ifndef __KCLIENT__ ⏎ |
| 0 | 0 | /* ⏎ |
| 1 | 1 | * KClient 1.9 deprecated API ⏎ |
| 2 | 2 | * ⏎ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KClientCompat/KClientCompat.h,v 1.2 2001/12/04 02:05:40 rjs3 Exp $ ⏎ | |
| 3 | * $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KClientCompat/KClientCompat.h,v 1.2 2001/12/04 02:05:40 rjs3 Exp $ ⏎ | |
| 4 | 4 | */ ⏎ |
| 5 | 5 | ⏎ |
| 6 | 6 | #ifndef __KCLIENTCOMPAT__ ⏎ |
| 0 | 0 | /* ⏎ |
| 1 | 1 | * KClient 1.9 deprecated API ⏎ |
| 2 | 2 | * ⏎ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KClientDeprecated/KClientDeprecated.h,v 1.2 2001/12/04 02:05:41 rjs3 Exp $ ⏎ | |
| 3 | * $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KClientDeprecated/KClientDeprecated.h,v 1.2 2001/12/04 02:05:41 rjs3 Exp $ ⏎ | |
| 4 | 4 | */ ⏎ |
| 5 | 5 | ⏎ |
| 6 | 6 | #ifndef __KCLIENTDEPRECATED__ ⏎ |
| 0 | 0 | /* ⏎ |
| 1 | 1 | * Kerberos Framework Header File ⏎ |
| 2 | 2 | * ⏎ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/Kerberos/Kerberos.h,v 1.2 2001/12/04 02:05:45 rjs3 Exp $ ⏎ | |
| 3 | * $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/Kerberos/Kerberos.h,v 1.2 2001/12/04 02:05:45 rjs3 Exp $ ⏎ | |
| 4 | 4 | */ ⏎ |
| 5 | 5 | ⏎ |
| 6 | 6 | #ifndef __KERBEROS__ ⏎ |
| 0 | 0 | /* ⏎ |
| 1 | 1 | * KerberosLogin.h ⏎ |
| 2 | 2 | * ⏎ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosLogin/KerberosLogin.h,v 1.2 2001/12/04 02:05:52 rjs3 Exp $ ⏎ | |
| 3 | * $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosLogin/KerberosLogin.h,v 1.2 2001/12/04 02:05:52 rjs3 Exp $ ⏎ | |
| 4 | 4 | * ⏎ |
| 5 | 5 | */ ⏎ |
| 6 | 6 | ⏎ |
| 40 | 40 | * $ ⏎ |
| 41 | 41 | */ ⏎ |
| 42 | 42 | ⏎ |
| 43 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosManager/KerberosManagerLib.h,v 1.2 2001/12/04 02:05:53 rjs3 Exp $ */ ⏎ | |
| 43 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosManager/KerberosManagerLib.h,v 1.2 2001/12/04 02:05:53 rjs3 Exp $ */ ⏎ | |
| 44 | 44 | ⏎ |
| 45 | 45 | #pragma once ⏎ |
| 46 | 46 | ⏎ |
| 35 | 35 | * $ ⏎ |
| 36 | 36 | */ ⏎ |
| 37 | 37 | ⏎ |
| 38 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosPreferences/KerberosPreferences.h,v 1.2 2001/12/04 02:05:54 rjs3 Exp $ */ ⏎ | |
| 38 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosPreferences/KerberosPreferences.h,v 1.2 2001/12/04 02:05:54 rjs3 Exp $ */ ⏎ | |
| 39 | 39 | ⏎ |
| 40 | 40 | /* ⏎ |
| 41 | 41 | * ⏎ |
| 35 | 35 | * $ ⏎ |
| 36 | 36 | */ ⏎ |
| 37 | 37 | ⏎ |
| 38 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/ErrorLib.h,v 1.2 2001/12/04 02:05:56 rjs3 Exp $ */ ⏎ | |
| 38 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/ErrorLib.h,v 1.2 2001/12/04 02:05:56 rjs3 Exp $ */ ⏎ | |
| 39 | 39 | ⏎ |
| 40 | 40 | /* ⏎ |
| 41 | 41 | * ⏎ |
| 35 | 35 | * $ ⏎ |
| 36 | 36 | */ ⏎ |
| 37 | 37 | ⏎ |
| 38 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/ErrorList.r,v 1.2 2001/12/04 02:05:56 rjs3 Exp $ */ ⏎ | |
| 38 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/ErrorList.r,v 1.2 2001/12/04 02:05:56 rjs3 Exp $ */ ⏎ | |
| 39 | 39 | ⏎ |
| 40 | 40 | type 'ErrT' { ⏎ |
| 41 | 41 | integer = $$CountOf (ErrorTable); // Number of errors in the table ⏎ |
| 35 | 35 | * $ ⏎ |
| 36 | 36 | */ ⏎ |
| 37 | 37 | ⏎ |
| 38 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/Idle.h,v 1.2 2001/12/04 02:05:56 rjs3 Exp $ */ ⏎ | |
| 38 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/Idle.h,v 1.2 2001/12/04 02:05:56 rjs3 Exp $ */ ⏎ | |
| 39 | 39 | ⏎ |
| 40 | 40 | /* ⏎ |
| 41 | 41 | * ⏎ |
| 35 | 35 | * $ ⏎ |
| 36 | 36 | */ ⏎ |
| 37 | 37 | ⏎ |
| 38 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/SocketErrors.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 38 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/SocketErrors.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 39 | 39 | ⏎ |
| 40 | 40 | /* ⏎ |
| 41 | 41 | * ⏎ |
| 35 | 35 | * $ ⏎ |
| 36 | 36 | */ ⏎ |
| 37 | 37 | ⏎ |
| 38 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/Sockets.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 38 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/Sockets.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 39 | 39 | ⏎ |
| 40 | 40 | /* ⏎ |
| 41 | 41 | * ⏎ |
| 35 | 35 | * $ ⏎ |
| 36 | 36 | */ ⏎ |
| 37 | 37 | ⏎ |
| 38 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/Utilities.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 38 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/Utilities.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 39 | 39 | ⏎ |
| 40 | 40 | /* ⏎ |
| 41 | 41 | * Utilities.h - Public header file for the Utilities library ⏎ |
| 35 | 35 | * $ ⏎ |
| 36 | 36 | */ ⏎ |
| 37 | 37 | ⏎ |
| 38 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/netdb.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 38 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/netdb.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 39 | 39 | ⏎ |
| 40 | 40 | /* MIT Sockets Library ⏎ |
| 41 | 41 | * netdb.h ⏎ |
| 35 | 35 | * $ ⏎ |
| 36 | 36 | */ ⏎ |
| 37 | 37 | ⏎ |
| 38 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/pwd.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 38 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/KerberosSupport/pwd.h,v 1.2 2001/12/04 02:05:57 rjs3 Exp $ */ ⏎ | |
| 39 | 39 | ⏎ |
| 40 | 40 | /* pwd.h -- struct passwd */ ⏎ |
| 41 | 41 | ⏎ |
| 40 | 40 | * $ ⏎ |
| 41 | 41 | */ ⏎ |
| 42 | 42 | ⏎ |
| 43 | /* $Header: /afs/andrew/system/cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/TicketKeeper/TicketKeeper.h,v 1.2 2001/12/04 02:05:58 rjs3 Exp $ */ ⏎ | |
| 43 | /* $Header: /cvs/src/sasl/mac/CommonKClient/mac_kclient3/Headers/TicketKeeper/TicketKeeper.h,v 1.2 2001/12/04 02:05:58 rjs3 Exp $ */ ⏎ | |
| 44 | 44 | ⏎ |
| 45 | 45 | #pragma once ⏎ |
| 46 | 46 | ⏎ |
| 0 | 0 | /* |
| 1 | * $Source: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/conf.h,v $ | |
| 1 | * $Source: /cvs/src/sasl/mac/kerberos_includes/conf.h,v $ | |
| 2 | 2 | * $Author: rjs3 $ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/conf.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 3 | * $Header: /cvs/src/sasl/mac/kerberos_includes/conf.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 4 | 4 | * |
| 5 | 5 | * Copyright 1988 by the Massachusetts Institute of Technology. |
| 6 | 6 | * |
| 0 | 0 | /* |
| 1 | * $Source: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/kerberos/des.h.unix,v $ | |
| 1 | * $Source: /cvs/src/sasl/mac/kerberos_includes/kerberos/des.h.unix,v $ | |
| 2 | 2 | * $Author: rjs3 $ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/kerberos/des.h.unix,v 1.2 2001/12/04 02:06:07 rjs3 Exp $ | |
| 3 | * $Header: /cvs/src/sasl/mac/kerberos_includes/kerberos/des.h.unix,v 1.2 2001/12/04 02:06:07 rjs3 Exp $ | |
| 4 | 4 | * |
| 5 | 5 | * Copyright 1987, 1988 by the Massachusetts Institute of Technology. |
| 6 | 6 | * |
| 0 | 0 | /* |
| 1 | * $Source: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/klog.h,v $ | |
| 1 | * $Source: /cvs/src/sasl/mac/kerberos_includes/klog.h,v $ | |
| 2 | 2 | * $Author: rjs3 $ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/klog.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 3 | * $Header: /cvs/src/sasl/mac/kerberos_includes/klog.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 4 | 4 | * |
| 5 | 5 | * Copyright 1988 by the Massachusetts Institute of Technology. |
| 6 | 6 | * |
| 0 | 0 | /* |
| 1 | * $Source: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/kparse.h,v $ | |
| 1 | * $Source: /cvs/src/sasl/mac/kerberos_includes/kparse.h,v $ | |
| 2 | 2 | * $Author: rjs3 $ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/kparse.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 3 | * $Header: /cvs/src/sasl/mac/kerberos_includes/kparse.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 4 | 4 | * |
| 5 | 5 | * Copyright 1988 by the Massachusetts Institute of Technology. |
| 6 | 6 | * |
| 0 | 0 | /* |
| 1 | * $Source: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/krb_conf.h,v $ | |
| 1 | * $Source: /cvs/src/sasl/mac/kerberos_includes/krb_conf.h,v $ | |
| 2 | 2 | * $Author: rjs3 $ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/krb_conf.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 3 | * $Header: /cvs/src/sasl/mac/kerberos_includes/krb_conf.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 4 | 4 | * |
| 5 | 5 | * Copyright 1988 by the Massachusetts Institute of Technology. |
| 6 | 6 | * |
| 0 | 0 | /* |
| 1 | * $Source: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/lsb_addr_comp.h,v $ | |
| 1 | * $Source: /cvs/src/sasl/mac/kerberos_includes/lsb_addr_comp.h,v $ | |
| 2 | 2 | * $Author: rjs3 $ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/lsb_addr_comp.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 3 | * $Header: /cvs/src/sasl/mac/kerberos_includes/lsb_addr_comp.h,v 1.2 2001/12/04 02:06:05 rjs3 Exp $ | |
| 4 | 4 | * |
| 5 | 5 | * Copyright 1988 by the Massachusetts Institute of Technology. |
| 6 | 6 | * |
| 0 | 0 | /* |
| 1 | * $Source: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/old_krb.h,v $ | |
| 1 | * $Source: /cvs/src/sasl/mac/kerberos_includes/old_krb.h,v $ | |
| 2 | 2 | * $Author: rjs3 $ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/old_krb.h,v 1.2 2001/12/04 02:06:06 rjs3 Exp $ | |
| 3 | * $Header: /cvs/src/sasl/mac/kerberos_includes/old_krb.h,v 1.2 2001/12/04 02:06:06 rjs3 Exp $ | |
| 4 | 4 | * |
| 5 | 5 | * Copyright 1987, 1988 by the Massachusetts Institute of Technology. |
| 6 | 6 | * |
| 0 | 0 | /* |
| 1 | * $Source: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/prot.h,v $ | |
| 1 | * $Source: /cvs/src/sasl/mac/kerberos_includes/prot.h,v $ | |
| 2 | 2 | * $Author: rjs3 $ |
| 3 | * $Header: /afs/andrew/system/cvs/src/sasl/mac/kerberos_includes/prot.h,v 1.2 2001/12/04 02:06:06 rjs3 Exp $ | |
| 3 | * $Header: /cvs/src/sasl/mac/kerberos_includes/prot.h,v 1.2 2001/12/04 02:06:06 rjs3 Exp $ | |
| 4 | 4 | * |
| 5 | 5 | * Copyright 1985, 1986, 1987, 1988 by the Massachusetts Institute |
| 6 | 6 | * of Technology. |
| 44 | 44 | ################################################################ |
| 45 | 45 | |
| 46 | 46 | # Library version info - here at the top, for sanity |
| 47 | # See <http://www.gnu.org/software/libtool/manual/libtool.html#Versioning> | |
| 47 | 48 | # CURRENT:REVISION:AGE |
| 48 | plugin_version = 2:25:0 | |
| 49 | plugin_version = 3:0:0 | |
| 49 | 50 | |
| 50 | 51 | INCLUDES=-I$(top_srcdir)/include -I$(top_srcdir)/lib -I$(top_srcdir)/sasldb -I$(top_builddir)/include |
| 51 | 52 | AM_LDFLAGS = -module -export-dynamic -rpath $(plugindir) -version-info $(plugin_version) |
| 359 | 359 | top_srcdir = @top_srcdir@ |
| 360 | 360 | |
| 361 | 361 | # Library version info - here at the top, for sanity |
| 362 | # See <http://www.gnu.org/software/libtool/manual/libtool.html#Versioning> | |
| 362 | 363 | # CURRENT:REVISION:AGE |
| 363 | plugin_version = 2:25:0 | |
| 364 | plugin_version = 3:0:0 | |
| 364 | 365 | INCLUDES = -I$(top_srcdir)/include -I$(top_srcdir)/lib -I$(top_srcdir)/sasldb -I$(top_builddir)/include |
| 365 | 366 | AM_LDFLAGS = -module -export-dynamic -rpath $(plugindir) -version-info $(plugin_version) |
| 366 | 367 | COMPAT_OBJS = @LTGETADDRINFOOBJS@ @LTGETNAMEINFOOBJS@ @LTSNPRINTFOBJS@ |
| 176 | 176 | all-recursive : $(PLUGINS) |
| 177 | 177 | |
| 178 | 178 | getaddrinfo.c: ..\lib\getaddrinfo.c |
| 179 | copy ..\lib\getaddrinfo.c . | |
| 179 | xcopy /D /Y ..\lib\getaddrinfo.c . | |
| 180 | 180 | |
| 181 | 181 | getnameinfo.c: ..\lib\getnameinfo.c |
| 182 | copy ..\lib\getnameinfo.c . | |
| 182 | xcopy /D /Y ..\lib\getnameinfo.c . | |
| 183 | 183 | |
| 184 | 184 | allockey.c: ..\sasldb\allockey.c |
| 185 | copy ..\sasldb\allockey.c . | |
| 185 | xcopy /D /Y ..\sasldb\allockey.c . | |
| 186 | 186 | |
| 187 | 187 | db_berkeley.c: ..\sasldb\db_berkeley.c |
| 188 | copy ..\sasldb\db_berkeley.c . | |
| 188 | xcopy /D /Y ..\sasldb\db_berkeley.c . | |
| 189 | 189 | |
| 190 | 190 | #Add /pdb: option? |
| 191 | 191 | |
| 287 | 287 | |
| 288 | 288 | $(generated_rc): |
| 289 | 289 | copy <<temp.rc $@ |
| 290 | #include "afxres.h" | |
| 290 | #include "windows.h" | |
| 291 | 291 | |
| 292 | 292 | VS_VERSION_INFO VERSIONINFO |
| 293 | 293 | FILEVERSION $(SASL_VERSION_MAJOR),$(SASL_VERSION_MINOR),$(SASL_VERSION_STEP),0 |
| 310 | 310 | VALUE "FileDescription", "CMU SASL $(@B) plugin\0" |
| 311 | 311 | VALUE "FileVersion", "$(SASL_VERSION_MAJOR).$(SASL_VERSION_MINOR).$(SASL_VERSION_STEP).0\0" |
| 312 | 312 | VALUE "InternalName", "$(@B)\0" |
| 313 | VALUE "LegalCopyright", "Copyright (c) Carnegie Mellon University 2002-2011\0" | |
| 313 | VALUE "LegalCopyright", "Copyright (c) Carnegie Mellon University 2002-2012\0" | |
| 314 | 314 | VALUE "OriginalFilename", "$(@B).dll\0" |
| 315 | 315 | VALUE "ProductName", "Carnegie Mellon University SASL\0" |
| 316 | 316 | VALUE "ProductVersion", "$(SASL_VERSION_MAJOR).$(SASL_VERSION_MINOR).$(SASL_VERSION_STEP)-0" |
| 197 | 197 | |
| 198 | 198 | /* for HTTP mode (RFC 2617) only */ |
| 199 | 199 | char *algorithm; |
| 200 | unsigned char *opaque; | |
| 200 | unsigned char *opaque; | |
| 201 | 201 | } c; /* client stuff */ |
| 202 | 202 | } u; |
| 203 | 203 | } reauth_entry_t; |
| 1898 | 1898 | { |
| 1899 | 1899 | context_t *text; |
| 1900 | 1900 | |
| 1901 | if ((sparams->flags & SASL_NEED_HTTP) && !sparams->http_request) { | |
| 1902 | SETERROR(sparams->utils, | |
| 1903 | "DIGEST-MD5 unavailable due to lack of HTTP request"); | |
| 1904 | return SASL_BADPARAM; | |
| 1905 | } | |
| 1906 | ||
| 1907 | 1901 | /* holds state are in -- allocate server size */ |
| 1908 | 1902 | text = sparams->utils->malloc(sizeof(server_context_t)); |
| 1909 | 1903 | if (text == NULL) |
| 2117 | 2111 | return SASL_FAIL; |
| 2118 | 2112 | } |
| 2119 | 2113 | |
| 2120 | if (text->http_mode && sparams->http_request->non_persist && | |
| 2114 | if (text->http_mode && | |
| 2121 | 2115 | sparams->utils->mutex_lock(text->reauth->mutex) == SASL_OK) { /* LOCK */ |
| 2122 | 2116 | |
| 2123 | 2117 | /* Create an initial cache entry for non-persistent HTTP connections */ |
| 2212 | 2206 | if (text->http_mode) { |
| 2213 | 2207 | /* per RFC 2617 (HTTP Request as set by calling application) */ |
| 2214 | 2208 | request = sparams->http_request; |
| 2209 | if (!request) { | |
| 2210 | SETERROR(sparams->utils, | |
| 2211 | "missing HTTP request in DIGEST-MD5, step 2"); | |
| 2212 | result = SASL_BADPARAM; | |
| 2213 | goto FreeAllMem; | |
| 2214 | } | |
| 2215 | 2215 | } |
| 2216 | 2216 | else { |
| 2217 | 2217 | /* per RFC 2831 */ |
| 2433 | 2433 | goto FreeAllMem; |
| 2434 | 2434 | } |
| 2435 | 2435 | |
| 2436 | if (text->state == 1) { | |
| 2436 | if (realm == NULL) { | |
| 2437 | /* From 2831bis: | |
| 2438 | If the directive is missing, "realm-value" will set to | |
| 2439 | the empty string when computing A1. */ | |
| 2440 | _plug_strdup(sparams->utils, "", &realm, NULL); | |
| 2441 | sparams->utils->log(sparams->utils->conn, SASL_LOG_DEBUG, | |
| 2442 | "The client didn't send a realm, assuming empty string."); | |
| 2443 | #if 0 | |
| 2444 | if (text->realm[0] != '\0') { | |
| 2445 | SETERROR(sparams->utils, | |
| 2446 | "realm changed: authentication aborted"); | |
| 2447 | result = SASL_BADAUTH; | |
| 2448 | goto FreeAllMem; | |
| 2449 | } | |
| 2450 | #endif | |
| 2451 | } | |
| 2452 | ||
| 2453 | if (!text->nonce) { | |
| 2437 | 2454 | unsigned val = hash((char *) nonce) % text->reauth->size; |
| 2438 | 2455 | |
| 2439 | 2456 | /* reauth attempt or continuation of HTTP Digest on a |
| 2461 | 2478 | } |
| 2462 | 2479 | |
| 2463 | 2480 | if (!text->nonce) { |
| 2464 | /* we don't have any reauth info, so bail */ | |
| 2481 | /* we don't have any reauth info */ | |
| 2465 | 2482 | sparams->utils->log(sparams->utils->conn, SASL_LOG_DEBUG, |
| 2466 | 2483 | "No reauth info for '%s' found", nonce); |
| 2467 | result = SASL_FAIL; | |
| 2484 | ||
| 2485 | /* we will continue processing the response to determine | |
| 2486 | if the client knows the password and return stale accordingly */ | |
| 2487 | } | |
| 2488 | } | |
| 2489 | ||
| 2490 | /* Sanity check the parameters */ | |
| 2491 | if (text->nonce) { | |
| 2492 | /* CLAIM: realm is not NULL below */ | |
| 2493 | if (text->realm == NULL) { | |
| 2494 | sparams->utils->log(sparams->utils->conn, SASL_LOG_DEBUG, | |
| 2495 | "The client specifies a realm when the server hasn't provided one. Using client's realm."); | |
| 2496 | _plug_strdup(sparams->utils, realm, &text->realm, NULL); | |
| 2497 | } else if ((strcmp(realm, text->realm) != 0) && | |
| 2498 | /* XXX - Not sure why the check for text->realm not being empty is needed, | |
| 2499 | as it should always be non-empty */ | |
| 2500 | (text->realm[0] != 0)) { | |
| 2501 | ||
| 2502 | client_ignores_realm = 1; | |
| 2503 | sparams->utils->log(sparams->utils->conn, SASL_LOG_DEBUG, | |
| 2504 | "The client tries to override server provided realm"); | |
| 2505 | if (text->realm) sparams->utils->free(text->realm); | |
| 2506 | _plug_strdup(sparams->utils, realm, &text->realm, NULL); | |
| 2507 | } | |
| 2508 | ||
| 2509 | if (strcmp((char *) nonce, (char *) text->nonce) != 0) { | |
| 2510 | SETERROR(sparams->utils, | |
| 2511 | "nonce changed: authentication aborted"); | |
| 2512 | result = SASL_BADAUTH; | |
| 2468 | 2513 | goto FreeAllMem; |
| 2469 | 2514 | } |
| 2470 | } | |
| 2471 | ||
| 2472 | /* Sanity check the parameters */ | |
| 2473 | if (realm == NULL) { | |
| 2474 | /* From 2831bis: | |
| 2475 | If the directive is missing, "realm-value" will set to | |
| 2476 | the empty string when computing A1. */ | |
| 2477 | _plug_strdup(sparams->utils, "", &realm, NULL); | |
| 2478 | sparams->utils->log(sparams->utils->conn, SASL_LOG_DEBUG, | |
| 2479 | "The client didn't send a realm, assuming empty string."); | |
| 2480 | if (text->realm[0] != '\0') { | |
| 2481 | SETERROR(sparams->utils, | |
| 2482 | "realm changed: authentication aborted"); | |
| 2483 | result = SASL_BADAUTH; | |
| 2484 | goto FreeAllMem; | |
| 2485 | } | |
| 2486 | ||
| 2487 | /* CLAIM: realm is not NULL below */ | |
| 2488 | } else if (text->realm == NULL) { | |
| 2489 | sparams->utils->log(sparams->utils->conn, SASL_LOG_DEBUG, | |
| 2490 | "The client specifies a realm when the server hasn't provided one. Using client's realm."); | |
| 2491 | _plug_strdup(sparams->utils, realm, &text->realm, NULL); | |
| 2492 | } else if ((strcmp(realm, text->realm) != 0) && | |
| 2493 | /* XXX - Not sure why the check for text->realm not being empty is needed, | |
| 2494 | as it should always be non-empty */ | |
| 2495 | (text->realm[0] != 0)) { | |
| 2496 | ||
| 2497 | client_ignores_realm = 1; | |
| 2498 | sparams->utils->log(sparams->utils->conn, SASL_LOG_DEBUG, | |
| 2499 | "The client tries to override server provided realm"); | |
| 2500 | if (text->realm) sparams->utils->free(text->realm); | |
| 2501 | _plug_strdup(sparams->utils, realm, &text->realm, NULL); | |
| 2502 | } | |
| 2503 | if (strcmp((char *) nonce, (char *) text->nonce) != 0) { | |
| 2504 | SETERROR(sparams->utils, | |
| 2505 | "nonce changed: authentication aborted"); | |
| 2506 | result = SASL_BADAUTH; | |
| 2507 | goto FreeAllMem; | |
| 2508 | } | |
| 2509 | if (noncecount != text->nonce_count) { | |
| 2510 | SETERROR(sparams->utils, | |
| 2511 | "incorrect nonce-count: authentication aborted"); | |
| 2512 | result = SASL_BADAUTH; | |
| 2513 | goto FreeAllMem; | |
| 2514 | } | |
| 2515 | #if 0 /* XXX Neither RFC 2617 nor RFC 2831 state that the cnonce | |
| 2516 | needs to remain constant for subsequent authentication to work */ | |
| 2517 | if (text->cnonce && strcmp((char *) cnonce, (char *) text->cnonce) != 0) { | |
| 2518 | SETERROR(sparams->utils, | |
| 2519 | "cnonce changed: authentication aborted"); | |
| 2520 | result = SASL_BADAUTH; | |
| 2521 | goto FreeAllMem; | |
| 2522 | } | |
| 2515 | #if 0 /* XXX Possible replay attack, but we will continue processing | |
| 2516 | * the response to determine if the client knows the password and | |
| 2517 | return stale accordingly */ | |
| 2518 | if (noncecount != text->nonce_count) { | |
| 2519 | SETERROR(sparams->utils, | |
| 2520 | "incorrect nonce-count: authentication aborted"); | |
| 2521 | result = SASL_BADAUTH; | |
| 2522 | goto FreeAllMem; | |
| 2523 | } | |
| 2523 | 2524 | #endif |
| 2525 | #if 0 /* XXX Neither RFC 2617 nor RFC 2831 state that the cnonce | |
| 2526 | needs to remain constant for subsequent authentication to work */ | |
| 2527 | if (text->cnonce && strcmp((char *) cnonce, (char *) text->cnonce) != 0) { | |
| 2528 | SETERROR(sparams->utils, | |
| 2529 | "cnonce changed: authentication aborted"); | |
| 2530 | result = SASL_BADAUTH; | |
| 2531 | goto FreeAllMem; | |
| 2532 | } | |
| 2533 | #endif | |
| 2534 | } | |
| 2524 | 2535 | |
| 2525 | 2536 | result = sparams->utils->prop_request(sparams->propctx, password_request); |
| 2526 | 2537 | if(result != SASL_OK) { |
| 2619 | 2630 | |
| 2620 | 2631 | Try_8859_1 = DigestCalcSecret(sparams->utils, |
| 2621 | 2632 | (unsigned char *) username, |
| 2622 | (unsigned char *) text->realm, | |
| 2633 | (unsigned char *) realm, | |
| 2623 | 2634 | sec->data, |
| 2624 | 2635 | sec->len, |
| 2625 | 2636 | FALSE, |
| 2635 | 2646 | |
| 2636 | 2647 | DigestCalcSecret(sparams->utils, |
| 2637 | 2648 | (unsigned char *) username, |
| 2638 | (unsigned char *) text->realm, | |
| 2649 | (unsigned char *) realm, | |
| 2639 | 2650 | sec->data, |
| 2640 | 2651 | sec->len, |
| 2641 | 2652 | TRUE, |
| 2728 | 2739 | |
| 2729 | 2740 | serverresponse = create_response(text, |
| 2730 | 2741 | sparams->utils, |
| 2731 | text->nonce, | |
| 2732 | text->nonce_count, | |
| 2742 | nonce, | |
| 2743 | noncecount, | |
| 2733 | 2744 | cnonce, |
| 2734 | 2745 | qop, |
| 2735 | 2746 | request, |
| 2749 | 2760 | |
| 2750 | 2761 | serverresponse = create_response(text, |
| 2751 | 2762 | sparams->utils, |
| 2752 | text->nonce, | |
| 2753 | text->nonce_count, | |
| 2763 | nonce, | |
| 2764 | noncecount, | |
| 2754 | 2765 | cnonce, |
| 2755 | 2766 | qop, |
| 2756 | 2767 | request, |
| 2783 | 2794 | } |
| 2784 | 2795 | |
| 2785 | 2796 | /* see if our nonce expired */ |
| 2786 | if (text->reauth->timeout && | |
| 2787 | time(0) - stext->timestamp > text->reauth->timeout) { | |
| 2788 | SETERROR(sparams->utils, "server nonce expired"); | |
| 2797 | if (!text->nonce || | |
| 2798 | (noncecount != text->nonce_count) || | |
| 2799 | (text->reauth->timeout && | |
| 2800 | time(0) - stext->timestamp > text->reauth->timeout)) { | |
| 2801 | if (!text->nonce) SETERROR(sparams->utils, "no cached server nonce"); | |
| 2802 | else if (noncecount != text->nonce_count) | |
| 2803 | SETERROR(sparams->utils, "incorrect nonce-count"); | |
| 2804 | else SETERROR(sparams->utils, "server nonce expired"); | |
| 2789 | 2805 | stext->stale = 1; |
| 2790 | 2806 | result = SASL_BADAUTH; |
| 2791 | 2807 | |
| 2792 | 2808 | goto FreeAllMem; |
| 2793 | } | |
| 2809 | } | |
| 2794 | 2810 | |
| 2795 | 2811 | /* |
| 2796 | 2812 | * nothing more to do; authenticated set oparams information |
| 3029 | 3045 | |
| 3030 | 3046 | /* re-initialize everything for a fresh start */ |
| 3031 | 3047 | memset(oparams, 0, sizeof(sasl_out_params_t)); |
| 3048 | if (text->nonce) sparams->utils->free(text->nonce); | |
| 3049 | if (text->realm) sparams->utils->free(text->realm); | |
| 3050 | text->nonce = text->realm = NULL; | |
| 3032 | 3051 | |
| 3033 | 3052 | /* fall through and issue challenge */ |
| 3034 | 3053 | } |
| 3444 | 3463 | |
| 3445 | 3464 | |
| 3446 | 3465 | resplen = 0; |
| 3466 | if (text->out_buf) params->utils->free(text->out_buf); | |
| 3447 | 3467 | text->out_buf = NULL; |
| 3448 | 3468 | text->out_buf_len = 0; |
| 3449 | 3469 | if (add_to_challenge(params->utils, |
| 71 | 71 | |
| 72 | 72 | #include <config.h> |
| 73 | 73 | #include <gssapi/gssapi.h> |
| 74 | ||
| 75 | #ifndef KRB5_HEIMDAL | |
| 74 | 76 | #ifdef HAVE_GSSAPI_GSSAPI_EXT_H |
| 75 | 77 | #include <gssapi/gssapi_ext.h> |
| 76 | 78 | #endif |
| 79 | #endif | |
| 80 | ||
| 77 | 81 | #include <fcntl.h> |
| 78 | 82 | #include <stdio.h> |
| 79 | 83 | #include <sasl.h> |
| 335 | 339 | gss_name_t without = GSS_C_NO_NAME; |
| 336 | 340 | gss_OID_set_desc mechs; |
| 337 | 341 | OM_uint32 out_flags = 0; |
| 338 | int ret = 0, equal = 0; | |
| 342 | int ret = SASL_OK, equal = 0; | |
| 339 | 343 | int initialContextToken = (text->gss_ctx == GSS_C_NO_CONTEXT); |
| 340 | 344 | char *p; |
| 341 | 345 | |
| 462 | 466 | GSS_C_NT_USER_NAME, |
| 463 | 467 | &without); |
| 464 | 468 | if (GSS_ERROR(maj_stat)) { |
| 465 | ret = SASL_FAIL; | |
| 466 | 469 | goto cleanup; |
| 467 | 470 | } |
| 468 | 471 | |
| 469 | 472 | maj_stat = gss_compare_name(&min_stat, text->client_name, |
| 470 | 473 | without, &equal); |
| 471 | 474 | if (GSS_ERROR(maj_stat)) { |
| 472 | ret = SASL_FAIL; | |
| 473 | 475 | goto cleanup; |
| 474 | 476 | } |
| 475 | 477 | |
| 485 | 487 | ret = params->canon_user(params->utils->conn, |
| 486 | 488 | text->authzid, 0, |
| 487 | 489 | SASL_CU_AUTHZID, oparams); |
| 488 | if (ret != SASL_OK) | |
| 490 | if (ret != SASL_OK) { | |
| 489 | 491 | goto cleanup; |
| 492 | } | |
| 490 | 493 | } |
| 491 | 494 | |
| 492 | 495 | ret = params->canon_user(params->utils->conn, |
| 495 | 498 | ? (SASL_CU_AUTHZID | SASL_CU_AUTHID) |
| 496 | 499 | : SASL_CU_AUTHID, |
| 497 | 500 | oparams); |
| 498 | if (ret != SASL_OK) | |
| 501 | if (ret != SASL_OK) { | |
| 499 | 502 | goto cleanup; |
| 503 | } | |
| 500 | 504 | |
| 501 | 505 | switch (text->gs2_flags & GS2_CB_FLAG_MASK) { |
| 502 | 506 | case GS2_CB_FLAG_N: |
| 527 | 531 | ret = SASL_OK; |
| 528 | 532 | |
| 529 | 533 | cleanup: |
| 530 | if (initialContextToken) | |
| 534 | if (ret == SASL_OK && maj_stat != GSS_S_COMPLETE) { | |
| 535 | sasl_gs2_seterror(text->utils, maj_stat, min_stat); | |
| 536 | ret = SASL_FAIL; | |
| 537 | } | |
| 538 | ||
| 539 | if (initialContextToken) { | |
| 531 | 540 | gss_release_buffer(&min_stat, &input_token); |
| 541 | } | |
| 532 | 542 | gss_release_buffer(&min_stat, &name_buf); |
| 533 | 543 | gss_release_buffer(&min_stat, &short_name_buf); |
| 534 | 544 | gss_release_buffer(&min_stat, &output_token); |
| 535 | 545 | gss_release_name(&min_stat, &without); |
| 536 | 546 | |
| 537 | if (ret == SASL_OK && maj_stat != GSS_S_COMPLETE) { | |
| 538 | sasl_gs2_seterror(text->utils, maj_stat, min_stat); | |
| 539 | ret = SASL_FAIL; | |
| 540 | } | |
| 541 | if (ret < SASL_OK) | |
| 547 | if (ret < SASL_OK) { | |
| 542 | 548 | sasl_gs2_free_context_contents(text); |
| 549 | } | |
| 543 | 550 | |
| 544 | 551 | return ret; |
| 545 | 552 | } |
| 697 | 704 | |
| 698 | 705 | if (text->gss_ctx == GSS_C_NO_CONTEXT) { |
| 699 | 706 | ret = gs2_get_init_creds(text, params, prompt_need, oparams); |
| 700 | if (ret != SASL_OK) | |
| 707 | if (ret != SASL_OK) { | |
| 701 | 708 | goto cleanup; |
| 709 | } | |
| 702 | 710 | |
| 703 | 711 | initialContextToken = 1; |
| 704 | } else | |
| 712 | } else { | |
| 705 | 713 | initialContextToken = 0; |
| 714 | } | |
| 706 | 715 | |
| 707 | 716 | if (text->server_name == GSS_C_NO_NAME) { /* only once */ |
| 708 | 717 | name_buf.length = strlen(params->service) + 1 + strlen(params->serverFQDN); |
| 728 | 737 | params->utils->free(name_buf.value); |
| 729 | 738 | name_buf.value = NULL; |
| 730 | 739 | |
| 731 | if (GSS_ERROR(maj_stat)) | |
| 740 | if (GSS_ERROR(maj_stat)) { | |
| 741 | ret = SASL_OK; | |
| 732 | 742 | goto cleanup; |
| 743 | } | |
| 733 | 744 | } |
| 734 | 745 | |
| 735 | 746 | /* From GSSAPI plugin: apparently this is for some IMAP bug workaround */ |
| 761 | 772 | strcmp(oparams->user, oparams->authid) ? |
| 762 | 773 | (char *) oparams->user : NULL, |
| 763 | 774 | &text->out_buf, &text->out_buf_len); |
| 764 | if (ret != 0) | |
| 775 | if (ret != 0) { | |
| 765 | 776 | goto cleanup; |
| 777 | } | |
| 766 | 778 | } |
| 767 | 779 | |
| 768 | 780 | req_flags = GSS_C_MUTUAL_FLAG | GSS_C_SEQUENCE_FLAG; |
| 782 | 794 | &output_token, |
| 783 | 795 | &ret_flags, |
| 784 | 796 | &text->lifetime); |
| 785 | if (GSS_ERROR(maj_stat)) | |
| 797 | if (GSS_ERROR(maj_stat)) { | |
| 798 | ret = SASL_OK; | |
| 786 | 799 | goto cleanup; |
| 800 | } | |
| 787 | 801 | |
| 788 | 802 | ret = gs2_make_message(text, params, initialContextToken, &output_token, |
| 789 | 803 | &text->out_buf, &text->out_buf_len); |
| 790 | if (ret != 0) | |
| 804 | if (ret != 0) { | |
| 791 | 805 | goto cleanup; |
| 806 | } | |
| 792 | 807 | |
| 793 | 808 | *clientout = text->out_buf; |
| 794 | 809 | *clientoutlen = text->out_buf_len; |
| 798 | 813 | goto cleanup; |
| 799 | 814 | } |
| 800 | 815 | |
| 801 | if (text->client_name != GSS_C_NO_NAME) | |
| 816 | if (text->client_name != GSS_C_NO_NAME) { | |
| 802 | 817 | gss_release_name(&min_stat, &text->client_name); |
| 803 | ||
| 818 | } | |
| 804 | 819 | maj_stat = gss_inquire_context(&min_stat, |
| 805 | 820 | text->gss_ctx, |
| 806 | 821 | &text->client_name, |
| 810 | 825 | &ret_flags, /* flags */ |
| 811 | 826 | NULL, |
| 812 | 827 | NULL); |
| 813 | if (GSS_ERROR(maj_stat)) | |
| 828 | if (GSS_ERROR(maj_stat)) { | |
| 829 | ret = SASL_OK; | |
| 814 | 830 | goto cleanup; |
| 831 | } | |
| 815 | 832 | |
| 816 | 833 | if ((ret_flags & req_flags) != req_flags) { |
| 817 | maj_stat = SASL_BADAUTH; | |
| 834 | ret = SASL_BADAUTH; | |
| 818 | 835 | goto cleanup; |
| 819 | 836 | } |
| 820 | 837 | |
| 822 | 839 | text->client_name, |
| 823 | 840 | &name_buf, |
| 824 | 841 | NULL); |
| 825 | if (GSS_ERROR(maj_stat)) | |
| 842 | if (GSS_ERROR(maj_stat)) { | |
| 843 | ret = SASL_OK; | |
| 826 | 844 | goto cleanup; |
| 845 | } | |
| 827 | 846 | |
| 828 | 847 | oparams->gss_peer_name = text->server_name; |
| 829 | 848 | oparams->gss_local_name = text->client_name; |
| 833 | 852 | oparams->maxoutbuf = 0xFFFFFF; |
| 834 | 853 | oparams->doneflag = 1; |
| 835 | 854 | |
| 855 | ret = SASL_OK; | |
| 856 | ||
| 836 | 857 | cleanup: |
| 837 | gss_release_buffer(&min_stat, &output_token); | |
| 838 | gss_release_buffer(&min_stat, &name_buf); | |
| 839 | ||
| 840 | 858 | if (ret == SASL_OK && maj_stat != GSS_S_COMPLETE) { |
| 841 | 859 | sasl_gs2_seterror(text->utils, maj_stat, min_stat); |
| 842 | 860 | ret = SASL_FAIL; |
| 843 | 861 | } |
| 844 | if (ret < SASL_OK) | |
| 862 | ||
| 863 | gss_release_buffer(&min_stat, &output_token); | |
| 864 | gss_release_buffer(&min_stat, &name_buf); | |
| 865 | ||
| 866 | if (ret < SASL_OK) { | |
| 845 | 867 | sasl_gs2_free_context_contents(text); |
| 868 | } | |
| 846 | 869 | |
| 847 | 870 | return ret; |
| 848 | 871 | } |
| 25 | 25 | #include <config.h> |
| 26 | 26 | |
| 27 | 27 | #include <gssapi/gssapi.h> |
| 28 | ||
| 29 | #ifndef KRB5_HEIMDAL | |
| 28 | 30 | #ifdef HAVE_GSSAPI_GSSAPI_EXT_H |
| 29 | 31 | #include <gssapi/gssapi_ext.h> |
| 32 | #endif | |
| 30 | 33 | #endif |
| 31 | 34 | |
| 32 | 35 | #ifndef HAVE_GSS_DECAPSULATE_TOKEN |
| 0 | 0 | /* GSSAPI SASL plugin |
| 1 | 1 | * Leif Johansson |
| 2 | 2 | * Rob Siemborski (SASL v2 Conversion) |
| 3 | * $Id: gssapi.c,v 1.112 2011/04/19 09:19:18 mel Exp $ | |
| 3 | * $Id: gssapi.c,v 1.115 2011/11/21 15:12:35 mel Exp $ | |
| 4 | 4 | */ |
| 5 | 5 | /* |
| 6 | 6 | * Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved. |
| 78 | 78 | #endif |
| 79 | 79 | |
| 80 | 80 | #include <errno.h> |
| 81 | #include <assert.h> | |
| 81 | 82 | |
| 82 | 83 | /***************************** Common Section *****************************/ |
| 83 | 84 | |
| 84 | static const char plugin_id[] = "$Id: gssapi.c,v 1.112 2011/04/19 09:19:18 mel Exp $"; | |
| 85 | static const char plugin_id[] = "$Id: gssapi.c,v 1.115 2011/11/21 15:12:35 mel Exp $"; | |
| 85 | 86 | |
| 86 | 87 | static const char * GSSAPI_BLANK_STRING = ""; |
| 88 | ||
| 89 | static gss_OID_desc gss_spnego_oid = { 6, (void *) "\x2b\x06\x01\x05\x05\x02" }; | |
| 87 | 90 | |
| 88 | 91 | #if !defined(HAVE_GSS_C_NT_HOSTBASED_SERVICE) && !defined(GSS_C_NT_HOSTBASED_SERVICE) |
| 89 | 92 | extern gss_OID gss_nt_service_name; |
| 140 | 143 | |
| 141 | 144 | typedef struct context { |
| 142 | 145 | int state; |
| 146 | ||
| 147 | gss_OID mech_type; /* GSS-SPNEGO or GSSAPI */ | |
| 148 | int http_mode; /* use RFC 4559 compatible protocol? */ | |
| 143 | 149 | |
| 144 | 150 | gss_ctx_id_t gss_ctx; |
| 145 | 151 | gss_name_t client_name; |
| 369 | 375 | } |
| 370 | 376 | |
| 371 | 377 | if (output_token->value && output) { |
| 372 | unsigned char * p = (unsigned char *) text->encode_buf; | |
| 378 | unsigned char * p; | |
| 373 | 379 | |
| 374 | 380 | ret = _plug_buf_alloc(text->utils, |
| 375 | 381 | &(text->encode_buf), |
| 382 | 388 | GSS_UNLOCK_MUTEX(text->utils); |
| 383 | 389 | return ret; |
| 384 | 390 | } |
| 391 | ||
| 392 | p = (unsigned char *) text->encode_buf; | |
| 385 | 393 | |
| 386 | 394 | p[0] = (output_token->length>>24) & 0xFF; |
| 387 | 395 | p[1] = (output_token->length>>16) & 0xFF; |
| 635 | 643 | text->client_creds = GSS_C_NO_CREDENTIAL; |
| 636 | 644 | text->state = SASL_GSSAPI_STATE_AUTHNEG; |
| 637 | 645 | |
| 646 | text->http_mode = (params->flags & SASL_NEED_HTTP); | |
| 647 | ||
| 638 | 648 | *conn_context = text; |
| 639 | 649 | |
| 650 | return SASL_OK; | |
| 651 | } | |
| 652 | ||
| 653 | static int | |
| 654 | gssapi_server_mech_authneg(context_t *text, | |
| 655 | sasl_server_params_t *params, | |
| 656 | const char *clientin, | |
| 657 | unsigned clientinlen, | |
| 658 | const char **serverout, | |
| 659 | unsigned *serveroutlen, | |
| 660 | sasl_out_params_t *oparams __attribute__((unused))) | |
| 661 | { | |
| 662 | gss_buffer_t input_token, output_token; | |
| 663 | gss_buffer_desc real_input_token, real_output_token; | |
| 664 | OM_uint32 maj_stat = 0, min_stat = 0; | |
| 665 | gss_buffer_desc name_token; | |
| 666 | int ret, equal = 0; | |
| 667 | unsigned out_flags = 0; | |
| 668 | gss_cred_id_t server_creds = (gss_cred_id_t) params->gss_creds; | |
| 669 | gss_buffer_desc name_without_realm; | |
| 670 | gss_name_t client_name_MN = NULL, without = NULL; | |
| 671 | gss_OID mech_type; | |
| 672 | ||
| 673 | input_token = &real_input_token; | |
| 674 | output_token = &real_output_token; | |
| 675 | output_token->value = NULL; output_token->length = 0; | |
| 676 | input_token->value = NULL; input_token->length = 0; | |
| 677 | ||
| 678 | if (text->server_name == GSS_C_NO_NAME) { /* only once */ | |
| 679 | if (params->serverFQDN == NULL | |
| 680 | || strlen(params->serverFQDN) == 0) { | |
| 681 | SETERROR(text->utils, "GSSAPI Failure: no serverFQDN"); | |
| 682 | sasl_gss_free_context_contents(text); | |
| 683 | return SASL_FAIL; | |
| 684 | } | |
| 685 | name_token.length = strlen(params->service) + 1 + strlen(params->serverFQDN); | |
| 686 | name_token.value = (char *)params->utils->malloc((name_token.length + 1) * sizeof(char)); | |
| 687 | if (name_token.value == NULL) { | |
| 688 | MEMERROR(text->utils); | |
| 689 | sasl_gss_free_context_contents(text); | |
| 690 | return SASL_NOMEM; | |
| 691 | } | |
| 692 | sprintf(name_token.value,"%s@%s", params->service, params->serverFQDN); | |
| 693 | ||
| 694 | GSS_LOCK_MUTEX(params->utils); | |
| 695 | maj_stat = gss_import_name (&min_stat, | |
| 696 | &name_token, | |
| 697 | GSS_C_NT_HOSTBASED_SERVICE, | |
| 698 | &text->server_name); | |
| 699 | GSS_UNLOCK_MUTEX(params->utils); | |
| 700 | ||
| 701 | params->utils->free(name_token.value); | |
| 702 | name_token.value = NULL; | |
| 703 | ||
| 704 | if (GSS_ERROR(maj_stat)) { | |
| 705 | sasl_gss_seterror(text->utils, maj_stat, min_stat); | |
| 706 | sasl_gss_free_context_contents(text); | |
| 707 | return SASL_FAIL; | |
| 708 | } | |
| 709 | ||
| 710 | if ( text->server_creds != GSS_C_NO_CREDENTIAL) { | |
| 711 | GSS_LOCK_MUTEX(params->utils); | |
| 712 | maj_stat = gss_release_cred(&min_stat, &text->server_creds); | |
| 713 | GSS_UNLOCK_MUTEX(params->utils); | |
| 714 | text->server_creds = GSS_C_NO_CREDENTIAL; | |
| 715 | } | |
| 716 | ||
| 717 | /* If caller didn't provide creds already */ | |
| 718 | if ( server_creds == GSS_C_NO_CREDENTIAL) { | |
| 719 | GSS_LOCK_MUTEX(params->utils); | |
| 720 | maj_stat = gss_acquire_cred(&min_stat, | |
| 721 | text->server_name, | |
| 722 | GSS_C_INDEFINITE, | |
| 723 | GSS_C_NO_OID_SET, | |
| 724 | GSS_C_ACCEPT, | |
| 725 | &text->server_creds, | |
| 726 | NULL, | |
| 727 | NULL); | |
| 728 | GSS_UNLOCK_MUTEX(params->utils); | |
| 729 | ||
| 730 | if (GSS_ERROR(maj_stat)) { | |
| 731 | sasl_gss_seterror(text->utils, maj_stat, min_stat); | |
| 732 | sasl_gss_free_context_contents(text); | |
| 733 | return SASL_FAIL; | |
| 734 | } | |
| 735 | server_creds = text->server_creds; | |
| 736 | } | |
| 737 | } | |
| 738 | ||
| 739 | if (clientinlen) { | |
| 740 | real_input_token.value = (void *)clientin; | |
| 741 | real_input_token.length = clientinlen; | |
| 742 | } | |
| 743 | ||
| 744 | ||
| 745 | GSS_LOCK_MUTEX(params->utils); | |
| 746 | maj_stat = | |
| 747 | gss_accept_sec_context(&min_stat, | |
| 748 | &(text->gss_ctx), | |
| 749 | server_creds, | |
| 750 | input_token, | |
| 751 | GSS_C_NO_CHANNEL_BINDINGS, | |
| 752 | &text->client_name, | |
| 753 | &mech_type, | |
| 754 | output_token, | |
| 755 | &out_flags, | |
| 756 | NULL, /* context validity period */ | |
| 757 | &(text->client_creds)); | |
| 758 | GSS_UNLOCK_MUTEX(params->utils); | |
| 759 | ||
| 760 | if (GSS_ERROR(maj_stat)) { | |
| 761 | sasl_gss_log(text->utils, maj_stat, min_stat); | |
| 762 | text->utils->seterror(text->utils->conn, SASL_NOLOG, "GSSAPI Failure: gss_accept_sec_context"); | |
| 763 | if (output_token->value) { | |
| 764 | GSS_LOCK_MUTEX(params->utils); | |
| 765 | gss_release_buffer(&min_stat, output_token); | |
| 766 | GSS_UNLOCK_MUTEX(params->utils); | |
| 767 | } | |
| 768 | sasl_gss_free_context_contents(text); | |
| 769 | return SASL_BADAUTH; | |
| 770 | } | |
| 771 | ||
| 772 | if (serveroutlen) { | |
| 773 | *serveroutlen = output_token->length; | |
| 774 | } | |
| 775 | if (output_token->value) { | |
| 776 | if (serverout) { | |
| 777 | ret = _plug_buf_alloc(text->utils, &(text->out_buf), | |
| 778 | &(text->out_buf_len), *serveroutlen); | |
| 779 | if(ret != SASL_OK) { | |
| 780 | GSS_LOCK_MUTEX(params->utils); | |
| 781 | gss_release_buffer(&min_stat, output_token); | |
| 782 | GSS_UNLOCK_MUTEX(params->utils); | |
| 783 | return ret; | |
| 784 | } | |
| 785 | memcpy(text->out_buf, output_token->value, *serveroutlen); | |
| 786 | *serverout = text->out_buf; | |
| 787 | } | |
| 788 | ||
| 789 | GSS_LOCK_MUTEX(params->utils); | |
| 790 | gss_release_buffer(&min_stat, output_token); | |
| 791 | GSS_UNLOCK_MUTEX(params->utils); | |
| 792 | } else { | |
| 793 | /* No output token, send an empty string */ | |
| 794 | *serverout = GSSAPI_BLANK_STRING; | |
| 795 | *serveroutlen = 0; | |
| 796 | } | |
| 797 | ||
| 798 | if (maj_stat == GSS_S_CONTINUE_NEEDED) { | |
| 799 | /* Context isn't complete */ | |
| 800 | return SASL_CONTINUE; | |
| 801 | } | |
| 802 | ||
| 803 | assert(maj_stat == GSS_S_COMPLETE); | |
| 804 | ||
| 805 | /* When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server | |
| 806 | examines the context to ensure that it provides a level of protection | |
| 807 | permitted by the server's security policy. In particular, if the | |
| 808 | integ_avail flag is not set in the context, then no security layer | |
| 809 | can be offered or accepted. If the conf_avail flag is not set in the | |
| 810 | context, then no security layer with confidentiality can be offered | |
| 811 | or accepted. */ | |
| 812 | if ((out_flags & GSS_C_INTEG_FLAG) == 0) { | |
| 813 | /* if the integ_avail flag is not set in the context, | |
| 814 | then no security layer can be offered or accepted. */ | |
| 815 | text->qop = LAYER_NONE; | |
| 816 | } else if ((out_flags & GSS_C_CONF_FLAG) == 0) { | |
| 817 | /* If the conf_avail flag is not set in the context, | |
| 818 | then no security layer with confidentiality can be offered | |
| 819 | or accepted. */ | |
| 820 | text->qop = LAYER_NONE | LAYER_INTEGRITY; | |
| 821 | } else { | |
| 822 | text->qop = LAYER_NONE | LAYER_INTEGRITY | LAYER_CONFIDENTIALITY; | |
| 823 | } | |
| 824 | ||
| 825 | if ((params->props.security_flags & SASL_SEC_PASS_CREDENTIALS) && | |
| 826 | (!(out_flags & GSS_C_DELEG_FLAG) || | |
| 827 | text->client_creds == GSS_C_NO_CREDENTIAL) ) | |
| 828 | { | |
| 829 | text->utils->seterror(text->utils->conn, SASL_LOG_WARN, | |
| 830 | "GSSAPI warning: no credentials were passed"); | |
| 831 | /* continue with authentication */ | |
| 832 | } | |
| 833 | ||
| 834 | GSS_LOCK_MUTEX(params->utils); | |
| 835 | maj_stat = gss_canonicalize_name(&min_stat, | |
| 836 | text->client_name, | |
| 837 | mech_type, | |
| 838 | &client_name_MN); | |
| 839 | GSS_UNLOCK_MUTEX(params->utils); | |
| 840 | ||
| 841 | if (GSS_ERROR(maj_stat)) { | |
| 842 | SETERROR(text->utils, "GSSAPI Failure: gss_canonicalize_name"); | |
| 843 | sasl_gss_free_context_contents(text); | |
| 844 | return SASL_BADAUTH; | |
| 845 | } | |
| 846 | ||
| 847 | name_token.value = NULL; | |
| 848 | name_without_realm.value = NULL; | |
| 849 | ||
| 850 | GSS_LOCK_MUTEX(params->utils); | |
| 851 | maj_stat = gss_display_name (&min_stat, | |
| 852 | client_name_MN, | |
| 853 | &name_token, | |
| 854 | NULL); | |
| 855 | GSS_UNLOCK_MUTEX(params->utils); | |
| 856 | ||
| 857 | if (GSS_ERROR(maj_stat)) { | |
| 858 | SETERROR(text->utils, "GSSAPI Failure: gss_display_name"); | |
| 859 | sasl_gss_free_context_contents(text); | |
| 860 | ret = SASL_BADAUTH; | |
| 861 | goto cleanup; | |
| 862 | } | |
| 863 | ||
| 864 | /* If the id contains a realm get the identifier for the user | |
| 865 | without the realm and see if it's the same id (i.e. | |
| 866 | tmartin == tmartin@ANDREW.CMU.EDU. If this is the case we just want | |
| 867 | to return the id (i.e. just "tmartin" */ | |
| 868 | if (strchr((char *) name_token.value, (int) '@') != NULL) { | |
| 869 | /* NOTE: libc malloc, as it is freed below by a gssapi internal | |
| 870 | * function! */ | |
| 871 | name_without_realm.value = params->utils->malloc(strlen(name_token.value)+1); | |
| 872 | if (name_without_realm.value == NULL) { | |
| 873 | MEMERROR(text->utils); | |
| 874 | ret = SASL_NOMEM; | |
| 875 | goto cleanup; | |
| 876 | } | |
| 877 | ||
| 878 | strcpy(name_without_realm.value, name_token.value); | |
| 879 | ||
| 880 | /* cut off string at '@' */ | |
| 881 | (strchr(name_without_realm.value,'@'))[0] = '\0'; | |
| 882 | ||
| 883 | name_without_realm.length = strlen( (char *) name_without_realm.value ); | |
| 884 | ||
| 885 | GSS_LOCK_MUTEX(params->utils); | |
| 886 | maj_stat = gss_import_name (&min_stat, | |
| 887 | &name_without_realm, | |
| 888 | /* Solaris 8/9 gss_import_name doesn't accept GSS_C_NULL_OID here, | |
| 889 | so use GSS_C_NT_USER_NAME instead if available. */ | |
| 890 | #ifdef HAVE_GSS_C_NT_USER_NAME | |
| 891 | GSS_C_NT_USER_NAME, | |
| 892 | #else | |
| 893 | GSS_C_NULL_OID, | |
| 894 | #endif | |
| 895 | &without); | |
| 896 | GSS_UNLOCK_MUTEX(params->utils); | |
| 897 | ||
| 898 | if (GSS_ERROR(maj_stat)) { | |
| 899 | SETERROR(text->utils, "GSSAPI Failure: gss_import_name"); | |
| 900 | sasl_gss_free_context_contents(text); | |
| 901 | ret = SASL_BADAUTH; | |
| 902 | goto cleanup; | |
| 903 | } | |
| 904 | ||
| 905 | GSS_LOCK_MUTEX(params->utils); | |
| 906 | maj_stat = gss_compare_name(&min_stat, | |
| 907 | client_name_MN, | |
| 908 | without, | |
| 909 | &equal); | |
| 910 | GSS_UNLOCK_MUTEX(params->utils); | |
| 911 | ||
| 912 | if (GSS_ERROR(maj_stat)) { | |
| 913 | SETERROR(text->utils, "GSSAPI Failure: gss_compare_name"); | |
| 914 | sasl_gss_free_context_contents(text); | |
| 915 | ret = SASL_BADAUTH; | |
| 916 | goto cleanup; | |
| 917 | } | |
| 918 | ||
| 919 | } else { | |
| 920 | equal = 0; | |
| 921 | } | |
| 922 | ||
| 923 | if (equal) { | |
| 924 | text->authid = strdup(name_without_realm.value); | |
| 925 | } else { | |
| 926 | text->authid = strdup(name_token.value); | |
| 927 | } | |
| 928 | ||
| 929 | if (text->authid == NULL) { | |
| 930 | MEMERROR(params->utils); | |
| 931 | ret = SASL_NOMEM; | |
| 932 | goto cleanup; | |
| 933 | } | |
| 934 | ||
| 935 | if (text->http_mode) { | |
| 936 | /* HTTP doesn't do any ssf negotiation */ | |
| 937 | text->state = SASL_GSSAPI_STATE_AUTHENTICATED; | |
| 938 | ret = SASL_OK; | |
| 939 | } | |
| 940 | else { | |
| 941 | /* Switch to ssf negotiation */ | |
| 942 | text->state = SASL_GSSAPI_STATE_SSFCAP; | |
| 943 | ret = SASL_CONTINUE; | |
| 944 | } | |
| 945 | ||
| 946 | cleanup: | |
| 947 | if (client_name_MN) { | |
| 948 | GSS_LOCK_MUTEX(params->utils); | |
| 949 | gss_release_name(&min_stat, &client_name_MN); | |
| 950 | GSS_UNLOCK_MUTEX(params->utils); | |
| 951 | } | |
| 952 | if (name_token.value) { | |
| 953 | GSS_LOCK_MUTEX(params->utils); | |
| 954 | gss_release_buffer(&min_stat, &name_token); | |
| 955 | GSS_UNLOCK_MUTEX(params->utils); | |
| 956 | } | |
| 957 | if (name_without_realm.value) { | |
| 958 | params->utils->free(name_without_realm.value); | |
| 959 | } | |
| 960 | if (without) { | |
| 961 | GSS_LOCK_MUTEX(params->utils); | |
| 962 | gss_release_name(&min_stat, &without); | |
| 963 | GSS_UNLOCK_MUTEX(params->utils); | |
| 964 | } | |
| 965 | ||
| 966 | return ret; | |
| 967 | } | |
| 968 | ||
| 969 | static int | |
| 970 | gssapi_server_mech_ssfcap(context_t *text, | |
| 971 | sasl_server_params_t *params, | |
| 972 | const char *clientin __attribute__((unused)), | |
| 973 | unsigned clientinlen, | |
| 974 | const char **serverout, | |
| 975 | unsigned *serveroutlen, | |
| 976 | sasl_out_params_t *oparams __attribute__((unused))) | |
| 977 | { | |
| 978 | gss_buffer_t input_token, output_token; | |
| 979 | gss_buffer_desc real_input_token, real_output_token; | |
| 980 | OM_uint32 maj_stat = 0, min_stat = 0; | |
| 981 | unsigned char sasldata[4]; | |
| 982 | int ret; | |
| 983 | ||
| 984 | input_token = &real_input_token; | |
| 985 | output_token = &real_output_token; | |
| 986 | output_token->value = NULL; output_token->length = 0; | |
| 987 | ||
| 988 | ||
| 989 | if (clientinlen != 0) { | |
| 990 | SETERROR(text->utils, "GSSAPI server is not expecting data at this stage"); | |
| 991 | sasl_gss_free_context_contents(text); | |
| 992 | return SASL_BADAUTH; | |
| 993 | } | |
| 994 | ||
| 995 | /* we have to decide what sort of encryption/integrity/etc., | |
| 996 | we support */ | |
| 997 | if (params->props.max_ssf < params->external_ssf) { | |
| 998 | text->limitssf = 0; | |
| 999 | } else { | |
| 1000 | text->limitssf = params->props.max_ssf - params->external_ssf; | |
| 1001 | } | |
| 1002 | if (params->props.min_ssf < params->external_ssf) { | |
| 1003 | text->requiressf = 0; | |
| 1004 | } else { | |
| 1005 | text->requiressf = params->props.min_ssf - params->external_ssf; | |
| 1006 | } | |
| 1007 | ||
| 1008 | /* build up our security properties token */ | |
| 1009 | if (text->requiressf != 0 && | |
| 1010 | (text->qop & (LAYER_INTEGRITY|LAYER_CONFIDENTIALITY))) { | |
| 1011 | if (params->props.maxbufsize > 0xFFFFFF) { | |
| 1012 | /* make sure maxbufsize isn't too large */ | |
| 1013 | /* maxbufsize = 0xFFFFFF */ | |
| 1014 | sasldata[1] = sasldata[2] = sasldata[3] = 0xFF; | |
| 1015 | } else { | |
| 1016 | sasldata[1] = (params->props.maxbufsize >> 16) & 0xFF; | |
| 1017 | sasldata[2] = (params->props.maxbufsize >> 8) & 0xFF; | |
| 1018 | sasldata[3] = (params->props.maxbufsize >> 0) & 0xFF; | |
| 1019 | } | |
| 1020 | } else { | |
| 1021 | /* From RFC 4752: "The client verifies that the server maximum buffer is 0 | |
| 1022 | if the server does not advertise support for any security layer." */ | |
| 1023 | sasldata[1] = sasldata[2] = sasldata[3] = 0; | |
| 1024 | } | |
| 1025 | ||
| 1026 | sasldata[0] = 0; | |
| 1027 | if(text->requiressf != 0 && !params->props.maxbufsize) { | |
| 1028 | params->utils->seterror(params->utils->conn, 0, | |
| 1029 | "GSSAPI needs a security layer but one is forbidden"); | |
| 1030 | return SASL_TOOWEAK; | |
| 1031 | } | |
| 1032 | ||
| 1033 | if (text->requiressf == 0) { | |
| 1034 | sasldata[0] |= LAYER_NONE; /* authentication */ | |
| 1035 | } | |
| 1036 | if ((text->qop & LAYER_INTEGRITY) && | |
| 1037 | text->requiressf <= 1 && | |
| 1038 | text->limitssf >= 1 && | |
| 1039 | params->props.maxbufsize) { | |
| 1040 | sasldata[0] |= LAYER_INTEGRITY; | |
| 1041 | } | |
| 1042 | if ((text->qop & LAYER_CONFIDENTIALITY) && | |
| 1043 | text->requiressf <= K5_MAX_SSF && | |
| 1044 | text->limitssf >= K5_MAX_SSF && | |
| 1045 | params->props.maxbufsize) { | |
| 1046 | sasldata[0] |= LAYER_CONFIDENTIALITY; | |
| 1047 | } | |
| 1048 | ||
| 1049 | /* Remember what we want and can offer */ | |
| 1050 | text->qop = sasldata[0]; | |
| 1051 | ||
| 1052 | real_input_token.value = (void *)sasldata; | |
| 1053 | real_input_token.length = 4; | |
| 1054 | ||
| 1055 | GSS_LOCK_MUTEX(params->utils); | |
| 1056 | maj_stat = gss_wrap(&min_stat, | |
| 1057 | text->gss_ctx, | |
| 1058 | 0, /* Just integrity checking here */ | |
| 1059 | GSS_C_QOP_DEFAULT, | |
| 1060 | input_token, | |
| 1061 | NULL, | |
| 1062 | output_token); | |
| 1063 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1064 | ||
| 1065 | if (GSS_ERROR(maj_stat)) { | |
| 1066 | sasl_gss_seterror(text->utils, maj_stat, min_stat); | |
| 1067 | if (output_token->value) { | |
| 1068 | GSS_LOCK_MUTEX(params->utils); | |
| 1069 | gss_release_buffer(&min_stat, output_token); | |
| 1070 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1071 | } | |
| 1072 | sasl_gss_free_context_contents(text); | |
| 1073 | return SASL_FAIL; | |
| 1074 | } | |
| 1075 | ||
| 1076 | ||
| 1077 | if (serveroutlen) | |
| 1078 | *serveroutlen = output_token->length; | |
| 1079 | if (output_token->value) { | |
| 1080 | if (serverout) { | |
| 1081 | ret = _plug_buf_alloc(text->utils, &(text->out_buf), | |
| 1082 | &(text->out_buf_len), *serveroutlen); | |
| 1083 | if(ret != SASL_OK) { | |
| 1084 | GSS_LOCK_MUTEX(params->utils); | |
| 1085 | gss_release_buffer(&min_stat, output_token); | |
| 1086 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1087 | return ret; | |
| 1088 | } | |
| 1089 | memcpy(text->out_buf, output_token->value, *serveroutlen); | |
| 1090 | *serverout = text->out_buf; | |
| 1091 | } | |
| 1092 | ||
| 1093 | GSS_LOCK_MUTEX(params->utils); | |
| 1094 | gss_release_buffer(&min_stat, output_token); | |
| 1095 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1096 | } | |
| 1097 | ||
| 1098 | /* Wait for ssf request and authid */ | |
| 1099 | text->state = SASL_GSSAPI_STATE_SSFREQ; | |
| 1100 | ||
| 1101 | return SASL_CONTINUE; | |
| 1102 | } | |
| 1103 | ||
| 1104 | static int | |
| 1105 | gssapi_server_mech_ssfreq(context_t *text, | |
| 1106 | sasl_server_params_t *params, | |
| 1107 | const char *clientin, | |
| 1108 | unsigned clientinlen, | |
| 1109 | const char **serverout __attribute__((unused)), | |
| 1110 | unsigned *serveroutlen __attribute__((unused)), | |
| 1111 | sasl_out_params_t *oparams) | |
| 1112 | { | |
| 1113 | gss_buffer_t input_token, output_token; | |
| 1114 | gss_buffer_desc real_input_token, real_output_token; | |
| 1115 | OM_uint32 maj_stat = 0, min_stat = 0; | |
| 1116 | OM_uint32 max_input; | |
| 1117 | int layerchoice; | |
| 1118 | ||
| 1119 | input_token = &real_input_token; | |
| 1120 | output_token = &real_output_token; | |
| 1121 | output_token->value = NULL; output_token->length = 0; | |
| 1122 | ||
| 1123 | real_input_token.value = (void *)clientin; | |
| 1124 | real_input_token.length = clientinlen; | |
| 1125 | ||
| 1126 | GSS_LOCK_MUTEX(params->utils); | |
| 1127 | maj_stat = gss_unwrap(&min_stat, | |
| 1128 | text->gss_ctx, | |
| 1129 | input_token, | |
| 1130 | output_token, | |
| 1131 | NULL, | |
| 1132 | NULL); | |
| 1133 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1134 | ||
| 1135 | if (GSS_ERROR(maj_stat)) { | |
| 1136 | sasl_gss_seterror(text->utils, maj_stat, min_stat); | |
| 1137 | sasl_gss_free_context_contents(text); | |
| 1138 | return SASL_FAIL; | |
| 1139 | } | |
| 1140 | ||
| 1141 | if (output_token->length < 4) { | |
| 1142 | SETERROR(text->utils, | |
| 1143 | "token too short"); | |
| 1144 | GSS_LOCK_MUTEX(params->utils); | |
| 1145 | gss_release_buffer(&min_stat, output_token); | |
| 1146 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1147 | sasl_gss_free_context_contents(text); | |
| 1148 | return SASL_FAIL; | |
| 1149 | } | |
| 1150 | ||
| 1151 | layerchoice = (int)(((char *)(output_token->value))[0]); | |
| 1152 | if (layerchoice == LAYER_NONE && | |
| 1153 | (text->qop & LAYER_NONE)) { /* no encryption */ | |
| 1154 | oparams->encode = NULL; | |
| 1155 | oparams->decode = NULL; | |
| 1156 | oparams->mech_ssf = 0; | |
| 1157 | } else if (layerchoice == LAYER_INTEGRITY && | |
| 1158 | (text->qop & LAYER_INTEGRITY)) { /* integrity */ | |
| 1159 | oparams->encode = &gssapi_integrity_encode; | |
| 1160 | oparams->decode = &gssapi_decode; | |
| 1161 | oparams->mech_ssf = 1; | |
| 1162 | } else if ((layerchoice == LAYER_CONFIDENTIALITY || | |
| 1163 | /* For compatibility with broken clients setting both bits */ | |
| 1164 | layerchoice == (LAYER_CONFIDENTIALITY|LAYER_INTEGRITY)) && | |
| 1165 | (text->qop & LAYER_CONFIDENTIALITY)) { /* privacy */ | |
| 1166 | oparams->encode = &gssapi_privacy_encode; | |
| 1167 | oparams->decode = &gssapi_decode; | |
| 1168 | /* FIX ME: Need to extract the proper value here */ | |
| 1169 | oparams->mech_ssf = K5_MAX_SSF; | |
| 1170 | } else { | |
| 1171 | /* not a supported encryption layer */ | |
| 1172 | SETERROR(text->utils, | |
| 1173 | "protocol violation: client requested invalid layer"); | |
| 1174 | /* Mark that we attempted negotiation */ | |
| 1175 | oparams->mech_ssf = 2; | |
| 1176 | if (output_token->value) { | |
| 1177 | GSS_LOCK_MUTEX(params->utils); | |
| 1178 | gss_release_buffer(&min_stat, output_token); | |
| 1179 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1180 | } | |
| 1181 | sasl_gss_free_context_contents(text); | |
| 1182 | return SASL_FAIL; | |
| 1183 | } | |
| 1184 | ||
| 1185 | if (output_token->length > 4) { | |
| 1186 | int ret; | |
| 1187 | ||
| 1188 | ret = params->canon_user(params->utils->conn, | |
| 1189 | ((char *) output_token->value) + 4, | |
| 1190 | (output_token->length - 4) * sizeof(char), | |
| 1191 | SASL_CU_AUTHZID, oparams); | |
| 1192 | ||
| 1193 | if (ret != SASL_OK) { | |
| 1194 | sasl_gss_free_context_contents(text); | |
| 1195 | return ret; | |
| 1196 | } | |
| 1197 | } | |
| 1198 | ||
| 1199 | /* No matter what, set the rest of the oparams */ | |
| 1200 | ||
| 1201 | oparams->maxoutbuf = | |
| 1202 | (((unsigned char *) output_token->value)[1] << 16) | | |
| 1203 | (((unsigned char *) output_token->value)[2] << 8) | | |
| 1204 | (((unsigned char *) output_token->value)[3] << 0); | |
| 1205 | ||
| 1206 | if (oparams->mech_ssf) { | |
| 1207 | maj_stat = gss_wrap_size_limit( &min_stat, | |
| 1208 | text->gss_ctx, | |
| 1209 | 1, | |
| 1210 | GSS_C_QOP_DEFAULT, | |
| 1211 | (OM_uint32) oparams->maxoutbuf, | |
| 1212 | &max_input); | |
| 1213 | ||
| 1214 | if(max_input > oparams->maxoutbuf) { | |
| 1215 | /* Heimdal appears to get this wrong */ | |
| 1216 | oparams->maxoutbuf -= (max_input - oparams->maxoutbuf); | |
| 1217 | } else { | |
| 1218 | /* This code is actually correct */ | |
| 1219 | oparams->maxoutbuf = max_input; | |
| 1220 | } | |
| 1221 | } | |
| 1222 | ||
| 1223 | GSS_LOCK_MUTEX(params->utils); | |
| 1224 | gss_release_buffer(&min_stat, output_token); | |
| 1225 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1226 | ||
| 1227 | text->state = SASL_GSSAPI_STATE_AUTHENTICATED; | |
| 1228 | ||
| 1229 | /* used by layers */ | |
| 1230 | _plug_decode_init(&text->decode_context, | |
| 1231 | text->utils, | |
| 1232 | (params->props.maxbufsize > 0xFFFFFF) ? 0xFFFFFF : | |
| 1233 | params->props.maxbufsize); | |
| 1234 | ||
| 640 | 1235 | return SASL_OK; |
| 641 | 1236 | } |
| 642 | 1237 | |
| 649 | 1244 | unsigned *serveroutlen, |
| 650 | 1245 | sasl_out_params_t *oparams) |
| 651 | 1246 | { |
| 652 | context_t *text = (context_t *)conn_context; | |
| 653 | gss_buffer_t input_token, output_token; | |
| 654 | gss_buffer_desc real_input_token, real_output_token; | |
| 655 | OM_uint32 maj_stat = 0, min_stat = 0; | |
| 656 | OM_uint32 max_input; | |
| 657 | gss_buffer_desc name_token; | |
| 658 | int ret, out_flags = 0 ; | |
| 659 | gss_cred_id_t server_creds = params->gss_creds; | |
| 660 | ||
| 661 | input_token = &real_input_token; | |
| 662 | output_token = &real_output_token; | |
| 663 | output_token->value = NULL; output_token->length = 0; | |
| 664 | input_token->value = NULL; input_token->length = 0; | |
| 665 | ||
| 666 | if(!serverout) { | |
| 1247 | context_t *text = (context_t *) conn_context; | |
| 1248 | int ret; | |
| 1249 | ||
| 1250 | if (!serverout) { | |
| 667 | 1251 | PARAMERROR(text->utils); |
| 668 | 1252 | return SASL_BADPARAM; |
| 669 | 1253 | } |
| 670 | ||
| 1254 | ||
| 671 | 1255 | *serverout = NULL; |
| 672 | *serveroutlen = 0; | |
| 673 | ||
| 674 | if (text == NULL) { | |
| 675 | return SASL_BADPROT; | |
| 676 | } | |
| 1256 | *serveroutlen = 0; | |
| 1257 | ||
| 1258 | if (text == NULL) return SASL_BADPROT; | |
| 1259 | ||
| 1260 | params->utils->log(NULL, SASL_LOG_DEBUG, | |
| 1261 | "GSSAPI server step %d\n", text->state); | |
| 677 | 1262 | |
| 678 | 1263 | switch (text->state) { |
| 679 | 1264 | |
| 680 | 1265 | case SASL_GSSAPI_STATE_AUTHNEG: |
| 681 | if (text->server_name == GSS_C_NO_NAME) { /* only once */ | |
| 682 | if (params->serverFQDN == NULL | |
| 683 | || strlen(params->serverFQDN) == 0) { | |
| 684 | SETERROR(text->utils, "GSSAPI Failure: no serverFQDN"); | |
| 685 | sasl_gss_free_context_contents(text); | |
| 686 | return SASL_FAIL; | |
| 687 | } | |
| 688 | name_token.length = strlen(params->service) + 1 + strlen(params->serverFQDN); | |
| 689 | name_token.value = (char *)params->utils->malloc((name_token.length + 1) * sizeof(char)); | |
| 690 | if (name_token.value == NULL) { | |
| 691 | MEMERROR(text->utils); | |
| 692 | sasl_gss_free_context_contents(text); | |
| 693 | return SASL_NOMEM; | |
| 694 | } | |
| 695 | sprintf(name_token.value,"%s@%s", params->service, params->serverFQDN); | |
| 696 | ||
| 697 | GSS_LOCK_MUTEX(params->utils); | |
| 698 | maj_stat = gss_import_name (&min_stat, | |
| 699 | &name_token, | |
| 700 | GSS_C_NT_HOSTBASED_SERVICE, | |
| 701 | &text->server_name); | |
| 702 | GSS_UNLOCK_MUTEX(params->utils); | |
| 703 | ||
| 704 | params->utils->free(name_token.value); | |
| 705 | name_token.value = NULL; | |
| 706 | ||
| 707 | if (GSS_ERROR(maj_stat)) { | |
| 708 | sasl_gss_seterror(text->utils, maj_stat, min_stat); | |
| 709 | sasl_gss_free_context_contents(text); | |
| 710 | return SASL_FAIL; | |
| 711 | } | |
| 712 | ||
| 713 | if ( text->server_creds != GSS_C_NO_CREDENTIAL) { | |
| 714 | GSS_LOCK_MUTEX(params->utils); | |
| 715 | maj_stat = gss_release_cred(&min_stat, &text->server_creds); | |
| 716 | GSS_UNLOCK_MUTEX(params->utils); | |
| 717 | text->server_creds = GSS_C_NO_CREDENTIAL; | |
| 718 | } | |
| 719 | ||
| 720 | /* If caller didn't provide creds already */ | |
| 721 | if ( server_creds == GSS_C_NO_CREDENTIAL) { | |
| 722 | GSS_LOCK_MUTEX(params->utils); | |
| 723 | maj_stat = gss_acquire_cred(&min_stat, | |
| 724 | text->server_name, | |
| 725 | GSS_C_INDEFINITE, | |
| 726 | GSS_C_NO_OID_SET, | |
| 727 | GSS_C_ACCEPT, | |
| 728 | &text->server_creds, | |
| 729 | NULL, | |
| 730 | NULL); | |
| 731 | GSS_UNLOCK_MUTEX(params->utils); | |
| 732 | ||
| 733 | if (GSS_ERROR(maj_stat)) { | |
| 734 | sasl_gss_seterror(text->utils, maj_stat, min_stat); | |
| 735 | sasl_gss_free_context_contents(text); | |
| 736 | return SASL_FAIL; | |
| 737 | } | |
| 738 | server_creds = text->server_creds; | |
| 739 | } | |
| 740 | } | |
| 741 | ||
| 742 | if (clientinlen) { | |
| 743 | real_input_token.value = (void *)clientin; | |
| 744 | real_input_token.length = clientinlen; | |
| 745 | } | |
| 746 | ||
| 747 | ||
| 748 | GSS_LOCK_MUTEX(params->utils); | |
| 749 | maj_stat = | |
| 750 | gss_accept_sec_context(&min_stat, | |
| 751 | &(text->gss_ctx), | |
| 752 | server_creds, | |
| 753 | input_token, | |
| 754 | GSS_C_NO_CHANNEL_BINDINGS, | |
| 755 | &text->client_name, | |
| 756 | NULL, /* resulting mech_name */ | |
| 757 | output_token, | |
| 758 | &out_flags, | |
| 759 | NULL, /* context validity period */ | |
| 760 | &(text->client_creds)); | |
| 761 | GSS_UNLOCK_MUTEX(params->utils); | |
| 762 | ||
| 763 | if (GSS_ERROR(maj_stat)) { | |
| 764 | sasl_gss_log(text->utils, maj_stat, min_stat); | |
| 765 | text->utils->seterror(text->utils->conn, SASL_NOLOG, "GSSAPI Failure: gss_accept_sec_context"); | |
| 766 | if (output_token->value) { | |
| 767 | GSS_LOCK_MUTEX(params->utils); | |
| 768 | gss_release_buffer(&min_stat, output_token); | |
| 769 | GSS_UNLOCK_MUTEX(params->utils); | |
| 770 | } | |
| 771 | sasl_gss_free_context_contents(text); | |
| 772 | return SASL_BADAUTH; | |
| 773 | } | |
| 774 | ||
| 775 | /* When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server | |
| 776 | examines the context to ensure that it provides a level of protection | |
| 777 | permitted by the server's security policy. In particular, if the | |
| 778 | integ_avail flag is not set in the context, then no security layer | |
| 779 | can be offered or accepted. If the conf_avail flag is not set in the | |
| 780 | context, then no security layer with confidentiality can be offered | |
| 781 | or accepted. */ | |
| 782 | if ((out_flags & GSS_C_INTEG_FLAG) == 0) { | |
| 783 | /* if the integ_avail flag is not set in the context, | |
| 784 | then no security layer can be offered or accepted. */ | |
| 785 | text->qop = LAYER_NONE; | |
| 786 | } else if ((out_flags & GSS_C_CONF_FLAG) == 0) { | |
| 787 | /* If the conf_avail flag is not set in the context, | |
| 788 | then no security layer with confidentiality can be offered | |
| 789 | or accepted. */ | |
| 790 | text->qop = LAYER_NONE | LAYER_INTEGRITY; | |
| 791 | } else { | |
| 792 | text->qop = LAYER_NONE | LAYER_INTEGRITY | LAYER_CONFIDENTIALITY; | |
| 793 | } | |
| 794 | ||
| 795 | if ((params->props.security_flags & SASL_SEC_PASS_CREDENTIALS) && | |
| 796 | (!(out_flags & GSS_C_DELEG_FLAG) || | |
| 797 | text->client_creds == GSS_C_NO_CREDENTIAL) ) | |
| 798 | { | |
| 799 | text->utils->seterror(text->utils->conn, SASL_LOG_WARN, | |
| 800 | "GSSAPI warning: no credentials were passed"); | |
| 801 | /* continue with authentication */ | |
| 802 | } | |
| 803 | ||
| 804 | if (serveroutlen) | |
| 805 | *serveroutlen = output_token->length; | |
| 806 | if (output_token->value) { | |
| 807 | if (serverout) { | |
| 808 | ret = _plug_buf_alloc(text->utils, &(text->out_buf), | |
| 809 | &(text->out_buf_len), *serveroutlen); | |
| 810 | if(ret != SASL_OK) { | |
| 811 | GSS_LOCK_MUTEX(params->utils); | |
| 812 | gss_release_buffer(&min_stat, output_token); | |
| 813 | GSS_UNLOCK_MUTEX(params->utils); | |
| 814 | return ret; | |
| 815 | } | |
| 816 | memcpy(text->out_buf, output_token->value, *serveroutlen); | |
| 817 | *serverout = text->out_buf; | |
| 818 | } | |
| 819 | ||
| 820 | GSS_LOCK_MUTEX(params->utils); | |
| 821 | gss_release_buffer(&min_stat, output_token); | |
| 822 | GSS_UNLOCK_MUTEX(params->utils); | |
| 823 | } else { | |
| 824 | /* No output token, send an empty string */ | |
| 825 | *serverout = GSSAPI_BLANK_STRING; | |
| 826 | *serveroutlen = 0; | |
| 827 | } | |
| 828 | ||
| 829 | if (maj_stat == GSS_S_COMPLETE) { | |
| 830 | /* Switch to ssf negotiation */ | |
| 831 | text->state = SASL_GSSAPI_STATE_SSFCAP; | |
| 832 | ||
| 833 | if (*serveroutlen != 0) { | |
| 834 | return SASL_CONTINUE; | |
| 835 | } | |
| 836 | ||
| 837 | /* Pretend that we just got an empty response from the client */ | |
| 838 | clientinlen = 0; | |
| 839 | ||
| 840 | /* fall through */ | |
| 841 | } else { | |
| 842 | return SASL_CONTINUE; | |
| 843 | } | |
| 844 | ||
| 845 | case SASL_GSSAPI_STATE_SSFCAP: { | |
| 846 | unsigned char sasldata[4]; | |
| 847 | gss_buffer_desc name_token; | |
| 848 | gss_buffer_desc name_without_realm; | |
| 849 | gss_name_t without = NULL; | |
| 850 | int equal; | |
| 851 | ||
| 852 | name_token.value = NULL; | |
| 853 | name_without_realm.value = NULL; | |
| 854 | ||
| 855 | if (clientinlen != 0) { | |
| 856 | SETERROR(text->utils, "GSSAPI server is not expecting data at this stage"); | |
| 857 | sasl_gss_free_context_contents(text); | |
| 858 | return SASL_BADAUTH; | |
| 859 | } | |
| 860 | ||
| 861 | GSS_LOCK_MUTEX(params->utils); | |
| 862 | maj_stat = gss_display_name (&min_stat, | |
| 863 | text->client_name, | |
| 864 | &name_token, | |
| 865 | NULL); | |
| 866 | GSS_UNLOCK_MUTEX(params->utils); | |
| 867 | ||
| 868 | if (GSS_ERROR(maj_stat)) { | |
| 869 | SETERROR(text->utils, "GSSAPI Failure"); | |
| 870 | sasl_gss_free_context_contents(text); | |
| 871 | return SASL_BADAUTH; | |
| 872 | } | |
| 873 | ||
| 874 | /* If the id contains a realm get the identifier for the user | |
| 875 | without the realm and see if it's the same id (i.e. | |
| 876 | tmartin == tmartin@ANDREW.CMU.EDU. If this is the case we just want | |
| 877 | to return the id (i.e. just "tmartin" */ | |
| 878 | if (strchr((char *) name_token.value, (int) '@') != NULL) { | |
| 879 | /* NOTE: libc malloc, as it is freed below by a gssapi internal | |
| 880 | * function! */ | |
| 881 | name_without_realm.value = params->utils->malloc(strlen(name_token.value)+1); | |
| 882 | if (name_without_realm.value == NULL) { | |
| 883 | if (name_token.value) { | |
| 884 | GSS_LOCK_MUTEX(params->utils); | |
| 885 | gss_release_buffer(&min_stat, &name_token); | |
| 886 | GSS_UNLOCK_MUTEX(params->utils); | |
| 887 | } | |
| 888 | MEMERROR(text->utils); | |
| 889 | return SASL_NOMEM; | |
| 890 | } | |
| 891 | ||
| 892 | strcpy(name_without_realm.value, name_token.value); | |
| 893 | ||
| 894 | /* cut off string at '@' */ | |
| 895 | (strchr(name_without_realm.value,'@'))[0] = '\0'; | |
| 896 | ||
| 897 | name_without_realm.length = strlen( (char *) name_without_realm.value ); | |
| 898 | ||
| 899 | GSS_LOCK_MUTEX(params->utils); | |
| 900 | maj_stat = gss_import_name (&min_stat, | |
| 901 | &name_without_realm, | |
| 902 | /* Solaris 8/9 gss_import_name doesn't accept GSS_C_NULL_OID here, | |
| 903 | so use GSS_C_NT_USER_NAME instead if available. */ | |
| 904 | #ifdef HAVE_GSS_C_NT_USER_NAME | |
| 905 | GSS_C_NT_USER_NAME, | |
| 906 | #else | |
| 907 | GSS_C_NULL_OID, | |
| 908 | #endif | |
| 909 | &without); | |
| 910 | GSS_UNLOCK_MUTEX(params->utils); | |
| 911 | ||
| 912 | if (GSS_ERROR(maj_stat)) { | |
| 913 | params->utils->free(name_without_realm.value); | |
| 914 | if (name_token.value) { | |
| 915 | GSS_LOCK_MUTEX(params->utils); | |
| 916 | gss_release_buffer(&min_stat, &name_token); | |
| 917 | GSS_UNLOCK_MUTEX(params->utils); | |
| 918 | } | |
| 919 | SETERROR(text->utils, "GSSAPI Failure"); | |
| 920 | sasl_gss_free_context_contents(text); | |
| 921 | return SASL_BADAUTH; | |
| 922 | } | |
| 923 | ||
| 924 | GSS_LOCK_MUTEX(params->utils); | |
| 925 | maj_stat = gss_compare_name(&min_stat, | |
| 926 | text->client_name, | |
| 927 | without, | |
| 928 | &equal); | |
| 929 | GSS_UNLOCK_MUTEX(params->utils); | |
| 930 | ||
| 931 | if (GSS_ERROR(maj_stat)) { | |
| 932 | params->utils->free(name_without_realm.value); | |
| 933 | if (name_token.value) { | |
| 934 | GSS_LOCK_MUTEX(params->utils); | |
| 935 | gss_release_buffer(&min_stat, &name_token); | |
| 936 | GSS_UNLOCK_MUTEX(params->utils); | |
| 937 | } | |
| 938 | if (without) { | |
| 939 | GSS_LOCK_MUTEX(params->utils); | |
| 940 | gss_release_name(&min_stat, &without); | |
| 941 | GSS_UNLOCK_MUTEX(params->utils); | |
| 942 | } | |
| 943 | SETERROR(text->utils, "GSSAPI Failure"); | |
| 944 | sasl_gss_free_context_contents(text); | |
| 945 | return SASL_BADAUTH; | |
| 946 | } | |
| 947 | ||
| 948 | GSS_LOCK_MUTEX(params->utils); | |
| 949 | gss_release_name(&min_stat,&without); | |
| 950 | GSS_UNLOCK_MUTEX(params->utils); | |
| 951 | ||
| 952 | } else { | |
| 953 | equal = 0; | |
| 954 | } | |
| 955 | ||
| 956 | if (equal) { | |
| 957 | text->authid = strdup(name_without_realm.value); | |
| 958 | ||
| 959 | if (text->authid == NULL) { | |
| 960 | MEMERROR(params->utils); | |
| 961 | return SASL_NOMEM; | |
| 962 | } | |
| 963 | } else { | |
| 964 | text->authid = strdup(name_token.value); | |
| 965 | ||
| 966 | if (text->authid == NULL) { | |
| 967 | MEMERROR(params->utils); | |
| 968 | return SASL_NOMEM; | |
| 969 | } | |
| 970 | } | |
| 971 | ||
| 972 | if (name_token.value) { | |
| 973 | GSS_LOCK_MUTEX(params->utils); | |
| 974 | gss_release_buffer(&min_stat, &name_token); | |
| 975 | GSS_UNLOCK_MUTEX(params->utils); | |
| 976 | } | |
| 977 | if (name_without_realm.value) { | |
| 978 | params->utils->free(name_without_realm.value); | |
| 979 | } | |
| 980 | ||
| 981 | /* we have to decide what sort of encryption/integrity/etc., | |
| 982 | we support */ | |
| 983 | if (params->props.max_ssf < params->external_ssf) { | |
| 984 | text->limitssf = 0; | |
| 985 | } else { | |
| 986 | text->limitssf = params->props.max_ssf - params->external_ssf; | |
| 987 | } | |
| 988 | if (params->props.min_ssf < params->external_ssf) { | |
| 989 | text->requiressf = 0; | |
| 990 | } else { | |
| 991 | text->requiressf = params->props.min_ssf - params->external_ssf; | |
| 992 | } | |
| 993 | ||
| 994 | /* build up our security properties token */ | |
| 995 | if (text->requiressf != 0 && | |
| 996 | (text->qop & (LAYER_INTEGRITY|LAYER_CONFIDENTIALITY))) { | |
| 997 | if (params->props.maxbufsize > 0xFFFFFF) { | |
| 998 | /* make sure maxbufsize isn't too large */ | |
| 999 | /* maxbufsize = 0xFFFFFF */ | |
| 1000 | sasldata[1] = sasldata[2] = sasldata[3] = 0xFF; | |
| 1001 | } else { | |
| 1002 | sasldata[1] = (params->props.maxbufsize >> 16) & 0xFF; | |
| 1003 | sasldata[2] = (params->props.maxbufsize >> 8) & 0xFF; | |
| 1004 | sasldata[3] = (params->props.maxbufsize >> 0) & 0xFF; | |
| 1005 | } | |
| 1006 | } else { | |
| 1007 | /* From RFC 4752: "The client verifies that the server maximum buffer is 0 | |
| 1008 | if the server does not advertise support for any security layer." */ | |
| 1009 | sasldata[1] = sasldata[2] = sasldata[3] = 0; | |
| 1010 | } | |
| 1011 | ||
| 1012 | sasldata[0] = 0; | |
| 1013 | if(text->requiressf != 0 && !params->props.maxbufsize) { | |
| 1014 | params->utils->seterror(params->utils->conn, 0, | |
| 1015 | "GSSAPI needs a security layer but one is forbidden"); | |
| 1016 | return SASL_TOOWEAK; | |
| 1017 | } | |
| 1018 | ||
| 1019 | if (text->requiressf == 0) { | |
| 1020 | sasldata[0] |= LAYER_NONE; /* authentication */ | |
| 1021 | } | |
| 1022 | if ((text->qop & LAYER_INTEGRITY) && | |
| 1023 | text->requiressf <= 1 && | |
| 1024 | text->limitssf >= 1 && | |
| 1025 | params->props.maxbufsize) { | |
| 1026 | sasldata[0] |= LAYER_INTEGRITY; | |
| 1027 | } | |
| 1028 | if ((text->qop & LAYER_CONFIDENTIALITY) && | |
| 1029 | text->requiressf <= K5_MAX_SSF && | |
| 1030 | text->limitssf >= K5_MAX_SSF && | |
| 1031 | params->props.maxbufsize) { | |
| 1032 | sasldata[0] |= LAYER_CONFIDENTIALITY; | |
| 1033 | } | |
| 1034 | ||
| 1035 | real_input_token.value = (void *)sasldata; | |
| 1036 | real_input_token.length = 4; | |
| 1037 | ||
| 1038 | GSS_LOCK_MUTEX(params->utils); | |
| 1039 | maj_stat = gss_wrap(&min_stat, | |
| 1040 | text->gss_ctx, | |
| 1041 | 0, /* Just integrity checking here */ | |
| 1042 | GSS_C_QOP_DEFAULT, | |
| 1043 | input_token, | |
| 1044 | NULL, | |
| 1045 | output_token); | |
| 1046 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1047 | ||
| 1048 | if (GSS_ERROR(maj_stat)) { | |
| 1049 | sasl_gss_seterror(text->utils, maj_stat, min_stat); | |
| 1050 | if (output_token->value) { | |
| 1051 | GSS_LOCK_MUTEX(params->utils); | |
| 1052 | gss_release_buffer(&min_stat, output_token); | |
| 1053 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1054 | } | |
| 1055 | sasl_gss_free_context_contents(text); | |
| 1056 | return SASL_FAIL; | |
| 1057 | } | |
| 1058 | ||
| 1059 | ||
| 1060 | if (serveroutlen) | |
| 1061 | *serveroutlen = output_token->length; | |
| 1062 | if (output_token->value) { | |
| 1063 | if (serverout) { | |
| 1064 | ret = _plug_buf_alloc(text->utils, &(text->out_buf), | |
| 1065 | &(text->out_buf_len), *serveroutlen); | |
| 1066 | if(ret != SASL_OK) { | |
| 1067 | GSS_LOCK_MUTEX(params->utils); | |
| 1068 | gss_release_buffer(&min_stat, output_token); | |
| 1069 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1070 | return ret; | |
| 1071 | } | |
| 1072 | memcpy(text->out_buf, output_token->value, *serveroutlen); | |
| 1073 | *serverout = text->out_buf; | |
| 1074 | } | |
| 1075 | ||
| 1076 | GSS_LOCK_MUTEX(params->utils); | |
| 1077 | gss_release_buffer(&min_stat, output_token); | |
| 1078 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1079 | } | |
| 1080 | ||
| 1081 | /* Remember what we want and can offer */ | |
| 1082 | text->qop = sasldata[0]; | |
| 1083 | ||
| 1084 | /* Wait for ssf request and authid */ | |
| 1085 | text->state = SASL_GSSAPI_STATE_SSFREQ; | |
| 1086 | ||
| 1087 | return SASL_CONTINUE; | |
| 1088 | } | |
| 1089 | ||
| 1090 | case SASL_GSSAPI_STATE_SSFREQ: { | |
| 1091 | int layerchoice; | |
| 1092 | ||
| 1093 | real_input_token.value = (void *)clientin; | |
| 1094 | real_input_token.length = clientinlen; | |
| 1095 | ||
| 1096 | GSS_LOCK_MUTEX(params->utils); | |
| 1097 | maj_stat = gss_unwrap(&min_stat, | |
| 1098 | text->gss_ctx, | |
| 1099 | input_token, | |
| 1100 | output_token, | |
| 1101 | NULL, | |
| 1102 | NULL); | |
| 1103 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1104 | ||
| 1105 | if (GSS_ERROR(maj_stat)) { | |
| 1106 | sasl_gss_seterror(text->utils, maj_stat, min_stat); | |
| 1107 | sasl_gss_free_context_contents(text); | |
| 1108 | return SASL_FAIL; | |
| 1109 | } | |
| 1110 | ||
| 1111 | if (output_token->length < 4) { | |
| 1112 | SETERROR(text->utils, | |
| 1113 | "token too short"); | |
| 1114 | GSS_LOCK_MUTEX(params->utils); | |
| 1115 | gss_release_buffer(&min_stat, output_token); | |
| 1116 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1117 | sasl_gss_free_context_contents(text); | |
| 1118 | return SASL_FAIL; | |
| 1119 | } | |
| 1120 | ||
| 1121 | layerchoice = (int)(((char *)(output_token->value))[0]); | |
| 1122 | if (layerchoice == LAYER_NONE && | |
| 1123 | (text->qop & LAYER_NONE)) { /* no encryption */ | |
| 1124 | oparams->encode = NULL; | |
| 1125 | oparams->decode = NULL; | |
| 1126 | oparams->mech_ssf = 0; | |
| 1127 | } else if (layerchoice == LAYER_INTEGRITY && | |
| 1128 | (text->qop & LAYER_INTEGRITY)) { /* integrity */ | |
| 1129 | oparams->encode = &gssapi_integrity_encode; | |
| 1130 | oparams->decode = &gssapi_decode; | |
| 1131 | oparams->mech_ssf = 1; | |
| 1132 | } else if ((layerchoice == LAYER_CONFIDENTIALITY || | |
| 1133 | /* For compatibility with broken clients setting both bits */ | |
| 1134 | layerchoice == (LAYER_CONFIDENTIALITY|LAYER_INTEGRITY)) && | |
| 1135 | (text->qop & LAYER_CONFIDENTIALITY)) { /* privacy */ | |
| 1136 | oparams->encode = &gssapi_privacy_encode; | |
| 1137 | oparams->decode = &gssapi_decode; | |
| 1138 | /* FIX ME: Need to extract the proper value here */ | |
| 1139 | oparams->mech_ssf = K5_MAX_SSF; | |
| 1140 | } else { | |
| 1141 | /* not a supported encryption layer */ | |
| 1142 | SETERROR(text->utils, | |
| 1143 | "protocol violation: client requested invalid layer"); | |
| 1144 | /* Mark that we attempted negotiation */ | |
| 1145 | oparams->mech_ssf = 2; | |
| 1146 | if (output_token->value) { | |
| 1147 | GSS_LOCK_MUTEX(params->utils); | |
| 1148 | gss_release_buffer(&min_stat, output_token); | |
| 1149 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1150 | } | |
| 1151 | sasl_gss_free_context_contents(text); | |
| 1152 | return SASL_FAIL; | |
| 1153 | } | |
| 1154 | ||
| 1155 | if (output_token->length > 4) { | |
| 1156 | int ret; | |
| 1157 | ||
| 1158 | ret = params->canon_user(params->utils->conn, | |
| 1159 | ((char *) output_token->value) + 4, | |
| 1160 | (output_token->length - 4) * sizeof(char), | |
| 1161 | SASL_CU_AUTHZID, oparams); | |
| 1162 | ||
| 1163 | if (ret != SASL_OK) { | |
| 1164 | sasl_gss_free_context_contents(text); | |
| 1165 | return ret; | |
| 1166 | } | |
| 1167 | ||
| 1168 | ret = params->canon_user(params->utils->conn, | |
| 1169 | text->authid, | |
| 1170 | 0, /* strlen(text->authid) */ | |
| 1171 | SASL_CU_AUTHID | SASL_CU_EXTERNALLY_VERIFIED, oparams); | |
| 1172 | if (ret != SASL_OK) { | |
| 1173 | sasl_gss_free_context_contents(text); | |
| 1174 | return ret; | |
| 1175 | } | |
| 1176 | } else /* if (output_token->length == 4) */ { | |
| 1177 | /* null authzid */ | |
| 1178 | int ret; | |
| 1179 | ||
| 1180 | ret = params->canon_user(params->utils->conn, | |
| 1181 | text->authid, | |
| 1182 | 0, /* strlen(text->authid) */ | |
| 1183 | SASL_CU_AUTHZID | SASL_CU_AUTHID | SASL_CU_EXTERNALLY_VERIFIED, | |
| 1184 | oparams); | |
| 1185 | ||
| 1186 | if (ret != SASL_OK) { | |
| 1187 | sasl_gss_free_context_contents(text); | |
| 1188 | return ret; | |
| 1189 | } | |
| 1190 | } | |
| 1191 | ||
| 1192 | /* No matter what, set the rest of the oparams */ | |
| 1193 | ||
| 1194 | if (text->client_creds != GSS_C_NO_CREDENTIAL) { | |
| 1195 | oparams->client_creds = &text->client_creds; | |
| 1196 | } | |
| 1197 | else { | |
| 1198 | oparams->client_creds = NULL; | |
| 1199 | } | |
| 1200 | ||
| 1201 | oparams->maxoutbuf = | |
| 1202 | (((unsigned char *) output_token->value)[1] << 16) | | |
| 1203 | (((unsigned char *) output_token->value)[2] << 8) | | |
| 1204 | (((unsigned char *) output_token->value)[3] << 0); | |
| 1205 | ||
| 1206 | if (oparams->mech_ssf) { | |
| 1207 | maj_stat = gss_wrap_size_limit( &min_stat, | |
| 1208 | text->gss_ctx, | |
| 1209 | 1, | |
| 1210 | GSS_C_QOP_DEFAULT, | |
| 1211 | (OM_uint32) oparams->maxoutbuf, | |
| 1212 | &max_input); | |
| 1213 | ||
| 1214 | if(max_input > oparams->maxoutbuf) { | |
| 1215 | /* Heimdal appears to get this wrong */ | |
| 1216 | oparams->maxoutbuf -= (max_input - oparams->maxoutbuf); | |
| 1217 | } else { | |
| 1218 | /* This code is actually correct */ | |
| 1219 | oparams->maxoutbuf = max_input; | |
| 1220 | } | |
| 1221 | } | |
| 1222 | ||
| 1223 | GSS_LOCK_MUTEX(params->utils); | |
| 1224 | gss_release_buffer(&min_stat, output_token); | |
| 1225 | GSS_UNLOCK_MUTEX(params->utils); | |
| 1226 | ||
| 1227 | text->state = SASL_GSSAPI_STATE_AUTHENTICATED; | |
| 1228 | ||
| 1229 | /* used by layers */ | |
| 1230 | _plug_decode_init(&text->decode_context, | |
| 1231 | text->utils, | |
| 1232 | (params->props.maxbufsize > 0xFFFFFF) ? 0xFFFFFF : | |
| 1233 | params->props.maxbufsize); | |
| 1234 | ||
| 1235 | oparams->doneflag = 1; | |
| 1236 | ||
| 1237 | return SASL_OK; | |
| 1238 | } | |
| 1239 | ||
| 1266 | ret = gssapi_server_mech_authneg(text, params, clientin, clientinlen, | |
| 1267 | serverout, serveroutlen, oparams); | |
| 1268 | if (ret != SASL_CONTINUE || *serveroutlen) break; | |
| 1269 | ||
| 1270 | /* Pretend that we just got an empty response from the client */ | |
| 1271 | clientinlen = 0; | |
| 1272 | ||
| 1273 | /* fall through */ | |
| 1274 | ||
| 1275 | case SASL_GSSAPI_STATE_SSFCAP: | |
| 1276 | ret = gssapi_server_mech_ssfcap(text, params, clientin, clientinlen, | |
| 1277 | serverout, serveroutlen, oparams); | |
| 1278 | break; | |
| 1279 | ||
| 1280 | case SASL_GSSAPI_STATE_SSFREQ: | |
| 1281 | ret = gssapi_server_mech_ssfreq(text, params, clientin, clientinlen, | |
| 1282 | serverout, serveroutlen, oparams); | |
| 1283 | break; | |
| 1284 | ||
| 1240 | 1285 | default: |
| 1241 | 1286 | params->utils->log(NULL, SASL_LOG_ERR, |
| 1242 | 1287 | "Invalid GSSAPI server step %d\n", text->state); |
| 1243 | 1288 | return SASL_FAIL; |
| 1244 | 1289 | } |
| 1245 | ||
| 1246 | return SASL_FAIL; /* should never get here */ | |
| 1290 | ||
| 1291 | if (ret == SASL_OK) { | |
| 1292 | ret = params->canon_user(params->utils->conn, | |
| 1293 | text->authid, | |
| 1294 | 0, /* strlen(text->authid) */ | |
| 1295 | (oparams->user ? 0 : SASL_CU_AUTHZID) | |
| 1296 | | SASL_CU_AUTHID | SASL_CU_EXTERNALLY_VERIFIED, | |
| 1297 | oparams); | |
| 1298 | ||
| 1299 | if (ret != SASL_OK) { | |
| 1300 | sasl_gss_free_context_contents(text); | |
| 1301 | return ret; | |
| 1302 | } | |
| 1303 | ||
| 1304 | if (text->client_creds != GSS_C_NO_CREDENTIAL) { | |
| 1305 | oparams->client_creds = &text->client_creds; | |
| 1306 | } | |
| 1307 | else { | |
| 1308 | oparams->client_creds = NULL; | |
| 1309 | } | |
| 1310 | ||
| 1311 | oparams->doneflag = 1; | |
| 1312 | } | |
| 1313 | ||
| 1314 | return ret; | |
| 1247 | 1315 | } |
| 1248 | 1316 | |
| 1249 | 1317 | static sasl_server_plug_t gssapi_server_plugins[] = |
| 1270 | 1338 | NULL, /* mech_avail */ |
| 1271 | 1339 | NULL /* spare */ |
| 1272 | 1340 | } |
| 1341 | #ifdef HAVE_GSS_SPNEGO | |
| 1342 | ,{ | |
| 1343 | "GSS-SPNEGO", /* mech_name */ | |
| 1344 | K5_MAX_SSF, /* max_ssf */ | |
| 1345 | SASL_SEC_NOPLAINTEXT | |
| 1346 | | SASL_SEC_NOACTIVE | |
| 1347 | | SASL_SEC_NOANONYMOUS | |
| 1348 | | SASL_SEC_MUTUAL_AUTH /* security_flags */ | |
| 1349 | | SASL_SEC_PASS_CREDENTIALS, | |
| 1350 | SASL_FEAT_WANT_CLIENT_FIRST | |
| 1351 | | SASL_FEAT_ALLOWS_PROXY | |
| 1352 | | SASL_FEAT_DONTUSE_USERPASSWD | |
| 1353 | | SASL_FEAT_SUPPORTS_HTTP, /* features */ | |
| 1354 | NULL, /* glob_context */ | |
| 1355 | &gssapi_server_mech_new, /* mech_new */ | |
| 1356 | &gssapi_server_mech_step, /* mech_step */ | |
| 1357 | &gssapi_common_mech_dispose, /* mech_dispose */ | |
| 1358 | &gssapi_common_mech_free, /* mech_free */ | |
| 1359 | NULL, /* setpass */ | |
| 1360 | NULL, /* user_query */ | |
| 1361 | NULL, /* idle */ | |
| 1362 | NULL, /* mech_avail */ | |
| 1363 | NULL /* spare */ | |
| 1364 | } | |
| 1365 | #endif | |
| 1273 | 1366 | }; |
| 1274 | 1367 | |
| 1275 | 1368 | int gssapiv2_server_plug_init( |
| 1322 | 1415 | |
| 1323 | 1416 | *out_version = SASL_SERVER_PLUG_VERSION; |
| 1324 | 1417 | *pluglist = gssapi_server_plugins; |
| 1418 | #ifdef HAVE_GSS_SPNEGO | |
| 1419 | *plugcount = 2; | |
| 1420 | #else | |
| 1325 | 1421 | *plugcount = 1; |
| 1422 | #endif | |
| 1326 | 1423 | |
| 1327 | 1424 | #ifdef GSS_USE_MUTEXES |
| 1328 | 1425 | if (!gss_mutex) { |
| 1338 | 1435 | |
| 1339 | 1436 | /***************************** Client Section *****************************/ |
| 1340 | 1437 | |
| 1341 | static int gssapi_client_mech_new(void *glob_context __attribute__((unused)), | |
| 1438 | static int gssapi_client_mech_new(void *glob_context, | |
| 1342 | 1439 | sasl_client_params_t *params, |
| 1343 | 1440 | void **conn_context) |
| 1344 | 1441 | { |
| 1352 | 1449 | } |
| 1353 | 1450 | |
| 1354 | 1451 | text->state = SASL_GSSAPI_STATE_AUTHNEG; |
| 1452 | text->mech_type = (gss_OID) glob_context; | |
| 1355 | 1453 | text->gss_ctx = GSS_C_NO_CONTEXT; |
| 1356 | 1454 | text->client_name = GSS_C_NO_NAME; |
| 1357 | 1455 | text->server_creds = GSS_C_NO_CREDENTIAL; |
| 1358 | 1456 | text->client_creds = GSS_C_NO_CREDENTIAL; |
| 1457 | ||
| 1458 | text->http_mode = (params->flags & SASL_NEED_HTTP); | |
| 1359 | 1459 | |
| 1360 | 1460 | *conn_context = text; |
| 1361 | 1461 | |
| 1389 | 1489 | *clientout = NULL; |
| 1390 | 1490 | *clientoutlen = 0; |
| 1391 | 1491 | |
| 1492 | params->utils->log(NULL, SASL_LOG_DEBUG, | |
| 1493 | "GSSAPI client step %d", text->state); | |
| 1494 | ||
| 1392 | 1495 | switch (text->state) { |
| 1393 | 1496 | |
| 1394 | 1497 | case SASL_GSSAPI_STATE_AUTHNEG: |
| 1501 | 1604 | client_creds, /* GSS_C_NO_CREDENTIAL */ |
| 1502 | 1605 | &text->gss_ctx, |
| 1503 | 1606 | text->server_name, |
| 1504 | GSS_C_NO_OID, | |
| 1607 | text->mech_type, | |
| 1505 | 1608 | req_flags, |
| 1506 | 1609 | 0, |
| 1507 | 1610 | GSS_C_NO_CHANNEL_BINDINGS, |
| 1621 | 1724 | |
| 1622 | 1725 | if (ret != SASL_OK) return ret; |
| 1623 | 1726 | |
| 1727 | if (text->http_mode) { | |
| 1728 | /* HTTP doesn't do any ssf negotiation */ | |
| 1729 | text->state = SASL_GSSAPI_STATE_AUTHENTICATED; | |
| 1730 | oparams->doneflag = 1; | |
| 1731 | return SASL_OK; | |
| 1732 | } | |
| 1733 | ||
| 1624 | 1734 | /* Switch to ssf negotiation */ |
| 1625 | 1735 | text->state = SASL_GSSAPI_STATE_SSFCAP; |
| 1626 | 1736 | } |
| 1727 | 1837 | oparams->decode = &gssapi_decode; |
| 1728 | 1838 | oparams->mech_ssf = 1; |
| 1729 | 1839 | mychoice = LAYER_INTEGRITY; |
| 1730 | } else if (need <= 0 && (serverhas & LAYER_NONE)) { | |
| 1840 | } else if ((text->qop & LAYER_NONE) && | |
| 1841 | need <= 0 && (serverhas & LAYER_NONE)) { | |
| 1731 | 1842 | /* no layer */ |
| 1732 | 1843 | oparams->encode = NULL; |
| 1733 | 1844 | oparams->decode = NULL; |
| 1879 | 1990 | return SASL_FAIL; /* should never get here */ |
| 1880 | 1991 | } |
| 1881 | 1992 | |
| 1882 | static const long gssapi_required_prompts[] = { | |
| 1993 | static const unsigned long gssapi_required_prompts[] = { | |
| 1883 | 1994 | SASL_CB_LIST_END |
| 1884 | 1995 | }; |
| 1885 | 1996 | |
| 1897 | 2008 | | SASL_FEAT_WANT_CLIENT_FIRST |
| 1898 | 2009 | | SASL_FEAT_ALLOWS_PROXY, /* features */ |
| 1899 | 2010 | gssapi_required_prompts, /* required_prompts */ |
| 1900 | NULL, /* glob_context */ | |
| 2011 | GSS_C_NO_OID, /* glob_context */ | |
| 1901 | 2012 | &gssapi_client_mech_new, /* mech_new */ |
| 1902 | 2013 | &gssapi_client_mech_step, /* mech_step */ |
| 1903 | 2014 | &gssapi_common_mech_dispose, /* mech_dispose */ |
| 1906 | 2017 | NULL, /* spare */ |
| 1907 | 2018 | NULL /* spare */ |
| 1908 | 2019 | } |
| 2020 | #ifdef HAVE_GSS_SPNEGO | |
| 2021 | ,{ | |
| 2022 | "GSS-SPNEGO", /* mech_name */ | |
| 2023 | K5_MAX_SSF, /* max_ssf */ | |
| 2024 | SASL_SEC_NOPLAINTEXT | |
| 2025 | | SASL_SEC_NOACTIVE | |
| 2026 | | SASL_SEC_NOANONYMOUS | |
| 2027 | | SASL_SEC_MUTUAL_AUTH | |
| 2028 | | SASL_SEC_PASS_CREDENTIALS, /* security_flags */ | |
| 2029 | SASL_FEAT_NEEDSERVERFQDN | |
| 2030 | | SASL_FEAT_WANT_CLIENT_FIRST | |
| 2031 | | SASL_FEAT_ALLOWS_PROXY | |
| 2032 | | SASL_FEAT_SUPPORTS_HTTP, /* features */ | |
| 2033 | gssapi_required_prompts, /* required_prompts */ | |
| 2034 | &gss_spnego_oid, /* glob_context */ | |
| 2035 | &gssapi_client_mech_new, /* mech_new */ | |
| 2036 | &gssapi_client_mech_step, /* mech_step */ | |
| 2037 | &gssapi_common_mech_dispose, /* mech_dispose */ | |
| 2038 | &gssapi_common_mech_free, /* mech_free */ | |
| 2039 | NULL, /* idle */ | |
| 2040 | NULL, /* spare */ | |
| 2041 | NULL /* spare */ | |
| 2042 | } | |
| 2043 | #endif | |
| 1909 | 2044 | }; |
| 1910 | 2045 | |
| 1911 | 2046 | int gssapiv2_client_plug_init(const sasl_utils_t *utils __attribute__((unused)), |
| 1921 | 2056 | |
| 1922 | 2057 | *out_version = SASL_CLIENT_PLUG_VERSION; |
| 1923 | 2058 | *pluglist = gssapi_client_plugins; |
| 2059 | #ifdef HAVE_GSS_SPNEGO | |
| 2060 | *plugcount = 2; | |
| 2061 | #else | |
| 1924 | 2062 | *plugcount = 1; |
| 2063 | #endif | |
| 1925 | 2064 | |
| 1926 | 2065 | #ifdef GSS_USE_MUTEXES |
| 1927 | 2066 | if(!gss_mutex) { |
| 1934 | 2073 | |
| 1935 | 2074 | return SASL_OK; |
| 1936 | 2075 | } |
| 1937 | ||
| 178 | 178 | |
| 179 | 179 | /* canonicalize username first, so that password verification is |
| 180 | 180 | * done against the canonical id */ |
| 181 | result = params->canon_user(params->utils->conn, text->username, | |
| 181 | result = params->canon_user(params->utils->conn, | |
| 182 | text->username, | |
| 182 | 183 | text->username_len, |
| 183 | SASL_CU_AUTHID | SASL_CU_AUTHZID, oparams); | |
| 184 | SASL_CU_AUTHID | SASL_CU_AUTHZID | SASL_CU_EXTERNALLY_VERIFIED, | |
| 185 | oparams); | |
| 184 | 186 | if (result != SASL_OK) return result; |
| 185 | 187 | |
| 186 | 188 | /* verify_password - return sasl_ok on success */ |
| 0 | 0 | /* NTLM SASL plugin |
| 1 | 1 | * Ken Murchison |
| 2 | * $Id: ntlm.c,v 1.36 2011/01/14 14:35:57 murch Exp $ | |
| 2 | * $Id: ntlm.c,v 1.37 2011/11/08 17:31:55 murch Exp $ | |
| 3 | 3 | * |
| 4 | 4 | * References: |
| 5 | 5 | * http://www.innovation.ch/java/ntlm.html |
| 99 | 99 | |
| 100 | 100 | /***************************** Common Section *****************************/ |
| 101 | 101 | |
| 102 | static const char plugin_id[] = "$Id: ntlm.c,v 1.36 2011/01/14 14:35:57 murch Exp $"; | |
| 102 | static const char plugin_id[] = "$Id: ntlm.c,v 1.37 2011/11/08 17:31:55 murch Exp $"; | |
| 103 | 103 | |
| 104 | 104 | #ifdef WIN32 |
| 105 | 105 | static ssize_t writev (SOCKET fd, const struct iovec *iov, size_t iovcnt); |
| 2141 | 2141 | 0, /* max_ssf */ |
| 2142 | 2142 | SASL_SEC_NOPLAINTEXT |
| 2143 | 2143 | | SASL_SEC_NOANONYMOUS, /* security_flags */ |
| 2144 | SASL_FEAT_WANT_CLIENT_FIRST, /* features */ | |
| 2144 | SASL_FEAT_WANT_CLIENT_FIRST | |
| 2145 | | SASL_FEAT_SUPPORTS_HTTP, /* features */ | |
| 2145 | 2146 | NULL, /* required_prompts */ |
| 2146 | 2147 | NULL, /* glob_context */ |
| 2147 | 2148 | &ntlm_client_mech_new, /* mech_new */ |
| 277 | 277 | otp_common_mech_free(void *global_context __attribute__((unused)), |
| 278 | 278 | const sasl_utils_t *utils __attribute__((unused))) |
| 279 | 279 | { |
| 280 | EVP_cleanup(); | |
| 280 | /* Don't call EVP_cleanup(); here, as this might confuse the calling | |
| 281 | application if it also uses OpenSSL */ | |
| 281 | 282 | } |
| 282 | 283 | |
| 283 | 284 | /***************************** Server Section *****************************/ |
| 158 | 158 | result = params->canon_user(params->utils->conn, |
| 159 | 159 | authen, |
| 160 | 160 | 0, |
| 161 | SASL_CU_AUTHID | canon_flags, | |
| 161 | SASL_CU_AUTHID | canon_flags | SASL_CU_EXTERNALLY_VERIFIED, | |
| 162 | 162 | oparams); |
| 163 | 163 | if (result != SASL_OK) { |
| 164 | 164 | _plug_free_string(params->utils, &passcopy); |
| 151 | 151 | return SASL_BADPARAM; |
| 152 | 152 | } |
| 153 | 153 | |
| 154 | len = ai->ai_addrlen; | |
| 154 | len = (socklen_t) ai->ai_addrlen; | |
| 155 | 155 | memcpy(&ss, ai->ai_addr, len); |
| 156 | 156 | freeaddrinfo(ai); |
| 157 | 157 | sockaddr_unmapped((struct sockaddr *)&ss, &len); |
| 229 | 229 | } |
| 230 | 230 | *curlen = newlen; |
| 231 | 231 | } else if(*rwbuf && *curlen < newlen) { |
| 232 | size_t needed = 2*(*curlen); | |
| 232 | unsigned needed = 2*(*curlen); | |
| 233 | 233 | |
| 234 | 234 | while(needed < newlen) |
| 235 | 235 | needed *= 2; |
| 266 | 266 | strcpy((char *) *out, in); |
| 267 | 267 | |
| 268 | 268 | if (outlen) |
| 269 | *outlen = len; | |
| 269 | *outlen = (int) len; | |
| 270 | 270 | |
| 271 | 271 | return SASL_OK; |
| 272 | 272 | } |
| 279 | 279 | |
| 280 | 280 | len = strlen(*str); |
| 281 | 281 | |
| 282 | utils->erasebuffer(*str, len); | |
| 282 | utils->erasebuffer(*str, (unsigned int) len); | |
| 283 | 283 | utils->free(*str); |
| 284 | 284 | |
| 285 | 285 | *str=NULL; |
| 1520 | 1520 | srp_common_mech_free(void *global_context __attribute__((unused)), |
| 1521 | 1521 | const sasl_utils_t *utils __attribute__((unused))) |
| 1522 | 1522 | { |
| 1523 | EVP_cleanup(); | |
| 1523 | /* Don't call EVP_cleanup(); here, as this might confuse the calling | |
| 1524 | application if it also uses OpenSSL */ | |
| 1524 | 1525 | } |
| 1525 | 1526 | |
| 1526 | 1527 |
| 80 | 80 | target_triplet = @target@ |
| 81 | 81 | noinst_PROGRAMS = client$(EXEEXT) server$(EXEEXT) |
| 82 | 82 | EXTRA_PROGRAMS = sample-client$(EXEEXT) sample-server$(EXEEXT) |
| 83 | EXTRA_DIST = http_digest_client.c | |
| 83 | 84 | subdir = sample |
| 84 | 85 | DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in $(srcdir)/NTMakefile |
| 85 | 86 | ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 |
| 135 | 136 | SOURCES = $(client_SOURCES) $(sample_client_SOURCES) \ |
| 136 | 137 | $(sample_server_SOURCES) $(server_SOURCES) |
| 137 | 138 | DIST_SOURCES = $(client_SOURCES) $(sample_client_SOURCES) \ |
| 138 | $(sample_server_SOURCES) $(server_SOURCES) $(srcdir)/http_digest_client.c | |
| 139 | $(sample_server_SOURCES) $(server_SOURCES) | |
| 139 | 140 | ETAGS = etags |
| 140 | 141 | CTAGS = ctags |
| 141 | 142 | DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) |
| 0 | /* $Id: client.c,v 1.8 2010/12/01 14:51:53 mel Exp $ */ | |
| 0 | /* $Id: client.c,v 1.9 2011/09/15 09:31:49 mel Exp $ */ | |
| 1 | 1 | /* |
| 2 | 2 | * Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved. |
| 3 | 3 | * |
| 59 | 59 | #include <assert.h> |
| 60 | 60 | |
| 61 | 61 | #include <sasl.h> |
| 62 | #include <saslplug.h> | |
| 62 | 63 | |
| 63 | 64 | #include "common.h" |
| 64 | 65 | |
| 183 | 184 | /* callbacks we support */ |
| 184 | 185 | static sasl_callback_t callbacks[] = { |
| 185 | 186 | { |
| 186 | SASL_CB_GETREALM, &getrealm, NULL | |
| 187 | SASL_CB_GETREALM, (sasl_callback_ft)&getrealm, NULL | |
| 187 | 188 | }, { |
| 188 | SASL_CB_USER, &simple, NULL | |
| 189 | SASL_CB_USER, (sasl_callback_ft)&simple, NULL | |
| 189 | 190 | }, { |
| 190 | SASL_CB_AUTHNAME, &simple, NULL | |
| 191 | SASL_CB_AUTHNAME, (sasl_callback_ft)&simple, NULL | |
| 191 | 192 | }, { |
| 192 | SASL_CB_PASS, &getsecret, NULL | |
| 193 | SASL_CB_PASS, (sasl_callback_ft)&getsecret, NULL | |
| 193 | 194 | }, { |
| 194 | 195 | SASL_CB_LIST_END, NULL, NULL |
| 195 | 196 | } |
| 44 | 44 | config/missing config/mkinstalldirs getaddrinfo.c \ |
| 45 | 45 | getnameinfo.c |
| 46 | 46 | ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 |
| 47 | am__aclocal_m4_deps = $(top_srcdir)/../config/kerberos_v4.m4 \ | |
| 48 | $(top_srcdir)/../config/sasldb.m4 \ | |
| 47 | am__aclocal_m4_deps = $(top_srcdir)/config/kerberos_v4.m4 \ | |
| 48 | $(top_srcdir)/config/sasldb.m4 \ | |
| 49 | 49 | $(top_srcdir)/../cmulocal/berkdb.m4 \ |
| 50 | 50 | $(top_srcdir)/../cmulocal/bsd_sockets.m4 \ |
| 51 | 51 | $(top_srcdir)/../cmulocal/c-attribute.m4 \ |
| 948 | 948 | AC_SUBST([am__untar]) |
| 949 | 949 | ]) # _AM_PROG_TAR |
| 950 | 950 | |
| 951 | m4_include([../config/kerberos_v4.m4]) | |
| 952 | m4_include([../config/sasldb.m4]) | |
| 951 | m4_include([config/kerberos_v4.m4]) | |
| 952 | m4_include([config/sasldb.m4]) | |
| 953 | 953 | m4_include([../cmulocal/berkdb.m4]) |
| 954 | 954 | m4_include([../cmulocal/bsd_sockets.m4]) |
| 955 | 955 | m4_include([../cmulocal/c-attribute.m4]) |
| 39 | 39 | #include <unistd.h> |
| 40 | 40 | #include <string.h> |
| 41 | 41 | #include <pwd.h> |
| 42 | #include <errno.h> | |
| 43 | #include <syslog.h> | |
| 42 | 44 | |
| 43 | 45 | #ifdef HAVE_CRYPT_H |
| 44 | 46 | #include <crypt.h> |
| 54 | 56 | # include <des.h> |
| 55 | 57 | # endif /* WITH_SSL_DES */ |
| 56 | 58 | # endif /* WITH_DES */ |
| 59 | ||
| 60 | # include "globals.h" | |
| 57 | 61 | /* END PUBLIC DEPENDENCIES */ |
| 58 | 62 | |
| 59 | 63 | #define RETURN(x) return strdup(x) |
| 72 | 76 | { |
| 73 | 77 | /* VARIABLES */ |
| 74 | 78 | struct passwd *pw; /* pointer to passwd file entry */ |
| 79 | int errnum; | |
| 75 | 80 | /* END VARIABLES */ |
| 76 | 81 | |
| 82 | errno = 0; | |
| 77 | 83 | pw = getpwnam(login); |
| 84 | errnum = errno; | |
| 78 | 85 | endpwent(); |
| 79 | 86 | |
| 80 | 87 | if (pw == NULL) { |
| 81 | RETURN("NO"); | |
| 88 | if (errnum != 0) { | |
| 89 | char *errstr; | |
| 90 | ||
| 91 | if (flags & VERBOSE) { | |
| 92 | syslog(LOG_DEBUG, "DEBUG: auth_getpwent: getpwnam(%s) failure: %m", login); | |
| 93 | } | |
| 94 | if (asprintf(&errstr, "NO Username lookup failure: %s", strerror(errno)) == -1) { | |
| 95 | /* XXX the hidden strdup() will likely fail and return NULL here.... */ | |
| 96 | RETURN("NO Username lookup failure: unknown error (ENOMEM formatting strerror())"); | |
| 97 | } | |
| 98 | return errstr; | |
| 99 | } else { | |
| 100 | if (flags & VERBOSE) { | |
| 101 | syslog(LOG_DEBUG, "DEBUG: auth_getpwent: getpwnam(%s): invalid username", login); | |
| 102 | } | |
| 103 | RETURN("NO Invalid username"); | |
| 104 | } | |
| 82 | 105 | } |
| 83 | 106 | |
| 84 | 107 | if (strcmp(pw->pw_passwd, (const char *)crypt(password, pw->pw_passwd))) { |
| 85 | RETURN("NO"); | |
| 108 | if (flags & VERBOSE) { | |
| 109 | syslog(LOG_DEBUG, "DEBUG: auth_getpwent: %s: invalid password", login); | |
| 110 | } | |
| 111 | RETURN("NO Incorrect password"); | |
| 86 | 112 | } |
| 87 | 113 | |
| 114 | if (flags & VERBOSE) { | |
| 115 | syslog(LOG_DEBUG, "DEBUG: auth_getpwent: OK: %s", login); | |
| 116 | } | |
| 88 | 117 | RETURN("OK"); |
| 89 | 118 | } |
| 90 | 119 | |
| 178 | 178 | char in = string[inidx]; |
| 179 | 179 | if (!(in >= 'a' && in <= 'z') && |
| 180 | 180 | !(in >= 'A' && in <= 'Z') && |
| 181 | !(in >= '0' && in <= '9') && | |
| 182 | in != '&' && in != '=' && in != '-' && in != '_') { | |
| 181 | !(in >= '0' && in <= '9')) { | |
| 183 | 182 | |
| 184 | 183 | /* encode it */ |
| 185 | 184 | if (outidx+3 > alloc) { |
| 241 | 240 | int biggest; |
| 242 | 241 | size_t i; |
| 243 | 242 | /* END VARIABLES */ |
| 243 | ||
| 244 | user = url_escape(user); | |
| 245 | if (!user) { | |
| 246 | logger(LOG_ERR, "auth_httpform:create_post_data", "failed to allocate memory"); | |
| 247 | return NULL; | |
| 248 | } | |
| 249 | ||
| 250 | password = url_escape(password); | |
| 251 | if (!password) { | |
| 252 | memset(user, 0, strlen(user)); | |
| 253 | free(user); | |
| 254 | logger(LOG_ERR, "auth_httpform:create_post_data", "failed to allocate memory"); | |
| 255 | return NULL; | |
| 256 | } | |
| 257 | ||
| 258 | realm = url_escape(realm); | |
| 259 | if (!realm) { | |
| 260 | memset(user, 0, strlen(user)); | |
| 261 | free(user); | |
| 262 | memset(password, 0, strlen(password)); | |
| 263 | free(password); | |
| 264 | logger(LOG_ERR, "auth_httpform:create_post_data", "failed to allocate memory"); | |
| 265 | return NULL; | |
| 266 | } | |
| 244 | 267 | |
| 245 | 268 | /* calculate memory needed for creating the complete query string. */ |
| 246 | 269 | ulen = strlen(user); |
| 247 | 270 | plen = strlen(password); |
| 248 | 271 | rlen = strlen(realm); |
| 249 | ||
| 272 | ||
| 250 | 273 | /* what if we have multiple %foo occurrences in the input query? */ |
| 251 | 274 | for (i = 0; i < strlen(formdata); i++) { |
| 252 | 275 | if (formdata[i] == '%') { |
| 265 | 288 | |
| 266 | 289 | if (!buf) { |
| 267 | 290 | logger(LOG_ERR, "auth_httpform:create_post_data", "failed to allocate memory"); |
| 268 | return NULL; | |
| 291 | goto CLEANUP; | |
| 269 | 292 | } |
| 270 | 293 | |
| 271 | 294 | buf_ptr = buf; |
| 307 | 330 | /* don't forget the rest */ |
| 308 | 331 | memcpy(buf_ptr, line_ptr, strlen(line_ptr)+1); |
| 309 | 332 | |
| 333 | CLEANUP: | |
| 334 | memset(user, 0, strlen(user)); | |
| 335 | memset(password, 0, strlen(password)); | |
| 336 | memset(realm, 0, strlen(realm)); | |
| 337 | free(user); | |
| 338 | free(password); | |
| 339 | free(realm); | |
| 340 | ||
| 310 | 341 | return buf; |
| 311 | 342 | } |
| 312 | 343 | |
| 470 | 501 | int s=-1; /* socket to remote auth host */ |
| 471 | 502 | struct addrinfo *r; /* remote socket address info */ |
| 472 | 503 | char *req; /* request, with user and pw */ |
| 473 | char *escreq; /* URL-escaped request */ | |
| 474 | 504 | char *c; /* scratch pointer */ |
| 475 | 505 | int rc; /* return code scratch area */ |
| 476 | 506 | char postbuf[RESP_LEN]; /* request buffer */ |
| 534 | 564 | syslog(LOG_WARNING, "auth_httpform: create_post_data == NULL"); |
| 535 | 565 | return strdup(RESP_IERROR); |
| 536 | 566 | } |
| 537 | escreq = url_escape(req); | |
| 538 | if (escreq == NULL) { | |
| 539 | memset(req, 0, strlen(req)); | |
| 540 | free(req); | |
| 541 | close(s); | |
| 542 | syslog(LOG_WARNING, "auth_httpform: url_escape == NULL"); | |
| 543 | return strdup(RESP_IERROR); | |
| 544 | } | |
| 545 | 567 | |
| 546 | 568 | postlen = snprintf(postbuf, RESP_LEN-1, |
| 547 | 569 | "POST %s HTTP/1.1" CRLF |
| 551 | 573 | "Content-Type: application/x-www-form-urlencoded" CRLF |
| 552 | 574 | "Content-Length: %d" TWO_CRLF |
| 553 | 575 | "%s", |
| 554 | r_uri, r_host, r_port, strlen(escreq), escreq); | |
| 576 | r_uri, r_host, r_port, strlen(req), req); | |
| 555 | 577 | |
| 556 | 578 | if (flags & VERBOSE) { |
| 557 | 579 | syslog(LOG_DEBUG, "auth_httpform: sending %s %s %s", |
| 558 | r_host, r_uri, escreq); | |
| 580 | r_host, r_uri, req); | |
| 559 | 581 | } |
| 560 | 582 | |
| 561 | 583 | /* send it */ |
| 567 | 589 | syslog(LOG_WARNING, "auth_httpform: failed to send request"); |
| 568 | 590 | memset(req, 0, strlen(req)); |
| 569 | 591 | free(req); |
| 570 | memset(escreq, 0, strlen(escreq)); | |
| 571 | free(escreq); | |
| 572 | 592 | memset(postbuf, 0, postlen); |
| 573 | 593 | close(s); |
| 574 | 594 | return strdup(RESP_IERROR); |
| 577 | 597 | /* don't need these any longer */ |
| 578 | 598 | memset(req, 0, strlen(req)); |
| 579 | 599 | free(req); |
| 580 | memset(escreq, 0, strlen(escreq)); | |
| 581 | free(escreq); | |
| 582 | 600 | memset(postbuf, 0, postlen); |
| 583 | 601 | |
| 584 | 602 | /* read and parse the response */ |
| 337 | 337 | /* all is good now */ |
| 338 | 338 | result = 1; |
| 339 | 339 | fini: |
| 340 | krb5_free_data_contents(context, &packet); | |
| 340 | if (!k5_retcode) { | |
| 341 | krb5_free_data_contents(context, &packet); | |
| 342 | } | |
| 341 | 343 | krb5_free_principal(context, server); |
| 342 | 344 | |
| 343 | 345 | return result; |
| 0 | ||
| 0 | 1 | /* MODULE: auth_rimap */ |
| 1 | 2 | |
| 2 | 3 | /* COPYRIGHT |
| 52 | 53 | * END SYNOPSIS */ |
| 53 | 54 | |
| 54 | 55 | #ifdef __GNUC__ |
| 55 | #ident "$Id: auth_rimap.c,v 1.13 2008/01/23 19:54:54 murch Exp $" | |
| 56 | #ident "$Id: auth_rimap.c,v 1.14 2011/09/22 14:39:03 mel Exp $" | |
| 56 | 57 | #endif |
| 57 | 58 | |
| 58 | 59 | /* PUBLIC DEPENDENCIES */ |
| 198 | 199 | } |
| 199 | 200 | *p2++ = *p1++; |
| 200 | 201 | } |
| 201 | strcat(p2, "\""); | |
| 202 | strcpy(p2, "\""); | |
| 202 | 203 | return c; |
| 203 | 204 | } |
| 204 | 205 | |
| 366 | 367 | alarm(NETWORK_IO_TIMEOUT); |
| 367 | 368 | rc = read(s, rbuf, sizeof(rbuf)); |
| 368 | 369 | alarm(0); |
| 370 | if ( rc>0 ) { | |
| 371 | /* check if there is more to read */ | |
| 372 | fd_set perm; | |
| 373 | int fds, ret; | |
| 374 | struct timeval timeout; | |
| 375 | ||
| 376 | FD_ZERO(&perm); | |
| 377 | FD_SET(s, &perm); | |
| 378 | fds = s +1; | |
| 379 | ||
| 380 | timeout.tv_sec = 1; | |
| 381 | timeout.tv_usec = 0; | |
| 382 | while( select (fds, &perm, NULL, NULL, &timeout ) >0 ) { | |
| 383 | if ( FD_ISSET(s, &perm) ) { | |
| 384 | ret = read(s, rbuf+rc, sizeof(rbuf)-rc); | |
| 385 | if ( ret<0 ) { | |
| 386 | rc = ret; | |
| 387 | break; | |
| 388 | } else { | |
| 389 | rc += ret; | |
| 390 | } | |
| 391 | } | |
| 392 | } | |
| 393 | } | |
| 369 | 394 | if (rc == -1) { |
| 370 | 395 | syslog(LOG_WARNING, "auth_rimap: read (banner): %m"); |
| 371 | 396 | (void) close(s); |
| 455 | 480 | alarm(NETWORK_IO_TIMEOUT); |
| 456 | 481 | rc = read(s, rbuf, sizeof(rbuf)); |
| 457 | 482 | alarm(0); |
| 483 | if ( rc>0 ) { | |
| 484 | /* check if there is more to read */ | |
| 485 | fd_set perm; | |
| 486 | int fds, ret; | |
| 487 | struct timeval timeout; | |
| 488 | ||
| 489 | FD_ZERO(&perm); | |
| 490 | FD_SET(s, &perm); | |
| 491 | fds = s +1; | |
| 492 | ||
| 493 | timeout.tv_sec = 1; | |
| 494 | timeout.tv_usec = 0; | |
| 495 | while( select (fds, &perm, NULL, NULL, &timeout ) >0 ) { | |
| 496 | if ( FD_ISSET(s, &perm) ) { | |
| 497 | ret = read(s, rbuf+rc, sizeof(rbuf)-rc); | |
| 498 | if ( ret<0 ) { | |
| 499 | rc = ret; | |
| 500 | break; | |
| 501 | } else { | |
| 502 | rc += ret; | |
| 503 | } | |
| 504 | } | |
| 505 | } | |
| 506 | } | |
| 458 | 507 | (void) close(s); /* we're done with the remote */ |
| 459 | 508 | if (rc == -1) { |
| 460 | 509 | syslog(LOG_WARNING, "auth_rimap: read (response): %m"); |
| 43 | 43 | # include <sys/types.h> |
| 44 | 44 | # include <time.h> |
| 45 | 45 | # include <pwd.h> |
| 46 | # include <errno.h> | |
| 46 | 47 | # include <syslog.h> |
| 47 | 48 | |
| 48 | 49 | #ifdef HAVE_CRYPT_H |
| 59 | 60 | # endif /* WITH_SSL_DES */ |
| 60 | 61 | # endif /* WITH_DES */ |
| 61 | 62 | |
| 62 | #endif /* ! HAVE_GETSPNAM */ | |
| 63 | # endif /* ! HAVE_GETSPNAM */ | |
| 64 | ||
| 63 | 65 | # ifdef HAVE_GETUSERPW |
| 64 | 66 | # include <userpw.h> |
| 65 | 67 | # include <usersec.h> |
| 108 | 110 | char *cpw; /* pointer to crypt() result */ |
| 109 | 111 | struct passwd *pw; /* return from getpwnam_r() */ |
| 110 | 112 | struct spwd *sp; /* return from getspnam_r() */ |
| 113 | int errnum; | |
| 111 | 114 | # ifdef _REENTRANT |
| 112 | 115 | struct passwd pwbuf; |
| 113 | 116 | char pwdata[PWBUFSZ]; /* pwbuf indirect data goes in here */ |
| 120 | 123 | # define RETURN(x) return strdup(x) |
| 121 | 124 | |
| 122 | 125 | /* |
| 123 | * "Magic" password field entries for SunOS. | |
| 126 | * "Magic" password field entries for SunOS/SysV | |
| 124 | 127 | * |
| 125 | * *LK* is hinted at in the shadow(4) man page, but the | |
| 126 | * only definition for it (that I could find) is in the passmgmt(1M) | |
| 127 | * man page. | |
| 128 | * "*LK*" is defined at in the shadow(4) man page, but of course any string | |
| 129 | * inserted in front of the password will prevent the strings from matching | |
| 128 | 130 | * |
| 129 | 131 | * *NP* is documented in getspnam(3) and indicates the caller had |
| 130 | 132 | * insufficient permission to read the shadow password database |
| 143 | 145 | # else |
| 144 | 146 | pw = getpwnam(login); |
| 145 | 147 | # endif /* _REENTRANT */ |
| 148 | errnum = errno; | |
| 146 | 149 | endpwent(); |
| 150 | ||
| 147 | 151 | if (pw == NULL) { |
| 148 | if (flags & VERBOSE) { | |
| 149 | syslog(LOG_DEBUG, "DEBUG: auth_shadow: getpwnam(%s) returned NULL", login); | |
| 150 | } | |
| 151 | RETURN("NO"); | |
| 152 | if (errnum != 0) { | |
| 153 | char *errstr; | |
| 154 | ||
| 155 | if (flags & VERBOSE) { | |
| 156 | syslog(LOG_DEBUG, "DEBUG: auth_shadow: getpwnam(%s) failure: %m", login); | |
| 157 | } | |
| 158 | if (asprintf(&errstr, "NO Username lookup failure: %s", strerror(errno)) == -1) { | |
| 159 | /* XXX the hidden strdup() will likely fail and return NULL here.... */ | |
| 160 | RETURN("NO Username lookup failure: unknown error (ENOMEM formatting strerror())"); | |
| 161 | } | |
| 162 | return errstr; | |
| 163 | } else { | |
| 164 | if (flags & VERBOSE) { | |
| 165 | syslog(LOG_DEBUG, "DEBUG: auth_shadow: getpwnam(%s): invalid username", login); | |
| 166 | } | |
| 167 | RETURN("NO Invalid username"); | |
| 168 | } | |
| 152 | 169 | } |
| 153 | 170 | |
| 154 | 171 | today = (long)time(NULL)/(24L*60*60); |
| 162 | 179 | # else |
| 163 | 180 | sp = getspnam(login); |
| 164 | 181 | # endif /* _REENTRANT */ |
| 182 | errnum = errno; | |
| 165 | 183 | endspent(); |
| 166 | 184 | |
| 167 | 185 | if (sp == NULL) { |
| 168 | if (flags & VERBOSE) { | |
| 169 | syslog(LOG_DEBUG, "DEBUG: auth_shadow: getspnam(%s) returned NULL", login); | |
| 170 | } | |
| 171 | RETURN("NO"); | |
| 186 | if (errnum != 0) { | |
| 187 | char *errstr; | |
| 188 | ||
| 189 | if (flags & VERBOSE) { | |
| 190 | syslog(LOG_DEBUG, "DEBUG: auth_shadow: getspnam(%s) failure: %m", login); | |
| 191 | } | |
| 192 | if (asprintf(&errstr, "NO Username shadow lookup failure: %s", strerror(errno)) == -1) { | |
| 193 | /* XXX the hidden strdup() will likely fail and return NULL here.... */ | |
| 194 | RETURN("NO Username shadow lookup failure: unknown error (ENOMEM formatting strerror())"); | |
| 195 | } | |
| 196 | return errstr; | |
| 197 | } else { | |
| 198 | if (flags & VERBOSE) { | |
| 199 | syslog(LOG_DEBUG, "DEBUG: auth_shadow: getspnam(%s): invalid shadow username", login); | |
| 200 | } | |
| 201 | RETURN("NO Invalid shadow username"); | |
| 202 | } | |
| 172 | 203 | } |
| 173 | 204 | |
| 174 | 205 | if (!strcmp(sp->sp_pwdp, SHADOW_PW_EPERM)) { |
| 178 | 209 | RETURN("NO Insufficient permission to access NIS authentication database (saslauthd)"); |
| 179 | 210 | } |
| 180 | 211 | |
| 181 | /* | |
| 182 | * Note: no check for SHADOW_PW_LOCKED. Returning a "locked" notification | |
| 183 | * would allow login-id namespace probes, and violates our policy of | |
| 184 | * not returning any information about a login until we have validated | |
| 185 | * the password. | |
| 186 | */ | |
| 187 | 212 | cpw = strdup((const char *)crypt(password, sp->sp_pwdp)); |
| 188 | 213 | if (strcmp(sp->sp_pwdp, cpw)) { |
| 189 | 214 | if (flags & VERBOSE) { |
| 215 | /* | |
| 216 | * This _should_ reveal the SHADOW_PW_LOCKED prefix to an | |
| 217 | * administrator trying to debug the situation, though maybe we | |
| 218 | * should do the check here and be less obtuse about it.... | |
| 219 | */ | |
| 190 | 220 | syslog(LOG_DEBUG, "DEBUG: auth_shadow: pw mismatch: '%s' != '%s'", |
| 191 | 221 | sp->sp_pwdp, cpw); |
| 192 | 222 | } |
| 193 | 223 | free(cpw); |
| 194 | RETURN("NO"); | |
| 224 | RETURN("NO Incorrect password"); | |
| 195 | 225 | } |
| 196 | 226 | free(cpw); |
| 197 | 227 | |
| 249 | 279 | |
| 250 | 280 | if (upw == 0) { |
| 251 | 281 | if (flags & VERBOSE) { |
| 252 | syslog(LOG_DEBUG, "auth_shadow: getuserpw(%s) == 0", | |
| 282 | syslog(LOG_DEBUG, "auth_shadow: getuserpw(%s) failed: %m", | |
| 253 | 283 | login); |
| 254 | 284 | } |
| 255 | RETURN("NO"); | |
| 285 | RETURN("NO Invalid username"); | |
| 256 | 286 | } |
| 257 | 287 | |
| 258 | 288 | if (strcmp(upw->upw_passwd, crypt(password, upw->upw_passwd)) != 0) { |
| 260 | 290 | syslog(LOG_DEBUG, "auth_shadow: pw mismatch: %s != %s", |
| 261 | 291 | password, upw->upw_passwd); |
| 262 | 292 | } |
| 263 | RETURN("NO"); | |
| 293 | RETURN("NO Incorrect password"); | |
| 264 | 294 | } |
| 265 | 295 | |
| 266 | 296 | RETURN("OK"); |
| 115 | 115 | if (complaint) |
| 116 | 116 | snprintf(complaint, complaint_len, "%s: line %d: no colon separator", filename, lineno); |
| 117 | 117 | cfile_free(cf); |
| 118 | fclose(infile); | |
| 118 | 119 | return 0; |
| 119 | 120 | } |
| 120 | 121 | *p++ = '\0'; |
| 125 | 126 | if (complaint) |
| 126 | 127 | snprintf(complaint, complaint_len, "%s: line %d: keyword %s: no value", filename, lineno, key); |
| 127 | 128 | cfile_free(cf); |
| 129 | fclose(infile); | |
| 128 | 130 | return 0; |
| 129 | 131 | } |
| 130 | 132 | |
| 136 | 138 | if (complaint) |
| 137 | 139 | snprintf(complaint, complaint_len, "cfile_read: no memory"); |
| 138 | 140 | cfile_free(cf); |
| 141 | fclose(infile); | |
| 139 | 142 | return 0; |
| 140 | 143 | } |
| 141 | 144 | } |
| 146 | 149 | snprintf(complaint, complaint_len, "cfile_read: no memory"); |
| 147 | 150 | cf->n_kv++; /* maybe one strdup() worked */ |
| 148 | 151 | cfile_free(cf); |
| 152 | fclose(infile); | |
| 149 | 153 | return 0; |
| 150 | 154 | } |
| 151 | 155 | |
| 0 | dnl checking for kerberos 4 libraries (and DES) | |
| 1 | ||
| 2 | AC_DEFUN([SASL_DES_CHK], [ | |
| 3 | AC_ARG_WITH(des, [ --with-des=DIR with DES (look in DIR) [yes] ], | |
| 4 | with_des=$withval, | |
| 5 | with_des=yes) | |
| 6 | ||
| 7 | LIB_DES="" | |
| 8 | if test "$with_des" != no; then | |
| 9 | if test -d $with_des; then | |
| 10 | CPPFLAGS="$CPPFLAGS -I${with_des}/include" | |
| 11 | LDFLAGS="$LDFLAGS -L${with_des}/lib" | |
| 12 | fi | |
| 13 | ||
| 14 | if test "$with_openssl" != no; then | |
| 15 | dnl check for openssl installing -lcrypto, then make vanilla check | |
| 16 | AC_CHECK_LIB(crypto, des_cbc_encrypt, [ | |
| 17 | AC_CHECK_HEADER(openssl/des.h, [AC_DEFINE(WITH_SSL_DES,[],[Use OpenSSL DES Implementation]) | |
| 18 | LIB_DES="-lcrypto"; | |
| 19 | with_des=yes], | |
| 20 | with_des=no)], | |
| 21 | with_des=no, $LIB_RSAREF) | |
| 22 | ||
| 23 | dnl same test again, different symbol name | |
| 24 | if test "$with_des" = no; then | |
| 25 | AC_CHECK_LIB(crypto, DES_cbc_encrypt, [ | |
| 26 | AC_CHECK_HEADER(openssl/des.h, [AC_DEFINE(WITH_SSL_DES,[],[Use OpenSSL DES Implementation]) | |
| 27 | LIB_DES="-lcrypto"; | |
| 28 | with_des=yes], | |
| 29 | with_des=no)], | |
| 30 | with_des=no, $LIB_RSAREF) | |
| 31 | fi | |
| 32 | fi | |
| 33 | ||
| 34 | if test "$with_des" = no; then | |
| 35 | AC_CHECK_LIB(des, des_cbc_encrypt, [LIB_DES="-ldes"; | |
| 36 | with_des=yes], with_des=no) | |
| 37 | fi | |
| 38 | ||
| 39 | if test "$with_des" = no; then | |
| 40 | AC_CHECK_LIB(des425, des_cbc_encrypt, [LIB_DES="-ldes425"; | |
| 41 | with_des=yes], with_des=no) | |
| 42 | fi | |
| 43 | ||
| 44 | if test "$with_des" = no; then | |
| 45 | AC_CHECK_LIB(des524, des_cbc_encrypt, [LIB_DES="-ldes524"; | |
| 46 | with_des=yes], with_des=no) | |
| 47 | fi | |
| 48 | ||
| 49 | if test "$with_des" = no; then | |
| 50 | dnl if openssl is around, we might be able to use that for des | |
| 51 | ||
| 52 | dnl if openssl has been compiled with the rsaref2 libraries, | |
| 53 | dnl we need to include the rsaref libraries in the crypto check | |
| 54 | LIB_RSAREF="" | |
| 55 | AC_CHECK_LIB(rsaref, RSAPublicEncrypt, | |
| 56 | LIB_RSAREF="-lRSAglue -lrsaref"; cmu_have_rsaref=yes, | |
| 57 | cmu_have_rsaref=no) | |
| 58 | ||
| 59 | AC_CHECK_LIB(crypto, des_cbc_encrypt, [ | |
| 60 | AC_CHECK_HEADER(openssl/des.h, [AC_DEFINE(WITH_SSL_DES,[],[Use OpenSSL DES Implementation]) | |
| 61 | LIB_DES="-lcrypto"; | |
| 62 | with_des=yes], | |
| 63 | with_des=no)], | |
| 64 | with_des=no, $LIB_RSAREF) | |
| 65 | fi | |
| 66 | fi | |
| 67 | ||
| 68 | if test "$with_des" != no; then | |
| 69 | AC_DEFINE(WITH_DES,[],[Use DES]) | |
| 70 | fi | |
| 71 | ||
| 72 | AC_SUBST(LIB_DES) | |
| 73 | ]) | |
| 74 | ||
| 75 | AC_DEFUN([SASL_KERBEROS_V4_CHK], [ | |
| 76 | AC_REQUIRE([SASL_DES_CHK]) | |
| 77 | ||
| 78 | AC_ARG_ENABLE(krb4, [ --enable-krb4 enable KERBEROS_V4 authentication [[no]] ], | |
| 79 | krb4=$enableval, | |
| 80 | krb4=no) | |
| 81 | ||
| 82 | if test "$krb4" != no; then | |
| 83 | dnl In order to compile kerberos4, we need libkrb and libdes. | |
| 84 | dnl (We've already gotten libdes from SASL_DES_CHK) | |
| 85 | dnl we might need -lresolv for kerberos | |
| 86 | AC_CHECK_LIB(resolv,res_search) | |
| 87 | ||
| 88 | dnl if we were ambitious, we would look more aggressively for the | |
| 89 | dnl krb4 install | |
| 90 | if test -d ${krb4}; then | |
| 91 | AC_CACHE_CHECK(for Kerberos includes, cyrus_krbinclude, [ | |
| 92 | for krbhloc in include/kerberosIV include/kerberos include | |
| 93 | do | |
| 94 | if test -f ${krb4}/${krbhloc}/krb.h ; then | |
| 95 | cyrus_krbinclude=${krb4}/${krbhloc} | |
| 96 | break | |
| 97 | fi | |
| 98 | done | |
| 99 | ]) | |
| 100 | ||
| 101 | if test -n "${cyrus_krbinclude}"; then | |
| 102 | CPPFLAGS="$CPPFLAGS -I${cyrus_krbinclude}" | |
| 103 | fi | |
| 104 | LDFLAGS="$LDFLAGS -L$krb4/lib" | |
| 105 | fi | |
| 106 | ||
| 107 | if test "$with_des" != no; then | |
| 108 | AC_CHECK_HEADER(krb.h, [ | |
| 109 | AC_CHECK_LIB(com_err, com_err, [ | |
| 110 | AC_CHECK_LIB(krb, krb_mk_priv, | |
| 111 | [COM_ERR="-lcom_err"; SASL_KRB_LIB="-lkrb"; krb4lib="yes"], | |
| 112 | krb4lib=no, $LIB_DES -lcom_err)], [ | |
| 113 | AC_CHECK_LIB(krb, krb_mk_priv, | |
| 114 | [COM_ERR=""; SASL_KRB_LIB="-lkrb"; krb4lib="yes"], | |
| 115 | krb4lib=no, $LIB_DES)])], krb4="no") | |
| 116 | ||
| 117 | if test "$krb4" != "no" -a "$krb4lib" = "no"; then | |
| 118 | AC_CHECK_LIB(krb4, krb_mk_priv, | |
| 119 | [COM_ERR=""; SASL_KRB_LIB="-lkrb4"; krb4=yes], | |
| 120 | krb4=no, $LIB_DES) | |
| 121 | fi | |
| 122 | if test "$krb4" = no; then | |
| 123 | AC_WARN(No Kerberos V4 found) | |
| 124 | fi | |
| 125 | else | |
| 126 | AC_WARN(No DES library found for Kerberos V4 support) | |
| 127 | krb4=no | |
| 128 | fi | |
| 129 | fi | |
| 130 | ||
| 131 | if test "$krb4" != no; then | |
| 132 | cmu_save_LIBS="$LIBS" | |
| 133 | LIBS="$LIBS $SASL_KRB_LIB" | |
| 134 | AC_CHECK_FUNCS(krb_get_err_text) | |
| 135 | LIBS="$cmu_save_LIBS" | |
| 136 | fi | |
| 137 | ||
| 138 | AC_MSG_CHECKING(KERBEROS_V4) | |
| 139 | if test "$krb4" != no; then | |
| 140 | AC_MSG_RESULT(enabled) | |
| 141 | SASL_MECHS="$SASL_MECHS libkerberos4.la" | |
| 142 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/kerberos4.c" | |
| 143 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS kerberos4.o" | |
| 144 | AC_DEFINE(STATIC_KERBEROS4,[],[User KERBEROS_V4 Staticly]) | |
| 145 | AC_DEFINE(HAVE_KRB,[],[Do we have Kerberos 4 Support?]) | |
| 146 | SASL_KRB_LIB="$SASL_KRB_LIB $LIB_DES $COM_ERR" | |
| 147 | else | |
| 148 | AC_MSG_RESULT(disabled) | |
| 149 | fi | |
| 150 | AC_SUBST(SASL_KRB_LIB) | |
| 151 | ]) | |
| 152 |
| 0 | ## libtool.m4 - Configure libtool for the target system. -*-Shell-script-*- | |
| 1 | ## Copyright (C) 1996-1999 Free Software Foundation, Inc. | |
| 2 | ## Originally by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996 | |
| 3 | ## | |
| 4 | ## This program is free software; you can redistribute it and/or modify | |
| 5 | ## it under the terms of the GNU General Public License as published by | |
| 6 | ## the Free Software Foundation; either version 2 of the License, or | |
| 7 | ## (at your option) any later version. | |
| 8 | ## | |
| 9 | ## This program is distributed in the hope that it will be useful, but | |
| 10 | ## WITHOUT ANY WARRANTY; without even the implied warranty of | |
| 11 | ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | |
| 12 | ## General Public License for more details. | |
| 13 | ## | |
| 14 | ## You should have received a copy of the GNU General Public License | |
| 15 | ## along with this program; if not, write to the Free Software | |
| 16 | ## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. | |
| 17 | ## | |
| 18 | ## As a special exception to the GNU General Public License, if you | |
| 19 | ## distribute this file as part of a program that contains a | |
| 20 | ## configuration script generated by Autoconf, you may include it under | |
| 21 | ## the same distribution terms that you use for the rest of that program. | |
| 22 | ||
| 23 | # serial 40 AC_PROG_LIBTOOL | |
| 24 | AC_DEFUN([AC_PROG_LIBTOOL], | |
| 25 | [AC_REQUIRE([AC_LIBTOOL_SETUP])dnl | |
| 26 | ||
| 27 | # Save cache, so that ltconfig can load it | |
| 28 | AC_CACHE_SAVE | |
| 29 | ||
| 30 | # Actually configure libtool. ac_aux_dir is where install-sh is found. | |
| 31 | CC="$CC" CFLAGS="$CFLAGS" CPPFLAGS="$CPPFLAGS" \ | |
| 32 | LD="$LD" LDFLAGS="$LDFLAGS" LIBS="$LIBS" \ | |
| 33 | LN_S="$LN_S" NM="$NM" RANLIB="$RANLIB" \ | |
| 34 | DLLTOOL="$DLLTOOL" AS="$AS" OBJDUMP="$OBJDUMP" \ | |
| 35 | ${CONFIG_SHELL-/bin/sh} $ac_aux_dir/ltconfig --no-reexec \ | |
| 36 | $libtool_flags --no-verify $ac_aux_dir/ltmain.sh $lt_target \ | |
| 37 | || AC_MSG_ERROR([libtool configure failed]) | |
| 38 | ||
| 39 | # Reload cache, that may have been modified by ltconfig | |
| 40 | AC_CACHE_LOAD | |
| 41 | ||
| 42 | # This can be used to rebuild libtool when needed | |
| 43 | LIBTOOL_DEPS="$ac_aux_dir/ltconfig $ac_aux_dir/ltmain.sh" | |
| 44 | ||
| 45 | # Always use our own libtool. | |
| 46 | LIBTOOL='$(SHELL) $(top_builddir)/libtool' | |
| 47 | AC_SUBST(LIBTOOL)dnl | |
| 48 | ||
| 49 | # Redirect the config.log output again, so that the ltconfig log is not | |
| 50 | # clobbered by the next message. | |
| 51 | exec 5>>./config.log | |
| 52 | ]) | |
| 53 | ||
| 54 | AC_DEFUN([AC_LIBTOOL_SETUP], | |
| 55 | [AC_PREREQ(2.13)dnl | |
| 56 | AC_REQUIRE([AC_ENABLE_SHARED])dnl | |
| 57 | AC_REQUIRE([AC_ENABLE_STATIC])dnl | |
| 58 | AC_REQUIRE([AC_ENABLE_FAST_INSTALL])dnl | |
| 59 | AC_REQUIRE([AC_CANONICAL_HOST])dnl | |
| 60 | AC_REQUIRE([AC_CANONICAL_BUILD])dnl | |
| 61 | AC_REQUIRE([AC_PROG_RANLIB])dnl | |
| 62 | AC_REQUIRE([AC_PROG_CC])dnl | |
| 63 | AC_REQUIRE([AC_PROG_LD])dnl | |
| 64 | AC_REQUIRE([AC_PROG_NM])dnl | |
| 65 | AC_REQUIRE([AC_PROG_LN_S])dnl | |
| 66 | dnl | |
| 67 | ||
| 68 | case "$target" in | |
| 69 | NONE) lt_target="$host" ;; | |
| 70 | *) lt_target="$target" ;; | |
| 71 | esac | |
| 72 | ||
| 73 | # Check for any special flags to pass to ltconfig. | |
| 74 | libtool_flags="--cache-file=$cache_file" | |
| 75 | test "$enable_shared" = no && libtool_flags="$libtool_flags --disable-shared" | |
| 76 | test "$enable_static" = no && libtool_flags="$libtool_flags --disable-static" | |
| 77 | test "$enable_fast_install" = no && libtool_flags="$libtool_flags --disable-fast-install" | |
| 78 | test "$ac_cv_prog_gcc" = yes && libtool_flags="$libtool_flags --with-gcc" | |
| 79 | test "$ac_cv_prog_gnu_ld" = yes && libtool_flags="$libtool_flags --with-gnu-ld" | |
| 80 | ifdef([AC_PROVIDE_AC_LIBTOOL_DLOPEN], | |
| 81 | [libtool_flags="$libtool_flags --enable-dlopen"]) | |
| 82 | ifdef([AC_PROVIDE_AC_LIBTOOL_WIN32_DLL], | |
| 83 | [libtool_flags="$libtool_flags --enable-win32-dll"]) | |
| 84 | AC_ARG_ENABLE(libtool-lock, | |
| 85 | [ --disable-libtool-lock avoid locking (might break parallel builds)]) | |
| 86 | test "x$enable_libtool_lock" = xno && libtool_flags="$libtool_flags --disable-lock" | |
| 87 | test x"$silent" = xyes && libtool_flags="$libtool_flags --silent" | |
| 88 | ||
| 89 | # Some flags need to be propagated to the compiler or linker for good | |
| 90 | # libtool support. | |
| 91 | case "$lt_target" in | |
| 92 | *-*-irix6*) | |
| 93 | # Find out which ABI we are using. | |
| 94 | echo '[#]line __oline__ "configure"' > conftest.$ac_ext | |
| 95 | if AC_TRY_EVAL(ac_compile); then | |
| 96 | case "`/usr/bin/file conftest.o`" in | |
| 97 | *32-bit*) | |
| 98 | LD="${LD-ld} -32" | |
| 99 | ;; | |
| 100 | *N32*) | |
| 101 | LD="${LD-ld} -n32" | |
| 102 | ;; | |
| 103 | *64-bit*) | |
| 104 | LD="${LD-ld} -64" | |
| 105 | ;; | |
| 106 | esac | |
| 107 | fi | |
| 108 | rm -rf conftest* | |
| 109 | ;; | |
| 110 | ||
| 111 | *-*-sco3.2v5*) | |
| 112 | # On SCO OpenServer 5, we need -belf to get full-featured binaries. | |
| 113 | SAVE_CFLAGS="$CFLAGS" | |
| 114 | CFLAGS="$CFLAGS -belf" | |
| 115 | AC_CACHE_CHECK([whether the C compiler needs -belf], lt_cv_cc_needs_belf, | |
| 116 | [AC_TRY_LINK([],[],[lt_cv_cc_needs_belf=yes],[lt_cv_cc_needs_belf=no])]) | |
| 117 | if test x"$lt_cv_cc_needs_belf" != x"yes"; then | |
| 118 | # this is probably gcc 2.8.0, egcs 1.0 or newer; no need for -belf | |
| 119 | CFLAGS="$SAVE_CFLAGS" | |
| 120 | fi | |
| 121 | ;; | |
| 122 | ||
| 123 | ifdef([AC_PROVIDE_AC_LIBTOOL_WIN32_DLL], | |
| 124 | [*-*-cygwin* | *-*-mingw*) | |
| 125 | AC_CHECK_TOOL(DLLTOOL, dlltool, false) | |
| 126 | AC_CHECK_TOOL(AS, as, false) | |
| 127 | AC_CHECK_TOOL(OBJDUMP, objdump, false) | |
| 128 | ;; | |
| 129 | ]) | |
| 130 | esac | |
| 131 | ]) | |
| 132 | ||
| 133 | # AC_LIBTOOL_DLOPEN - enable checks for dlopen support | |
| 134 | AC_DEFUN([AC_LIBTOOL_DLOPEN], [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])]) | |
| 135 | ||
| 136 | # AC_LIBTOOL_WIN32_DLL - declare package support for building win32 dll's | |
| 137 | AC_DEFUN([AC_LIBTOOL_WIN32_DLL], [AC_BEFORE([$0], [AC_LIBTOOL_SETUP])]) | |
| 138 | ||
| 139 | # AC_ENABLE_SHARED - implement the --enable-shared flag | |
| 140 | # Usage: AC_ENABLE_SHARED[(DEFAULT)] | |
| 141 | # Where DEFAULT is either `yes' or `no'. If omitted, it defaults to | |
| 142 | # `yes'. | |
| 143 | AC_DEFUN([AC_ENABLE_SHARED], [dnl | |
| 144 | define([AC_ENABLE_SHARED_DEFAULT], ifelse($1, no, no, yes))dnl | |
| 145 | AC_ARG_ENABLE(shared, | |
| 146 | changequote(<<, >>)dnl | |
| 147 | << --enable-shared[=PKGS] build shared libraries [default=>>AC_ENABLE_SHARED_DEFAULT], | |
| 148 | changequote([, ])dnl | |
| 149 | [p=${PACKAGE-default} | |
| 150 | case "$enableval" in | |
| 151 | yes) enable_shared=yes ;; | |
| 152 | no) enable_shared=no ;; | |
| 153 | *) | |
| 154 | enable_shared=no | |
| 155 | # Look at the argument we got. We use all the common list separators. | |
| 156 | IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}:," | |
| 157 | for pkg in $enableval; do | |
| 158 | if test "X$pkg" = "X$p"; then | |
| 159 | enable_shared=yes | |
| 160 | fi | |
| 161 | done | |
| 162 | IFS="$ac_save_ifs" | |
| 163 | ;; | |
| 164 | esac], | |
| 165 | enable_shared=AC_ENABLE_SHARED_DEFAULT)dnl | |
| 166 | ]) | |
| 167 | ||
| 168 | # AC_DISABLE_SHARED - set the default shared flag to --disable-shared | |
| 169 | AC_DEFUN([AC_DISABLE_SHARED], [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl | |
| 170 | AC_ENABLE_SHARED(no)]) | |
| 171 | ||
| 172 | # AC_ENABLE_STATIC - implement the --enable-static flag | |
| 173 | # Usage: AC_ENABLE_STATIC[(DEFAULT)] | |
| 174 | # Where DEFAULT is either `yes' or `no'. If omitted, it defaults to | |
| 175 | # `yes'. | |
| 176 | AC_DEFUN([AC_ENABLE_STATIC], [dnl | |
| 177 | define([AC_ENABLE_STATIC_DEFAULT], ifelse($1, no, no, yes))dnl | |
| 178 | AC_ARG_ENABLE(static, | |
| 179 | changequote(<<, >>)dnl | |
| 180 | << --enable-static[=PKGS] build static libraries [default=>>AC_ENABLE_STATIC_DEFAULT], | |
| 181 | changequote([, ])dnl | |
| 182 | [p=${PACKAGE-default} | |
| 183 | case "$enableval" in | |
| 184 | yes) enable_static=yes ;; | |
| 185 | no) enable_static=no ;; | |
| 186 | *) | |
| 187 | enable_static=no | |
| 188 | # Look at the argument we got. We use all the common list separators. | |
| 189 | IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}:," | |
| 190 | for pkg in $enableval; do | |
| 191 | if test "X$pkg" = "X$p"; then | |
| 192 | enable_static=yes | |
| 193 | fi | |
| 194 | done | |
| 195 | IFS="$ac_save_ifs" | |
| 196 | ;; | |
| 197 | esac], | |
| 198 | enable_static=AC_ENABLE_STATIC_DEFAULT)dnl | |
| 199 | ]) | |
| 200 | ||
| 201 | # AC_DISABLE_STATIC - set the default static flag to --disable-static | |
| 202 | AC_DEFUN([AC_DISABLE_STATIC], [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl | |
| 203 | AC_ENABLE_STATIC(no)]) | |
| 204 | ||
| 205 | ||
| 206 | # AC_ENABLE_FAST_INSTALL - implement the --enable-fast-install flag | |
| 207 | # Usage: AC_ENABLE_FAST_INSTALL[(DEFAULT)] | |
| 208 | # Where DEFAULT is either `yes' or `no'. If omitted, it defaults to | |
| 209 | # `yes'. | |
| 210 | AC_DEFUN([AC_ENABLE_FAST_INSTALL], [dnl | |
| 211 | define([AC_ENABLE_FAST_INSTALL_DEFAULT], ifelse($1, no, no, yes))dnl | |
| 212 | AC_ARG_ENABLE(fast-install, | |
| 213 | changequote(<<, >>)dnl | |
| 214 | << --enable-fast-install[=PKGS] optimize for fast installation [default=>>AC_ENABLE_FAST_INSTALL_DEFAULT], | |
| 215 | changequote([, ])dnl | |
| 216 | [p=${PACKAGE-default} | |
| 217 | case "$enableval" in | |
| 218 | yes) enable_fast_install=yes ;; | |
| 219 | no) enable_fast_install=no ;; | |
| 220 | *) | |
| 221 | enable_fast_install=no | |
| 222 | # Look at the argument we got. We use all the common list separators. | |
| 223 | IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}:," | |
| 224 | for pkg in $enableval; do | |
| 225 | if test "X$pkg" = "X$p"; then | |
| 226 | enable_fast_install=yes | |
| 227 | fi | |
| 228 | done | |
| 229 | IFS="$ac_save_ifs" | |
| 230 | ;; | |
| 231 | esac], | |
| 232 | enable_fast_install=AC_ENABLE_FAST_INSTALL_DEFAULT)dnl | |
| 233 | ]) | |
| 234 | ||
| 235 | # AC_ENABLE_FAST_INSTALL - set the default to --disable-fast-install | |
| 236 | AC_DEFUN([AC_DISABLE_FAST_INSTALL], [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl | |
| 237 | AC_ENABLE_FAST_INSTALL(no)]) | |
| 238 | ||
| 239 | # AC_PROG_LD - find the path to the GNU or non-GNU linker | |
| 240 | AC_DEFUN([AC_PROG_LD], | |
| 241 | [AC_ARG_WITH(gnu-ld, | |
| 242 | [ --with-gnu-ld assume the C compiler uses GNU ld [default=no]], | |
| 243 | test "$withval" = no || with_gnu_ld=yes, with_gnu_ld=no) | |
| 244 | AC_REQUIRE([AC_PROG_CC])dnl | |
| 245 | AC_REQUIRE([AC_CANONICAL_HOST])dnl | |
| 246 | AC_REQUIRE([AC_CANONICAL_BUILD])dnl | |
| 247 | ac_prog=ld | |
| 248 | if test "$ac_cv_prog_gcc" = yes; then | |
| 249 | # Check if gcc -print-prog-name=ld gives a path. | |
| 250 | AC_MSG_CHECKING([for ld used by GCC]) | |
| 251 | ac_prog=`($CC -print-prog-name=ld) 2>&5` | |
| 252 | case "$ac_prog" in | |
| 253 | # Accept absolute paths. | |
| 254 | changequote(,)dnl | |
| 255 | [\\/]* | [A-Za-z]:[\\/]*) | |
| 256 | re_direlt='/[^/][^/]*/\.\./' | |
| 257 | changequote([,])dnl | |
| 258 | # Canonicalize the path of ld | |
| 259 | ac_prog=`echo $ac_prog| sed 's%\\\\%/%g'` | |
| 260 | while echo $ac_prog | grep "$re_direlt" > /dev/null 2>&1; do | |
| 261 | ac_prog=`echo $ac_prog| sed "s%$re_direlt%/%"` | |
| 262 | done | |
| 263 | test -z "$LD" && LD="$ac_prog" | |
| 264 | ;; | |
| 265 | "") | |
| 266 | # If it fails, then pretend we aren't using GCC. | |
| 267 | ac_prog=ld | |
| 268 | ;; | |
| 269 | *) | |
| 270 | # If it is relative, then search for the first ld in PATH. | |
| 271 | with_gnu_ld=unknown | |
| 272 | ;; | |
| 273 | esac | |
| 274 | elif test "$with_gnu_ld" = yes; then | |
| 275 | AC_MSG_CHECKING([for GNU ld]) | |
| 276 | else | |
| 277 | AC_MSG_CHECKING([for non-GNU ld]) | |
| 278 | fi | |
| 279 | AC_CACHE_VAL(ac_cv_path_LD, | |
| 280 | [if test -z "$LD"; then | |
| 281 | IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}${PATH_SEPARATOR-:}" | |
| 282 | for ac_dir in $PATH; do | |
| 283 | test -z "$ac_dir" && ac_dir=. | |
| 284 | if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then | |
| 285 | ac_cv_path_LD="$ac_dir/$ac_prog" | |
| 286 | # Check to see if the program is GNU ld. I'd rather use --version, | |
| 287 | # but apparently some GNU ld's only accept -v. | |
| 288 | # Break only if it was the GNU/non-GNU ld that we prefer. | |
| 289 | if "$ac_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > /dev/null; then | |
| 290 | test "$with_gnu_ld" != no && break | |
| 291 | else | |
| 292 | test "$with_gnu_ld" != yes && break | |
| 293 | fi | |
| 294 | fi | |
| 295 | done | |
| 296 | IFS="$ac_save_ifs" | |
| 297 | else | |
| 298 | ac_cv_path_LD="$LD" # Let the user override the test with a path. | |
| 299 | fi]) | |
| 300 | LD="$ac_cv_path_LD" | |
| 301 | if test -n "$LD"; then | |
| 302 | AC_MSG_RESULT($LD) | |
| 303 | else | |
| 304 | AC_MSG_RESULT(no) | |
| 305 | fi | |
| 306 | test -z "$LD" && AC_MSG_ERROR([no acceptable ld found in \$PATH]) | |
| 307 | AC_PROG_LD_GNU | |
| 308 | ]) | |
| 309 | ||
| 310 | AC_DEFUN([AC_PROG_LD_GNU], | |
| 311 | [AC_CACHE_CHECK([if the linker ($LD) is GNU ld], ac_cv_prog_gnu_ld, | |
| 312 | [# I'd rather use --version here, but apparently some GNU ld's only accept -v. | |
| 313 | if $LD -v 2>&1 </dev/null | egrep '(GNU|with BFD)' 1>&5; then | |
| 314 | ac_cv_prog_gnu_ld=yes | |
| 315 | else | |
| 316 | ac_cv_prog_gnu_ld=no | |
| 317 | fi]) | |
| 318 | ]) | |
| 319 | ||
| 320 | # AC_PROG_NM - find the path to a BSD-compatible name lister | |
| 321 | AC_DEFUN([AC_PROG_NM], | |
| 322 | [AC_MSG_CHECKING([for BSD-compatible nm]) | |
| 323 | AC_CACHE_VAL(ac_cv_path_NM, | |
| 324 | [if test -n "$NM"; then | |
| 325 | # Let the user override the test. | |
| 326 | ac_cv_path_NM="$NM" | |
| 327 | else | |
| 328 | IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}${PATH_SEPARATOR-:}" | |
| 329 | for ac_dir in $PATH /usr/ccs/bin /usr/ucb /bin; do | |
| 330 | test -z "$ac_dir" && ac_dir=. | |
| 331 | if test -f $ac_dir/nm || test -f $ac_dir/nm$ac_exeext ; then | |
| 332 | # Check to see if the nm accepts a BSD-compat flag. | |
| 333 | # Adding the `sed 1q' prevents false positives on HP-UX, which says: | |
| 334 | # nm: unknown option "B" ignored | |
| 335 | if ($ac_dir/nm -B /dev/null 2>&1 | sed '1q'; exit 0) | egrep /dev/null >/dev/null; then | |
| 336 | ac_cv_path_NM="$ac_dir/nm -B" | |
| 337 | break | |
| 338 | elif ($ac_dir/nm -p /dev/null 2>&1 | sed '1q'; exit 0) | egrep /dev/null >/dev/null; then | |
| 339 | ac_cv_path_NM="$ac_dir/nm -p" | |
| 340 | break | |
| 341 | else | |
| 342 | ac_cv_path_NM=${ac_cv_path_NM="$ac_dir/nm"} # keep the first match, but | |
| 343 | continue # so that we can try to find one that supports BSD flags | |
| 344 | fi | |
| 345 | fi | |
| 346 | done | |
| 347 | IFS="$ac_save_ifs" | |
| 348 | test -z "$ac_cv_path_NM" && ac_cv_path_NM=nm | |
| 349 | fi]) | |
| 350 | NM="$ac_cv_path_NM" | |
| 351 | AC_MSG_RESULT([$NM]) | |
| 352 | ]) | |
| 353 | ||
| 354 | # AC_CHECK_LIBM - check for math library | |
| 355 | AC_DEFUN([AC_CHECK_LIBM], | |
| 356 | [AC_REQUIRE([AC_CANONICAL_HOST])dnl | |
| 357 | LIBM= | |
| 358 | case "$lt_target" in | |
| 359 | *-*-beos* | *-*-cygwin*) | |
| 360 | # These system don't have libm | |
| 361 | ;; | |
| 362 | *-ncr-sysv4.3*) | |
| 363 | AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM="-lmw") | |
| 364 | AC_CHECK_LIB(m, main, LIBM="$LIBM -lm") | |
| 365 | ;; | |
| 366 | *) | |
| 367 | AC_CHECK_LIB(m, main, LIBM="-lm") | |
| 368 | ;; | |
| 369 | esac | |
| 370 | ]) | |
| 371 | ||
| 372 | # AC_LIBLTDL_CONVENIENCE[(dir)] - sets LIBLTDL to the link flags for | |
| 373 | # the libltdl convenience library, adds --enable-ltdl-convenience to | |
| 374 | # the configure arguments. Note that LIBLTDL is not AC_SUBSTed, nor | |
| 375 | # is AC_CONFIG_SUBDIRS called. If DIR is not provided, it is assumed | |
| 376 | # to be `${top_builddir}/libltdl'. Make sure you start DIR with | |
| 377 | # '${top_builddir}/' (note the single quotes!) if your package is not | |
| 378 | # flat, and, if you're not using automake, define top_builddir as | |
| 379 | # appropriate in the Makefiles. | |
| 380 | AC_DEFUN([AC_LIBLTDL_CONVENIENCE], [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl | |
| 381 | case "$enable_ltdl_convenience" in | |
| 382 | no) AC_MSG_ERROR([this package needs a convenience libltdl]) ;; | |
| 383 | "") enable_ltdl_convenience=yes | |
| 384 | ac_configure_args="$ac_configure_args --enable-ltdl-convenience" ;; | |
| 385 | esac | |
| 386 | LIBLTDL=ifelse($#,1,$1,['${top_builddir}/libltdl'])/libltdlc.la | |
| 387 | INCLTDL=ifelse($#,1,-I$1,['-I${top_builddir}/libltdl']) | |
| 388 | ]) | |
| 389 | ||
| 390 | # AC_LIBLTDL_INSTALLABLE[(dir)] - sets LIBLTDL to the link flags for | |
| 391 | # the libltdl installable library, and adds --enable-ltdl-install to | |
| 392 | # the configure arguments. Note that LIBLTDL is not AC_SUBSTed, nor | |
| 393 | # is AC_CONFIG_SUBDIRS called. If DIR is not provided, it is assumed | |
| 394 | # to be `${top_builddir}/libltdl'. Make sure you start DIR with | |
| 395 | # '${top_builddir}/' (note the single quotes!) if your package is not | |
| 396 | # flat, and, if you're not using automake, define top_builddir as | |
| 397 | # appropriate in the Makefiles. | |
| 398 | # In the future, this macro may have to be called after AC_PROG_LIBTOOL. | |
| 399 | AC_DEFUN([AC_LIBLTDL_INSTALLABLE], [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl | |
| 400 | AC_CHECK_LIB(ltdl, main, | |
| 401 | [test x"$enable_ltdl_install" != xyes && enable_ltdl_install=no], | |
| 402 | [if test x"$enable_ltdl_install" = xno; then | |
| 403 | AC_MSG_WARN([libltdl not installed, but installation disabled]) | |
| 404 | else | |
| 405 | enable_ltdl_install=yes | |
| 406 | fi | |
| 407 | ]) | |
| 408 | if test x"$enable_ltdl_install" = x"yes"; then | |
| 409 | ac_configure_args="$ac_configure_args --enable-ltdl-install" | |
| 410 | LIBLTDL=ifelse($#,1,$1,['${top_builddir}/libltdl'])/libltdl.la | |
| 411 | INCLTDL=ifelse($#,1,-I$1,['-I${top_builddir}/libltdl']) | |
| 412 | else | |
| 413 | ac_configure_args="$ac_configure_args --enable-ltdl-install=no" | |
| 414 | LIBLTDL="-lltdl" | |
| 415 | INCLTDL= | |
| 416 | fi | |
| 417 | ]) | |
| 418 | ||
| 419 | dnl old names | |
| 420 | AC_DEFUN([AM_PROG_LIBTOOL], [indir([AC_PROG_LIBTOOL])])dnl | |
| 421 | AC_DEFUN([AM_ENABLE_SHARED], [indir([AC_ENABLE_SHARED], $@)])dnl | |
| 422 | AC_DEFUN([AM_ENABLE_STATIC], [indir([AC_ENABLE_STATIC], $@)])dnl | |
| 423 | AC_DEFUN([AM_DISABLE_SHARED], [indir([AC_DISABLE_SHARED], $@)])dnl | |
| 424 | AC_DEFUN([AM_DISABLE_STATIC], [indir([AC_DISABLE_STATIC], $@)])dnl | |
| 425 | AC_DEFUN([AM_PROG_LD], [indir([AC_PROG_LD])])dnl | |
| 426 | AC_DEFUN([AM_PROG_NM], [indir([AC_PROG_NM])])dnl | |
| 427 | ||
| 428 | dnl This is just to silence aclocal about the macro not being used | |
| 429 | ifelse([AC_DISABLE_FAST_INSTALL])dnl |
| 1371 | 1371 | hardcode_shlibpath_var=no |
| 1372 | 1372 | ;; |
| 1373 | 1373 | |
| 1374 | darwin[15]* | rhapsody*) | |
| 1374 | darwin[15].* | rhapsody*) | |
| 1375 | 1375 | allow_undefined_flag='-undefined error' |
| 1376 | archive_cmds='$CC $(test x$module = xyes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs $linkopts -install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != x0.0 && echo $verstring)' | |
| 1376 | archive_cmds='$CC $(test x$module = xyes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs $linkopts $(test x$module != xyes && echo -install_name $rpath/$soname) $(test -n "$verstring" -a x$verstring != x0.0 && echo $verstring)' | |
| 1377 | 1377 | # We need to add '_' to the symbols in $export_symbols first |
| 1378 | 1378 | #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols $lib' |
| 1379 | 1379 | hardcode_direct=yes |
| 0 | dnl Check for PLAIN (and therefore crypt) | |
| 1 | ||
| 2 | AC_DEFUN([SASL_PLAIN_CHK],[ | |
| 3 | AC_REQUIRE([SASL2_CRYPT_CHK]) | |
| 4 | ||
| 5 | dnl PLAIN | |
| 6 | AC_ARG_ENABLE(plain, [ --enable-plain enable PLAIN authentication [yes] ], | |
| 7 | plain=$enableval, | |
| 8 | plain=yes) | |
| 9 | ||
| 10 | PLAIN_LIBS="" | |
| 11 | if test "$plain" != no; then | |
| 12 | dnl In order to compile plain, we need crypt. | |
| 13 | if test "$cmu_have_crypt" = yes; then | |
| 14 | PLAIN_LIBS=$LIB_CRYPT | |
| 15 | fi | |
| 16 | fi | |
| 17 | AC_SUBST(PLAIN_LIBS) | |
| 18 | ||
| 19 | AC_MSG_CHECKING(PLAIN) | |
| 20 | if test "$plain" != no; then | |
| 21 | AC_MSG_RESULT(enabled) | |
| 22 | SASL_MECHS="$SASL_MECHS libplain.la" | |
| 23 | if test "$enable_static" = yes; then | |
| 24 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS plain.o" | |
| 25 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/plain.c" | |
| 26 | AC_DEFINE(STATIC_PLAIN,[],[Link PLAIN Staticly]) | |
| 27 | fi | |
| 28 | else | |
| 29 | AC_MSG_RESULT(disabled) | |
| 30 | fi | |
| 31 | ]) |
| 0 | dnl Functions to check what database to use for libsasldb | |
| 1 | ||
| 2 | dnl Berkeley DB specific checks first.. | |
| 3 | ||
| 4 | dnl Figure out what database type we're using | |
| 5 | AC_DEFUN([SASL_DB_CHECK], [ | |
| 6 | cmu_save_LIBS="$LIBS" | |
| 7 | AC_ARG_WITH(dblib, [ --with-dblib=DBLIB set the DB library to use [berkeley] ], | |
| 8 | dblib=$withval, | |
| 9 | dblib=auto_detect) | |
| 10 | ||
| 11 | CYRUS_BERKELEY_DB_OPTS() | |
| 12 | ||
| 13 | SASL_DB_LIB="" | |
| 14 | ||
| 15 | case "$dblib" in | |
| 16 | dnl this is unbelievably painful due to confusion over what db-3 should be | |
| 17 | dnl named. arg. | |
| 18 | berkeley) | |
| 19 | CYRUS_BERKELEY_DB_CHK() | |
| 20 | CPPFLAGS="${CPPFLAGS} ${BDB_INCADD}" | |
| 21 | SASL_DB_INC=$BDB_INCADD | |
| 22 | SASL_DB_LIB="${BDB_LIBADD}" | |
| 23 | ;; | |
| 24 | gdbm) | |
| 25 | AC_ARG_WITH(gdbm,[ --with-gdbm=PATH use gdbm from PATH], | |
| 26 | with_gdbm="${withval}") | |
| 27 | ||
| 28 | case "$with_gdbm" in | |
| 29 | ""|yes) | |
| 30 | AC_CHECK_HEADER(gdbm.h, [ | |
| 31 | AC_CHECK_LIB(gdbm, gdbm_open, SASL_DB_LIB="-lgdbm", | |
| 32 | dblib="no")], | |
| 33 | dblib="no") | |
| 34 | ;; | |
| 35 | *) | |
| 36 | if test -d $with_gdbm; then | |
| 37 | CPPFLAGS="${CPPFLAGS} -I${with_gdbm}/include" | |
| 38 | LDFLAGS="${LDFLAGS} -L${with_gdbm}/lib" | |
| 39 | SASL_DB_LIB="-lgdbm" | |
| 40 | else | |
| 41 | with_gdbm="no" | |
| 42 | fi | |
| 43 | esac | |
| 44 | ;; | |
| 45 | ndbm) | |
| 46 | dnl We want to attempt to use -lndbm if we can, just in case | |
| 47 | dnl there's some version of it installed and overriding libc | |
| 48 | AC_CHECK_HEADER(ndbm.h, [ | |
| 49 | AC_CHECK_LIB(ndbm, dbm_open, SASL_DB_LIB="-lndbm", [ | |
| 50 | AC_CHECK_FUNC(dbm_open,,dblib="no")])], | |
| 51 | dblib="no") | |
| 52 | ;; | |
| 53 | auto_detect) | |
| 54 | dnl How about berkeley db? | |
| 55 | CYRUS_BERKELEY_DB_CHK() | |
| 56 | if test "$dblib" = no; then | |
| 57 | dnl How about ndbm? | |
| 58 | AC_CHECK_HEADER(ndbm.h, [ | |
| 59 | AC_CHECK_LIB(ndbm, dbm_open, | |
| 60 | dblib="ndbm"; SASL_DB_LIB="-lndbm", | |
| 61 | dblib="weird")], | |
| 62 | dblib="no") | |
| 63 | if test "$dblib" = "weird"; then | |
| 64 | dnl Is ndbm in the standard library? | |
| 65 | AC_CHECK_FUNC(dbm_open, dblib="ndbm", dblib="no") | |
| 66 | fi | |
| 67 | ||
| 68 | if test "$dblib" = no; then | |
| 69 | dnl Can we use gdbm? | |
| 70 | AC_CHECK_HEADER(gdbm.h, [ | |
| 71 | AC_CHECK_LIB(gdbm, gdbm_open, dblib="gdbm"; | |
| 72 | SASL_DB_LIB="-lgdbm", dblib="no")], | |
| 73 | dblib="no") | |
| 74 | fi | |
| 75 | else | |
| 76 | dnl we took Berkeley | |
| 77 | CPPFLAGS="${CPPFLAGS} ${BDB_INCADD}" | |
| 78 | SASL_DB_INC=$BDB_INCADD | |
| 79 | SASL_DB_LIB="${BDB_LIBADD}" | |
| 80 | fi | |
| 81 | ;; | |
| 82 | none) | |
| 83 | ;; | |
| 84 | no) | |
| 85 | ;; | |
| 86 | *) | |
| 87 | AC_MSG_WARN([Bad DB library implementation specified;]) | |
| 88 | AC_ERROR([Use either \"berkeley\", \"gdbm\", \"ndbm\" or \"none\"]) | |
| 89 | dblib=no | |
| 90 | ;; | |
| 91 | esac | |
| 92 | LIBS="$cmu_save_LIBS" | |
| 93 | ||
| 94 | AC_MSG_CHECKING(DB library to use) | |
| 95 | AC_MSG_RESULT($dblib) | |
| 96 | ||
| 97 | SASL_DB_BACKEND="db_${dblib}.lo" | |
| 98 | SASL_DB_BACKEND_STATIC="db_${dblib}.o allockey.o" | |
| 99 | SASL_DB_BACKEND_STATIC_SRCS="\$(top_srcdir)/sasldb/db_${dblib}.c \$(top_srcdir)/sasldb/allockey.c" | |
| 100 | SASL_DB_UTILS="saslpasswd2 sasldblistusers2" | |
| 101 | SASL_DB_MANS="saslpasswd2.8 sasldblistusers2.8" | |
| 102 | ||
| 103 | case "$dblib" in | |
| 104 | gdbm) | |
| 105 | SASL_MECHS="$SASL_MECHS libsasldb.la" | |
| 106 | AC_DEFINE(SASL_GDBM,[],[Use GDBM for SASLdb]) | |
| 107 | ;; | |
| 108 | ndbm) | |
| 109 | SASL_MECHS="$SASL_MECHS libsasldb.la" | |
| 110 | AC_DEFINE(SASL_NDBM,[],[Use NDBM for SASLdb]) | |
| 111 | ;; | |
| 112 | berkeley) | |
| 113 | SASL_MECHS="$SASL_MECHS libsasldb.la" | |
| 114 | AC_DEFINE(SASL_BERKELEYDB,[],[Use BerkeleyDB for SASLdb]) | |
| 115 | ;; | |
| 116 | *) | |
| 117 | AC_MSG_WARN([Disabling SASL authentication database support]) | |
| 118 | dnl note that we do not add libsasldb.la to SASL_MECHS, since it | |
| 119 | dnl will just fail to load anyway. | |
| 120 | SASL_DB_BACKEND="db_none.lo" | |
| 121 | SASL_DB_BACKEND_STATIC="db_none.o" | |
| 122 | SASL_DB_BACKEND_STATIC_SRCS="\$(top_srcdir)/sasldb/db_none.c" | |
| 123 | SASL_DB_UTILS="" | |
| 124 | SASL_DB_MANS="" | |
| 125 | SASL_DB_LIB="" | |
| 126 | ;; | |
| 127 | esac | |
| 128 | ||
| 129 | if test "$enable_static" = yes; then | |
| 130 | if test "$dblib" != "none"; then | |
| 131 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS \$(top_srcdir)/plugins/sasldb.c $SASL_DB_BACKEND_STATIC_SRCS" | |
| 132 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS sasldb.o $SASL_DB_BACKEND_STATIC" | |
| 133 | AC_DEFINE(STATIC_SASLDB,[],[Link SASLdb Staticly]) | |
| 134 | else | |
| 135 | SASL_STATIC_OBJS="$SASL_STATIC_OBJS $SASL_DB_BACKEND_STATIC" | |
| 136 | SASL_STATIC_SRCS="$SASL_STATIC_SRCS $SASL_DB_BACKEND_STATIC_SRCS" | |
| 137 | fi | |
| 138 | fi | |
| 139 | ||
| 140 | AC_SUBST(SASL_DB_UTILS) | |
| 141 | AC_SUBST(SASL_DB_MANS) | |
| 142 | AC_SUBST(SASL_DB_BACKEND) | |
| 143 | AC_SUBST(SASL_DB_BACKEND_STATIC) | |
| 144 | AC_SUBST(SASL_DB_INC) | |
| 145 | AC_SUBST(SASL_DB_LIB) | |
| 146 | ]) | |
| 147 | ||
| 148 | dnl Figure out what database path we're using | |
| 149 | AC_DEFUN([SASL_DB_PATH_CHECK], [ | |
| 150 | AC_ARG_WITH(dbpath, [ --with-dbpath=PATH set the DB path to use [/etc/sasldb2] ], | |
| 151 | dbpath=$withval, | |
| 152 | dbpath=/etc/sasldb2) | |
| 153 | AC_MSG_CHECKING(DB path to use) | |
| 154 | AC_MSG_RESULT($dbpath) | |
| 155 | AC_DEFINE_UNQUOTED(SASL_DB_PATH, "$dbpath", [Path to default SASLdb database])]) |
| 2477 | 2477 | |
| 2478 | 2478 | # Define the identity of the package. |
| 2479 | 2479 | PACKAGE=saslauthd |
| 2480 | VERSION=2.1.25 | |
| 2480 | VERSION=2.1.26 | |
| 2481 | 2481 | |
| 2482 | 2482 | |
| 2483 | 2483 | cat >>confdefs.h <<_ACEOF |
| 9625 | 9625 | |
| 9626 | 9626 | LIBS="$cmu_save_LIBS" |
| 9627 | 9627 | |
| 9628 | cmu_save_LIBS="$LIBS" | |
| 9629 | LIBS="$LIBS $GSSAPIBASE_LIBS" | |
| 9630 | { $as_echo "$as_me:$LINENO: checking for SPNEGO support in GSSAPI libraries" >&5 | |
| 9631 | $as_echo_n "checking for SPNEGO support in GSSAPI libraries... " >&6; } | |
| 9632 | if test "$cross_compiling" = yes; then | |
| 9633 | { { $as_echo "$as_me:$LINENO: error: in \`$ac_pwd':" >&5 | |
| 9634 | $as_echo "$as_me: error: in \`$ac_pwd':" >&2;} | |
| 9635 | { { $as_echo "$as_me:$LINENO: error: cannot run test program while cross compiling | |
| 9636 | See \`config.log' for more details." >&5 | |
| 9637 | $as_echo "$as_me: error: cannot run test program while cross compiling | |
| 9638 | See \`config.log' for more details." >&2;} | |
| 9639 | { (exit 1); exit 1; }; }; } | |
| 9640 | else | |
| 9641 | cat >conftest.$ac_ext <<_ACEOF | |
| 9642 | /* confdefs.h. */ | |
| 9643 | _ACEOF | |
| 9644 | cat confdefs.h >>conftest.$ac_ext | |
| 9645 | cat >>conftest.$ac_ext <<_ACEOF | |
| 9646 | /* end confdefs.h. */ | |
| 9647 | ||
| 9648 | #ifdef HAVE_GSSAPI_H | |
| 9649 | #include <gssapi.h> | |
| 9650 | #else | |
| 9651 | #include <gssapi/gssapi.h> | |
| 9652 | #endif | |
| 9653 | ||
| 9654 | int main(void) | |
| 9655 | { | |
| 9656 | gss_OID_desc spnego_oid = { 6, (void *) "\x2b\x06\x01\x05\x05\x02" }; | |
| 9657 | gss_OID_set mech_set; | |
| 9658 | OM_uint32 min_stat; | |
| 9659 | int have_spnego = 0; | |
| 9660 | ||
| 9661 | if (gss_indicate_mechs(&min_stat, &mech_set) == GSS_S_COMPLETE) { | |
| 9662 | gss_test_oid_set_member(&min_stat, &spnego_oid, mech_set, &have_spnego); | |
| 9663 | gss_release_oid_set(&min_stat, &mech_set); | |
| 9664 | } | |
| 9665 | ||
| 9666 | return (!have_spnego); // 0 = success, 1 = failure | |
| 9667 | } | |
| 9668 | ||
| 9669 | _ACEOF | |
| 9670 | rm -f conftest$ac_exeext | |
| 9671 | if { (ac_try="$ac_link" | |
| 9672 | case "(($ac_try" in | |
| 9673 | *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; | |
| 9674 | *) ac_try_echo=$ac_try;; | |
| 9675 | esac | |
| 9676 | eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" | |
| 9677 | $as_echo "$ac_try_echo") >&5 | |
| 9678 | (eval "$ac_link") 2>&5 | |
| 9679 | ac_status=$? | |
| 9680 | $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 | |
| 9681 | (exit $ac_status); } && { ac_try='./conftest$ac_exeext' | |
| 9682 | { (case "(($ac_try" in | |
| 9683 | *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; | |
| 9684 | *) ac_try_echo=$ac_try;; | |
| 9685 | esac | |
| 9686 | eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" | |
| 9687 | $as_echo "$ac_try_echo") >&5 | |
| 9688 | (eval "$ac_try") 2>&5 | |
| 9689 | ac_status=$? | |
| 9690 | $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 | |
| 9691 | (exit $ac_status); }; }; then | |
| 9692 | ||
| 9693 | cat >>confdefs.h <<\_ACEOF | |
| 9694 | #define HAVE_GSS_SPNEGO /**/ | |
| 9695 | _ACEOF | |
| 9696 | ||
| 9697 | { $as_echo "$as_me:$LINENO: result: yes" >&5 | |
| 9698 | $as_echo "yes" >&6; } | |
| 9699 | else | |
| 9700 | $as_echo "$as_me: program exited with status $ac_status" >&5 | |
| 9701 | $as_echo "$as_me: failed program was:" >&5 | |
| 9702 | sed 's/^/| /' conftest.$ac_ext >&5 | |
| 9703 | ||
| 9704 | ( exit $ac_status ) | |
| 9705 | { $as_echo "$as_me:$LINENO: result: no" >&5 | |
| 9706 | $as_echo "no" >&6; } | |
| 9707 | fi | |
| 9708 | rm -rf conftest.dSYM | |
| 9709 | rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext | |
| 9710 | fi | |
| 9711 | ||
| 9712 | ||
| 9713 | LIBS="$cmu_save_LIBS" | |
| 9714 | ||
| 9628 | 9715 | else |
| 9629 | 9716 | { $as_echo "$as_me:$LINENO: result: disabled" >&5 |
| 9630 | 9717 | $as_echo "disabled" >&6; } |
| 10070 | 10157 | fi |
| 10071 | 10158 | |
| 10072 | 10159 | saved_LIBS=$LIBS |
| 10073 | for dbname in ${with_bdb} db-4.7 db4.7 db47 db-4.6 db4.6 db46 db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 db-4.2 db4.2 db42 db-4.1 db4.1 db41 db-4.0 db4.0 db-4 db40 db4 db-3.3 db3.3 db33 db-3.2 db3.2 db32 db-3.1 db3.1 db31 db-3 db30 db3 db | |
| 10074 | do | |
| 10160 | for dbname in ${with_bdb} \ | |
| 10161 | db-5.2 db5.2 db52 \ | |
| 10162 | db-5.1 db5.2 db51 \ | |
| 10163 | db-5.0 db5.2 db50 \ | |
| 10164 | db-4.8 db4.8 db48 \ | |
| 10165 | db-4.7 db4.7 db47 \ | |
| 10166 | db-4.6 db4.6 db46 \ | |
| 10167 | db-4.5 db4.5 db45 \ | |
| 10168 | db-4.4 db4.4 db44 \ | |
| 10169 | db-4.3 db4.3 db43 \ | |
| 10170 | db-4.2 db4.2 db42 \ | |
| 10171 | db-4.1 db4.1 db41 \ | |
| 10172 | db-4.0 db4.0 db40 db-4 db4 \ | |
| 10173 | db-3.3 db3.3 db33 \ | |
| 10174 | db-3.2 db3.2 db32 \ | |
| 10175 | db-3.1 db3.1 db31 \ | |
| 10176 | db-3.0 db3.0 db30 db-3 db3 \ | |
| 10177 | db | |
| 10178 | do | |
| 10075 | 10179 | LIBS="$saved_LIBS -l$dbname" |
| 10076 | 10180 | cat >conftest.$ac_ext <<_ACEOF |
| 10077 | 10181 | /* confdefs.h. */ |
| 10880 | 10984 | fi |
| 10881 | 10985 | |
| 10882 | 10986 | saved_LIBS=$LIBS |
| 10883 | for dbname in ${with_bdb} db-4.7 db4.7 db47 db-4.6 db4.6 db46 db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 db-4.2 db4.2 db42 db-4.1 db4.1 db41 db-4.0 db4.0 db-4 db40 db4 db-3.3 db3.3 db33 db-3.2 db3.2 db32 db-3.1 db3.1 db31 db-3 db30 db3 db | |
| 10884 | do | |
| 10987 | for dbname in ${with_bdb} \ | |
| 10988 | db-5.2 db5.2 db52 \ | |
| 10989 | db-5.1 db5.2 db51 \ | |
| 10990 | db-5.0 db5.2 db50 \ | |
| 10991 | db-4.8 db4.8 db48 \ | |
| 10992 | db-4.7 db4.7 db47 \ | |
| 10993 | db-4.6 db4.6 db46 \ | |
| 10994 | db-4.5 db4.5 db45 \ | |
| 10995 | db-4.4 db4.4 db44 \ | |
| 10996 | db-4.3 db4.3 db43 \ | |
| 10997 | db-4.2 db4.2 db42 \ | |
| 10998 | db-4.1 db4.1 db41 \ | |
| 10999 | db-4.0 db4.0 db40 db-4 db4 \ | |
| 11000 | db-3.3 db3.3 db33 \ | |
| 11001 | db-3.2 db3.2 db32 \ | |
| 11002 | db-3.1 db3.1 db31 \ | |
| 11003 | db-3.0 db3.0 db30 db-3 db3 \ | |
| 11004 | db | |
| 11005 | do | |
| 10885 | 11006 | LIBS="$saved_LIBS -l$dbname" |
| 10886 | 11007 | cat >conftest.$ac_ext <<_ACEOF |
| 10887 | 11008 | /* confdefs.h. */ |
| 13194 | 13315 | |
| 13195 | 13316 | |
| 13196 | 13317 | |
| 13197 | for ac_func in strlcat strlcpy | |
| 13318 | ||
| 13319 | for ac_func in asprintf strlcat strlcpy | |
| 13198 | 13320 | do |
| 13199 | 13321 | as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` |
| 13200 | 13322 | { $as_echo "$as_me:$LINENO: checking for $ac_func" >&5 |
| 14 | 14 | AC_DEFINE_UNQUOTED(PATH_SASLAUTHD_RUNDIR, "$with_saslauthd",[Location of saslauthd socket]) |
| 15 | 15 | AM_CONDITIONAL(SASLAUTHD, test "$with_saslauthd" != no) |
| 16 | 16 | |
| 17 | AM_INIT_AUTOMAKE(saslauthd,2.1.25) | |
| 17 | AM_INIT_AUTOMAKE(saslauthd,2.1.26) | |
| 18 | 18 | CMU_INIT_AUTOMAKE |
| 19 | 19 | |
| 20 | 20 | dnl Checks for programs. |
| 194 | 194 | dnl Checks for library functions. |
| 195 | 195 | AC_TYPE_SIGNAL |
| 196 | 196 | AC_CHECK_FUNCS(gethostname mkdir socket strdup) |
| 197 | dnl Only look for one or the other | |
| 197 | 198 | AC_CHECK_FUNCS(getspnam getuserpw, break) |
| 198 | AC_CHECK_FUNCS(strlcat strlcpy) | |
| 199 | AC_CHECK_FUNCS(asprintf strlcat strlcpy) | |
| 199 | 200 | |
| 200 | 201 | if test $ac_cv_func_getspnam = yes; then |
| 201 | 202 | AC_MSG_CHECKING(if getpwnam_r/getspnam_r take 5 arguments) |
| 326 | 327 | extern size_t saslauthd_strlcat(char *dst, const char *src, size_t len); |
| 327 | 328 | #define strlcat(x,y,z) saslauthd_strlcat((x),(y),(z)) |
| 328 | 329 | #endif |
| 330 | #ifndef HAVE_ASPRINTF | |
| 331 | extern int asprintf(char **str, const char *fmt, ...); | |
| 332 | #endif | |
| 329 | 333 | |
| 330 | 334 | #endif |
| 331 | 335 | ]) |
| 168 | 168 | *p = tolower(*p); |
| 169 | 169 | p++; |
| 170 | 170 | } |
| 171 | if (*p != ':') | |
| 171 | if (*p != ':') { | |
| 172 | fclose(infile); | |
| 172 | 173 | return LAK_FAIL; |
| 174 | } | |
| 173 | 175 | |
| 174 | 176 | *p++ = '\0'; |
| 175 | 177 | |
| 176 | 178 | while (*p && isspace((int) *p)) |
| 177 | 179 | p++; |
| 178 | 180 | |
| 179 | if (!*p) | |
| 181 | if (!*p) { | |
| 182 | fclose(infile); | |
| 180 | 183 | return LAK_FAIL; |
| 184 | } | |
| 181 | 185 | |
| 182 | 186 | if (!strcasecmp(key, "ldap_servers")) |
| 183 | 187 | strlcpy(conf->servers, p, LAK_URL_LEN); |
| 71 | 71 | --rr Combine the realm with the login (with an ’@’ sign in between). |
| 72 | 72 | e.g. login: "foo" realm: "bar" will get passed as login: |
| 73 | 73 | "foo@bar". Note that the realm will still be passed, which may |
| 74 | lead to unexpected behaviour. | |
| 74 | lead to unexpected behavior for authentication mechanisms that | |
| 75 | make use of the realm, however for mechanisms which don’t, such | |
| 76 | as _g_e_t_p_w_e_n_t, this is the only way to authenticate domain-specific | |
| 77 | users sharing the same userid. | |
| 75 | 78 | |
| 76 | 79 | --vv Print the version number and available authentication mechanisms |
| 77 | 80 | on standard error, then exit. |
| 84 | 87 | AAUUTTHHEENNTTIICCAATTIIOONN MMEECCHHAANNIISSMMSS |
| 85 | 88 | ssaassllaauutthhdd supports one or more "authentication mechanisms", dependent |
| 86 | 89 | upon the facilities provided by the underlying operating system. The |
| 87 | mechanism is selected by the --aahhoo flag from the following list of | |
| 88 | choices: | |
| 90 | mechanism is selected by the --aa flag from the following list of choices: | |
| 89 | 91 | |
| 90 | 92 | dce _(_A_I_X_) |
| 91 | 93 | |
| 185 | 187 | passwd(1), getpwent(3), getspnam(3), getuserpw(3), sasl_checkpass(3) |
| 186 | 188 | sia_authenticate_user(3), |
| 187 | 189 | |
| 188 | CMU-SASL 10 24 2002 CMU-SASL | |
| 190 | CMU-SASL 12 12 2005 CMU-SASL | |
| 11 | 11 | |
| 12 | 12 | /* Define if your getpwnam_r()/getspnam_r() functions take 5 arguments */ |
| 13 | 13 | #undef GETXXNAM_R_5ARG |
| 14 | ||
| 15 | /* Define to 1 if you have the `asprintf' function. */ | |
| 16 | #undef HAVE_ASPRINTF | |
| 14 | 17 | |
| 15 | 18 | /* Define to 1 if you have the <crypt.h> header file. */ |
| 16 | 19 | #undef HAVE_CRYPT_H |
| 75 | 78 | |
| 76 | 79 | /* Define to 1 if you have the `gss_oid_equal' function. */ |
| 77 | 80 | #undef HAVE_GSS_OID_EQUAL |
| 81 | ||
| 82 | /* Define if your GSSAPI implementation supports SPNEGO */ | |
| 83 | #undef HAVE_GSS_SPNEGO | |
| 78 | 84 | |
| 79 | 85 | /* Include HTTP form Support */ |
| 80 | 86 | #undef HAVE_HTTPFORM |
| 328 | 334 | extern size_t saslauthd_strlcat(char *dst, const char *src, size_t len); |
| 329 | 335 | #define strlcat(x,y,z) saslauthd_strlcat((x),(y),(z)) |
| 330 | 336 | #endif |
| 331 | ||
| 332 | #endif | |
| 333 | ||
| 337 | #ifndef HAVE_ASPRINTF | |
| 338 | extern int asprintf(char **str, const char *fmt, ...); | |
| 339 | #endif | |
| 340 | ||
| 341 | #endif | |
| 342 | ||
| 9 | 9 | .\" manpage in saslauthd.8 whenever you change this source |
| 10 | 10 | .\" version. Only the pre-formatted manpage is installed. |
| 11 | 11 | .\" |
| 12 | .Dd 10 24 2002 | |
| 12 | .Dd 12 12 2005 | |
| 13 | 13 | .Dt SASLAUTHD 8 |
| 14 | 14 | .Os "CMU-SASL" |
| 15 | 15 | .Sh NAME |
| 97 | 97 | Disable the use of a lock file for controlling access to accept(). |
| 98 | 98 | .It Fl r |
| 99 | 99 | Combine the realm with the login (with an '@' sign in between). e.g. |
| 100 | login: "foo" realm: "bar" will get passed as login: "foo@bar". Note that | |
| 101 | the realm will still be passed, which may lead to unexpected behaviour. | |
| 100 | login: "foo" realm: "bar" will get passed as login: "foo@bar". Note | |
| 101 | that the realm will still be passed, which may lead to unexpected | |
| 102 | behavior for authentication mechanisms that make use of the realm, | |
| 103 | however for mechanisms which don't, such as | |
| 104 | .Ar getpwent , | |
| 105 | this is the only way to authenticate domain-specific users sharing the | |
| 106 | same userid. | |
| 102 | 107 | .It Fl v |
| 103 | 108 | Print the version number and available authentication |
| 104 | 109 | mechanisms on standard error, then exit. |
| 118 | 123 | .Qq authentication mechanisms , |
| 119 | 124 | dependent upon the facilities provided by the underlying operating system. |
| 120 | 125 | The mechanism is selected by the |
| 121 | .Fl aho | |
| 126 | .Fl a | |
| 122 | 127 | flag from the following list of choices: |
| 123 | 128 | .Bl -tag -width "kerberos4" |
| 124 | 129 | .It Li dce |
| 226 | 226 | } |
| 227 | 227 | } |
| 228 | 228 | |
| 229 | #ifndef HAVE_ASPRINTF | |
| 230 | ||
| 231 | # include <stdarg.h> | |
| 232 | ||
| 233 | /* | |
| 234 | * asprintf -- work around lame systems that haven't added their own yet | |
| 235 | * | |
| 236 | * XXX relies on a valid working (SuSv3) vsnprintf(), OK on SunOS-5.10 BUT NOT BEFORE! | |
| 237 | */ | |
| 238 | int | |
| 239 | asprintf(char **str, | |
| 240 | const char *fmt, | |
| 241 | ...) | |
| 242 | { | |
| 243 | va_list ap; | |
| 244 | char *newstr; | |
| 245 | size_t len; | |
| 246 | int ret; | |
| 247 | ||
| 248 | *str = NULL; | |
| 249 | ||
| 250 | va_start(ap, fmt); | |
| 251 | ret = vsnprintf((char *) NULL, (size_t) 0, fmt, ap); | |
| 252 | va_end(ap); | |
| 253 | if (ret < 0) { | |
| 254 | return ret; | |
| 255 | } | |
| 256 | len = (size_t) ret + 1; /* allow for nul */ | |
| 257 | if ((newstr = malloc(len)) == NULL) { | |
| 258 | return (-1); | |
| 259 | } | |
| 260 | va_start(ap, fmt); | |
| 261 | ret = vsnprintf(newstr, len, fmt, ap); | |
| 262 | va_end(ap); | |
| 263 | if (ret >= 0 && (size_t) ret < len) { /* XXX (ret == len-1) */ | |
| 264 | *str = newstr; | |
| 265 | } else { | |
| 266 | free(newstr); | |
| 267 | return ret; | |
| 268 | } | |
| 269 | ||
| 270 | return ret; | |
| 271 | } | |
| 272 | #endif /* HAVE_ASPRINTF */ | |
| 273 | ||
| 229 | 274 | #ifndef HAVE_STRLCPY |
| 230 | 275 | /* strlcpy -- copy string smartly. |
| 231 | 276 | * |
| 0 | 0 | /* db_berkeley.c--SASL berkeley db interface |
| 1 | 1 | * Rob Siemborski |
| 2 | 2 | * Tim Martin |
| 3 | * $Id: db_berkeley.c,v 1.10 2011/09/01 14:12:18 mel Exp $ | |
| 3 | * $Id: db_berkeley.c,v 1.11 2011/09/12 08:50:47 mel Exp $ | |
| 4 | 4 | */ |
| 5 | 5 | /* |
| 6 | 6 | * Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved. |
| 52 | 52 | #include <errno.h> |
| 53 | 53 | #include "sasldb.h" |
| 54 | 54 | |
| 55 | #define DB_VERSION_FULL ((DB_VERSION_MAJOR << 24) | (DB_VERSION_MINOR << 16) | DB_VERSION_PATCH) | |
| 56 | ||
| 55 | 57 | static int db_ok = 0; |
| 56 | 58 | #if defined(KEEP_DB_OPEN) |
| 57 | 59 | static DB * g_db = NULL; |
| 78 | 80 | #endif |
| 79 | 81 | |
| 80 | 82 | if (utils->getcallback(conn, SASL_CB_GETOPT, |
| 81 | &getopt, &cntxt) == SASL_OK) { | |
| 83 | (sasl_callback_ft *)&getopt, &cntxt) == SASL_OK) { | |
| 82 | 84 | const char *p; |
| 83 | 85 | if (getopt(cntxt, NULL, "sasldb_path", &p, NULL) == SASL_OK |
| 84 | 86 | && p != NULL && *p != 0) { |
| 94 | 96 | #endif |
| 95 | 97 | #endif |
| 96 | 98 | |
| 97 | #if DB_VERSION_MAJOR < 3 | |
| 99 | #if DB_VERSION_FULL < 0x03000000 | |
| 98 | 100 | ret = db_open(path, DB_HASH, flags, 0660, NULL, NULL, mbdb); |
| 99 | #else /* DB_VERSION_MAJOR < 3 */ | |
| 101 | #else /* DB_VERSION_FULL < 0x03000000 */ | |
| 100 | 102 | ret = db_create(mbdb, NULL, 0); |
| 101 | 103 | if (ret == 0 && *mbdb != NULL) |
| 102 | 104 | { |
| 103 | #if DB_VERSION_MAJOR == 4 && DB_VERSION_MINOR >= 1 | |
| 105 | #if DB_VERSION_FULL >= 0x04010000 | |
| 104 | 106 | ret = (*mbdb)->open(*mbdb, NULL, path, NULL, DB_HASH, flags, 0660); |
| 105 | 107 | #else |
| 106 | 108 | ret = (*mbdb)->open(*mbdb, path, NULL, DB_HASH, flags, 0660); |
| 111 | 113 | *mbdb = NULL; |
| 112 | 114 | } |
| 113 | 115 | } |
| 114 | #endif /* DB_VERSION_MAJOR < 3 */ | |
| 116 | #endif /* DB_VERSION_FULL < 0x03000000 */ | |
| 115 | 117 | |
| 116 | 118 | if (ret != 0) { |
| 117 | 119 | if (rdwr == 0 && ret == ENOENT) { |
| 367 | 369 | if (!utils) return SASL_BADPARAM; |
| 368 | 370 | |
| 369 | 371 | if (utils->getcallback(conn, SASL_CB_GETOPT, |
| 370 | &getopt, &cntxt) == SASL_OK) { | |
| 372 | (sasl_callback_ft *)&getopt, &cntxt) == SASL_OK) { | |
| 371 | 373 | const char *p; |
| 372 | 374 | if (getopt(cntxt, NULL, "sasldb_path", &p, NULL) == SASL_OK |
| 373 | 375 | && p != NULL && *p != 0) { |
| 463 | 465 | |
| 464 | 466 | if(!dbh->cursor) { |
| 465 | 467 | /* make cursor */ |
| 466 | #if DB_VERSION_MAJOR < 3 | |
| 467 | #if DB_VERSION_MINOR < 6 | |
| 468 | #if DB_VERSION_FULL < 0x03060000 | |
| 468 | 469 | result = mbdb->cursor(mbdb, NULL,&dbh->cursor); |
| 469 | 470 | #else |
| 470 | 471 | result = mbdb->cursor(mbdb, NULL,&dbh->cursor, 0); |
| 471 | #endif /* DB_VERSION_MINOR < 7 */ | |
| 472 | #else /* DB_VERSION_MAJOR < 3 */ | |
| 473 | result = mbdb->cursor(mbdb, NULL,&dbh->cursor, 0); | |
| 474 | #endif /* DB_VERSION_MAJOR < 3 */ | |
| 472 | #endif /* DB_VERSION_FULL < 0x03000000 */ | |
| 475 | 473 | |
| 476 | 474 | if (result!=0) { |
| 477 | 475 | return SASL_FAIL; |
| 199 | 199 | |
| 200 | 200 | #include <db.h> |
| 201 | 201 | |
| 202 | #define DB_VERSION_FULL ((DB_VERSION_MAJOR << 24) | (DB_VERSION_MINOR << 16) | DB_VERSION_PATCH) | |
| 202 | 203 | /* |
| 203 | 204 | * Open the database |
| 204 | 205 | * |
| 207 | 208 | { |
| 208 | 209 | int ret; |
| 209 | 210 | |
| 210 | #if DB_VERSION_MAJOR < 3 | |
| 211 | #if DB_VERSION_FULL < 0x03000000 | |
| 211 | 212 | ret = db_open(path, DB_HASH, DB_CREATE, 0664, NULL, NULL, mbdb); |
| 212 | #else /* DB_VERSION_MAJOR < 3 */ | |
| 213 | #else /* DB_VERSION_FULL < 0x03000000 */ | |
| 213 | 214 | ret = db_create(mbdb, NULL, 0); |
| 214 | 215 | if (ret == 0 && *mbdb != NULL) |
| 215 | 216 | { |
| 216 | #if DB_VERSION_MAJOR == 4 && DB_VERSION_MINOR >= 1 | |
| 217 | #if DB_VERSION_FULL >= 0x04010000 | |
| 217 | 218 | ret = (*mbdb)->open(*mbdb, NULL, path, NULL, DB_HASH, DB_CREATE, 0664); |
| 218 | 219 | #else |
| 219 | 220 | ret = (*mbdb)->open(*mbdb, path, NULL, DB_HASH, DB_CREATE, 0664); |
| 224 | 225 | *mbdb = NULL; |
| 225 | 226 | } |
| 226 | 227 | } |
| 227 | #endif /* DB_VERSION_MAJOR < 3 */ | |
| 228 | #endif /* DB_VERSION_FULL < 0x03000000 */ | |
| 228 | 229 | |
| 229 | 230 | if (ret != 0) { |
| 230 | 231 | fprintf(stderr,"Error opening password file %s\n", path); |
| 262 | 263 | if (result!=SASL_OK) goto cleanup; |
| 263 | 264 | |
| 264 | 265 | /* make cursor */ |
| 265 | #if DB_VERSION_MAJOR < 3 | |
| 266 | #if DB_VERSION_MINOR < 6 | |
| 266 | #if DB_VERSION_FULL < 0x03060000 | |
| 267 | 267 | result = mbdb->cursor(mbdb, NULL,&cursor); |
| 268 | 268 | #else |
| 269 | 269 | result = mbdb->cursor(mbdb, NULL,&cursor, 0); |
| 270 | #endif /* DB_VERSION_MINOR < 7 */ | |
| 271 | #else /* DB_VERSION_MAJOR < 3 */ | |
| 272 | result = mbdb->cursor(mbdb, NULL,&cursor, 0); | |
| 273 | #endif /* DB_VERSION_MAJOR < 3 */ | |
| 270 | #endif /* DB_VERSION_FULL < 0x03060000 */ | |
| 274 | 271 | |
| 275 | 272 | if (result!=0) { |
| 276 | 273 | fprintf(stderr,"Making cursor failure: %s\n",db_strerror(result)); |
| 0 | 0 | /* testsuite.c -- Stress the library a little |
| 1 | 1 | * Rob Siemborski |
| 2 | 2 | * Tim Martin |
| 3 | * $Id: testsuite.c,v 1.48 2011/09/01 14:12:18 mel Exp $ | |
| 3 | * $Id: testsuite.c,v 1.49 2011/11/09 15:49:47 murch Exp $ | |
| 4 | 4 | */ |
| 5 | 5 | /* |
| 6 | 6 | * Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved. |
| 94 | 94 | #define REALLY_LONG_LENGTH 32000 |
| 95 | 95 | #define REALLY_LONG_BACKOFF 2000 |
| 96 | 96 | |
| 97 | const char *username = "murch"; | |
| 97 | const char *username = "ken"; | |
| 98 | 98 | const char *nonexistant_username = "ABCDEFGHIJ"; |
| 99 | const char *authname = "murch"; | |
| 100 | const char *proxyasname = "murchproxy"; | |
| 99 | const char *authname = "ken"; | |
| 100 | const char *proxyasname = "kenproxy"; | |
| 101 | 101 | const char *password = "1234"; |
| 102 | 102 | sasl_secret_t * g_secret = NULL; |
| 103 | 103 | const char *cu_plugin = "INTERNAL"; |
| 1323 | 1323 | |
| 1324 | 1324 | printf("%s --> start\n",mech); |
| 1325 | 1325 | |
| 1326 | if (strcmp(mech,"GSSAPI")==0) service = gssapi_service; | |
| 1326 | if (strncmp(mech,"GSS",3)==0) service = gssapi_service; | |
| 1327 | 1327 | |
| 1328 | 1328 | if (sasl_client_init(client_interactions)!=SASL_OK) fatal("Unable to init client"); |
| 1329 | 1329 | |
| 1573 | 1573 | |
| 1574 | 1574 | if(!server_conn || !client_conn) return SASL_BADPARAM; |
| 1575 | 1575 | |
| 1576 | if (strcmp(mech,"GSSAPI")==0) service = gssapi_service; | |
| 1576 | if (strncmp(mech,"GSS",3)==0) service = gssapi_service; | |
| 1577 | 1577 | |
| 1578 | 1578 | result = sasl_client_init((c_calls ? c_calls : client_interactions)); |
| 1579 | 1579 | if (result!=SASL_OK) { |
| 1728 | 1728 | |
| 1729 | 1729 | if(!server_conn || !client_conn) return SASL_BADPARAM; |
| 1730 | 1730 | |
| 1731 | if (strcmp(mech,"GSSAPI")==0) service = gssapi_service; | |
| 1731 | if (strncmp(mech,"GSS",3)==0) service = gssapi_service; | |
| 1732 | 1732 | |
| 1733 | 1733 | |
| 1734 | 1734 | if (sasl_client_init((c_calls ? c_calls : client_interactions))!=SASL_OK) |
| 1861 | 1861 | |
| 1862 | 1862 | if(!server_conn || !client_conn) return SASL_BADPARAM; |
| 1863 | 1863 | |
| 1864 | if (strcmp(mech,"GSSAPI")==0) service = gssapi_service; | |
| 1864 | if (strncmp(mech,"GSS",3)==0) service = gssapi_service; | |
| 1865 | 1865 | |
| 1866 | 1866 | if (sasl_client_init((c_calls ? c_calls : client_interactions))!=SASL_OK) |
| 1867 | 1867 | fatal("unable to init client"); |
| 1999 | 1999 | |
| 2000 | 2000 | if(!server_conn || !client_conn) return SASL_BADPARAM; |
| 2001 | 2001 | |
| 2002 | if (strcmp(mech,"GSSAPI")==0) service = gssapi_service; | |
| 2002 | if (strncmp(mech,"GSS",3)==0) service = gssapi_service; | |
| 2003 | 2003 | |
| 2004 | 2004 | if (sasl_client_init((c_calls ? c_calls : client_interactions))!=SASL_OK) |
| 2005 | 2005 | fatal("unable to init client"); |
| 1 | 1 | #Keep in sync with include/sasl.h and win32/include/config.h |
| 2 | 2 | SASL_VERSION_MAJOR=2 |
| 3 | 3 | SASL_VERSION_MINOR=1 |
| 4 | SASL_VERSION_STEP=25 | |
| 4 | SASL_VERSION_STEP=26 | |
| 5 | 5 | |
| 6 | 6 | !IF "$(STATIC)" == "" |
| 7 | 7 | STATIC=yes |
| 172 | 172 | ENABLE_WIN64_WARNINGS=/Wp64 |
| 173 | 173 | !ENDIF |
| 174 | 174 | |
| 175 | CPP_PROJ= $(CODEGEN) /W3 $(EXCEPTHANDLING) /O2 $(ENABLE_WIN64_WARNINGS) /Zi /D "NDEBUG" $(CPPFLAGS) /FD /c | |
| 175 | CPP_PROJ= $(CODEGEN) /W3 $(EXCEPTHANDLING) /O2 $(ENABLE_WIN64_WARNINGS) /Zi /D "NDEBUG" /D _CRT_SECURE_NO_DEPRECATE=1 $(CPPFLAGS) /FD /c | |
| 176 | 176 | |
| 177 | 177 | incremental=no |
| 178 | 178 | |
| 193 | 193 | !ENDIF |
| 194 | 194 | !ENDIF |
| 195 | 195 | |
| 196 | CPP_PROJ=$(CODEGEN) /W3 /Gm $(EXCEPTHANDLING) /ZI /Od /D "_DEBUG" $(CPPFLAGS) /FD /GZ /c | |
| 196 | CPP_PROJ=$(CODEGEN) /W3 /Gm $(EXCEPTHANDLING) /ZI /Od /D "_DEBUG" /D _CRT_SECURE_NO_DEPRECATE=1 $(CPPFLAGS) /FD /GZ /c | |
| 197 | 197 | |
| 198 | 198 | incremental=yes |
| 199 | 199 | |