From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 1 16:45:26 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12676 for ; Fri, 1 Feb 2002 16:45:26 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id PAA23762 for ietf-krb-wg-outgoing; Fri, 1 Feb 2002 15:16:30 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA23756 for ; Fri, 1 Feb 2002 15:16:28 -0600 (CST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA15215 for ; Fri, 1 Feb 2002 15:16:28 -0600 (CST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Fri, 1 Feb 2002 13:15:13 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Feb 2002 13:15:11 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 13:15:13 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 13:15:12 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Fri, 1 Feb 2002 13:12:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: PKINIT-15 comments Date: Fri, 1 Feb 2002 13:12:52 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD03969472@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: PKINIT-15 comments Thread-Index: AcGrZYnVRHvv8hsISxev3cLBq1cGLg== From: "John Brezak" To: X-OriginalArrivalTime: 01 Feb 2002 21:12:52.0456 (UTC) FILETIME=[35BAB680:01C1AB65] Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB65.35B193FE" ------_=_NextPart_001_01C1AB65.35B193FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few quick PKINIT-15 comments: =20 1) Section 3.2.2 - Any number of TypedData should be allowed in the sequence with one beint the TD-TRUSTED-CERTIFIERS TypedData. Same thing in other cases. The KDC should be allowed to add additional TypedData to the kerb-error, but at least one must contain the specified error code. =20 2) In this section: If the certificate chain can be verified, but the name of the client in the certificate does not match the client's name in the request, then the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data field in this case. there are few problems: - the "name of the client" should specifically say the "cname" and "crealm" and refer explicitly to an AS request. - it should be allowed to have the KDC supply ancillary e-data (using TypedData), but none is required for this particular error. - what fields in the certificate must be checked for a match? =20 =20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D John Brezak * mailto:jbrezak@microsoft.com Microsoft Corporation ( 425-706-2602 One Microsoft Way Redmond, WA 98052 =20 ------_=_NextPart_001_01C1AB65.35B193FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

A few = quick=20 PKINIT-15 comments:

1) = Section 3.2.2 -=20 Any number of TypedData should be allowed in the sequence with one beint = the=20 TD-TRUSTED-CERTIFIERS TypedData. Same thing in other cases. The KDC = should be=20 allowed to add additional TypedData to the kerb-error, but at least one = must=20 contain the specified error code.

2) In this=20 section:

If the = certificate chain can=20 be verified, but the name of the client in the certificate = does not=20 match the client's name in the request, then the KDC returns an = error of=20 type KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying = e-data field in this case.

there = are few=20 problems:

- the = "name of the=20 client" should specifically say the "cname" and "crealm" and refer = explicitly to=20 an AS request.

- it = should be=20 allowed to have the KDC supply ancillary e-data (using TypedData), but = none is=20 required for this particular error.

- what = fields in the=20 certificate must be checked for a match?

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D

John Brezak &n= bsp; =20 * = mailto:jbrezak@microsoft.com

Microsoft = Corporation =20 (=20 425-706-2602

One Microsoft=20 Way

Redmond, WA=20 98052

=00 ------_=_NextPart_001_01C1AB65.35B193FE-- --------------InterScan_NT_MIME_Boundary-- From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 5 10:28:59 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03756 for ; Tue, 5 Feb 2002 10:28:58 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id IAA29307 for ietf-krb-wg-outgoing; Tue, 5 Feb 2002 08:58:32 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA29296; Tue, 5 Feb 2002 08:58:30 -0600 (CST) Received: from www.yahho.com (28.c210-85-16.ethome.net.tw [210.85.16.28]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id IAA07967; Tue, 5 Feb 2002 08:58:06 -0600 (CST) Date: Tue, 5 Feb 2002 08:58:06 -0600 (CST) Received: from mars by ara.seed.net.tw with SMTP id aNSWgoOGhsvdZpKAVG7pPV; Tue, 05 Feb 2002 23:07:08 +0800 Message-ID: From: 3ZRklY@tpts6.seed.net.tw To: J8Ovhn9R@microsoft.com X-Mailer: YcwZTcRSS1xEldoxHY1fvIE1iPKS Content-Type: text/plain; X-Priority: 3 X-MSMail-Priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by atalanta.ctd.anl.gov id IAB29297 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit 推薦你們一個不錯的網站---數位視野各種數位相機的評比與網友的互動討論,可以做為購買前的參考. 還提供了許多沖洗數位照片的門市及網站,目前4x6一張只要6元! 更特別的是,還有記憶卡的出租,我過年出國就打算向他們租記憶卡,就不用把Notebook扛出去! www.dcview.com.tw From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 6 00:40:11 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03977 for ; Wed, 6 Feb 2002 00:40:10 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id XAA02769 for ietf-krb-wg-outgoing; Tue, 5 Feb 2002 23:01:22 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id XAA02763 for ; Tue, 5 Feb 2002 23:01:20 -0600 (CST) From: mail@roseflex.com Received: from pc7 ([211.196.228.178]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id XAA26090 for ; Tue, 5 Feb 2002 23:01:18 -0600 (CST) Received: from pc7 ([211.196.228.178]) by pc7 with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 13:41:16 +0900 Subject: [撩檣惜堅]措頂譆渠艙�婦煎鍔デ滓蝶.... Date: Wed, 06 Feb 2002 13:41:16 +0900 Message-Id: <37293.570330937504000.167123@localhost> MIME-Version: 1.0 Content-Type: text/html; charset=euc-kr Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Feb 2002 04:41:16.0593 (UTC) FILETIME=[837F3A10:01C1AEC8] Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit :: Roseflex 詭橾 ::

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 6 01:13:03 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04331 for ; Wed, 6 Feb 2002 01:13:02 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id XAA18360 for ietf-krb-wg-outgoing; Tue, 5 Feb 2002 23:50:00 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id XAA18354 for ; Tue, 5 Feb 2002 23:49:58 -0600 (CST) From: mail@roseflex.com Received: from pc7 ([211.196.228.178]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id XAA03726 for ; Tue, 5 Feb 2002 23:49:56 -0600 (CST) Received: from pc7 ([211.196.228.178]) by pc7 with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 14:24:40 +0900 Subject: [惜堅]Г旎檜ノ蹂ビ褊棲梱? 雖旎褐羶ビ撮蹂.. Date: Wed, 06 Feb 2002 14:24:40 +0900 Message-Id: <37293.600473460646400.633721@localhost> MIME-Version: 1.0 Content-Type: text/html; charset=euc-kr Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Feb 2002 05:24:40.0907 (UTC) FILETIME=[93CA01B0:01C1AECE] Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit

:: 熱褐剪睡 ::

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 6 16:42:37 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03298 for ; Wed, 6 Feb 2002 16:42:37 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id OAA17704 for ietf-krb-wg-outgoing; Wed, 6 Feb 2002 14:49:22 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA17698 for ; Wed, 6 Feb 2002 14:49:21 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA21343 for ; Wed, 6 Feb 2002 14:49:20 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA21678; Wed, 6 Feb 2002 15:49:20 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22108; Wed, 6 Feb 2002 15:49:19 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA00445; Wed, 6 Feb 2002 15:49:19 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id PAA31484; Wed, 6 Feb 2002 15:49:18 -0500 To: "Louis LeVay" Cc: ietf-krb-wg@anl.gov Subject: Re: Clarification on KRB encrypted data checksums References: <25B3F18B89FFD411BCCB00508BCF607C021C33E0@zcard04e.ca.nortel.com> From: Ken Raeburn Date: 06 Feb 2002 15:49:18 -0500 In-Reply-To: <25B3F18B89FFD411BCCB00508BCF607C021C33E0@zcard04e.ca.nortel.com> Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk "Louis LeVay" writes: > However, when looking at the MIT code implementation (krb5-1.2.2 and > earlier), it appears that the checksum (MD5 hash in this case) inludes the > PAD (for the encryption block). Yes, that's correct. > Is this implementation incorrect (and would lead to inter-op problems for > any Krb implementation that wasn't derived from an MIT code base), or should > the spec be updated accordingly (which I believe is currently undergoing > updates to the encryption/checksum section anyways)? I'm updating the draft now. It should be correct when -01 gets submitted. Thanks for catching it. Ken From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 6 21:18:13 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07493 for ; Wed, 6 Feb 2002 21:18:13 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id UAA13603 for ietf-krb-wg-outgoing; Wed, 6 Feb 2002 20:06:37 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA13597 for ; Wed, 6 Feb 2002 20:06:35 -0600 (CST) From: DebtPlan649@eudoramail.com Received: from truenorth.ca (mail.truenorth.ca [207.35.185.226]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA23711 for ; Wed, 6 Feb 2002 20:06:34 -0600 (CST) Received: from mx1.eudoramail.com (207.93.225.216) by truenorth.ca with ESMTP (Eudora Internet Mail Server 3.0.1); Wed, 6 Feb 2002 17:21:18 -0500 Message-ID: <00002bef60d0$00005436$000041d4@mx1.eudoramail.com> To: Subject: Slash You Debt Payments! (No Loan Needed) IWL Date: Wed, 06 Feb 2002 16:22:01 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: DebtPlan649@eudoramail.com Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: quoted-printable Debt Plan Services


	No new loans needed Consolidate regardless of credit problems= Redu= ce interest to as low as 1.5% Stop late or over-limit fees =

Trained experts on your Side

STOP credi= tor harassment

Be debt free in 1/3 the time

Minimum of $2,500 in unsecured debt to q= ualify

Quick-No obligation-Confidential debt analysis

&nbs= p;

We have helped thousands of people just like you.
Click here for more information

We respect your online privacy. We have included contact information = and a way
for removal from our mailing list. If you wish to be remov= ed from this list, please
reply with "remove" as subject, a= nd provide the address(es) to be deleted from our list. Any inconvenience = caused is sincerely regretted.

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 09:34:49 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28078 for ; Thu, 7 Feb 2002 09:34:49 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id IAA19677 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 08:23:18 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA19671 for ; Thu, 7 Feb 2002 08:23:17 -0600 (CST) Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.103]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA24872 for ; Thu, 7 Feb 2002 08:23:17 -0600 (CST) Received: by luminous.mit.edu (Postfix, from userid 1000) id B2C07765C2; Thu, 7 Feb 2002 09:23:14 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Why does a client care about the anonymous flag? Message-Id: <20020207142314.B2C07765C2@luminous.mit.edu> Date: Thu, 7 Feb 2002 09:23:14 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Quoting section 2 of the current draft: Each Kerberos ticket contains a set of flags which are used to indicate attributes of that ticket. Most flags may be requested by a client when the ticket is obtained; some are automatically turned on and off by a Kerberos server as required. The following sections explain what the various flags mean, and gives examples of reasons to use such a flag. With the excepttion of the ANONYMOUS and INVALID flags clients may ignore ticket flags that are not recognized. Why does a client care about an anonymous flag? What should my client do differently if it has an anonymous flag set in one of its tickets? Could this better be stated by requiring that clients who request anonymous tickets confirm their request is understood. Also, to be consistent with the extensibility model I will require that clients ignore ticket flags they do not understand and that KDCs ignore KDC options they do not understand. Naturally I will discuss the implications of this and how to distinguish (when useful) between prohibited by policy and not understood. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 10:06:29 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29240 for ; Thu, 7 Feb 2002 10:06:28 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id IAA02566 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 08:56:47 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA02559 for ; Thu, 7 Feb 2002 08:56:45 -0600 (CST) Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.103]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA02334 for ; Thu, 7 Feb 2002 08:56:46 -0600 (CST) Received: by luminous.mit.edu (Postfix, from userid 1000) id ACD19765C2; Thu, 7 Feb 2002 09:56:45 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Section 2 diffs clarifying ticket flag extensibility Message-Id: <20020207145645.ACD19765C2@luminous.mit.edu> Date: Thu, 7 Feb 2002 09:56:45 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk This is intended to address an issue opened at the IETF meeting about the impact of our extensibility proposal on ticket flags and to clarify how one should design new flags in the future. --- krbrev2-6.html 2002/02/07 14:12:00 1.1 +++ krbrev2-6.html 2002/02/07 14:51:47 1.2 @@ -4,12 +4,33 @@ indicate attributes of that ticket. Most flags may be requested by a client when the ticket is obtained; some are automatically turned on and off by a Kerberos server as required. The following sections -explain what the various flags mean, and gives examples of reasons to -use such a flag. With the excepttion of the ANONYMOUS and INVALID -flags clients may ignore ticket flags that are not recognized. +explain what the various flags mean and give examples of reasons to +use them. With the excepttion of the ANONYMOUS and INVALID flags +clients MUST ignore ticket flags that are not recognized. KDCs MUST +ignore KDC options that are not recognized. Unfortunately some +implementations of RFC 1510 are known to reject unknown KDC options, +so clients may wish to only send options known to be defined by RFC +1510 in the non-extensible varients of messages. + +

+ +Since KDCs ignore unknown options, clients MUST confirm that the +resulting ticket meets their needs. For example, as discussed in +section 2.8, a client requiring anonymous communication needs to make +sure that the ticket is actually anonymous. A KDC that prohibits issuing of anonymous tickets or that does not understand the anonymous option would not return an anonymous ticket. + +

+ +Note that it is not in general possible to determine whether an option +was not honored because it was not understood or because it was +rejected either through configuration or policy. Designers of options +should consider whether the distinction is important for their option. +In cases where it is, a mechanism for the KDC to return an indication +that the option was understood but rejected needs to be provided in +the specification of the option. Often in such cases, the mechanism +needs to be broad enough to permit an error or reason to be returned. -

2.1. Initial, pre-authenticated, and hardware authenticated -tickets

2.1. Initial, pre-authenticated, and hardware authenticated tickets

The INITIAL flag indicates that a ticket was issued using the AS protocol and not issued based on a ticket-granting ticket. @@ -234,6 +255,12 @@ originate from different users. Users request anonymous ticket by setting the REQUEST-ANONYMOUS option in an AS or TGS request. +

+ +If a client requires anonymous communication then the client should check to make sure that the resulting ticket it actually anonymous. A KDC that does not understand the anonymous-requested flag will not return an error, but will instead return a normal ticket. + + +

2.9. Other KDC options

There are three additional options which may be set in a client's @@ -309,3 +336,6 @@ Name canonicalization was then removed and set aside for a separate document. Section 2.9.2 and .3 were renumbered to .1 and .2. +

+ +Discussion of how extensibility affects ticket flags and KDC options was added to the introduction. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 10:06:33 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29251 for ; Thu, 7 Feb 2002 10:06:32 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id IAA01519 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 08:54:10 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA01513 for ; Thu, 7 Feb 2002 08:54:09 -0600 (CST) Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.103]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA01868 for ; Thu, 7 Feb 2002 08:54:09 -0600 (CST) Received: by luminous.mit.edu (Postfix, from userid 1000) id B5501765C2; Thu, 7 Feb 2002 09:54:08 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Section 1 diffs for extensibility Message-Id: <20020207145408.B5501765C2@luminous.mit.edu> Date: Thu, 7 Feb 2002 09:54:08 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Here is my preliminary integration of extensibility changes into section 1 for the WG's comments. I will send these to Cliff once finalized. --- krbrev1-4.html 2002/02/07 14:12:28 1.1 +++ krbrev1-4.html 2002/02/07 14:17:47 1.3 @@ -384,7 +384,133 @@ options for application authentication (e.g. the PKTAPP proposal) are provided. -

1.4. Environmental assumptions

+ +

1.4. Extensibility Model

+ +In the past, significant interoperability problems have been caused by +different assumptions about how the Kerberos protocol can be extended. +However, as the deployed base of Kerberos implementations grows, +extending Kerberos becomes more important. In order to insure that +vendors and the IETF can extend the protocol while maintaining backward compatibility, this specification outlines a framework for extending Kerberos. +

+Kerberos provides two general mechanisms for protocol extensibility. +Many protocol messages contain typed holes--sub-messages that contain +an octet-string along with an integer that defines how to interpret +the octet-string. The integer types are registered centrally, but can +be used both for vendor extensions and for extensions standardized in +the IETF. +

+Most messages also contain ASN.1 extension markers. These markers +allow fields to be added in future versions of this specification. +Because tag numbers and order in the sequence need to be agreed on in +order to maintain interoperability, implementations MUST NOT include +ASN.1 extensions except when those extensions are specified by IETF +standards-track documents. +

+ +

1.4.1. Compatibility with RFC 1510

+ +Implementations of RFC 1510 did not use extensible ASN.1 types. +Sending additional fields not in RFC 1510 to these implementations +results in undefined behavior. Examples of this behavior are known to +include discarding messages with no error indications. + +

+ +Where messages have been changed since RFC 1510, ASN.1 choice types +are used; one arm of the choice provides a message compatible with RFC +1510 and the other arm provides the current, extensible message. + +

+ +Implementations sending new messages MUST insure that the recipient +supports these new messages. Along with each extensible message is a +guideline for when that message MAY be used. IF that guideline is +followed, then the recipient is guaranteed to understand the message. + +

+ +

1.4.2. Sending Extensible Messages

+ +Care must be taken to make sure that old implementations can +understand messages sent to them even if they do not understand an +extension that is used. Unless the sender knows the extension is +supported, the extension cannot change the semantics of the core +message or previously defined extensions. + +

+ +For example, an extension including key information necessary to +decrypt the encrypted part of a KDC-REP could only be used in +situations where the recipient was known to support the extension. +Thus when designing such extensions it is important to provide a way +for the recipient to notify the sender of support for the extension. +For example in the case of an extension that changes the KDC-REP reply +key, the client could indicate support for the extension by including +a padata element in the AS-REQ sequence. The KDC should only use the +extension if this padata element is present in the AS-REQ. Even if +policy requires the use of the extension, it is better to return an +error indicating that the extension is required than to use the +extension when the recipient may not support it; debugging why +implementations do not interoperate is easier when errors are +returned. + +

1.4.3. Receiving Extensible Messages

+ +Recipients of unknown message extensions (either in typed +holes or ASN.1 types) should preserve the encoding of the extension +but otherwise ignore the presence of the extension. If the message is +used later--for example, when a ticket is later used in an +AP-REQ--then the unknown extensions MUST be included. + +

+ +There is one exception to this rule. If an unknown authorization data +element type is received by a server either in an AP-REQ or in a +ticket contained in an AP-REQ, then the authentication SHOULD fail. +Authorization data is intended to restrict the use of the ticket. If +the service cannot determine whether the restriction applies to that +service then a security weakness may result if the ticket can be used +for that service. Authorization elements that are optional can be +enclosed in the AD-IF-RELEVANT element. + +

+ +Many RFC 1510 implementations ignore unknown authorization data +elements. Depending on these implementations to honor authorization +data restrictions may create a security weakness. +

1.5. Authenticating Cleartext Portions of Messages

+ +One of the design goals of Kerberos was to avoid encrypting more of +the authentication exchange that was required. This reduces the load +on the KDC and busy servers. Also, at the time, it helped with +certain legal export requirements. Unfortunately, various denial of +service attacks and downgrade attacks are possible unless this +plaintext is somehow protected against modification. + +

+ +The extensible varients of the messages described in this +specification wrap the actual message in an ASN.1 sequence containing +a keyed checksum of the contents of the message. Guidelines in +section 3 specify when the checksum MUST be included and what key MUST +be used. Guidelines on when to include a checksum are never +ambiguous: a particular PDU is never correct both with and without a +checksum. With the exception of the KRB-ERROR message, receiving +implementations MUST reject messages where a checksum is included and +not expected or where a checksum is expected but not included. The +receiving implementation does not always have sufficient information +to know whether a KRB-ERROR should contain a checksum. Even so, +KRB-ERROR messages with invalid checksums MUST be rejected and +implementations MAY consider the presence or absence of a checksum +when evaluating whether to trust the error. + +

+ +This authenticated cleartext protection is provided only in the extensible varients of the messages; it is never used whan talking to an RFC 1510 implementation. + + +

1.6. Environmental assumptions

Kerberos imposes a few assumptions on the environment in which it can properly function: @@ -426,7 +552,7 @@ -

1.5. Glossary of terms

1.7. Glossary of terms

Below is a list of terms used throughout this document. @@ -598,5 +724,9 @@

Discussion related to Name Canonicalization has been dropped. + +

+ +Folded in the introduction to extensibility and the authenticated cleartext solution. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 14:29:47 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06802 for ; Thu, 7 Feb 2002 14:29:47 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA15990 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 13:18:09 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA15972 for ; Thu, 7 Feb 2002 13:18:07 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA29281 for ; Thu, 7 Feb 2002 13:18:07 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA23051 for ; Thu, 7 Feb 2002 14:18:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA19988 for ; Thu, 7 Feb 2002 14:14:03 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA24842 for ; Thu, 7 Feb 2002 14:05:15 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id OAA24354; Thu, 7 Feb 2002 14:05:14 -0500 (EST) Date: Thu, 7 Feb 2002 14:05:14 -0500 (EST) Message-Id: <200202071905.OAA24354@tir-na-nogth.mit.edu> From: Sam Hartman To: ietf-krb-wg@anl.gov Subject: What do you do if you can't describe your request is as-req1 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk So, we had this discussion before but I don't think really came to a conclusion. Let's say just for argument that I've got a client name I don't know how to specify in an AS-REQ1. Clearly I'm planning on communicating with only new KDCs, but I need to know what to send if I'm not sure the other end is new. The request is going to fail, but I want an error back from an old KDC. That means I can't just send a new request. I think I send some sort of bogus old request with a pa-as-req2. But what do I put in the bogus old request? From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 14:47:48 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07405 for ; Thu, 7 Feb 2002 14:47:48 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA24527 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 13:37:02 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA24521 for ; Thu, 7 Feb 2002 13:37:01 -0600 (CST) Received: from gate2.stm.ubswarburg.com (gate2.stm.ubswarburg.com [151.191.1.12]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA03365 for ; Thu, 7 Feb 2002 13:37:01 -0600 (CST) Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id OAA20717; Thu, 7 Feb 2002 14:36:54 -0500 (EST) Received: from (thirteen.ubswarburg.com [192.168.0.7]) by gate2 via smap (V2.0/ubsw) id xma020508; Thu, 7 Feb 2002 14:36:29 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan4 [192.168.0.7]) by virscan4.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA22547; Thu, 7 Feb 2002 14:38:34 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA15400; Thu, 7 Feb 2002 14:36:29 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id OAA26687; Thu, 7 Feb 2002 14:35:36 -0500 (EST) Date: Thu, 7 Feb 2002 14:35:36 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-krb-wg@anl.gov Subject: Re: What do you do if you can't describe your request is as-req1 Message-ID: <20020207143535.J27171@sm2p1386swk.wdr.com> Mail-Followup-To: Sam Hartman , ietf-krb-wg@anl.gov References: <200202071905.OAA24354@tir-na-nogth.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200202071905.OAA24354@tir-na-nogth.mit.edu>; from hartmans@mit.edu on Thu, Feb 07, 2002 at 02:05:14PM -0500 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Thu, Feb 07, 2002 at 02:05:14PM -0500, Sam Hartman wrote: > The request is going to fail, but I want an error back from an old > KDC. That means I can't just send a new request. > > I think I send some sort of bogus old request with a pa-as-req2. But > what do I put in the bogus old request? I say use bogus names for this - standard bogus names :) Any names sufficiently unlikely to exist as valid principals will do, but with bogus names you can make certain that they don't exist in any realm. At the very least that way if your using a sniffer you'll be able to see right away that the client is meaning to do an as-req2 that can't be done as an as-req1. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 15:14:56 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08340 for ; Thu, 7 Feb 2002 15:14:55 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id OAA06314 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 14:04:45 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA06308 for ; Thu, 7 Feb 2002 14:04:43 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA09804 for ; Thu, 7 Feb 2002 14:04:43 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA17127; Thu, 7 Feb 2002 15:04:43 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA02067; Thu, 7 Feb 2002 15:04:42 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA28390; Thu, 7 Feb 2002 15:04:42 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id PAA24439; Thu, 7 Feb 2002 15:04:41 -0500 (EST) To: Nicolas Williams Cc: ietf-krb-wg@anl.gov Subject: Re: What do you do if you can't describe your request is as-req1 References: <200202071905.OAA24354@tir-na-nogth.mit.edu> <20020207143535.J27171@sm2p1386swk.wdr.com> From: Sam Hartman Date: 07 Feb 2002 15:04:41 -0500 In-Reply-To: Nicolas Williams's message of "Thu, 7 Feb 2002 14:35:36 -0500" Message-ID: Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, Feb 07, 2002 at 02:05:14PM -0500, Sam Hartman wrote: >> The request is going to fail, but I want an error back from an old >> KDC. That means I can't just send a new request. >> >> I think I send some sort of bogus old request with a pa-as-req2. But >> what do I put in the bogus old request? Nicolas> I say use bogus names for this - standard bogus names :) Yeah, but I'm having trouble coming up with someone we as a community dislike to canonize for the client principal, and not really sure whether rvd, discuss or POP would make a better server principal.;-) Seriously, someone should pick specific bogus names for me to use. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 15:26:30 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08678 for ; Thu, 7 Feb 2002 15:26:29 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id OAA09413 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 14:11:57 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA09407 for ; Thu, 7 Feb 2002 14:11:55 -0600 (CST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA11498 for ; Thu, 7 Feb 2002 14:11:56 -0600 (CST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA07047; Thu, 7 Feb 2002 15:11:55 -0500 (EST) Date: Thu, 7 Feb 2002 15:11:55 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Sam Hartman Cc: ietf-krb-wg@anl.gov Subject: Re: What do you do if you can't describe your request is as-req1 In-Reply-To: Your message of Thu, 7 Feb 2002 14:05:14 -0500 (EST) Message-ID: Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk > > > So, we had this discussion before but I don't think really came to a > conclusion. Let's say just for argument that I've got a client name I > don't know how to specify in an AS-REQ1. Clearly I'm planning on > communicating with only new KDCs, but I need to know what to send if > I'm not sure the other end is new. > > The request is going to fail, but I want an error back from an old > KDC. That means I can't just send a new request. > > I think I send some sort of bogus old request with a pa-as-req2. But > what do I put in the bogus old request? > What happens if you put in an empty string for the name? The discussions we hard were going in the direction that you would put an old style representation of the name in the old request. That would mean converting the name to ASCII. Of course a name consisting entirely of Tibetan is not going to translate well. In Kermit when we translate between two character sets and there is a failed mapping for a character we replace it with a '?' to indicate that something was there. We could extend that here and say that if the name does not translate to ASCII (or the locally defined default 8-bit character set) that it be replaced with either the empty string or a string consisting of a single question mark, "?". Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 15:34:49 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09026 for ; Thu, 7 Feb 2002 15:34:48 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id OAA12973 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 14:20:17 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA12967 for ; Thu, 7 Feb 2002 14:20:16 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA13287 for ; Thu, 7 Feb 2002 14:20:16 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id PAA21394; Thu, 7 Feb 2002 15:23:19 -0500 (EST) Received: from (twelve.ubswarburg.com [192.168.0.6]) by gate via smap (V2.0) id xma020995; Thu, 7 Feb 2002 15:22:25 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan3 [192.168.0.6]) by virscan3.swissbank.com (8.8.8/8.8.8) with ESMTP id PAA29202; Thu, 7 Feb 2002 15:18:47 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id PAA26800; Thu, 7 Feb 2002 15:19:19 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id PAA27108; Thu, 7 Feb 2002 15:18:23 -0500 (EST) Date: Thu, 7 Feb 2002 15:18:23 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-krb-wg@anl.gov Subject: Re: What do you do if you can't describe your request is as-req1 Message-ID: <20020207151821.K27171@sm2p1386swk.wdr.com> Mail-Followup-To: Sam Hartman , ietf-krb-wg@anl.gov References: <200202071905.OAA24354@tir-na-nogth.mit.edu> <20020207143535.J27171@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from hartmans@MIT.EDU on Thu, Feb 07, 2002 at 03:04:41PM -0500 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Thu, Feb 07, 2002 at 03:04:41PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Thu, Feb 07, 2002 at 02:05:14PM -0500, Sam Hartman wrote: > >> The request is going to fail, but I want an error back from an old > >> KDC. That means I can't just send a new request. > >> > >> I think I send some sort of bogus old request with a pa-as-req2. But > >> what do I put in the bogus old request? > > Nicolas> I say use bogus names for this - standard bogus names :) > > Yeah, but I'm having trouble coming up with someone we as a community > dislike to canonize for the client principal, and not really sure > whether rvd, discuss or POP would make a better server principal.;-) LOL! I don't want to volunteer my principal name... > Seriously, someone should pick specific bogus names for me to use. Hows's "bogus_user_had_better_not_exist" and "bogus_service_..."? Too long, fine, how's "bogus-user"/"bogus-service"? Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 17:58:56 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12147 for ; Thu, 7 Feb 2002 17:58:56 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id QAA16235 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 16:47:20 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA16229 for ; Thu, 7 Feb 2002 16:47:18 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA15791 for ; Thu, 7 Feb 2002 16:47:18 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g17MkjH21353; Thu, 7 Feb 2002 17:46:46 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g17Mki300170; Thu, 7 Feb 2002 17:46:44 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J3PACAD>; Thu, 7 Feb 2002 17:46:44 -0500 Message-ID: <25B3F18B89FFD411BCCB00508BCF607C021C344B@zcard04e.ca.nortel.com> From: "Louis LeVay" To: "'Ken Raeburn'" Cc: ietf-krb-wg@anl.gov Subject: RE: Clarification on KRB encrypted data checksums Date: Thu, 7 Feb 2002 17:46:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B029.502EB2F0" Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B029.502EB2F0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Ken Raeburn [mailto:raeburn@MIT.EDU] > > However, when looking at the MIT code implementation (krb5-1.2.2 and > > earlier), it appears that the checksum (MD5 hash in this > case) inludes the > > PAD (for the encryption block). > > Yes, that's correct. > By "correct", I assume you are confirming my obsveration on the MIT code implementation...not necessarily that it is correct (see below) > > Is this implementation incorrect (and would lead to > inter-op problems for > > any Krb implementation that wasn't derived from an MIT code > base), or should > > the spec be updated accordingly (which I believe is > currently undergoing > > updates to the encryption/checksum section anyways)? > > I'm updating the draft now. It should be correct when -01 gets > submitted. > So the spec would be updated to reflect the MIT implementation (i.e. checksum includes the PADDING)? If not, then it seems in order to verify the checksum, the receiver would have to do some partial ASN decoding of the msg (app data) to determine the *real* length of the data using the implicit ASN encoded length (seems ok...since all use of EncryptedData in 1510bis has ASN.1 encoded msg data)? ...other alternatives exist but would also need to be newly defined Thx Louis > Thanks for catching it. > > Ken > ------_=_NextPart_001_01C1B029.502EB2F0 Content-Type: text/html; charset="iso-8859-1" RE: Clarification on KRB encrypted data checksums

> -----Original Message-----
> From: Ken Raeburn [mailto:raeburn@MIT.EDU]

> > However, when looking at the MIT code implementation (krb5-1.2.2 and
> > earlier), it appears that the checksum (MD5 hash in this
> case) inludes the
> > PAD (for the encryption block).
>
> Yes, that's correct.
>

By "correct", I assume you are confirming my obsveration on the
MIT code implementation...not necessarily that it is correct
(see below)

> > Is this implementation incorrect (and would lead to
> inter-op problems for
> > any Krb implementation that wasn't derived from an MIT code
> base), or should
> > the spec be updated accordingly (which I believe is
> currently undergoing
> > updates to the encryption/checksum section anyways)?
>
> I'm updating the draft now. It should be correct when -01 gets
> submitted.
>

So the spec would be updated to reflect the MIT implementation
(i.e. checksum includes the PADDING)?

If not, then it seems in order to verify the checksum, the
receiver would have to do some partial ASN decoding of the msg (app data)
to determine the *real* length of the data using the implicit ASN encoded length
(seems ok...since all use of EncryptedData in 1510bis has ASN.1 encoded
msg data)? ...other alternatives exist but would also need to be newly defined

Thx
Louis

> Thanks for catching it.
>
> Ken
>

------_=_NextPart_001_01C1B029.502EB2F0-- From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 18:52:42 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13351 for ; Thu, 7 Feb 2002 18:52:40 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id RAA01513 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 17:25:19 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA01507 for ; Thu, 7 Feb 2002 17:25:17 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA23442 for ; Thu, 7 Feb 2002 17:25:17 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA25686; Thu, 7 Feb 2002 18:25:17 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA01321; Thu, 7 Feb 2002 18:25:17 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id SAA28694; Thu, 7 Feb 2002 18:25:16 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA23504; Thu, 7 Feb 2002 18:25:15 -0500 (EST) To: Nicolas Williams Cc: Sam Hartman , ietf-krb-wg@anl.gov Subject: Re: What do you do if you can't describe your request is as-req1 References: <200202071905.OAA24354@tir-na-nogth.mit.edu> <20020207143535.J27171@sm2p1386swk.wdr.com> <20020207151821.K27171@sm2p1386swk.wdr.com> From: Derek Atkins Date: 07 Feb 2002 18:25:15 -0500 In-Reply-To: <20020207151821.K27171@sm2p1386swk.wdr.com> Message-ID: Lines: 62 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Are strings NULL-terminated or length-encoded? If the latter, you could use a one-byte-long string with just the NUL character. -derek Nicolas Williams writes: > On Thu, Feb 07, 2002 at 03:04:41PM -0500, Sam Hartman wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > > > > Nicolas> On Thu, Feb 07, 2002 at 02:05:14PM -0500, Sam Hartman wrote: > > >> The request is going to fail, but I want an error back from an old > > >> KDC. That means I can't just send a new request. > > >> > > >> I think I send some sort of bogus old request with a pa-as-req2. But > > >> what do I put in the bogus old request? > > > > Nicolas> I say use bogus names for this - standard bogus names :) > > > > Yeah, but I'm having trouble coming up with someone we as a community > > dislike to canonize for the client principal, and not really sure > > whether rvd, discuss or POP would make a better server principal.;-) > > LOL! I don't want to volunteer my principal name... > > > Seriously, someone should pick specific bogus names for me to use. > > Hows's "bogus_user_had_better_not_exist" and "bogus_service_..."? Too > long, fine, how's "bogus-user"/"bogus-service"? > > Cheers, > > Nico > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 7 21:01:37 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15659 for ; Thu, 7 Feb 2002 21:01:37 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id TAA23147 for ietf-krb-wg-outgoing; Thu, 7 Feb 2002 19:52:05 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA23141 for ; Thu, 7 Feb 2002 19:52:04 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA17977 for ; Thu, 7 Feb 2002 19:52:04 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA19292; Thu, 7 Feb 2002 20:52:03 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA13288; Thu, 7 Feb 2002 20:52:03 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id UAA29357; Thu, 7 Feb 2002 20:52:02 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id UAA24577; Thu, 7 Feb 2002 20:52:02 -0500 (EST) To: Derek Atkins Cc: Nicolas Williams , ietf-krb-wg@anl.gov Subject: Re: What do you do if you can't describe your request is as-req1 References: <200202071905.OAA24354@tir-na-nogth.mit.edu> <20020207143535.J27171@sm2p1386swk.wdr.com> <20020207151821.K27171@sm2p1386swk.wdr.com> From: Sam Hartman Date: 07 Feb 2002 20:52:02 -0500 In-Reply-To: Derek Atkins's message of "07 Feb 2002 18:25:15 -0500" Message-ID: Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> Are strings NULL-terminated or length-encoded? If the latter, you Derek> could use a one-byte-long string with just the NUL character. Derek> -derek I'm going to take jaltman's suggestion of a single ?. The suggestions of null string or string containing null seem more appropriate for my test cases than protocol description. Remember we are trying to maximize interop, not maximize bug discovery. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 10:29:30 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11093 for ; Fri, 8 Feb 2002 10:29:29 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA00203 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 09:17:26 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA00187 for ; Fri, 8 Feb 2002 09:17:23 -0600 (CST) Received: from localhost ([211.179.75.140]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id JAA29174 for ; Fri, 8 Feb 2002 09:17:23 -0600 (CST) Message-Id: <200202081517.JAA29174@dns2.anl.gov> Reply-To: mallbank@mallbank.co.kr From: mallbank To: ietf-krb-wg@anl.gov Subject: [惜堅]澗ヒ路掘蹴..蜂撲檜雖葆撮蹂! 路屢觼殮棲棻. Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 9 Feb 2002 00:17:22 +0900 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk 路屢觼澗ヒ路

檜薑爾陛ノ蹂ビ衛雖彊擎碟眷朝ョ塊橈檜爾魚薄縑渠ボ憮曄ボ蒂掘ベ棲棻.
獄詭橾等檜攪朝奢偃瞳檣夠縑憮鏃菜フ匙戲煎詭橾檜諼縑偃檣薑爾朝橈蝗棲棻.
[熱褐剪睡]蒂援腦衛賊棻擠睡攪朝詭橾檜陛雖彊啪腌棲棻.
傳フ惜堅塭朝旋擊嫩ɵ 檜詭橾擎蝶疒戲煎睡攪勘溥雖螃棲詭橾睡陛晦棟縑撲薑ビ衛賊檜諦綠蝌フ睡盟曖詭橾擎ニビ褒熱氈蝗棲棻.

路屢觼縑憮朝億煎遴澗ヒ路樂瑞暮擊偃嫦ビ罹盪溫ビ啪薯奢ビ堅濠ベ棲棻.

澗ヒ路曖輿蹂⑸癒

- 鼻ゴ碟盟婦葬塽蓮遴鼻ゴ蛔煙
- 懍龱�蒂鱔フ寰瞪フ唸營衛蝶蠱
- 堅偌婦葬衛蝶蠱鱉營
- 檣晦鼻ゴ, 辦熱堅偌婦葬
- 堅偌寞僥煎斜塽 �錳瞪羹詭橾晦棟
- 除ぇフ褻濛戲煎澗ヒ路 �唳滲唳陛棟
- 啪衛匸濠翕儅撩晦棟 (錳ビ朝熱虜躑)
- 撮暮擊檜辨ビ罹爾寰縑纂醞

爾棻濠撮フ頂辨擎 �［檜雖縑氈蝗棲棻.
濠褐氈啪棻艇樂瑞暮婁綠掖ブ熱氈蝗棲棻.

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 10:40:01 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11706 for ; Fri, 8 Feb 2002 10:40:01 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA05048 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 09:29:49 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA05042 for ; Fri, 8 Feb 2002 09:29:48 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA01684 for ; Fri, 8 Feb 2002 09:29:48 -0600 (CST) Message-ID: <3C63EBAA.8B44CB15@anl.gov> Date: Fri, 08 Feb 2002 09:15:54 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-krb-wg@anl.gov Subject: Interim IETF KRB-WG meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit The interim meeting is on for next week. The focus of the meeting will be the revisions, with the first item of business will be what needs to be in the revisions, and what need to be in separate documents. We will then go on to work on the revisions. On a lighter note, many of us will be arriving on Monday, so if anyone is interested in dinner, I propose that they meet in the hotel lobby at 6:30p. ----- The Kerberos WG of the IETF will be holding a two day meeting to work on the Kerberos revisions draft. This is intended to be a working meeting where the attendees will work on the details of the revisions document, and any documents which closely relate to the revisions. (This announcement is being made per RFC 2026 Section 8. The meeting was also discussed at IETF-52, at both krb-wg and saag sessions.) When: February 12-13 9:00AM-5:00PM Where: Building W92 2nd floor South Station conference room MIT 304 Vassar St Cambridge, MA What: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-revisions-10.txt The Hyatt Regency at 575 Memorial Drive 617-492-1234, has rooms available for $189 per night if you tell them you're coming for a conference at MIT. The hotel is right across the street from building W92. (Despite the street addresses, both have their entrances on Amesbury St that runs between them. Walk out the hotel entrance, and W92 is across the street and to the left.) MIT has kindly agreed to provide a continental breakfast, and lunch, so we will start refreshments at 8:00. I have heard from about 10 of the WG members who said they could come. If you are comings, please let me know. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 14:38:40 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21659 for ; Fri, 8 Feb 2002 14:38:40 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA11494 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 13:27:55 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA11483; Fri, 8 Feb 2002 13:27:53 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA22094; Fri, 8 Feb 2002 13:27:53 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA10685; Fri, 8 Feb 2002 14:27:53 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA20588; Fri, 8 Feb 2002 14:27:53 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA03472; Fri, 8 Feb 2002 14:27:52 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id OAA24927; Fri, 8 Feb 2002 14:27:52 -0500 (EST) To: "Douglas E. Engert" Cc: ietf-krb-wg@anl.gov Subject: Re: Interim IETF KRB-WG meeting References: <3C63EBAA.8B44CB15@anl.gov> From: Sam Hartman Date: 08 Feb 2002 14:27:51 -0500 In-Reply-To: "Douglas E. Engert"'s message of "Fri, 08 Feb 2002 09:15:54 -0600" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Doug, John brought up an interesting point in a discussion with us last week. It's fairly important that we produce a spec that is acceptable to vendors: we want to make sure that vendors can justify implementing our changes. John has some ideas on how to accomplish this. I think that it would be worth a some of our time to discuss these issues. Also, I'll have a short presentation prepared on the open issues list. If you have an issue with the extensibility proposal that has not been properly addressed and it isn't on the list I sent out in December, please let me know. I know about several issues that Microsoft presented in SLC and in mail since then. Jeff Altman is arriving Sunday. We hope to have something intelligent to say about UTF-8 by Tuesday. I also continue to work on coming up with proposed patches to the draft to integrate parts of the extensibility proposal that appear to have general agreement. The actual ASN.1 still has several open issues, as do a few details. But I think the basic framework is getting to a point where at least looking at how it fits into the draft would be worth our time. --Sam From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 18:21:15 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27347 for ; Fri, 8 Feb 2002 18:21:14 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id RAA12995 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 17:08:01 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA12984 for ; Fri, 8 Feb 2002 17:07:59 -0600 (CST) Received: from assaris.sics.se (gw.permabit.com [4.36.55.2]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA09162 for ; Fri, 8 Feb 2002 17:07:59 -0600 (CST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id AAA72741; Sat, 9 Feb 2002 00:08:11 +0100 (CET) (envelope-from assar) From: assar@kth.se To: ietf-krb-wg@anl.gov Subject: some comments on draft-ietf-cat-kerberos-revisions-10.txt Date: 09 Feb 2002 00:08:11 +0100 Message-ID: <5ld6zfo9lw.fsf@assaris.sics.se> Lines: 78 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk The notes in the text (like [24]) seems to be half-way converted between sequential numbering and per-section numbering, but there are lots of old references (like [24]) and the notes themselves for these are not in the document. A document this long should really have a table of contents. 3.1.5 the description of key-expiration should note that this field is deprecated, and that last-req should be used instead. The same field is refered to as 'key_exp' in seciont 4.2. section 5, ASN definitions The defintions mostly seem to use INT32 and UINT32, but there are a number of places where INTEGER is still used. These should presumably be changed to INT32 or UINT32. 5.4.1: What is the difference between reserved and unused bits? The labeling between the ASN1 code and the text is not consistent. The request-anonymous flag is spelt inconsistently with and without dash. 5.4.2 last-req:, the lr-type values should really have constants and a table for defining them instead of the paragraph of prose. It's also missing (7), the expiration time of the account. 5.6 The KRB_SAFE2 message is refered but never defined in the document. 5* The document talks about keytypes, when it really should be encryption types. 5.10 List of tags is not up-to-date. (10 is listed twice) what is TGT-REQ ? 22 is KRB-CRED (and this list is also partially repeated in 8.3) section 6: Why is combine-keys defined in this document? 6.1: still talks about keytypes (and sometimes about etype) key usage 1024 and 1025 are both reserved for applications and for using with other protocols that are defined in terms of the kerberos encryption methods. A table of salt types would be useful. 7.2: has a list of principal types, which is different from the one in 8.2 section 9.1: I suggest crc-32, and des-mac, des-mac-k be removed from the checksum list 9.1: claims that TCP is a MUST, but in 8.2.2, it's a should /assar From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 18:27:03 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27381 for ; Fri, 8 Feb 2002 18:27:02 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id RAA16360 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 17:15:47 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA16354 for ; Fri, 8 Feb 2002 17:15:43 -0600 (CST) Received: from assaris.sics.se (gw.permabit.com [4.36.55.2]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA10469 for ; Fri, 8 Feb 2002 17:15:43 -0600 (CST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id AAA72763; Sat, 9 Feb 2002 00:15:55 +0100 (CET) (envelope-from assar) From: assar@kth.se To: hartmans@mit.edu (Sam Hartman) Cc: ietf-krb-wg@anl.gov Subject: Re: Why does a client care about the anonymous flag? References: <20020207142314.B2C07765C2@luminous.mit.edu> Date: 09 Feb 2002 00:15:55 +0100 In-Reply-To: hartmans@mit.edu's message of "Thu, 7 Feb 2002 09:23:14 -0500 (EST)" Message-ID: <5l8za3o990.fsf@assaris.sics.se> Lines: 21 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk hartmans@mit.edu (Sam Hartman) writes: > Why does a client care about an anonymous flag? What should my > client do differently if it has an anonymous flag set in one of its > tickets? I would think that there can be clients/users that for policy reasons decide that they will only send anonymous tickets to a certain service. The client could either keep track of it requested a particular service as anonymous and use that for deciding if it should be used, or it could just grab the bits it gets back from the server (which it does for lots of other ticket attributes such as expiration times - the server might have changed them). > Could this better be stated by requiring that clients who request > anonymous tickets confirm their request is understood. But yes, the only thing the client can verify is that the KDC has understood that it wanted an anonymous tickets, it has to trust the KDC to do this. /assar From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 19:06:59 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27907 for ; Fri, 8 Feb 2002 19:06:59 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id RAA02795 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 17:56:15 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA02789 for ; Fri, 8 Feb 2002 17:56:13 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA17624 for ; Fri, 8 Feb 2002 17:56:14 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA16770; Fri, 8 Feb 2002 18:56:13 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA02923; Fri, 8 Feb 2002 18:56:12 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id SAA23358; Fri, 8 Feb 2002 18:56:12 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id SAA07701; Fri, 8 Feb 2002 18:56:12 -0500 To: assar@kth.se Cc: ietf-krb-wg@anl.gov Subject: Re: some comments on draft-ietf-cat-kerberos-revisions-10.txt References: <5ld6zfo9lw.fsf@assaris.sics.se> From: Ken Raeburn Date: 08 Feb 2002 18:56:12 -0500 In-Reply-To: <5ld6zfo9lw.fsf@assaris.sics.se> Message-ID: Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk > A document this long should really have a table of contents. According to the editor requirements, it's actually required for anything remotely close to this size. Since the master form is HTML at the moment, I'm not sure how that's going to happen. > section 6: > > Why is combine-keys defined in this document? To provide a single interface for preauth mechanisms like SAM to use, rather than specifying things like "XOR your DES keys together", which breaks if you're not using one of the listed encryption systems. For our existing systems, "xor and maybe fix parity" may suffice, > 6.1: > > still talks about keytypes (and sometimes about etype) Oops. I'll try to fix that in the next rev of the crypto draft. (In case it escaped your notice, draft-ietf-krb-wg-crypto-XX.txt was split off, and kerberos-revisions will refer to it in the future.) > key usage 1024 and 1025 are both reserved for applications and for > using with other protocols that are defined in terms of the kerberos > encryption methods. Hmm, I'll look into that. > A table of salt types would be useful. Salt types are going away; the replacement will be a more generic and opaque "string to key parameters" blob, the interpretation of which is left to each cryptosystem, sent by the KDC via preauth. The existing preauth support for salt types would be converted to a specialized form of the parameters. For example, AFS3-SALT might mean the blob is one octet with a value of 1 *if* one of the DES enctypes is used, which the DES string-to-key function interprets to mean "I'll call the AFS s2k function instead of using the normal code". Using this blob lets us say things like, for AES, the blob will be an ASCII string with decimal digits indicating the number of iterations for the PKCS#5 key generation function. And we don't have to do weird hacks to the salt string to encode such info. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 19:49:33 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28407 for ; Fri, 8 Feb 2002 19:49:33 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id SAA17527 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 18:37:34 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA17521 for ; Fri, 8 Feb 2002 18:37:33 -0600 (CST) Received: from localhost ([61.248.253.33]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id SAA24575 for ; Fri, 8 Feb 2002 18:37:24 -0600 (CST) Message-Id: <200202090037.SAA24575@dns2.anl.gov> Reply-To: webmaster@ibuksorak.com From: �饜葆擊 To: ietf-krb-wg@anl.gov Subject: [惜堅]貲瞰/⺕陛繹陛褶欽嬪⺕ユ雖.*磁撲學�饜葆擊* Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 9 Feb 2002 09:36:28 +0900 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk 陛濠磁撲學�饜葆擊

磁撲學�饜葆擊擎陛褶⺕ユ雖殮棲棻.

陝謙貲瞰 . ⺕陛繹縑

陛褶欽嬪⺕ユ雖蒂瓊戲衛釭蹂?

斜歲磁撲學�饜葆擊擊贗葛ボ爾撮蹂...

盪⻣ �饜葆擊擎蕪睡攪瞪ボ螃朝瞪鱔奢徹檣嬴掙檜縑濰濛擊鷓錶掘菟濰擊等辦朝夥款奢徹擊餌辨ビ艘堅傳フ瞪鱔陛螟曖碳ぇヘ擊ボ模ビ晦嬪ビ罹憮曄衝殮衝掘褻煎勒蹴ビ艘戲貊勒蹴濠營朝 100% �饜模釭鼠, 骯給煎雖擎 �饜餵殮棲棻.
傳フ檣霞齒, 繭掙, 歎霞戲煎夥款擊葆馬ビ罹嬴煎葆 �婁諦 �饜曖錳瞳諼摹檜寞轎腎橫 Д擋牖�檜諾撩ボ雖堅, 褐唳鱔, 婦瞰膩, ニ睡嘐辨, 蝶⑷溯蝶ボ模, 熨鏃薯剪縑饕錯フ �棟檜氈橫鼻殲フ嬴藹擊替郭褒熱氈蝗棲棻.

		Ｃ瑤繹縑朝熱瓣� 偽擎撲學骯曖瞰唳擊虜都ビ衛賊憮瑤釭僭擊嗯擊熱氈戲貊, 盪溫フ陛問戲煎匸衙ベ棲棻. Ｃ罹葷繹縑朝盪⻣餵蕙, 啗堊縑憮僭啾檜諦閉衛紫ビ堅 20碟剪葬縑朝樓蟾夥棻陛氈橫ボ熱踹婁褐摹フ夥棻 �紫闌晦撮蹂.
嬴期フ碟嬪晦!			-詣霞撿唳-

Ｃ 陛擊繹 羲衛陝謙骯擒蟾諦骯擒蟾輿, 斜葬堅 �溥フ撲學欽シ擊虜都ビ褒熱氈蝗棲棻

Ｃ 啖選繹縑朝堅掘葆釭馬濠偽擎匙擊掘錶詳擊熱紫氈掘蹂,,剩謠擎匙偽嬴蹂,,

雖旎蕨擒ビ撮蹂,,,,,

樓蟾ボ熱踹濰頂團夢紫氈橫蹂 葭觼

﹥ 陛濠磁撲學�饜葆擊 �［檜雖 : http://www.ibuksorak.com
﹥ 檜詭橾 : webmaster@ibuksorak.com

獄詭橾擎薑爾鱔褐蜂徹睦薯 50褻縑曖剪フ [�爾] 詭橾殮棲棻.
敝ビ曖ヤ犒フ陳婁ビ衛朝橾賅舒廓璽ビ衛望夥塭貊...
𧘇ヅ煎斜極螃盟煎醞犒詭橾擊嫡戲樟棻賊薑醞ɛ 餌婁萄葬貊
渦檜鼻詭橾擊嫡堅談雖彊戲衛賊 [熱褐剪睡]蒂贗葛ボ輿衛剪釭
�褐ビ罹輿衛賊闊衛餉薯ビ啊蝗棲棻. 馬餌ベ棲棻.
.

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 19:57:33 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28478 for ; Fri, 8 Feb 2002 19:57:32 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id SAA20660 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 18:46:20 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA20649; Fri, 8 Feb 2002 18:46:18 -0600 (CST) Received: from www.yahho.com (28.c210-85-16.ethome.net.tw [210.85.16.28]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id SAA26039; Fri, 8 Feb 2002 18:45:58 -0600 (CST) Date: Fri, 8 Feb 2002 18:45:58 -0600 (CST) Received: from tcts1 by venus.seed.net.tw with SMTP id UttEQJKYPVostxG5R; Sat, 09 Feb 2002 08:55:04 +0800 Message-ID: From: A43gz@yahoo.com To: X7uUAemCQpP0K@tcts1.seed.net.tw Subject: qbCeOrHLAqvp2b3Eln5N7mDNuhk MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_voYwEjHS1D0UbB2hqMCbY2A" X-Mailer: IcT7fpPthP6zeMG13rkJlB57UW X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_voYwEjHS1D0UbB2hqMCbY2A Content-Type: multipart/alternative; boundary="----=_NextPart_voYwEjHS1D0UbB2hqMCbY2AAA" ------=_NextPart_voYwEjHS1D0UbB2hqMCbY2AAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4wIj4NCjxtZXRhIG5hbWU9IlByb2dJZCIgY29udGVu dD0iRnJvbnRQYWdlLkVkaXRvci5Eb2N1bWVudCI+DQo8dGl0bGU+saGkSLhgxeW77rBPPC90aXRs ZT4NCjwvaGVhZD4NCg0KPGJvZHk+DQoNCjxwPq+7pm6vuiE8L3A+DQo8cD6hQDxhIGhyZWY9Imh0 dHA6Ly93d3cuaXZpZGVvLmNvbXR3L2ZsYXNoL3JvbWFuY2UuYXNwIj4NCjxvYmplY3QgY2xhc3Np ZD0iY2xzaWQ6RDI3Q0RCNkUtQUU2RC0xMWNmLTk2QjgtNDQ0NTUzNTQwMDAwIiBjb2RlQmFzZT0i aHR0cDovL2Rvd25sb2FkLm1hY3JvbWVkaWEuY29tL3B1Yi9zaG9ja3dhdmUvY2Ficy9mbGFzaC9z d2ZsYXNoLmNhYiN2ZXJzaW9uPTQsMCwyLDAiIGhlaWdodD0iMzI0IiB3aWR0aD0iNTUwIj4NCiAg PHBhcmFtIG5hbWU9Il9jeCIgdmFsdWU9IjE0NTUyIj4NCiAgPHBhcmFtIG5hbWU9Il9jeSIgdmFs dWU9Ijg1NzMiPg0KICA8cGFyYW0gbmFtZT0iTW92aWUiIHZhbHVlPSJodHRwOi8vd3d3Lml2aWRl by5jb20udHcvZmxhc2gvY2FyZF8zLnN3ZiI+DQogIDxwYXJhbSBuYW1lPSJTcmMiIHZhbHVlPSJo dHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvY2FyZF8zLnN3ZiI+DQogIDxwYXJhbSBuYW1l PSJXTW9kZSIgdmFsdWU9IldpbmRvdyI+DQogIDxwYXJhbSBuYW1lPSJQbGF5IiB2YWx1ZT0iMCI+ DQogIDxwYXJhbSBuYW1lPSJMb29wIiB2YWx1ZT0iLTEiPg0KICA8cGFyYW0gbmFtZT0iUXVhbGl0 eSIgdmFsdWU9IkhpZ2giPg0KICA8cGFyYW0gbmFtZT0iU0FsaWduIiB2YWx1ZT4NCiAgPHBhcmFt IG5hbWU9Ik1lbnUiIHZhbHVlPSItMSI+DQogIDxwYXJhbSBuYW1lPSJCYXNlIiB2YWx1ZT4NCiAg PHBhcmFtIG5hbWU9IlNjYWxlIiB2YWx1ZT0iU2hvd0FsbCI+DQogIDxwYXJhbSBuYW1lPSJEZXZp Y2VGb250IiB2YWx1ZT0iMCI+DQogIDxwYXJhbSBuYW1lPSJFbWJlZE1vdmllIiB2YWx1ZT0iMCI+ DQogIDxwYXJhbSBuYW1lPSJCR0NvbG9yIiB2YWx1ZT4NCiAgPHBhcmFtIG5hbWU9IlNXUmVtb3Rl IiB2YWx1ZT4NCiAgPHBhcmFtIG5hbWU9IlN0YWNraW5nIiB2YWx1ZT0iYmVsb3ciPjxlbWJlZCBz cmM9Imh0dHA6Ly93d3cuaXZpZGVvLmNvbS50dy9mbGFzaC9jYXJkXzMuc3dmIiBxdWFsaXR5PSJo aWdoIiBwbHVnaW5zcGFnZT0iaHR0cDovL3d3dy5tYWNyb21lZGlhLmNvbS9zaG9ja3dhdmUvZG93 bmxvYWQvaW5kZXguY2dpP1AxX1Byb2RfVmVyc2lvbj1TaG9ja3dhdmVGbGFzaCIgdHlwZT0iYXBw bGljYXRpb24veC1zaG9ja3dhdmUtZmxhc2giIHdpZHRoPSI1NTAiIGhlaWdodD0iMzI0Ij4NCjwv b2JqZWN0Pg0KPC9hPg0KPC9wPg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4= ------=_NextPart_voYwEjHS1D0UbB2hqMCbY2AAA-- ------=_NextPart_voYwEjHS1D0UbB2hqMCbY2A-- From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 22:13:04 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01081 for ; Fri, 8 Feb 2002 22:13:03 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id VAA05238 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 21:01:21 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA05232 for ; Fri, 8 Feb 2002 21:01:19 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA16902 for ; Fri, 8 Feb 2002 21:01:19 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA04525; Fri, 8 Feb 2002 22:01:19 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA10128; Fri, 8 Feb 2002 22:01:18 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id WAA26359; Fri, 8 Feb 2002 22:01:18 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id WAA25141; Fri, 8 Feb 2002 22:01:17 -0500 (EST) To: assar@kth.se Cc: ietf-krb-wg@anl.gov Subject: Re: Why does a client care about the anonymous flag? References: <20020207142314.B2C07765C2@luminous.mit.edu> <5l8za3o990.fsf@assaris.sics.se> From: Sam Hartman Date: 08 Feb 2002 22:01:17 -0500 In-Reply-To: assar@kth.se's message of "09 Feb 2002 00:15:55 +0100" Message-ID: Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "assar" == assar writes: assar> hartmans@mit.edu (Sam Hartman) writes: >> Why does a client care about an anonymous flag? What should my >> client do differently if it has an anonymous flag set in one of its >> tickets? assar> I would think that there can be clients/users that for policy reasons assar> decide that they will only send anonymous tickets to a certain assar> service. The client could either keep track of it requested a assar> particular service as anonymous and use that for deciding if it should assar> be used, or it could just grab the bits it gets back from the server assar> (which it does for lots of other ticket attributes such as expiration assar> times - the server might have changed them). Sure. That's sufficient to say some clients care about anonymous, but not strong enough for a statement that clients must care. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 8 22:23:41 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01184 for ; Fri, 8 Feb 2002 22:23:40 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id VAA08452 for ietf-krb-wg-outgoing; Fri, 8 Feb 2002 21:12:24 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA08446 for ; Fri, 8 Feb 2002 21:12:23 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA18635 for ; Fri, 8 Feb 2002 21:12:23 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA15656; Fri, 8 Feb 2002 22:12:20 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA10537; Fri, 8 Feb 2002 22:12:20 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id WAA04922; Fri, 8 Feb 2002 22:12:20 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id WAA25144; Fri, 8 Feb 2002 22:12:19 -0500 (EST) To: Ken Raeburn Cc: assar@kth.se, ietf-krb-wg@anl.gov Subject: Re: some comments on draft-ietf-cat-kerberos-revisions-10.txt References: <5ld6zfo9lw.fsf@assaris.sics.se> From: Sam Hartman Date: 08 Feb 2002 22:12:19 -0500 In-Reply-To: Ken Raeburn's message of "08 Feb 2002 18:56:12 -0500" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "Ken" == Ken Raeburn writes: >> key usage 1024 and 1025 are both reserved for applications and for >> using with other protocols that are defined in terms of the kerberos >> encryption methods. Ken> Hmm, I'll look into that. You really can't distinguish between these two cases can you? From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sat Feb 9 14:14:14 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18938 for ; Sat, 9 Feb 2002 14:14:13 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA12046 for ietf-krb-wg-outgoing; Sat, 9 Feb 2002 13:02:21 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA12040 for ; Sat, 9 Feb 2002 13:02:20 -0600 (CST) Received: from assaris.sics.se (ASTRAL-VINE.MIT.EDU [18.101.1.27]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA07597 for ; Sat, 9 Feb 2002 13:02:20 -0600 (CST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id UAA13847; Sat, 9 Feb 2002 20:02:32 +0100 (CET) (envelope-from assar) From: assar@kth.se To: Ken Raeburn Cc: ietf-krb-wg@anl.gov Subject: Re: some comments on draft-ietf-cat-kerberos-revisions-10.txt References: <5ld6zfo9lw.fsf@assaris.sics.se> Date: 09 Feb 2002 20:02:32 +0100 In-Reply-To: Ken Raeburn's message of "08 Feb 2002 18:56:12 -0500" Message-ID: <5ly9i2eawn.fsf@assaris.sics.se> Lines: 41 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Ken Raeburn writes: > > A document this long should really have a table of contents. > > According to the editor requirements, it's actually required for > anything remotely close to this size. Since the master form is HTML > at the moment, I'm not sure how that's going to happen. How is the text version generated from the master HTML? > > Why is combine-keys defined in this document? > > To provide a single interface for preauth mechanisms like SAM to use, > rather than specifying things like "XOR your DES keys together", which > breaks if you're not using one of the listed encryption systems. For > our existing systems, "xor and maybe fix parity" may suffice, How would this work for trying to advance this to draft standard? Would we have to show that this actually interoperates used by some other protocol or would it be enough with having test programs? > > 6.1: > > > > still talks about keytypes (and sometimes about etype) > > Oops. I'll try to fix that in the next rev of the crypto draft. (In > case it escaped your notice, draft-ietf-krb-wg-crypto-XX.txt was split > off, and kerberos-revisions will refer to it in the future.) Yeah, I haven't had time to read that draft yet and I thought I should send in my comments to the revisions first. > > A table of salt types would be useful. > > Salt types are going away; the replacement will be a more generic and > opaque "string to key parameters" blob, the interpretation of which is > left to each cryptosystem, sent by the KDC via preauth. What preauth option is that? I didn't find any mentioned in draft-ietf-krb-wg-crypto-00.txt. /assar From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sat Feb 9 14:15:51 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18986 for ; Sat, 9 Feb 2002 14:15:50 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA12643 for ietf-krb-wg-outgoing; Sat, 9 Feb 2002 13:04:42 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA12637 for ; Sat, 9 Feb 2002 13:04:41 -0600 (CST) Received: from assaris.sics.se (ASTRAL-VINE.MIT.EDU [18.101.1.27]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA07893 for ; Sat, 9 Feb 2002 13:04:41 -0600 (CST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id UAA13853; Sat, 9 Feb 2002 20:04:54 +0100 (CET) (envelope-from assar) From: assar@kth.se To: Sam Hartman Cc: Ken Raeburn , ietf-krb-wg@anl.gov Subject: Re: some comments on draft-ietf-cat-kerberos-revisions-10.txt References: <5ld6zfo9lw.fsf@assaris.sics.se>

Date: 09 Feb 2002 20:04:54 +0100 In-Reply-To: Sam Hartman's message of "08 Feb 2002 22:12:19 -0500" Message-ID: <5lu1sqeasp.fsf@assaris.sics.se> Lines: 18 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Sam Hartman writes: > >>>>> "Ken" == Ken Raeburn writes: > > >> key usage 1024 and 1025 are both reserved for applications and for > >> using with other protocols that are defined in terms of the kerberos > >> encryption methods. > > Ken> Hmm, I'll look into that. > > You really can't distinguish between these two cases can you? I don't think you can. But I would like the document to read "if you use a key usage value for your application, take a number [1026,2047]." (and leaving 1024 - 1025 for the protocols that are already defined in terms of the kerberos crypto types. I think this is just a clarification, and not a change of the intended meaning. /assar From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sat Feb 9 14:29:13 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19067 for ; Sat, 9 Feb 2002 14:29:12 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA16086 for ietf-krb-wg-outgoing; Sat, 9 Feb 2002 13:15:31 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA16080 for ; Sat, 9 Feb 2002 13:15:29 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA09404 for ; Sat, 9 Feb 2002 13:15:27 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA10953; Sat, 9 Feb 2002 14:15:10 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA04721; Sat, 9 Feb 2002 14:15:09 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id OAA08048; Sat, 9 Feb 2002 14:15:09 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id OAA20170; Sat, 9 Feb 2002 14:15:09 -0500 To: assar@kth.se Cc: ietf-krb-wg@anl.gov Subject: Re: some comments on draft-ietf-cat-kerberos-revisions-10.txt References: <5ld6zfo9lw.fsf@assaris.sics.se> <5ly9i2eawn.fsf@assaris.sics.se> From: Ken Raeburn Date: 09 Feb 2002 14:15:09 -0500 In-Reply-To: <5ly9i2eawn.fsf@assaris.sics.se> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk assar@kth.se writes: > How is the text version generated from the master HTML? My guess: Netscape's "Save As..." function, plus some post-processing for page breaks. > > > Why is combine-keys defined in this document? > > To provide a single interface for preauth mechanisms like SAM to use, > > rather than specifying things like "XOR your DES keys together", which > > breaks if you're not using one of the listed encryption systems. For > > our existing systems, "xor and maybe fix parity" may suffice, > > How would this work for trying to advance this to draft standard? > Would we have to show that this actually interoperates used by some > other protocol or would it be enough with having test programs? I'm expecting/hoping Ken Hornstein's next rev of the draft outlining SAM preauth will use it. But a test vector ought to be good enough, I think, to show that an implementation of a cryptosystem is correct. Interoperability between implementations of these preauth schemes would indicate compatible implementations of not only the function but also the callers. > > Salt types are going away; the replacement will be a more generic and > > opaque "string to key parameters" blob, the interpretation of which is > > left to each cryptosystem, sent by the KDC via preauth. > > What preauth option is that? I didn't find any mentioned in > draft-ietf-krb-wg-crypto-00.txt. As with all the actualy protocol messages, it's outside the scope of the crypto draft. I need to write up a proposal to add to kerberos-revisions. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sat Feb 9 16:19:20 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19766 for ; Sat, 9 Feb 2002 16:19:20 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id PAA20056 for ietf-krb-wg-outgoing; Sat, 9 Feb 2002 15:09:08 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA20050 for ; Sat, 9 Feb 2002 15:09:06 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA26133 for ; Sat, 9 Feb 2002 15:09:06 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA12141; Sat, 9 Feb 2002 16:09:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA07417; Sat, 9 Feb 2002 16:09:05 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA13752; Sat, 9 Feb 2002 16:09:05 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id QAA25397; Sat, 9 Feb 2002 16:09:04 -0500 (EST) To: assar@kth.se Cc: Ken Raeburn , ietf-krb-wg@anl.gov Subject: Re: some comments on draft-ietf-cat-kerberos-revisions-10.txt References: <5ld6zfo9lw.fsf@assaris.sics.se>

<5lu1sqeasp.fsf@assaris.sics.se> From: Sam Hartman Date: 09 Feb 2002 16:09:04 -0500 In-Reply-To: assar@kth.se's message of "09 Feb 2002 20:04:54 +0100" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "assar" == assar writes: assar> Sam Hartman writes: >> >>>>> "Ken" == Ken Raeburn writes: >> >> >> key usage 1024 and 1025 are both reserved for applications and for >> >> using with other protocols that are defined in terms of the kerberos >> >> encryption methods. >> Ken> Hmm, I'll look into that. >> >> You really can't distinguish between these two cases can you? assar> I don't think you can. But I would like the document to read "if you assar> use a key usage value for your application, take a number assar> [1026,2047]." (and leaving 1024 - 1025 for the protocols that are assar> already defined in terms of the kerberos crypto types. I think this assar> is just a clarification, and not a change of the intended meaning. Hmm, I think the actual intent is that if you called krb5_mk_priv or krb5_mk_safe without giving a keyusage, say because you use one of the current APIs that doesn't use a keyusage, then you get these keyusage numbers. You'd get that either because you had a random application with an unspecified protocol or because you had an old protocol spec. Continuing to use these keyusages indefinitely for applications is probably OK, especially when the service name is application specific. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sun Feb 10 18:34:24 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12043 for ; Sun, 10 Feb 2002 18:34:23 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id RAA25438 for ietf-krb-wg-outgoing; Sun, 10 Feb 2002 17:19:19 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA25432 for ; Sun, 10 Feb 2002 17:19:17 -0600 (CST) Received: from assaris.sics.se (ASTRAL-VINE.MIT.EDU [18.101.1.27]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA13265 for ; Sun, 10 Feb 2002 17:19:17 -0600 (CST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id AAA15757; Mon, 11 Feb 2002 00:19:30 +0100 (CET) (envelope-from assar) From: assar@kth.se To: Sam Hartman Cc: Ken Raeburn , ietf-krb-wg@anl.gov Subject: Re: some comments on draft-ietf-cat-kerberos-revisions-10.txt References: <5ld6zfo9lw.fsf@assaris.sics.se>

<5lu1sqeasp.fsf@assaris.sics.se> Date: 11 Feb 2002 00:19:30 +0100 In-Reply-To: Sam Hartman's message of "09 Feb 2002 16:09:04 -0500" Message-ID: <5laduggc1p.fsf@assaris.sics.se> Lines: 11 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Sam Hartman writes: > Hmm, I think the actual intent is that if you called krb5_mk_priv or > krb5_mk_safe without giving a keyusage, say because you use one of the > current APIs that doesn't use a keyusage, then you get these keyusage > numbers. You'd get that either because you had a random application > with an unspecified protocol or because you had an old protocol spec. So that's different from 13 and 15 by having the application not choose the keys? /assar From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sun Feb 10 21:41:27 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15099 for ; Sun, 10 Feb 2002 21:41:27 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id UAA19934 for ietf-krb-wg-outgoing; Sun, 10 Feb 2002 20:29:05 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA19928 for ; Sun, 10 Feb 2002 20:29:04 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA11326 for ; Sun, 10 Feb 2002 20:29:04 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA21768; Sun, 10 Feb 2002 21:29:04 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA13112; Sun, 10 Feb 2002 21:29:03 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id VAA12291; Sun, 10 Feb 2002 21:29:03 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id VAA26063; Sun, 10 Feb 2002 21:29:02 -0500 (EST) To: assar@kth.se Cc: Ken Raeburn , ietf-krb-wg@anl.gov Subject: Re: some comments on draft-ietf-cat-kerberos-revisions-10.txt References: <5ld6zfo9lw.fsf@assaris.sics.se>

<5lu1sqeasp.fsf@assaris.sics.se> <5laduggc1p.fsf@assaris.sics.se> From: Sam Hartman Date: 10 Feb 2002 21:29:02 -0500 In-Reply-To: assar@kth.se's message of "11 Feb 2002 00:19:30 +0100" Message-ID: Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "assar" == assar writes: assar> Sam Hartman writes: >> Hmm, I think the actual intent is that if you called krb5_mk_priv or >> krb5_mk_safe without giving a keyusage, say because you use one of the >> current APIs that doesn't use a keyusage, then you get these keyusage >> numbers. You'd get that either because you had a random application >> with an unspecified protocol or because you had an old protocol spec. assar> So that's different from 13 and 15 by having the application not assar> choose the keys? O, hmm, you're right. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 11 15:23:45 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16197 for ; Mon, 11 Feb 2002 15:23:45 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id OAA09083 for ietf-krb-wg-outgoing; Mon, 11 Feb 2002 14:10:04 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA09072; Mon, 11 Feb 2002 14:10:02 -0600 (CST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA18745; Mon, 11 Feb 2002 14:10:02 -0600 (CST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Mon, 11 Feb 2002 12:08:55 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Feb 2002 12:08:55 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 12:08:54 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 12:08:54 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 11 Feb 2002 12:06:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Interim IETF KRB-WG meeting Date: Mon, 11 Feb 2002 12:06:44 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD051AE848@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Interim IETF KRB-WG meeting Thread-Index: AcGw1p/w4IGAFsv1S42pGP2+hlbKvQCRmv4A From: "John Brezak" To: "Sam Hartman" , "Douglas E. Engert" Cc: X-OriginalArrivalTime: 11 Feb 2002 20:06:45.0284 (UTC) FILETIME=[A13DCE40:01C1B337] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by atalanta.ctd.anl.gov id OAA09073 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit I'd like to propose that we take the current kerberos-revisions, which is the delta from 1510 without any ASN.1 extensibility cleanup and move toward getting this completed - last call for the spring meetings. Once that is completed, let us move forward with a more comprehensive Kerberos extensibility and features I-D called "Kerberos 6". Here is my rationale: - I did a review of the changes required to implement the current ASN.1 proposal and found it to be in the order of 9 EM and a recurring cost of an additional person to keep up with ongoing testing. - ASN.1 extensibility is important and should have been in the protocol from the beginning, however it will be very difficult and expensive to fit this into the current protocol. We need to stop thinking about this as a neat update to the current protocol - it is a new protocol and we should approach it from this perspective. - The extensibility and cleanup of ASN.1 is not sufficient justification for implementation. From a vendor perspective, 1510 can continue to be used with additional extensions for some time without having to resort to the additional cost of a new protocol. - The GeneralString problem is best dealt with in a major protocol revision. Existing practice can be documented in the kerberos-revisions along with recommendations on achieving interoperability across implementations. There is also a dependency on DNS internationalization that needs to be resolved before moving forward. I understand that the IESG wants this addressed, but there are sufficient impediments to accomplishing this. - It is important to describe how current typed holes are to be utililized that is not sufficiently explained in 1510. For example authorization data and error data needs to have clear explainations. The current Kerberos-revisions does this. - Ticket extensions are needed quickly to support PKCROSS. PKCROSS is a very important protocol needed to grow the adoption of Kerberos. - Signed plaintext is a difficult problem and important problem, but I believe it can be deferred until Kerb6 because Kerberos has been useful without it. If needed pa-data and e-data can be used for this. Not pretty, but it can work. - Resources are limited. So far the working group have been completely absorbed in Kerberos-revisions. There are important clarifications needed in Kerberos that need to be documented in an RFC. There are other functional areas of Kerberos like - referrals, initial authentication protection, PK integration, new encryption types, application protocols, implications of transitivity on namespaces, etc., that need attention of this group. These areas will directly speed adoption of Kerberos and deserve much more attention. I propose this timeline: - Last call for PKINIT and Kerberos-revisions (1510 delta) for Spring 2002 - Last call for PKCROSS Winter 2002 - Last call for Kerberos6 Spring 2003 I would suggest taking the Tuesday meeting to make the required feature list for Kerberos-revisions '02 and focus on moving this forward toward last call. We need to get control of Kerberos-revision's features otherwise we will never ship it. > -----Original Message----- > From: Sam Hartman [mailto:hartmans@mit.edu] > Sent: Friday, February 08, 2002 11:28 AM > To: Douglas E. Engert > Cc: ietf-krb-wg@anl.gov > Subject: Re: Interim IETF KRB-WG meeting > > > Doug, John brought up an interesting point in a discussion > with us last week. It's fairly important that we produce a > spec that is acceptable to vendors: we want to make sure that > vendors can justify implementing our changes. > > John has some ideas on how to accomplish this. I think that > it would be worth a some of our time to discuss these issues. > > Also, I'll have a short presentation prepared on the open > issues list. If you have an issue with the extensibility > proposal that has not been properly addressed and it isn't on > the list I sent out in December, please let me know. > > > I know about several issues that Microsoft presented in SLC > and in mail since then. > > Jeff Altman is arriving Sunday. We hope to have something > intelligent to say about UTF-8 by Tuesday. > > > I also continue to work on coming up with proposed patches to > the draft to integrate parts of the extensibility proposal > that appear to have general agreement. The actual ASN.1 > still has several open issues, as do a few details. But I > think the basic framework is getting to a point where at > least looking at how it fits into the draft would be worth our time. > > --Sam > From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 11 15:56:50 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16941 for ; Mon, 11 Feb 2002 15:56:49 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id OAA23961 for ietf-krb-wg-outgoing; Mon, 11 Feb 2002 14:44:08 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA23950; Mon, 11 Feb 2002 14:44:06 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA26438; Mon, 11 Feb 2002 14:44:05 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id PAA06827; Mon, 11 Feb 2002 15:46:48 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma006737; Mon, 11 Feb 2002 15:46:22 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id PAA22815; Mon, 11 Feb 2002 15:41:48 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id PAA01765; Mon, 11 Feb 2002 15:43:13 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id PAA15590; Mon, 11 Feb 2002 15:42:11 -0500 (EST) Date: Mon, 11 Feb 2002 15:42:11 -0500 From: Nicolas Williams To: John Brezak Cc: Sam Hartman , "Douglas E. Engert" , ietf-krb-wg@anl.gov Subject: Simple AS exch protection / UTF-8 is not dependent on IDN (was Re: Interim IETF KRB-WG meeting) Message-ID: <20020211154209.O27171@sm2p1386swk.wdr.com> Mail-Followup-To: John Brezak , Sam Hartman , "Douglas E. Engert" , ietf-krb-wg@anl.gov References: <4AEE3169443CDD4796CA8A00B02191CD051AE848@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <4AEE3169443CDD4796CA8A00B02191CD051AE848@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>; from jbrezak@windows.microsoft.com on Mon, Feb 11, 2002 at 12:06:44PM -0800 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Mon, Feb 11, 2002 at 12:06:44PM -0800, John Brezak wrote: > - The GeneralString problem is best dealt with in a major protocol > revision. Existing practice can be documented in the kerberos-revisions > along with recommendations on achieving interoperability across > implementations. There is also a dependency on DNS internationalization > that needs to be resolved before moving forward. I understand that the > IESG wants this addressed, but there are sufficient impediments to > accomplishing this. Actually, I believe there is no dependency on the DNS i18n stuff. The reason is that RFC1510 Kerberos is already so different, so much broader in its namespace from DNS that it is simply not possible to retrofit IDN and stay backwards compatible with RFC1510 usage in the ASCII part of the Kerberos namespace. The stringprep draft is a useful guideline for dealing with the UTF-8 normalization issues however, but it need not progress for the Kerberos extensibility/UTF-8 stuff to progress (the applicable bits of stringprep are so small that they could be lifted almost verbatim, thus eliminating the normative reference to stringprep altogether). > - Signed plaintext is a difficult problem and important problem, but I > believe it can be deferred until Kerb6 because Kerberos has been useful > without it. If needed pa-data and e-data can be used for this. Not > pretty, but it can work. I think there's a way to secure RFC1510 AS exchanges without having to perform sugery on the ASN.1 such that systems with service principals can secure AS exchanges for user logins as follows: - TCP connect to AS - send AP-REQ to AS using the client [workstation] host's SPN - wait for AP-REQ or KRB-ERROR from AS - if KRB-ERROR log loudly and proceed with traditional AS-REQ; log any KRB-ERROR reply to the traditional AS-REQ loudly - if AP-REP send AS-REQ wrapped in a KRB-SAFE and wait for an AS-REP or KRB-ERROR wrapped in a KRB-SAFE Very simple to implement, no new ASN.1, backwards compatible with RFC1510. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 11 19:29:32 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20886 for ; Mon, 11 Feb 2002 19:29:31 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id SAA17791 for ietf-krb-wg-outgoing; Mon, 11 Feb 2002 18:12:50 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA17779; Mon, 11 Feb 2002 18:12:48 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA08533; Mon, 11 Feb 2002 18:12:48 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA04620; Mon, 11 Feb 2002 19:11:38 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA15646; Mon, 11 Feb 2002 19:11:38 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA25188; Mon, 11 Feb 2002 19:11:38 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id TAA26564; Mon, 11 Feb 2002 19:11:37 -0500 (EST) To: "John Brezak" Cc: "Douglas E. Engert" , Subject: Re: Interim IETF KRB-WG meeting References: <4AEE3169443CDD4796CA8A00B02191CD051AE848@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> From: Sam Hartman Date: 11 Feb 2002 19:11:37 -0500 In-Reply-To: "John Brezak"'s message of "Mon, 11 Feb 2002 12:06:44 -0800" Message-ID: Lines: 81 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "John" == John Brezak writes: John> I'd like to propose that we take the current kerberos-revisions, which John> is the delta from 1510 without any ASN.1 extensibility cleanup and move John> toward getting this completed - last call for the spring meetings. Once John> that is completed, let us move forward with a more comprehensive John> Kerberos extensibility and features I-D called "Kerberos 6". I must say that I'm somewhat shocked and surprised by this proposal; it certainly presents a different tone than the discussions we've been having over the last few weeks. I do appreciate you bringing these issues forward to the WG so we can discuss them fully. This proposal also presents a significant departure from the consensus that was apparent at the Salt Lake City meeting (and later supported on the list) that we wanted to solve the extensibility problems in revisions. Coming to realize that you want to reconsider a decision, particularly a recent decision, does happen from time to time. However, as I discussed previously it seems that as a working group we have two options if we believe the December proposal is too expensive. We could decide that another proposal provides a solution to the extensibility problem at a lower cost. The easiest way of doing this is to find a lower-cost proposal. We think we've done the best we can, but someone else could always think of something clever. We did try and split out our proposal so that our goals were separate from the specific implementation. Thus it should be fairly easy to argue that a specific alternative proposal solves the same problems we did even if the implementation is very different. Alternatively, we could decide that we don't want to solve the extensibility problem possibly because it is too expensive. We tried to clearly state our reasons for believing that the extensibility problem needed to be solved. If you want to move forward on this option, then you should explicitly disagree with one of our assumptions or the reasoning that lead us from the assumption to the conclusion that we need to solve the extensibility problem. Alternatively you could present a case that we've correctly identified a problem and its consequences but that solving the problem is too expensive. If you present such a case, you should explain how to deal with the consequences of the problem. For example we argued that without extensibility mechanisms vendors are likely to extend the protocol in incompatible ways. If you argue we don't want to solve extensibility, you should explain what we do about these incompatible extensions or why it is acceptable to have interoperability decrease over time. I'm not clear whether you consider your proposal to be an alternative proposal that eventually solves extensibility or an argument that we don't need to solve extensibility now. Either way, I'm not sure how you save money with this proposal instead of just going forward with the new protocol. If we continue to encourage use of protocols based on RFC 1510 and do not fix the extensibility problems, what do we do to avoid the evolutionary problems of Kerberos Version 4? Similarly we have some technical concerns with your proposal. OUr efforts to fix Kerberos over the past year have been motivated by problems with the existing Kerberos revisions document. Certainly, the revisions document presented at San Diego was not compatible with RFC 1510. We aren't sure what you consider to be an acceptable delta over RFC 1510 and we are not convinced that generating such a delta is easier than completing work on revisions. Similarly we contend that ticket extensions cannot be added to Kerberos without adding capability negotiation. We are very uncomfortable adding capability negotiation now for ticket extensions and later for other protocol features. That's just my initial reaction. We look forward to discussing these and other issues in the Kerberos meeting. --Sam From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 12 11:10:11 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16628 for ; Tue, 12 Feb 2002 11:10:11 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA12956 for ietf-krb-wg-outgoing; Tue, 12 Feb 2002 09:57:13 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA12950 for ; Tue, 12 Feb 2002 09:57:12 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA16731 for ; Tue, 12 Feb 2002 09:57:12 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16155; Tue, 12 Feb 2002 10:57:09 -0500 (EST) Message-Id: <200202121557.KAA16155@ietf.org> To: IETF-Announce: ; Cc: ietf-krb-wg@anl.gov From: The IESG SUBJECT: Last Call: Initial and Pass Through Authentication Using Kerberos V5 and GSS-API (IAKERB) to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 12 Feb 2002 10:57:08 -0500 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk The IESG has received a request from the Kerberos WG Working Group to consider Initial and Pass Through Authentication Using Kerberos V5 and GSS-API (IAKERB) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 26, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-cat-iakerb-08.txt From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 12 11:17:22 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16859 for ; Tue, 12 Feb 2002 11:17:21 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA15898 for ietf-krb-wg-outgoing; Tue, 12 Feb 2002 10:05:22 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA15892 for ; Tue, 12 Feb 2002 10:05:21 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA18870 for ; Tue, 12 Feb 2002 10:05:21 -0600 (CST) Message-ID: <3C693D40.BFEAD6B0@anl.gov> Date: Tue, 12 Feb 2002 10:05:20 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-krb-wg@anl.gov Subject: [Fwd: Re: Kerb WG iakerb and change/set password Internet drafts] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Re: Kerb WG iakerb and change/set password Internet drafts Date: Tue, 12 Feb 2002 00:55:44 -0500 From: "Jeffrey I. Schiller" To: "Douglas E. Engert" CC: Jonathan Trostle References: <001f01c1b2bd$467e7420$01e8a8c0@host3sy2bx4q> <3C67D4EF.8157365C@anl.gov> Ok. I finally figured out what happened and why IAKERB and Set/Change Password got stuck. The long and short of it is that IETF Last Calls were never sent, but the documents were entered into the tracking system, and then dropped (the tracking system was undergoing revision at the time). Until today I had thought they had gone through IETF last call and that all I had to do is the ballot, but that doesn't appear to be the case. I have submitted formal requests for last calls for both documents. I have also submitted my formal ballot for Set/Change, so all that has to happen now is the IESG needs to approve the Set/Change document, which it can do at its telechat on March 7th assuming no issues arise during last call. As for IAKERB, I am concerned about Martin Rex's message. Doug: Do you believe you have consensus, given Martin's objections? If Martin raises a concern during IETF Wide Last Call, I need to prepare a formal response. We'll see what happens (Jonathan: Want to Help? [I have your previous response already]). Assuming nothing that we cannot handle, it too can be finished at the March 7th telechat. -Jeff From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 12 11:35:34 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17453 for ; Tue, 12 Feb 2002 11:35:34 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA21807 for ietf-krb-wg-outgoing; Tue, 12 Feb 2002 10:21:24 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA21801 for ; Tue, 12 Feb 2002 10:21:23 -0600 (CST) Received: from raeburn.org (209-6-22-64.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.22.64]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA22654 for ; Tue, 12 Feb 2002 10:21:22 -0600 (CST) Received: from rsx-11.raeburn.org ([18.101.0.232]) by raeburn.org (8.11.3/8.11.3) with ESMTP id g1CGLLZ18726; Tue, 12 Feb 2002 11:21:21 -0500 (EST) Received: from raeburn by rsx-11.raeburn.org with local (Exim 3.34 #1 (Debian)) id 16afgF-0000Sx-00; Tue, 12 Feb 2002 11:21:19 -0500 From: Ken Raeburn To: ietf-krb-wg@anl.gov Subject: some initial notes from WG meeting Message-Id: Date: Tue, 12 Feb 2002 11:21:19 -0500 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk So, after John's recent email to the group and other stuff, we started off the interim meeting looking at what items have been added or discussed over time, in order to then try to get some idea what might actually be important for kerberos-revisions or other working group work. The stuff we've come up with so far is below. - RFC1510 compatibility - clarifications to RFC 1510 - internationalization - compat w/existing implementations - implementation notes - ticket extensions - authenticated plaintext - extensibility by vendors & IETF - evolvability by IETF - modern crypto - protect AS_REQ from weak passwords - PFS for KDC exchanges - PFS for appl exchanges (e.g., SAFE, PRIV) - remove address dependencies - minimize implementation cost - minimize testing cost - enable tying tickets to host/location/whatever - make PK & other WG work items possible - EDATA is screwed - new ticket flags: ANONYMOUS, TRANSITED-POLICY-CHECKED, OK-AS-DELEGATE - new KDC options: REQ-ANON, CANONICALIZE, DISABLE-TRANSITED-CHECK - cross-realm referrals - client name canonicalization - gnuftp.raeburn.org type of referral - realm authority for transited cross-realm authentication (the problem statement itself still needs some clarification) - key exchange without authentication - migration path for internationalization - clarification of principal name types + Packet Cable cares about auth plaintext and PK-CROSS + IBM cares about migration path for internationalization If we've overlooked anything, please let us know. Ken From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 12 11:46:02 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17939 for ; Tue, 12 Feb 2002 11:46:02 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA26637 for ietf-krb-wg-outgoing; Tue, 12 Feb 2002 10:33:13 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA26631 for ; Tue, 12 Feb 2002 10:33:12 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA25314 for ; Tue, 12 Feb 2002 10:33:12 -0600 (CST) Message-ID: <3C6943C6.735388BE@anl.gov> Date: Tue, 12 Feb 2002 10:33:10 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-krb-wg@anl.gov Subject: KRB-WG Interum meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit The KRB-WG meeting has started, and Ken R. has sent out a note already. Present at the meeting: Doug E., Jeff A., Ken H., Cliff N., John B., Nico W., Tom Y., Ken R., Sam H., and Jeff H. If other members have issued or comments, please send them ASAP. We are currently going through the list Ken sent out, deciding which items are a must. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 12 21:30:41 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03944 for ; Tue, 12 Feb 2002 21:30:40 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id UAA06346 for ietf-krb-wg-outgoing; Tue, 12 Feb 2002 20:08:07 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA06324 for ; Tue, 12 Feb 2002 20:08:05 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA22643 for ; Tue, 12 Feb 2002 20:08:05 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03448; Tue, 12 Feb 2002 21:08:02 -0500 (EST) Message-Id: <200202130208.VAA03448@ietf.org> To: IETF-Announce: ; Cc: ietf-krb-wg@anl.gov From: The IESG SUBJECT: Last Call: Kerberos Set/Change Password: Version 2 to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 12 Feb 2002 21:08:02 -0500 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk The IESG has received a request from the Kerberos WG Working Group to consider Kerberos Set/Change Password: Version 2 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 26, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-06.txt From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 06:33:47 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27631 for ; Wed, 13 Feb 2002 06:33:46 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id FAA19578 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 05:20:01 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id FAA19551; Wed, 13 Feb 2002 05:20:00 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id FAA18624; Wed, 13 Feb 2002 05:19:59 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id MAA13922; Wed, 13 Feb 2002 12:23:30 +0100 (MEZ) From: Martin Rex Message-Id: <200202131119.MAA07279@uw1048.wdf.sap-ag.de> Subject: Re: [Fwd: Re: Kerb WG iakerb and change/set password Internet drafts] To: deengert@anl.gov (Douglas E. Engert) Date: Wed, 13 Feb 2002 12:19:25 +0100 (MET) Cc: jis@mit.edu, john3725@world.std.com, ietf-krb-wg@anl.gov In-Reply-To: <3C693D40.BFEAD6B0@anl.gov> from "Douglas E. Engert" at Feb 12, 2 10:05:20 am Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit I am still extremely concerned about the IAKERB proposal. I still strongly object to how IAKERB is encapsulated with GSS-API requires the bloated SPNEGO with no added value (and seriously underspecified SPNEGO negotiation details) instead of running the negotiation completely inside (as far as apps above GSS-API are concerned) of the Kerberos GSS-API mechanism. (take the details from my last Emails on this issue). I don't have a good feeling about the actual underlying Kerberos message exchange is technically sound, but I don't have the necessary Kerberos background and experience to comment on that or come up with alternative proposals (and therefore will not object to these details). I really would appreciate if at least one of the Kerberos(&GSS-API) gurus (like Ted Ts'o or John Linn) would take a detailed look at the IAKERB proposal... -Martin Douglas E. Engert (forwarding Jeff Schiller's Email): > > -------- Original Message -------- > Subject: Re: Kerb WG iakerb and change/set password Internet drafts > Date: Tue, 12 Feb 2002 00:55:44 -0500 > From: "Jeffrey I. Schiller" > To: "Douglas E. Engert" > CC: Jonathan Trostle > References: <001f01c1b2bd$467e7420$01e8a8c0@host3sy2bx4q> <3C67D4EF.8157365C@anl.gov> > > Ok. I finally figured out what happened and why IAKERB and Set/Change > Password got stuck. The long and short of it is that IETF Last Calls > were never sent, but the documents were entered into the tracking > system, and then dropped (the tracking system was undergoing revision > at the time). Until today I had thought they had gone through IETF > last call and that all I had to do is the ballot, but that doesn't > appear to be the case. > > I have submitted formal requests for last calls for both documents. I > have also submitted my formal ballot for Set/Change, so all that has > to happen now is the IESG needs to approve the Set/Change document, > which it can do at its telechat on March 7th assuming no issues arise > during last call. > > As for IAKERB, I am concerned about Martin Rex's message. Doug: Do you > believe you have consensus, given Martin's objections? If Martin > raises a concern during IETF Wide Last Call, I need to prepare a > formal response. We'll see what happens (Jonathan: Want to Help? [I > have your previous response already]). Assuming nothing that we cannot > handle, it too can be finished at the March 7th telechat. > > -Jeff > From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 06:51:40 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28140 for ; Wed, 13 Feb 2002 06:51:39 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id FAA24114 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 05:40:22 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id FAA24103; Wed, 13 Feb 2002 05:40:21 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id FAA21744; Wed, 13 Feb 2002 05:40:20 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id MAA00029; Wed, 13 Feb 2002 12:43:52 +0100 (MEZ) From: Martin Rex Message-Id: <200202131139.MAA07354@uw1048.wdf.sap-ag.de> Subject: Kerb WG iakerb To: ietf-krb-wg@anl.gov Date: Wed, 13 Feb 2002 12:39:48 +0100 (MET) Cc: deengert@anl.gov, jis@mit.edu, john3725@world.std.com Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit I don't know whether I ever explained why the underlying IAKERB message exchange makes me uncomfortable (which is why I would really appreciate if Kerberos Gurus would comment on this part of the proposal). (a) requires the KDC to issue a service ticket to a user (b) requires the Kerberos implementation of the user to cache the user's longterm credentials indefinitely (b) As far as I understood it was meant to be a feature that the user's "ticket manager" program (be it kinit or something more sphisticated) would need to have the user's long term secret only for a very short time to be able to decrypt the AS_REP response from the KDC, so that the window of exposure for this longterm key remains as small as possible. (a) Since user's long term secrets are much more vulnerable to dictionary attacks than the (hopefully randomly generated) long term keys there is a potential danger in allowing the KDC to issue AP_REQ for user principals -- because these can be used to mount offline dictionary attacks. In order to minimize the possibility for offline dictionary attacks against user's long term keys the KDC should be permitted to: * deny issuing service tickets for users (user2user tickets are different in that they use a strong random key) * deny issuing TGTs in absence of valid pre-authentication data However this would be incompatible with the current IAKERB proposal. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 08:07:07 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00297 for ; Wed, 13 Feb 2002 08:07:06 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id GAA10329 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 06:54:40 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id GAA10318; Wed, 13 Feb 2002 06:54:38 -0600 (CST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id GAA03372; Wed, 13 Feb 2002 06:54:38 -0600 (CST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id HAA19182; Wed, 13 Feb 2002 07:54:35 -0500 (EST) Date: Wed, 13 Feb 2002 7:54:34 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: ietf-krb-wg@anl.gov, deengert@anl.gov, jis@mit.edu, john3725@world.std.com Subject: Re: Kerb WG iakerb In-Reply-To: Your message of Wed, 13 Feb 2002 12:39:48 +0100 (MET) Message-ID: Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk The reality is that most of the authors of the Kerberos revisions documents have been far too focused on attempting to solve the numerous problems with the base documents to spend any time examining the many side documents which have been sent to last call. It is unlikely that during this period that documents such as IAKERB will receive the attention they require. I agree with Martin's unease at (b). However, IAKERB would not be the first use of long term storage of the user's long term password on the system. Microsoft Windows already stores to the long term password in order to attempt to retrieve new TGT's automatically before they expire; or for use in comparing the end user's secret when waking up from an suspend mode or returning to a locked workstation. I believe other OS's do similar things. I'm more concerned with the inability to require the use of Pre-Auth data for two reasons. (1) offline dictionary attacks; (2) pre-auth is the primary way we have of extending the Kerberos 5 protocol to support extensibility and internationalization. If IAKERB cannot require the use of Pre-Auth it will be incompatible with future versions of Kerberos 5. - Jeff > I don't know whether I ever explained why the underlying IAKERB > message exchange makes me uncomfortable (which is why I would > really appreciate if Kerberos Gurus would comment on this part > of the proposal). > > (a) requires the KDC to issue a service ticket to a user > > (b) requires the Kerberos implementation of the user to cache > the user's longterm credentials indefinitely > > (b) > As far as I understood it was meant to be a feature that the user's > "ticket manager" program (be it kinit or something more sphisticated) > would need to have the user's long term secret only for a very short > time to be able to decrypt the AS_REP response from the KDC, so > that the window of exposure for this longterm key remains as > small as possible. > > (a) > Since user's long term secrets are much more vulnerable to dictionary > attacks than the (hopefully randomly generated) long term keys there > is a potential danger in allowing the KDC to issue AP_REQ for > user principals -- because these can be used to mount offline > dictionary attacks. > > In order to minimize the possibility for offline dictionary attacks > against user's long term keys the KDC should be permitted to: > > * deny issuing service tickets for users (user2user tickets > are different in that they use a strong random key) > > * deny issuing TGTs in absence of valid pre-authentication data > > However this would be incompatible with the current IAKERB proposal. > > > -Martin > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 12:06:32 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12950 for ; Wed, 13 Feb 2002 12:06:31 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA19333 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 10:52:46 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA19313 for ; Wed, 13 Feb 2002 10:52:45 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA23480 for ; Wed, 13 Feb 2002 10:52:44 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA26619; Wed, 13 Feb 2002 17:56:15 +0100 (MEZ) From: Martin Rex Message-Id: <200202131652.RAA10608@uw1048.wdf.sap-ag.de> Subject: Re: Simple AS exch protection / UTF-8 is not dependent on IDN (was Re: Interim IETF KRB-WG meeting) To: Nicolas.Williams@ubsw.com (Nicolas Williams) Date: Wed, 13 Feb 2002 17:52:10 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <20020211154209.O27171@sm2p1386swk.wdr.com> from "Nicolas Williams" at Feb 11, 2 03:42:11 pm Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > > - Signed plaintext is a difficult problem and important problem, but I > > believe it can be deferred until Kerb6 because Kerberos has been useful > > without it. If needed pa-data and e-data can be used for this. Not > > pretty, but it can work. > > I think there's a way to secure RFC1510 AS exchanges without having to > perform sugery on the ASN.1 such that systems with service principals > can secure AS exchanges for user logins as follows: > > - TCP connect to AS > - send AP-REQ to AS using the client [workstation] host's SPN > - wait for AP-REQ or KRB-ERROR from AS > > - if KRB-ERROR log loudly and proceed with traditional AS-REQ; log > any KRB-ERROR reply to the traditional AS-REQ loudly > > - if AP-REP send AS-REQ wrapped in a KRB-SAFE and wait for an AS-REP > or KRB-ERROR wrapped in a KRB-SAFE > > Very simple to implement, no new ASN.1, backwards compatible with RFC1510. What about workstations without a host SPN? (and IAKERB scenarios?) What do you do if the host SPN is from a different realm than the realm the user wants to login to? Do we want to require the host-SPN to be accessible for the user (or require a trusted service for this purpose) from *ALL* Kerberos implementations? -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 12:27:15 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14598 for ; Wed, 13 Feb 2002 12:27:14 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id LAA25633 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 11:14:33 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA25615 for ; Wed, 13 Feb 2002 11:14:32 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA28428 for ; Wed, 13 Feb 2002 11:14:32 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id MAA23127; Wed, 13 Feb 2002 12:17:38 -0500 (EST) Received: from (twelve.ubswarburg.com [192.168.0.6]) by gate via smap (V2.0) id xma021700; Wed, 13 Feb 2002 12:16:05 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan3 [192.168.0.6]) by virscan3.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA07791; Wed, 13 Feb 2002 12:12:14 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA16597; Wed, 13 Feb 2002 12:12:49 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id MAA27434; Wed, 13 Feb 2002 12:11:43 -0500 (EST) Date: Wed, 13 Feb 2002 12:11:43 -0500 From: Nicolas Williams To: mrex@sap-ag.de Cc: ietf-krb-wg@anl.gov Subject: Re: Simple AS exch protection / UTF-8 is not dependent on IDN (was Re: Interim IETF KRB-WG meeting) Message-ID: <20020213121142.B27171@sm2p1386swk.wdr.com> Mail-Followup-To: mrex@sap-ag.de, ietf-krb-wg@anl.gov References: <20020211154209.O27171@sm2p1386swk.wdr.com> <200202131652.RAA10608@uw1048.wdf.sap-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200202131652.RAA10608@uw1048.wdf.sap-ag.de>; from martin.rex@sap-ag.de on Wed, Feb 13, 2002 at 05:52:10PM +0100 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk This was a straw man. I wasn't seriously proposing this. Nico On Wed, Feb 13, 2002 at 05:52:10PM +0100, Martin Rex wrote: > > What about workstations without a host SPN? (and IAKERB scenarios?) > > What do you do if the host SPN is from a different realm than > the realm the user wants to login to? > > Do we want to require the host-SPN to be accessible for the user > (or require a trusted service for this purpose) from *ALL* Kerberos > implementations? > > -Martin -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 12:59:51 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15540 for ; Wed, 13 Feb 2002 12:59:50 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id LAA05075 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 11:45:19 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA05062; Wed, 13 Feb 2002 11:45:17 -0600 (CST) Received: from TheWorld.com (pcls1.std.com [199.172.62.103]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA05303; Wed, 13 Feb 2002 11:45:17 -0600 (CST) Received: from host3sy2bx4q (adsl-64-171-14-173.dsl.sntc01.pacbell.net [64.171.14.173]) by TheWorld.com (8.9.3/8.9.3) with SMTP id MAA11254; Wed, 13 Feb 2002 12:45:14 -0500 Message-ID: <001201c1b4b5$83bf30f0$01e8a8c0@host3sy2bx4q> From: "Jonathan Trostle" To: , Cc: , References: <200202131139.MAA07354@uw1048.wdf.sap-ag.de> Subject: Re: Kerb WG iakerb Date: Wed, 13 Feb 2002 09:40:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Martin Rex" To: Cc: ; ; Sent: Wednesday, February 13, 2002 3:39 AM Subject: Kerb WG iakerb > I don't know whether I ever explained why the underlying IAKERB > message exchange makes me uncomfortable (which is why I would > really appreciate if Kerberos Gurus would comment on this part > of the proposal). > > (a) requires the KDC to issue a service ticket to a user > > (b) requires the Kerberos implementation of the user to cache > the user's longterm credentials indefinitely Sorry, I haven't looked at the draft for quite a while. I vaguely recall some issue along these lines in an earlier version of the draft but I thought it was fixed in the latest draft (08). Why would this be required? > > (b) > As far as I understood it was meant to be a feature that the user's > "ticket manager" program (be it kinit or something more sphisticated) > would need to have the user's long term secret only for a very short > time to be able to decrypt the AS_REP response from the KDC, so > that the window of exposure for this longterm key remains as > small as possible. > > (a) > Since user's long term secrets are much more vulnerable to dictionary > attacks than the (hopefully randomly generated) long term keys there > is a potential danger in allowing the KDC to issue AP_REQ for > user principals -- because these can be used to mount offline > dictionary attacks. > > In order to minimize the possibility for offline dictionary attacks > against user's long term keys the KDC should be permitted to: > > * deny issuing service tickets for users (user2user tickets > are different in that they use a strong random key) > > * deny issuing TGTs in absence of valid pre-authentication data > > However this would be incompatible with the current IAKERB proposal. I don't recall IAKERB having these restrictions. Jonathan > > > -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 13:01:29 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15608 for ; Wed, 13 Feb 2002 13:01:29 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id LAA06042 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 11:48:29 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA06031; Wed, 13 Feb 2002 11:48:28 -0600 (CST) Received: from TheWorld.com (pcls1.std.com [199.172.62.103]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA06114; Wed, 13 Feb 2002 11:48:28 -0600 (CST) Received: from host3sy2bx4q (adsl-64-171-14-173.dsl.sntc01.pacbell.net [64.171.14.173]) by TheWorld.com (8.9.3/8.9.3) with SMTP id MAA16176; Wed, 13 Feb 2002 12:48:24 -0500 Message-ID: <001801c1b4b5$f585c730$01e8a8c0@host3sy2bx4q> From: "Jonathan Trostle" To: , Cc: , , References: Subject: Re: Kerb WG iakerb Date: Wed, 13 Feb 2002 09:43:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jeffrey Altman" To: Cc: ; ; ; Sent: Wednesday, February 13, 2002 4:54 AM Subject: Re: Kerb WG iakerb > The reality is that most of the authors of the Kerberos revisions > documents have been far too focused on attempting to solve the > numerous problems with the base documents to spend any time examining > the many side documents which have been sent to last call. It is > unlikely that during this period that documents such as IAKERB will > receive the attention they require. It went through WG last call so it should hopefully be done - I did get some good comments from several WG participants. > > I agree with Martin's unease at (b). However, IAKERB would not be the > first use of long term storage of the user's long term password on the > system. Microsoft Windows already stores to the long term password in > order to attempt to retrieve new TGT's automatically before they > expire; or for use in comparing the end user's secret when waking up > from an suspend mode or returning to a locked workstation. I believe > other OS's do similar things. I too agree with Martin's unease. IAKERB shouldn't (and hopefully doesn't in the current spec.) require long term storage. > > I'm more concerned with the inability to require the use of Pre-Auth > data for two reasons. (1) offline dictionary attacks; (2) pre-auth is > the primary way we have of extending the Kerberos 5 protocol to > support extensibility and internationalization. If IAKERB cannot > require the use of Pre-Auth it will be incompatible with future > versions of Kerberos 5. Right. Jonathan > > - Jeff > > > I don't know whether I ever explained why the underlying IAKERB > > message exchange makes me uncomfortable (which is why I would > > really appreciate if Kerberos Gurus would comment on this part > > of the proposal). > > > > (a) requires the KDC to issue a service ticket to a user > > > > (b) requires the Kerberos implementation of the user to cache > > the user's longterm credentials indefinitely > > > > (b) > > As far as I understood it was meant to be a feature that the user's > > "ticket manager" program (be it kinit or something more sphisticated) > > would need to have the user's long term secret only for a very short > > time to be able to decrypt the AS_REP response from the KDC, so > > that the window of exposure for this longterm key remains as > > small as possible. > > > > (a) > > Since user's long term secrets are much more vulnerable to dictionary > > attacks than the (hopefully randomly generated) long term keys there > > is a potential danger in allowing the KDC to issue AP_REQ for > > user principals -- because these can be used to mount offline > > dictionary attacks. > > > > In order to minimize the possibility for offline dictionary attacks > > against user's long term keys the KDC should be permitted to: > > > > * deny issuing service tickets for users (user2user tickets > > are different in that they use a strong random key) > > > > * deny issuing TGTs in absence of valid pre-authentication data > > > > However this would be incompatible with the current IAKERB proposal. > > > > > > -Martin > > > > > > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! > The Kermit Project @ Columbia University includes Telnet, FTP and HTTP > http://www.kermit-project.org/ secured with Kerberos, SRP, and > kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 13:51:10 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17122 for ; Wed, 13 Feb 2002 13:51:09 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA18310 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 12:30:27 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA18281; Wed, 13 Feb 2002 12:30:25 -0600 (CST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA15071; Wed, 13 Feb 2002 12:30:25 -0600 (CST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GRH00HHII2PYD@smtp.fnal.gov>; Wed, 13 Feb 2002 12:30:25 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id g1DIUOZ13693; Wed, 13 Feb 2002 12:30:24 -0600 (CST) Date: Wed, 13 Feb 2002 12:30:24 -0600 From: Matt Crawford Subject: Re: some initial notes from WG meeting In-reply-to: "12 Feb 2002 11:21:19 EST." To: Ken Raeburn , "Douglas E. Engert" Cc: ietf-krb-wg@anl.gov Message-id: <200202131830.g1DIUOZ13693@gungnir.fnal.gov> Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk - protect AS_REQ from weak passwords I still think DCE RFC 26.0 is the simplest way to go on this item. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 13:57:47 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17392 for ; Wed, 13 Feb 2002 13:57:46 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA21773 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 12:42:08 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA21767 for ; Wed, 13 Feb 2002 12:42:07 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA17370 for ; Wed, 13 Feb 2002 12:42:06 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA03320; Wed, 13 Feb 2002 19:44:59 +0100 (MEZ) From: Martin Rex Message-Id: <200202131840.TAA11510@uw1048.wdf.sap-ag.de> Subject: Re: Kerb WG iakerb To: john3725@world.std.com (Jonathan Trostle) Date: Wed, 13 Feb 2002 19:40:55 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <001201c1b4b5$83bf30f0$01e8a8c0@host3sy2bx4q> from "Jonathan Trostle" at Feb 13, 2 09:40:22 am Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Jonathan Trostle wrote: > > > (a) > > Since user's long term secrets are much more vulnerable to dictionary > > attacks than the (hopefully randomly generated) long term keys there > > is a potential danger in allowing the KDC to issue AP_REQ for > > user principals -- because these can be used to mount offline > > dictionary attacks. > > > > In order to minimize the possibility for offline dictionary attacks > > against user's long term keys the KDC should be permitted to: > > > > * deny issuing service tickets for users (user2user tickets > > are different in that they use a strong random key) > > > > * deny issuing TGTs in absence of valid pre-authentication data > > > > However this would be incompatible with the current IAKERB proposal. > > I don't recall IAKERB having these restrictions. IAKERB reverses the context establishment between user and IAKERB proxy, so it requires the KDC to issue a service ticket encrypted in the user's long term secret. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 14:03:49 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17579 for ; Wed, 13 Feb 2002 14:03:48 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA23749 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 12:48:15 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA23741 for ; Wed, 13 Feb 2002 12:48:13 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA18598 for ; Wed, 13 Feb 2002 12:48:12 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA06489; Wed, 13 Feb 2002 19:51:38 +0100 (MEZ) From: Martin Rex Message-Id: <200202131847.TAA11542@uw1048.wdf.sap-ag.de> Subject: Re: Kerb WG iakerb To: john3725@world.std.com (Jonathan Trostle) Date: Wed, 13 Feb 2002 19:47:33 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <001801c1b4b5$f585c730$01e8a8c0@host3sy2bx4q> from "Jonathan Trostle" at Feb 13, 2 09:43:33 am Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Jonathan Trostle wrote: > > > Jeffrey Altman wrote: > > > > I agree with Martin's unease at (b). However, IAKERB would not be the > > first use of long term storage of the user's long term password on the > > system. Microsoft Windows already stores to the long term password in > > order to attempt to retrieve new TGT's automatically before they > > expire; or for use in comparing the end user's secret when waking up > > from an suspend mode or returning to a locked workstation. I believe > > other OS's do similar things. > > I too agree with Martin's unease. IAKERB shouldn't (and hopefully doesn't in > the current spec.) require long term storage. I don't see how you could change that as long as the IAKERB proxy uses a service ticket addressed at the user principal encrypted with the user's longterm key. GSS-API doesn't have means to set or request a password/secret for acquisition of credentials or establishment of a security context so the long term secret needs to be supplied to IAKERB outside of the GSS-API and cached so that when an application is launched and requests the IAKERB mechanism the message exchange can actually be performed. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 14:06:20 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17656 for ; Wed, 13 Feb 2002 14:06:20 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA25233 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 12:53:31 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA25227 for ; Wed, 13 Feb 2002 12:53:30 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA19636 for ; Wed, 13 Feb 2002 12:53:30 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA08967; Wed, 13 Feb 2002 19:57:00 +0100 (MEZ) From: Martin Rex Message-Id: <200202131852.TAA11565@uw1048.wdf.sap-ag.de> Subject: Re: some initial notes from WG meeting To: crawdad@fnal.gov (Matt Crawford) Date: Wed, 13 Feb 2002 19:52:56 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <200202131830.g1DIUOZ13693@gungnir.fnal.gov> from "Matt Crawford" at Feb 13, 2 12:30:24 pm Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Matt Crawford wrote: > > - protect AS_REQ from weak passwords > > I still think DCE RFC 26.0 is the simplest way to go on this item. DCE requires DCE as a prerequisite... If the scheme was adopted by Kerberos, how would the Kerberos client implementation know whether a KDC requests the superencryption? Going through a (cryptographic) failure and requiring a second network roundtrip is only a second-best solution -- well, for TGTs this might be a bearable overhead since it really doesn't happen that often a day (broken Kerberos implementations excepted -- I'm still puzzled about the repeated ticket acquisition in my KDC logs when running with a W2K pro Kerberos in an MIT-KDC realm ...). -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 14:06:58 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17668 for ; Wed, 13 Feb 2002 14:06:58 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA24735 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 12:51:45 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA24728 for ; Wed, 13 Feb 2002 12:51:43 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA19222 for ; Wed, 13 Feb 2002 12:51:43 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA14139 for ; Wed, 13 Feb 2002 13:51:43 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA13085; Wed, 13 Feb 2002 13:46:24 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id NAA12445; Wed, 13 Feb 2002 13:46:23 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id NAA23506; Wed, 13 Feb 2002 13:46:23 -0500 To: ietf-krb-wg@anl.gov Subject: Re: some initial notes from WG meeting References: <200202131830.g1DIUOZ13693@gungnir.fnal.gov> From: Ken Raeburn Date: 13 Feb 2002 13:46:23 -0500 In-Reply-To: <200202131830.g1DIUOZ13693@gungnir.fnal.gov> Message-ID: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Matt Crawford writes: > - protect AS_REQ from weak passwords > I still think DCE RFC 26.0 is the simplest way to go on this item. Yes, John and I were talking about it a few minutes ago. For cases where it applies, it looks like an excellent approach. There are cases where it doesn't, though. (Mainly the "Athena public workstation" model where a machine has no long-term key unknown to random potential attackers.) We might be able to adapt it for such cases though. We'll probably be talking about it more later on today. Mostly, though, we're discussing importance of issues for inclusion in updated Kerberos specs, not specific solutions to each issue. (Yes, it's a step or two backwards from where I thought we were before, which was working out details of specific changes.) From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 14:12:59 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17863 for ; Wed, 13 Feb 2002 14:12:58 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA26265 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 12:57:22 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA26249 for ; Wed, 13 Feb 2002 12:57:20 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA20466; Wed, 13 Feb 2002 12:57:20 -0600 (CST) Message-ID: <3C6AB70E.5E7E6911@anl.gov> Date: Wed, 13 Feb 2002 12:57:18 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Crawford CC: Ken Raeburn , ietf-krb-wg@anl.gov Subject: Re: some initial notes from WG meeting References: <200202131830.g1DIUOZ13693@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Matt Crawford wrote: > > - protect AS_REQ from weak passwords > > I still think DCE RFC 26.0 is the simplest way to go on this item. Thanks, RFC 26.0 did come up in the WG. One problem is is there is no host key. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 14:48:43 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18926 for ; Wed, 13 Feb 2002 14:48:42 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA06254 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 13:31:35 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA06238 for ; Wed, 13 Feb 2002 13:31:34 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA27650 for ; Wed, 13 Feb 2002 13:31:33 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA29909; Wed, 13 Feb 2002 20:35:04 +0100 (MEZ) From: Martin Rex Message-Id: <200202131930.UAA11791@uw1048.wdf.sap-ag.de> Subject: Re: some initial notes from WG meeting To: mrex@sap-ag.de Date: Wed, 13 Feb 2002 20:30:59 +0100 (MET) Cc: crawdad@fnal.gov, ietf-krb-wg@anl.gov In-Reply-To: <200202131852.TAA11565@uw1048.wdf.sap-ag.de> from "Martin Rex" at Feb 13, 2 07:52:56 pm Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Too much work, not enough sleep ... sorry for the typo: I wrote: > > Matt Crawford wrote: > > > > - protect AS_REQ from weak passwords > > > > I still think DCE RFC 26.0 is the simplest way to go on this item. > > DCE requires DCE as a prerequisite... > > If the scheme was adopted by Kerberos, how would the Kerberos client - implementation know whether a KDC requests the superencryption? + implementation know whether a KDC supports the superencryption? > > Going through a (cryptographic) failure and requiring a second > network roundtrip is only a second-best solution -- well, for > TGTs this might be a bearable overhead since it really doesn't > happen that often a day (broken Kerberos implementations excepted > -- I'm still puzzled about the repeated ticket acquisition in my KDC logs > when running with a W2K pro Kerberos in an MIT-KDC realm ...). > From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 13 20:31:10 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25364 for ; Wed, 13 Feb 2002 20:31:09 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id TAA13466 for ietf-krb-wg-outgoing; Wed, 13 Feb 2002 19:16:18 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA13460 for ; Wed, 13 Feb 2002 19:16:17 -0600 (CST) Received: from lycos.com ([61.79.73.104]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id TAA07259 for ; Wed, 13 Feb 2002 19:16:07 -0600 (CST) Message-Id: <200202140116.TAA07259@dns2.anl.gov> Reply-To: guikhyi8@lycos.com From: 啻⑷錶觼 To: Subject: [惜堅]援掘釭ブ熱氈朝餌機塽睡機殮棲棻 Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 14 Feb 2002 10:15:54 +0900 X-User: 2.62-figjdliv-lilkhn-Ddigq Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk

Ⅱ ョ塊橈檜 �爾詭橾擊爾頂啪脹薄餌婁萄董棲棻.
Ⅱ 薑爾鱔褐蜂檜辨襠霞徹敘薑擊遽熱ビ罹惜堅詭橾歜擊ォ衛ビ艘擰棲棻.
Ⅱ 瞪濠辦ぇ輿模朝檣攪喘鼻縑憮鏃菜ビ艘戲貊, 瞪濠辦ぇ輿模諼橫集フ偃檣薑爾紫陛雖堅氈雖彊蝗棲棻

!!!! 雖旎檜牖除椒眷憮盪⻣棻檜傘蝶ⅷ蒂虜釭褐匙擎渠欽フヤ遴檜塭 �褐ベ棲棻. !!!!

奩骨蝗棲棻.

盪朝睡骯縑憮霜濰擊棻棲賊憮睡機戲煎檜餌機擊霞ヤビ堅氈朝濰鬼團檜塢餌塋殮棲棻.
瞳斛瞳檜堅翮薑瞳戲煎髦賊憮濠晦嫦瞪擊嬪ボ莒歜橈檜喻溘ビ堅氈蝗棲棻.

餌機擎僭煩虜釭憮渠�蒂釭援橫撿陛濰謠啊雖虜, 辦摹憮賊戲煎渠楞擊憲溥萄葬棲髦う爾衛堅啗樓婦褕檜氈戲衛賊翱塊輿衛晦夥奧棲棻....

餌機曖偃喃檜檜ボビ晦蔣堅, 啻⑷웤擊 И撩ビ朝寞徹檜 on-line, off-line 戲煎棻曄ビ堅, 菔朝餌塋紫傘鼠釭蔣啪陶菜ブ熱氈晦陽僥縑援掘釭ビ褒熱陛氈蝗棲棻.

⑸ɛ 晦襄縑橫雯 И衝檜萇啻⑷웤 葆馨冂擊ビ堅啗衛朝碟菟檜賊渦遵澀ビ褒熱
氈蝗棲棻.

檜餌機擎鱔褐餌機醞陛濰試盪衛濛脹億煎遴餌機戲煎憮棻檜傘蝶ⅷ 塭朝 �餌煎滌薑鱔褐1龱諦 2龱曖 �餌殮棲棻.

濠獄橈檜紫濠晦餌機擊ビ朝匙婁偽戲貊衛除檜⺮葷縑評塭薄離斜敘賅陛醴螳 1喇 � �錳熱諦衙轎擋賊縑憮綠掖陛寰腆薑紫煎 �濰腎朝捲濰ɛ 綠蟒檜氈朝餌機殮棲棻.

嬴葆紫輿滲縑憮嬴朝碟菟檜棻欽啗餌機擊ビ衛賊憮偽檜餌機ボ爾雖彊啊傍朝薯寰フ舒廓鎢寰菟橫爾褐碟菟剪曖橈戲葬塭儅陝腌棲棻.

斜溢雖虜棻欽啗陛匱棲梱. 晦襄衛濰曖嶸鱔掘褻蒂夥紱橫闊醞除嶸鱔欽啗(識匸, 渠葬薄) 傳朝惜堅橈檜掘瞪縑曖フ匸衙煎醞除欽啗縑憮嫦儅腎朝雖轎擊還罹斜熱櫛擊模綠濠縑啪 �錳衛麵輿朝摹霞И 匸衙寞衝殮棲棻.

啻⑷鋸餌機擎 �錳菟曖營掘衙陛緒艇薯ゴ戲煎掘撩腎橫撿フ棻朝匙擎澀嬴衛啊轄?
辦葬陛ビ瑞紫瞪�蒂勘雖彊堅朝髦嬴陞熱橈棻朝匙擊椒眷憮紫檣薑ビ褊棲梱?
夥煎檜瞪�蹂旎擊 Г營晦除鱔褐縑 �碳煎陶睡ビ朝匙擊摹碳煎蘋萄縑醱瞪ボ憮噙朝匙檜餌機殮棲棻.

2000喇紫措頂模綠衛濰醞鱔褐衛濰敘賅朝濠斜虜纂擒24褻錳檜歷戲貊 2001喇紫朝嬴霜鱔啗陛釭螃雖彊嬴澀賅腦雖虜￤壁棺橫陬戲貊霤堅煎蜓噪萄萼棻賊課模綠衛濰擎擒 1褻錳, 濠翕離衛濰-擒6褻, 嶸盟(戮嶸)衛濰-擒6褻錳檜歷蝗棲棻.
鱔褐衛濰敘賅陛橡葆釭贖衛濰檣雖颶濛檜陛衛啊轄?

檜剪渠鱔褐衛濰檜檜渠煎偃寞脹棻賊辦葬釭塭褐唳檣鱔褐擎斜渠煎諼措嶸熱機羹縑濡衝渡ブ熱夤縑橈蝗棲棻.
斜楚憮薑睡縑憮滌薑鱔褐擊ョ辨ビ罹偃檣瞪�措(1龱餌機濠)戲煎ビ罹旎偃寞檜瞪縑措薯唳爵溘擊乾蹺晦嬪フ措疇餌機殮棲棻.

鱔ベ摹碳蘋萄ビ釭煎衛頂.諼,奢醞瞪� 鱔�朝僭煩⺕渠こ晦謙,廓龱滲唳橈檜 011睡攪 019梱雖蹴晦棟戲煎號擎幗⑹擊援腦雖彊堅螞陛褶檜ヘ眷除ぇビ啪餌辨ビ褒熱氈蝗棲棻.

僭煩鼻晦頂辨擎嬴輿晦獄瞳檣頂辨檜掘蹂.
濠晦壽戲煎 2貲虜萃熱氈朝夥檜傘葬掘褻殮棲棻

檜諼縑紫睡陛骯機紫閨虜嬴棲塭熱櫛掘褻,瞪濠鼻剪楚蛔蛔ビ堅談擎檜撿晦朝號戲釭檜薑紫煎撲貲擊ボ萄葬掘蹂渦掙推ビ褐匙菟擎霜蕾鼻氬擊ビ衛剪釭 �餌曖 �［檜雖蒂萃楝爾衛賊腎啊擰棲棻.

http://www.dynastytel.co.kr(滌薑鱔褐)
http://www.clubaqua.co.kr(罹ヤ餌)
http://www.visiondynasty.com(瞪濠鼻剪楚)
http://www.e-dynasty.co.kr(�［檜雖)
翱塊籀 : codejang@intizen.com
H.P : 019-596-9808
熱褐剪睡 : e-dynasty@simmani.com 傳朝嬴楚曖熱褐剪睡幗⑹擊揚楝輿撮蹂

錳纂彊戲衛賊熱褐剪睡蒂揚楝輿衛堅薯跡縑熱褐剪睡塭堅瞳橫輿衛晦夥奧棲棻. 碳ぇ擊萄溜棻賊賸歎ベ棲棻. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 14 03:58:14 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13668 for ; Thu, 14 Feb 2002 03:58:13 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id CAA03034 for ietf-krb-wg-outgoing; Thu, 14 Feb 2002 02:38:04 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id CAA03015 for ; Thu, 14 Feb 2002 02:38:02 -0600 (CST) Received: from TheWorld.com (pcls4.std.com [199.172.62.106]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id CAA16968 for ; Thu, 14 Feb 2002 02:38:01 -0600 (CST) Received: from host3sy2bx4q (adsl-64-171-14-173.dsl.sntc01.pacbell.net [64.171.14.173]) by TheWorld.com (8.9.3/8.9.3) with SMTP id DAA17529; Thu, 14 Feb 2002 03:37:58 -0500 Message-ID: <003401c1b532$3a3dde90$01e8a8c0@host3sy2bx4q> From: "Jonathan Trostle" To: Cc: References: <200202131840.TAA11510@uw1048.wdf.sap-ag.de> Subject: Re: Kerb WG iakerb Date: Thu, 14 Feb 2002 00:33:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Martin Rex" To: "Jonathan Trostle" Cc: Sent: Wednesday, February 13, 2002 10:40 AM Subject: Re: Kerb WG iakerb > Jonathan Trostle wrote: > > > > > (a) > > > Since user's long term secrets are much more vulnerable to dictionary > > > attacks than the (hopefully randomly generated) long term keys there > > > is a potential danger in allowing the KDC to issue AP_REQ for > > > user principals -- because these can be used to mount offline > > > dictionary attacks. > > > > > > In order to minimize the possibility for offline dictionary attacks > > > against user's long term keys the KDC should be permitted to: > > > > > > * deny issuing service tickets for users (user2user tickets > > > are different in that they use a strong random key) > > > > > > * deny issuing TGTs in absence of valid pre-authentication data > > > > > > However this would be incompatible with the current IAKERB proposal. > > > > I don't recall IAKERB having these restrictions. > > > IAKERB reverses the context establishment between user and IAKERB proxy, > so it requires the KDC to issue a service ticket encrypted in the > user's long term secret. The ticket that is targetted at the user is encrypted in the session key from the ticket that the user sends to the proxy for the TGS case. Same for the AS case, except the proxy obtains the ticket from the AS exchange. The fastest way to see this is to look at the diagrams in the spec. Jonathan > > -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 14 05:40:17 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14844 for ; Thu, 14 Feb 2002 05:40:16 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id EAA05109 for ietf-krb-wg-outgoing; Thu, 14 Feb 2002 04:28:13 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id EAA05103 for ; Thu, 14 Feb 2002 04:28:11 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id EAA06181 for ; Thu, 14 Feb 2002 04:28:11 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id LAA13464; Thu, 14 Feb 2002 11:31:37 +0100 (MEZ) From: Martin Rex Message-Id: <200202141027.LAA14679@uw1048.wdf.sap-ag.de> Subject: Re: Kerb WG iakerb To: john3725@world.std.com (Jonathan Trostle) Date: Thu, 14 Feb 2002 11:27:32 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <003401c1b532$3a3dde90$01e8a8c0@host3sy2bx4q> from "Jonathan Trostle" at Feb 14, 2 00:33:06 am Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Jonathan Trostle wrote: > > > > > IAKERB reverses the context establishment between user and IAKERB proxy, > > so it requires the KDC to issue a service ticket encrypted in the > > user's long term secret. > > The ticket that is targetted at the user is encrypted in the session key > from the ticket that the user sends to the proxy for the TGS case. Same for > the AS case, except the proxy obtains the ticket from the AS exchange. The > fastest way to see this is to look at the diagrams in the spec. You mean that it is a user2user authentication? No, I didn't see that from the diagrams. But as I've mentioned before, I'm not deeply intimate with Kerberos, just with GSS-API. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 15 14:00:06 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15705 for ; Fri, 15 Feb 2002 14:00:01 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA13352 for ietf-krb-wg-outgoing; Fri, 15 Feb 2002 12:41:36 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA13346 for ; Fri, 15 Feb 2002 12:41:33 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA08344 for ; Fri, 15 Feb 2002 12:41:32 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id NAA19604; Fri, 15 Feb 2002 13:44:39 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma019472; Fri, 15 Feb 2002 13:44:07 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA16045; Fri, 15 Feb 2002 13:39:29 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA05916; Fri, 15 Feb 2002 13:40:54 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id NAA08430; Fri, 15 Feb 2002 13:39:45 -0500 (EST) Date: Fri, 15 Feb 2002 13:39:44 -0500 From: Nicolas Williams To: mrex@sap-ag.de Cc: Jonathan Trostle , ietf-krb-wg@anl.gov Subject: Re: Kerb WG iakerb Message-ID: <20020215133943.O27171@sm2p1386swk.wdr.com> Mail-Followup-To: mrex@sap-ag.de, Jonathan Trostle , ietf-krb-wg@anl.gov References: <001801c1b4b5$f585c730$01e8a8c0@host3sy2bx4q> <200202131847.TAA11542@uw1048.wdf.sap-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200202131847.TAA11542@uw1048.wdf.sap-ag.de>; from martin.rex@sap-ag.de on Wed, Feb 13, 2002 at 07:47:33PM +0100 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk There's no reason why one could not design an API that includes the ability to prompt the user, like PAM, say, for whatever passwords and tokens are needed and *still* be compliant with GSS-API on the wire. GSS-API and GSS-API bindings are not the same thing. :) That said, the default behaviour by most implementations can probably be relied upon to be password-caching. Sigh. Nico On Wed, Feb 13, 2002 at 07:47:33PM +0100, Martin Rex wrote: > > I don't see how you could change that as long as the IAKERB proxy > uses a service ticket addressed at the user principal encrypted > with the user's longterm key. GSS-API doesn't have means to > set or request a password/secret for acquisition of credentials > or establishment of a security context so the long term secret needs > to be supplied to IAKERB outside of the GSS-API and cached so > that when an application is launched and requests the IAKERB > mechanism the message exchange can actually be performed. > > > -Martin -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Fri Feb 15 17:59:33 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22634 for ; Fri, 15 Feb 2002 17:59:33 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id QAA28801 for ietf-krb-wg-outgoing; Fri, 15 Feb 2002 16:49:25 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA28795 for ; Fri, 15 Feb 2002 16:49:24 -0600 (CST) Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA01329 for ; Fri, 15 Feb 2002 16:49:23 -0600 (CST) Received: from gamera.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.006D35C5@mailer.syr.edu>; Fri, 15 Feb 2002 17:48:45 -0500 Received: from syr.edu (syru210-198.ecs.syr.edu [128.230.210.198]) by gamera.syr.edu (8.8.7/8.8.7) with ESMTP id RAA14599; Fri, 15 Feb 2002 17:48:43 -0500 (EST) Message-ID: <3C6D9054.2040807@syr.edu> Date: Fri, 15 Feb 2002 17:48:52 -0500 From: Joncheng Kuo Organization: Syracuse University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en,zh-TW,pdf MIME-Version: 1.0 To: ietf-krb-wg@anl.gov Subject: Can Authorization Data be retrieved through GSSAPI? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm new to this mail list. A basic format of Authorization Data has been added to the revision of the draft Kerberos standard. Is there any way that this Authorization Data can be exposed through GSSAPI? If not, is there any move to make an extension on GSSAPI? Joncheng Kuo From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sat Feb 16 04:20:27 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09552 for ; Sat, 16 Feb 2002 04:20:26 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id DAA10587 for ietf-krb-wg-outgoing; Sat, 16 Feb 2002 03:09:45 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id DAA10567 for ; Sat, 16 Feb 2002 03:09:39 -0600 (CST) Received: from interfree.it (ppp-81-226-na04u-dada6.iunet.it [151.35.81.226] (may be forged)) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id DAA07041 for ; Sat, 16 Feb 2002 03:09:22 -0600 (CST) Message-Id: <200202160909.DAA07041@dns2.anl.gov> From: "Promo3000" To: Subject: Software e-commerce Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Sat, 16 Feb 2002 10.02.35 +0100 Reply-To: "Promo3000" Content-Transfer-Encoding: 8bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit

Spettabile Azienda,

Vi presentiamo il software professionale per l'e-commerce:

i p e r 1 � la soluzione migliore per aprire un negozio su internet, � un programma completo e potente ed allo stesso tempo semplice e facile nell'utilizzo e nella navigazione.

Perfetto sia per la vendita al dettaglio e sia per la vendita all'ingrosso: 6 listini prezzi, con la possibilità di abbinare ad ogni cliente il relativo listino;
si può scegliere se far visionare il negozio a tutti o solo ai clienti registrati ed attivati, per esempio solo ai rivenditori, previo riconoscimento tramite password;
si può far visionare i prodotti a tutti senza i relativi prezzi, e far vedere i prezzi con la possibilità di acquisto solo ai rivenditori.
� completo:
carrello della spesa;
stato degli ordini, il cliente può seguire in linea lo stato di avanzamento della consegna del prodotto;
illimitato numero di prodotti;
illimitato numero di varianti e di opzioni per ogni prodotto;
illimitato numero di categorie e livelli di sottocategorie;
calcolo delle spese di trasporto tenendo conto del corriere, della distanza, del peso e dell'importo della spesa;
qualsiasi tipo di pagamento: sono compresi i moduli per il collegamento, per far pagare i clienti con la carta di credito, con i server sicuri di oltre 70 banche italiane e con le più importanti banche internazionali, è stato previsto anche il pagamento con forma mista: acconto con carta di credito o con le nuove carte prepagate e il resto contrassegno.
� immediato: avviene tutto in tempo reale, appena inserito un nuovo prodotto � subito in linea, il negozio è gestibile, tramite password, da qualsiasi computer collegato ad internet, ovunque Vi troviate.
� ideale:
per chi vuole realizzare personalmente il proprio negozio senza dover scrivere nessuna riga di codice.
� indispensabile:
per gli studi grafici che costruiscono negozi per i loro clienti, con questo programma si possono occupare solo della parte grafica senza addentrarsi nella programmazione, il programma non ha .dll o .exe che riscrivono il tutto ad ogni inserimento. � costruito in linguaggio HTML ed in ASP ed il tutto � collegato ad un database in formato Microsoft Access, la parte amministrativa pu� restare uguale per tutti i negozi, per la parte che vede il cliente finale vengono fornite tutte le informazioni necessarie per adattare il tutto a qualsiasi grafica.
� multilingua:
� pronto per creare negozi in italiano, inglese, francese, tedesco e spagnolo.
Con una sola copia del programma si può creare un intero CENTRO COMMERCIALE, si possono creare un numero illimitato di negozi (sotto un unico dominio), ed ogni esercente di ogni negozio può amministrare completamente il propro negozio.
È economico, ci sono 3 versioni: Light 100 Euro, Completa per la vendita al dettaglio 200 Euro e 300 Euro la versione PRO per il commercio al dettaglio ed all'ingrosso.
Eccezionali soluzioni per i rivenditori e gli studi grafici.
È gia usato con soddisfazione da centinaia di aziende.

Distinti Saluti

Promo3000

Cliccate qu� per avere altre informazioni sul programma IPER1

Cliccate quì per una dimostrazione del programma IPER1

Cliccate quì per provare il programma IPER1

Italiano

Espa隳l

English

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sat Feb 16 15:08:28 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16140 for ; Sat, 16 Feb 2002 15:08:27 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA09416 for ietf-krb-wg-outgoing; Sat, 16 Feb 2002 13:56:11 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA09410 for ; Sat, 16 Feb 2002 13:56:10 -0600 (CST) Received: from localhost ([211.228.6.26]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id NAA11760 for ; Sat, 16 Feb 2002 13:56:04 -0600 (CST) Message-Id: <200202161956.NAA11760@dns2.anl.gov> Reply-To: dyd2103@kornet.net From: 寰撩繹 To: ietf-krb-wg@anl.gov Subject: 撮鼻縑檜楛橾檜......'惜堅' Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 17 Feb 2002 04:56:05 +0900 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk

掖鱔餌堅爾鼻鼻氬寰頂

濠翕離爾レ雖晝晦遽婁徹睦鼻槳ボ擋曖離檜綠掖[薑爾]

- 濠翕離爾レ擒婦縑憮朝爾レ旎雖晝擊 擒婦雖晝晦遽縑曖フ骯轎旎擋婁徹睦鼻槳ボ擋擊雖晝ブ熱氈紫煙敘薑腎橫氈蝗棲棻.

- 爾レ餌朝嬪曖舒晦遽縑曖ボ爾鼻擊ビ堅氈晦縑ニボ濠陛濠褐曖掏葬蒂 嬴替傍賅腦替傍縑評塭繭雖離檜爾鼻檜檜瑞橫雖堅氈蝗棲棻.

斜楝賊舒晦遽檜橫雯離檜陛氈朝雖賃陛雖虜憲嬴瑣棲棻.

爾レ�餌擒婦雖晝晦遽

徹睦鼻槳ボ擋

離檜碟戮

橾

奩

睡

鼻

餌

堅

嬪濠猿

函1晝鼻ボ煎6偃錯殮錳衛  200虜

刻14晝鼻ボ                9虜

函擒500╪700虜

刻擒50╪100虜

擒2╪10寡

⺕機槳ボ

函模菜檣薑-殮隸模菜擋曖 80%

       -殮隸碳陛衛橾辨歜旎80%

刻橾辨斬煎濠 ; 紫衛 847,637

                               堯襟 900,284

-殮隸模菜瞪擋檣薑

-鱔啗模菜檣薑陛棟

紫衛橾辨 900,284

堯襟陴濠 1,281,150

鱔啗模菜檣薑衛橾辨歜旎曖 1.5寡╪2寡

偃龱綠

-檣薑碳陛

-餌雖葆綠陛薑偃龱虜檣薑

-鼻ボ薑紫評塭檣薑檣薑

-6撮嘐虜殮錳晦除頂檣薑

1殖縑 120虜離檜嫦儅

濰

ボ

嫦

儅

嬪濠猿

-濰ボ  20%       80虜

-濰ボ 100%     1000虜

-濰ボ  20%   1000虜

-濰ボ 100%   5000虜

12.5寡離檜

      5寡離檜

鼻褒熱櫛

(橾褒檜櫛)

-濰ボ檣薑腎釭模菜鼻褒橈朝唳辦 50%虜檣薑

-醞除檜濠奢薯 L啗熱瞳辨

-濰ボ檣薑腎賊 100%檣薑
     (寡離檜)

-醞除檜濠奢薯 H啗熱

檜濠奢薯寞衝縑評塭釭檜橫萵熱煙觼啪離檜陛陴

餌

蜂

衛

嬪濠猿

-20撮╪60撮           3200虜

-20撮嘐虜 60撮檜鼻    2800虜

           5000虜

1.5╪1.78寡

≦ 鼻晦ォ朝斛ɛ 橾睡曖離檜蒂撲貲フ匙歜.

掖鱔餌堅爾鼻 �褒ɛ 憲堅嫡擰衛棻.
濠撮フ鼻氬擊錳ビ衛賊 060-700-2114 煎...

盪⻣ �戲煎螃衛溥賊罹晦蒂贗葛 http//www.sos113.com

掖鱔餌堅爾鼻鼻氬 [060-700-2114]

獄詭橾擎薑爾鱔褐睡掏堅餌ホ縑曖剪薯跡縑 [惜堅]塭ォ衛脹惜堅詭橾殮棲棻. 詭橾擊檗橫輿褐等渠ボ馬餌蒂萄董棲棻. 渦檜鼻熱褐擊錳纂彊戲衛賊 熱褐剪睡蒂贗葛ビ衛橫敝ビ曖檜詭橾輿模蒂部梱雖殮溘ビ賊熱褐剪睡籀葬陛脾擊憲溥萄董棲棻.

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sat Feb 16 17:21:24 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17181 for ; Sat, 16 Feb 2002 17:21:24 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id QAA22981 for ietf-krb-wg-outgoing; Sat, 16 Feb 2002 16:10:40 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA22973 for ; Sat, 16 Feb 2002 16:10:35 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA01507 for ; Sat, 16 Feb 2002 16:10:35 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id RAA06643; Sat, 16 Feb 2002 17:09:34 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma006239; Sat, 16 Feb 2002 17:09:16 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id RAA08250; Sat, 16 Feb 2002 17:04:38 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id RAA27191; Sat, 16 Feb 2002 17:06:03 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id RAA14211; Sat, 16 Feb 2002 17:04:52 -0500 (EST) Date: Sat, 16 Feb 2002 17:04:52 -0500 From: Nicolas Williams To: Joncheng Kuo Cc: ietf-krb-wg@anl.gov Subject: Re: Can Authorization Data be retrieved through GSSAPI? Message-ID: <20020216170451.X27171@sm2p1386swk.wdr.com> Mail-Followup-To: Joncheng Kuo , ietf-krb-wg@anl.gov References: <3C6D9054.2040807@syr.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3C6D9054.2040807@syr.edu>; from ckuo01@syr.edu on Fri, Feb 15, 2002 at 05:48:52PM -0500 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Authz data was always in RFC1510. And no, the GSS-API C Bindings do not provide an API for getting at the authz data. But GSS is not merely about the specific bindings. GSS could probably use some revisions. Nico On Fri, Feb 15, 2002 at 05:48:52PM -0500, Joncheng Kuo wrote: > Hi, > > I'm new to this mail list. > > A basic format of Authorization Data has been added to the revision of > the draft Kerberos standard. Is there any way that this Authorization > Data can be exposed through GSSAPI? If not, is there any move to make an > extension on GSSAPI? > > Joncheng Kuo -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Sun Feb 17 14:40:31 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10510 for ; Sun, 17 Feb 2002 14:40:31 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA24733 for ietf-krb-wg-outgoing; Sun, 17 Feb 2002 13:29:16 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA24727 for ; Sun, 17 Feb 2002 13:29:14 -0600 (CST) Received: from industrial-algebra.mit.edu (STRATTON-THIRTY-TWO.MIT.EDU [18.187.5.32]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA05791 for ; Sun, 17 Feb 2002 13:29:14 -0600 (CST) Received: by industrial-algebra.mit.edu (Postfix, from userid 8042) id 34F28151681; Sun, 17 Feb 2002 14:29:12 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Call for volunteers to explain why we care about authenticated cleartext Message-Id: <20020217192912.34F28151681@industrial-algebra.mit.edu> Date: Sun, 17 Feb 2002 14:29:12 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk At the meeting last week it became clear that I was not doing a good job of explaining to John why we care about authenticated cleartext. He would like to know what attacks we solve by authenticating cleartext and what it gets us. He doesn't seem to find the DOS attacks--even the DOS attacks related to ticket substitution to be particularly interesting, or at least he iimplied he would be happier if there were more interesting benefits. Is there someone in the group who would be able to write up a good statement of why we care about these problems and what we hope to get out of the solution? From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 09:25:42 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03566 for ; Mon, 18 Feb 2002 09:25:42 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id IAA17241 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 08:08:05 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA17235 for ; Mon, 18 Feb 2002 08:08:04 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA23887 for ; Mon, 18 Feb 2002 08:08:04 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA24042; Mon, 18 Feb 2002 09:08:03 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA11758; Mon, 18 Feb 2002 09:08:03 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA08992; Mon, 18 Feb 2002 09:08:02 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id JAA29331; Mon, 18 Feb 2002 09:08:02 -0500 (EST) To: Joncheng Kuo Cc: ietf-krb-wg@anl.gov Subject: Re: Can Authorization Data be retrieved through GSSAPI? References: <3C6D9054.2040807@syr.edu> From: Sam Hartman Date: 18 Feb 2002 09:08:02 -0500 In-Reply-To: Joncheng Kuo's message of "Fri, 15 Feb 2002 17:48:52 -0500" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "Joncheng" == Joncheng Kuo writes: Joncheng> Hi, I'm new to this mail list. Joncheng> A basic format of Authorization Data has been added to Joncheng> the revision of the draft Kerberos standard. Is there Joncheng> any way that this Authorization Data can be exposed Joncheng> through GSSAPI? If not, is there any move to make an Joncheng> extension on GSSAPI? It is not currently possible to get this data through GSSAPI. There an effort to add this to GSSAPI. However as time progresses it is becoming more clear that there are significant mismatches between GSSAPI's idea of the universe and Kerberos's idea of the universe. It's also becoming clear that various GSSAPI concepts (particularly naming or credentials depending on how you look at it) are insufficient for certain real-world deployments. I expect that a lot of us who have worked on Kerberos will be pushing toreactivate the CAT working group and discuss these issues once we are done with revisions. You could of course ask implementers to agree on an API for exposing the autherization data as an extension to GSSAPI. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 10:23:13 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04793 for ; Mon, 18 Feb 2002 10:23:12 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA11780 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 09:09:06 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA11774 for ; Mon, 18 Feb 2002 09:09:04 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA07340 for ; Mon, 18 Feb 2002 09:09:02 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA13376; Mon, 18 Feb 2002 16:11:57 +0100 (MEZ) From: Martin Rex Message-Id: <200202181507.QAA11045@uw1048.wdf.sap-ag.de> Subject: Re: Can Authorization Data be retrieved through GSSAPI? To: ckuo01@syr.edu Date: Mon, 18 Feb 2002 16:07:49 +0100 (MET) Cc: ietf-krb-wg@anl.gov, hartmans@mit.edu, Nicolas.Williams@ubsw.com In-Reply-To: from "Sam Hartman" at Feb 18, 2 09:08:02 am Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > >>>>> "Joncheng" == Joncheng Kuo writes: > > Joncheng> Hi, I'm new to this mail list. > > Joncheng> A basic format of Authorization Data has been added to > Joncheng> the revision of the draft Kerberos standard. Is there > Joncheng> any way that this Authorization Data can be exposed > Joncheng> through GSSAPI? If not, is there any move to make an > Joncheng> extension on GSSAPI? > > It is not currently possible to get this data through GSSAPI. There > an effort to add this to GSSAPI. However as time progresses it is > becoming more clear that there are significant mismatches between > GSSAPI's idea of the universe and Kerberos's idea of the universe. > It's also becoming clear that various GSSAPI concepts (particularly > naming or credentials depending on how you look at it) are > insufficient for certain real-world deployments. > > I expect that a lot of us who have worked on Kerberos will be pushing > toreactivate the CAT working group and discuss these issues once we > are done with revisions. > > You could of course ask implementers to agree on an API for exposing > the autherization data as an extension to GSSAPI. In the past there have been at least two proposals for providing such authorization information in a GENERIC fashion via an *optional* extension to GSS-API, one from the SESAME project (a european project by several eurpoean companies and at least one university) and one called GAA from people around Cliffort Neuman. Besides the generic approaches there are always the product specific means to do it (DCE should have such a capability). The main reason why this hasn't catched any significant momentum is that in the lack of people who are going to use it with at least 2 (preferably more) entirely different authentication schemes and user management models it is unlikely that someone will come up with a true *generic* model. It might have been for the existence of DEC DASS that DEC came up with a GSS-API proposal that was actually generic enough to support authentication schemes beyond Kerberos. The majority of engineers is heavily entangled with a single authentication scheme and almost always grasps the abstraction model of the GSS-API in a painful cent-by-cent fashion. Now what you have today is quite a lot of authentication schemes that don't offer any authorization data, and a few scheme that offer some very product/scheme-specific authentication data (product specific or even proprietary data formats for that data). What should a "portable" application do these days? If the application should work portably across all available mechanisms, it will have to define and manage its own authorization data for all mechanisms (and users) that don't provide such data. Trying to mix and match the authorization information from completely different mechanisms plus providing a pure-application-based authorization scheme for the majority of GSS-API mechanism without authorization data might prove to be a difficult problem. Being faced with a complex (legacy) application one might realize that some of the existing authorization schemes are unable to represent the existing authorization granularity... In the end you realize that often it is the most portable (across arbitrary gssapi mechanisms) and backward compatible (across the installed base of an application) solution to not use any external authorization data even for gssapi mechanisms that support (some limited) form of authorization data. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 10:37:55 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05050 for ; Mon, 18 Feb 2002 10:37:54 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA17339 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 09:23:00 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA17330 for ; Mon, 18 Feb 2002 09:22:58 -0600 (CST) Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.103]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA10732 for ; Mon, 18 Feb 2002 09:22:57 -0600 (CST) Received: by luminous.mit.edu (Postfix, from userid 1000) id 611B976626; Mon, 18 Feb 2002 10:22:55 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Proposed changes to Kerberos revisions From: Sam Hartman Date: 18 Feb 2002 10:22:54 -0500 Message-ID: <87r8nix19t.fsf@luminous.mit.edu> Lines: 19 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk --=-=-= Here are the proposed changes I said I'd make last week. I'll send these to Cliff early Tuesday. Some of my changes are for the extensions document, some for clarifications and some for both. I've used the tag to mark sections destined only for extensions and the tag to mark sections only for clarifications. Hopefully Cliff can write a simple script to pull these out and create the links he talked about last week. --=-=-= Content-Disposition: attachment; filename=krbrev1-4.diff Content-Description: Differences to section 1 --- krbrev1-4.html 2002/02/07 14:12:28 1.1 +++ krbrev1-4.html 2002/02/15 19:37:22 @@ -384,7 +384,225 @@ options for application authentication (e.g. the PKTAPP proposal) are provided. -

1.4. Environmental assumptions

+ + +

1.4. Extensibility Model

+ +In the past, significant interoperability problems have been caused by +different assumptions about how the Kerberos protocol can be extended. +However, as the deployed base of Kerberos implementations grows, +extending Kerberos becomes more important. In order to insure that +vendors and the IETF can extend the protocol while maintaining +backward compatibility, this specification outlines a framework for +extending Kerberos. +

+ +Most messages also contain ASN.1 extension markers. These markers +allow fields to be added in future versions of this specification. +Because tag numbers and order in the sequence need to be agreed on in +order to maintain interoperability, implementations MUST NOT include +ASN.1 extensions except when those extensions are specified by IETF +standards-track documents. + +

1.4.1. Compatibility with RFC 1510

+ +

1.4.2. Sending Extensible Messages

1.4.3. Receiving Extensible Messages

+ +Many RFC 1510 implementations ignore unknown authorization data +elements. Depending on these implementations to honor authorization +data restrictions may create a security weakness. + + +

1.4. Extending Kerberos Without Breaking Interoperability

+ +In the past, significant interoperability problems have been caused by +different assumptions about how the Kerberos protocol can be extended. +However, as the deployed base of Kerberos implementations grows, +extending Kerberos becomes more important. This section gives + guidelines + that should + enable + implementers + to extend + Kerberos + while + maintaining + interoperability. + +

+ +The primary extension mechanism is typed holes--sub-messages that +contain an octet-string along with an integer that defines how to +interpret the octet-string--included in several Kerberos messages. The +integer types are registered centrally, but can be used both for vendor +extensions and for extensions standardized in the IETF. + +

+ +For many years it was believed that Kerberos could be extended simply by +adding fields to the ASN.1 types. This is not true. Sending additional +fields often results in the entire message being discarded with no error +indication. Future versions of this specification will provide a +mechanism for the IETF to add ASN.1 fields without creating an +interoperability problem. + +

+Recipients of unknown message extensions should preserve the encoding of +the extension but otherwise ignore the presence of the extension. +Recipients MUST NOT decline a request simply because an extension is +present. + +

+ +There is one exception to this rule. If an unknown authorization data +element type is received by a server either in an AP-REQ or in a ticket +contained in an AP-REQ, then the authentication SHOULD fail. +Authorization data is intended to restrict the use of the ticket. If +the service cannot determine whether the restriction applies to that +service then a security weakness may result if the ticket can be used +for that service. Authorization elements that are optional can be +enclosed in the AD-IF-RELEVANT element. + +

+ +Many RFC 1510 implementations ignore unknown authorization data +elements. Depending on these implementations to honor authorization +data restrictions may create a security weakness. + +

1.5. Authenticating Cleartext Portions of Messages

+ +The extensible variants of the messages described in this +specification wrap the actual message in an ASN.1 sequence containing +a keyed checksum of the contents of the message. Guidelines in +section 3 specify when the checksum MUST be included and what key MUST +be used. Guidelines on when to include a checksum are never +ambiguous: a particular PDU is never correct both with and without a +checksum. With the exception of the KRB_ERROR message, receiving +implementations MUST reject messages where a checksum is included and +not expected or where a checksum is expected but not included. The +receiving implementation does not always have sufficient information +to know whether a KRB_ERROR should contain a checksum. Even so, +KRB_ERROR messages with invalid checksums MUST be rejected and +implementations MAY consider the presence or absence of a checksum +when evaluating whether to trust the error. + +

+ +This authenticated cleartext protection is provided only in the +extensible variants of the messages; it is never used whan talking to +an RFC 1510 implementation. + + + +

1.6. Environmental assumptions

Kerberos imposes a few assumptions on the environment in which it can properly function: @@ -426,7 +644,7 @@ -

1.5. Glossary of terms

1.7. Glossary of terms

Below is a list of terms used throughout this document. @@ -599,4 +817,10 @@ Discussion related to Name Canonicalization has been dropped. +

+ +Folded in the introduction to extensibility and the authenticated +cleartext solution. +

+Added clarifications version of extensibility comments. --=-=-= Content-Disposition: attachment; filename=krbrev2-6.diff Content-Description: Differences to section 2 --- krbrev2-6.html 2002/02/07 14:12:00 1.1 +++ krbrev2-6.html 2002/02/15 19:45:11 @@ -4,12 +4,35 @@ indicate attributes of that ticket. Most flags may be requested by a client when the ticket is obtained; some are automatically turned on and off by a Kerberos server as required. The following sections -explain what the various flags mean, and gives examples of reasons to -use such a flag. With the excepttion of the ANONYMOUS and INVALID -flags clients may ignore ticket flags that are not recognized. +explain what the various flags mean and give examples of reasons to +use them. With the excepttion of the ANONYMOUS and INVALID flags +clients MUST ignore ticket flags that are not recognized. KDCs MUST +ignore KDC options that are not recognized. Unfortunately some +implementations of RFC 1510 are known to reject unknown KDC options, +so clients may need to resend a request without KDC options added +since RFC 1510 if their request is rejected. + +

+ +Since KDCs ignore unknown options, clients MUST confirm that the +resulting ticket meets their needs. For example, as discussed in +section 2.8, a client requiring anonymous communication needs to make +sure that the ticket is actually anonymous. A KDC that prohibits +issuing of anonymous tickets or that does not understand the anonymous +option would not return an anonymous ticket. + +

2.1. Initial, pre-authenticated, and hardware authenticated -tickets

2.1. Initial, pre-authenticated, and hardware authenticated tickets

The INITIAL flag indicates that a ticket was issued using the AS protocol and not issued based on a ticket-granting ticket. @@ -234,6 +257,12 @@ originate from different users. Users request anonymous ticket by setting the REQUEST-ANONYMOUS option in an AS or TGS request. +

2.9. Other KDC options

There are three additional options which may be set in a client's @@ -309,3 +338,6 @@ Name canonicalization was then removed and set aside for a separate document. Section 2.9.2 and .3 were renumbered to .1 and .2. +

+ +Discussion of how extensibility affects ticket flags and KDC options was added to the introduction. --=-=-= Content-Disposition: attachment; filename=krbrev3-4.diff Content-Description: Differences to section 3 --- krbrev3-4.html 2002/02/07 14:12:00 1.1 +++ krbrev3-4.html 2002/02/17 22:05:02 @@ -2,6 +2,12 @@ The following sections describe the interactions between network clients and servers and the messages involved in those exchanges. + +

+ +As discussed in section 1.4, most messages have an extensible varient. This section gives guidelines for when the extensible varients should be used and for messages wrapped in integrity checksums, what key is used. + +

3.1. The Authentication Service Exchange

@@ -44,6 +50,11 @@ in the client's secret key. The KRB_AS_REP message contains information which can be used to detect replays, and to associate it with the message to which it replies. + +The extensible variant of the +KRB_AS_REP message also contains a checksum that the client can use to +determine whether its request was modified in transit. +

@@ -52,25 +63,33 @@ simply sends a reply without knowing or caring whether they are the same. This is acceptable because nobody but the principal whose identity was given in the request will be able to use the reply. Its -critical information is encrypted in that principal's key. The -initial request supports an optional field that can be used to pass -additional information that might be needed for the initial exchange. -This field may be used for pre-authentication as described in section -3.1.1. +critical information is encrypted in that principal's key. However, +an attacker can send a KRB_AS_REQ message to get known plaintext in +order to attack the principal's key. Especially if the key is based +on a password, this may create a security exposure. So, the initial +request supports an optional field that can be used to pass additional +information that might be needed for the initial exchange. This field +should be used for pre-authentication as described in section 3.1.1.

Various errors can occur; these are indicated by an error response (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR message contains information which can -be used to associate it with the message to which it replies. If -suitable preauthentication has occurred, an optional checksum may be -included in the KRB_ERROR message to prevent fabrication or -modification of the KRB_ERROR message. When a checksum is not -present, the lack of integrity protection precludes the ability to -detect replays, fabrications, or modifications of the message, and the -client must not depend on information in the KRB_ERROR message for -security critical operations. +be used to associate it with the message to which it replies. + +The extensible variant of the KRB_ERROR message provides for a +checksum to protect against fabrication or modification. As discussed +in section 1.5, the client may not always have enough information to +know whether the checksum should have been included by the KDC. When +a checksum is not present, the lack of integrity protection precludes +the ability to detect replays, fabrications, or modifications of the +message, and the client must not depend on information in the +KRB_ERROR message for security critical operations. + + +The contents of the KRB_ERROR message are not integrity-protected. As such, the client cannot detect replays, fabrications or modifications. A solution to this problem will be included in a future version of the protocol. +

3.1.1. Generation of KRB_AS_REQ message

@@ -88,11 +107,101 @@ The client prepares the KRB_AS_REQ message and sends it to the KDC. + +

+The as-req1 message MUST be used unless the client knows that the +realm of the KDC supports extensible messages. If the client receives +an as-rep2 from a KDC in the realm, then the client can assume that +the realm supports extensible messages and MAY send as-req2 messages +in future. + +

+ +If any KDC in the realm claims to support extensible messages all +the KDCs in the realm MUST accept the extensible messages. For staged +upgrades realms can first install KDCs that support the new messages +and after all KDCs are upgraded the realm can then start using the new +messages. + +

+ +If the client does not have information on the realm's capabilities + cached, it needs to discover whether the realm + supports extensible messages. Two mechanisms are + provided to do this. + +

+ +A client can use the pa-as-req padata type. This element includes the + encoding of a as-req2 message and is included in + the padata field of an old as-req1 message. + +

+ +Old KDCs or new KDCs that are not responding to new messages yet will +ignore PA-AS-REQ padata elements. Old KDCs already ignore padata they +do not understand. New KDCs must ignore everything in the AS-REQ +besides the PA-AS-REQ element. In particular, new KDCs only consider +the padata elements in the PA-AS-REQ's padata sequence. They ignore +any padata elements in the outer AS-REQ other than the PA-AS-REQ +element. Clients MUST NOT send more than one PA-AS-REQ padata +element, MUST NOT send a PA-AS-REQ element inside another PA-AS-REQ +element and MUST NOT send a PA-AS-REQ in a TGS-REQ. + +

+ +The second discovery mechanism is provided by the pre-authentication + required error that a KDC returns in + response to an as-req1 message. A new KDC + that is responding to extensible messages + MUST include a padata element of type + pa-as-req with no associated data in + pre-authentication required errors. The + presence of this element indicates + willingness to accept as-req2 messages. + Clients that can entirely specify their + request using the old as-req1 message May + send such a message. For realms that + require pre-authentication, the client will + receive a pre-authentication required error + that indicates whether new messages are + supported. Unfortunately clients using this + discovery mechanism rather than directly + sending pa-as-req in the original message + will end up using old messages in realms + that do not require pre-authentication. + +

+ +Sometimes a client may not be able to express a principal name or + other option in an as-req1. Such clients + MUST use the first discovery mechanism. + They SHOULD send an as-req1 with a client + and server principal consisting of a + single question mark (`?'). This request + is guaranteed to generate an error if the + KDC only supports as-req1. The real + request is encoded in the pa-as-req + element. + + +

+ +The checksum is never included in as-req2 messages. Instead the + as-rep2 includes a checksum of the as-req2 + received at the KDC. The client SHOULD + verify this checksum against the message + sent to detect modifications. + + +

3.1.2. Receipt of KRB_AS_REQ message

If all goes well, processing the KRB_AS_REQ message will result in the creation of a ticket for the client to present to the server. The -format for the ticket is described in section 5.3.1. The contents of +format for the ticket is described in section 5.3.1. See section + 3.xticket for guidelines on what ticket + format to use. The contents of the ticket are determined as follows.

3.1.3. Generation of KRB_AS_REP message

@@ -118,29 +227,39 @@

When responding to an AS request, if there are multiple encryption -keys registered for a client in the Kerberos database (or if the key -registered supports multiple encryption types; e.g. DES3-CBC-SHA1 and -DES3-CBC-SHA1-KD), then the etype field from the AS request is used by -the KDC to select the encryption method to be used to protect the -encrypted part of the KRB_AS_REP message which is sent to the client. -If there is more than one supported strong encryption type in the -etype list, the first valid etype for which an encryption key is -available is used. The encryption method used to protect the -encrypted part of the KRB_TGS_REP message is the keytype of the -session key found in the ticket granting ticket presented in the -KRB_TGS_REQ. +keys registered for a client in the Kerberos database , then the etype +field from the AS request is used by the KDC to select the encryption +method to be used to protect the encrypted part of the KRB_AS_REP +message which is sent to the client. If there is more than one +supported strong encryption type in the etype list, the first valid +etype for which an encryption key is available is used. The +encryption method used to protect the encrypted part of the +KRB_TGS_REP message is the keytype of the session key found in the +ticket granting ticket presented in the KRB_TGS_REQ.

-If the user's key was generated using an alternate string to key -function than that used by the selected encryption type, information -needed by the string to key function will be returned to the client in -the padata field of the KRB_AS_REP message using the PA-PW-SALT, -PA-AFS3-SALT, or similar pre-authentication typed values. This does -not affect the encryption performed by the KDC since the key stored in -the principal database already has the string to key transformation -applied. - +When the user's key is generated from a password or pass phrase, the + string-to-key function for the particular encryption + key type is used, as specified in [KCRYPTO]. The + salt value and additional parameters for the + string-to-key function have default values + (specified by section 6 and by the encryption + mechanism specification, respectively) that may be + overridden by preauthentication data (PA-PW-SALT, + PA-AFS3-SALT, PA-ETYPE-INFO, PA-S2K-PARAMS, etc). + Since the KDC is presumed to store a copy of the + resulting key only, these values should not be + changed for password-based keys except perhaps when + changing the principal's key. + +

+ +It is not possible to reliably generate a user's key given a pass + phrase without contacting the KDC, since it will + not be known whether alternate salt or parameter + values are required. +

When the etype field is present in a KDC request, whether an AS or TGS @@ -224,17 +343,32 @@

-If all of the above succeed, the server will encrypt ciphertext part -of the ticket using the encryption key extracted from the server +If all of the above succeed, the server will encrypt ciphertext part of +the ticket using the encryption key extracted from the server principal's record in the Kerberos database using the encryption type -associated with the server principal's key (this choice is NOT -affected by the etype field in the request). It then formats a -KRB_AS_REP message (see section 5.4.2), copying the addresses in the -request into the caddr of the response, placing any required -pre-authentication data into the padata of the response, and encrypts -the ciphertext part in the client's key using an acceptable encryption -method requested in the etype field of the request, and sends the -message to the client. See section A.2 for pseudocode. +associated with the server principal's key (this choice is NOT affected +by the etype field in the request). It then formats a KRB_AS_REP +message (see section 5.4.2), copying the addresses in the request into +the caddr of the response, placing any required pre-authentication data +into the padata of the response, and encrypts the ciphertext part in the +client's key using an acceptable encryption method requested in the +etype field of the request, or in some key specified by +pre-authentication mechanisms being used. See section A.2 for +pseudocode. + + +

+ +A KDC responding to an as-req1 MUST use the as-rep1. A KDC responding +to an as-req2 or a PA-AS-REQ MUST use the as-rep2 . Note that a KDC +supporting extensible messages in a realm where not all KDCs have been +upgraded to support extensible messages should respond to an as-req1 +(using a as-rep1 response) even if it contains a PA-AS-REQ padata +element; see Section 3.1.1 for details. The as-rep2 MUST be +checksummed in the reply key used to encrypt the enc-part. The +checksum of the as-req included in the as-rep should be encrypted in +the same key. +

3.1.4. Generation of KRB_ERROR message

@@ -244,6 +378,13 @@ values. The error message contents and details are described in Section 5.9.1. + +

+XXX this is filler for the checksumming guidelines. We have + discussion of what we want on the list, but I'm focusing on + clarifications, so I don't have time to write it up now. + +

3.1.5. Receipt of KRB_AS_REP message

If the reply message type is KRB_AS_REP, then the client verifies that @@ -337,6 +478,13 @@ end server along with any additional application-specific information. See section A.9 for pseudocode. + +

+An extensible ap-req2 MUST be used if a ticket2 is used; an ap-req1 otherwise. +The ap-req2 MUST be checksummed in the xxx session key of the ticket +used. + +

3.2.3. Receipt of KRB_AP_REQ message

Authentication is based on the server's current time of day (clocks @@ -385,15 +533,14 @@ the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client from the ticket are compared against the same fields in the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is -returned (they might not match, for example, if the wrong session key -was used to encrypt the authenticator). The addresses in the ticket -(if any) are then searched for an address matching the -operating-system reported address of the client. If no match is found -or the server insists on ticket addresses but none are present in the -ticket, the KRB_AP_ERR_BADADDR error is returned. If the local -(server) time and the client time in the authenticator differ by more -than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW -error is returned. +returned; this normally is caused by a client error or attempted +attack. The addresses in the ticket (if any) are then searched for an +address matching the operating-system reported address of the client. +If no match is found or the server insists on ticket addresses but +none are present in the ticket, the KRB_AP_ERR_BADADDR error is +returned. If the local (server) time and the client time in the +authenticator differ by more than the allowable clock skew (e.g., 5 +minutes), the KRB_AP_ERR_SKEW error is returned.

@@ -481,6 +628,13 @@ The KRB_AP_REP message is encrypted in the session key extracted from the ticket. See section A.11 for pseudocode. + +

+An ap-rep2 MUST be used to respond to an ap-rep2; ap-rep1 MUST be used +to respond to ap-req1. The ap-req2 MUST be checksummed in the xxx +session key of the ticket used in the AP-REQ. + +

3.2.5. Receipt of KRB_AP_REP message

If a KRB_AP_REP message is returned, the client uses the session key @@ -493,6 +647,8 @@

3.2.6. Using the encryption key

+XXX This seems inconsistent with crypto-architecture; we should look + at before publication. After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server share an encryption key which can be used by the application. In some cases, the use of this session key will be implicit in the @@ -602,9 +758,8 @@ be used to detect replays, and to associate it with the message to which it replies. The KRB_ERROR message also contains information which can be used to associate it with the message to which it -replies, but except when an optional checksum is included in the -KRB_ERROR message, it is not possible to detect replays or -fabrications of such messages. +replies. The same comments about integrity protection of KRB_ERROR + messages mentioned in section 3.1 apply to the TGS exchange.

3.3.1. Generation of KRB_TGS_REQ message

@@ -657,6 +812,15 @@ Once prepared, the message is sent to a Kerberos server for the destination realm. See section A.5 for pseudocode. + +

+A client MUST use a tgs-req1 with a ticket1 ticket-granting-ticket. A +client MUST use tgs-req2 with a ticket2 ticket-granting-ticket. The +tgs-req2 MUST be checksummed in the xxx session key of the ticket used +to construct the PA-TGS-REQ AP-REQ message. + + +

3.3.2. Receipt of KRB_TGS_REQ message

The KRB_TGS_REQ message is processed in a manner similar to the @@ -942,12 +1106,16 @@ When an application wishes to send a KRB_SAFE message, it collects its data and the appropriate control information and computes a checksum -over them. The checksum algorithm should be a keyed one-way hash -function (such as the RSA- MD5-DES checksum algorithm specified in -section 6.4.5, or the DES MAC), generated using the sub-session key if -present, or the session key. Different algorithms may be selected by -changing the checksum type in the message. Unkeyed or -non-collision-proof checksums are not suitable for this use. +over them. The checksum algorithm should be the keyed checksum +mandated to be implemented along with the crypto system used for the +sub-session or session key. The checksum is generated using the +sub-session key if present, or the session key. Some implementations +use a different checksum algorithm for KRB_SAFE messages but doing so +in a interoperable manner is impossible. Implementations should +accept any checksum algorithm they implement that both has adequate +security and that has keys compatible with the sub-session or session +key. Unkeyed or non-collision-proof checksums are not suitable for +this use.

@@ -990,7 +1158,8 @@ and type fields match the current version and KRB_SAFE, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application verifies that the checksum used is a -collision-proof keyed checksum, and if it is not, a +collision-proof keyed checksum that uses keys compatible with the +sub-session or session key as appropriate, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If the sender's address was included in the control information, the recipient verifies that the operating system's report of the sender's address matches the @@ -1101,6 +1270,12 @@ negotiated via subkeys, or the session key if no negotiation has occurred). +

+ +xxx Implementation note about unencrypted KRB_CRED messages go here. + Need to make sure we understand what MIT does and reconcile with + Microsoft. +

3.6.2. Receipt of KRB_CRED message

When an application receives a KRB_CRED message, it verifies it. If @@ -1229,3 +1404,19 @@ 7/01 - removed reference to name canonicalization. + +

+Changed may preauthenticate to should preauthenticate and included note +about known plaintext attacks. + +

+ + +Remove text about keys that support multipmle encryption types. The + crypto draft doesn't really define things that way and it is out of + scope for the protocol spec anyway. + +

+Added some useful text for clarifications. There are few places where + placeholders rather than text have been added. Once text is + agreed on these will be replaced. --=-=-=-- From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 10:45:58 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05332 for ; Mon, 18 Feb 2002 10:45:58 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA21227 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 09:31:23 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA21213 for ; Mon, 18 Feb 2002 09:31:21 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA12945 for ; Mon, 18 Feb 2002 09:31:21 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA11455; Mon, 18 Feb 2002 10:31:20 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA09872; Mon, 18 Feb 2002 10:31:19 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA10862; Mon, 18 Feb 2002 10:31:19 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id KAA29351; Mon, 18 Feb 2002 10:31:18 -0500 (EST) To: ckuo01@syr.edu, ietf-krb-wg@anl.gov, Nicolas.Williams@ubsw.com Subject: Re: Can Authorization Data be retrieved through GSSAPI? References: <200202181507.QAA11045@uw1048.wdf.sap-ag.de> From: Sam Hartman Date: 18 Feb 2002 10:31:18 -0500 In-Reply-To: Martin Rex's message of "Mon, 18 Feb 2002 16:07:49 +0100 (MET)" Message-ID: Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "Martin" == Martin Rex writes: Martin> In the end you realize that often it is the most portable Martin> (across arbitrary gssapi mechanisms) and backward Martin> compatible (across the installed base of an application) Martin> solution to not use any external authorization data even Martin> for gssapi mechanisms that support (some limited) form of Martin> authorization data. Sure, but there are many reasons for using GSSAPI. I've seen a lot of applications start using GSSAPI lately, very aware that they will have to add mechanism-specific knowledge for every GSSAPI mechanism they support. They end up choosing GSSAPI either because they believe that even given this requirement, adding new mechanisms will be easier. Others choose GSSAPI because they want to use Kerberos and want to work on Windows/Solaris. Others choose GSSAPI because they want SASL. So, while the portable decision may be to do application-specific authorization, many application authors are finding that decision does not satisfy their users. The criticality of Kerberos authorization data is also going to be very annoying for GSSAPI. In order to actually get authorization data to be critical, we as implementers are going to have to make sure that gss_accept_sec_context fails if the authorization data has not been understood by the library or application by the end of the call. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 10:49:36 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05367 for ; Mon, 18 Feb 2002 10:49:36 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA23212 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 09:35:02 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA23206 for ; Mon, 18 Feb 2002 09:35:00 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA13881 for ; Mon, 18 Feb 2002 09:34:59 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA02283; Mon, 18 Feb 2002 16:38:32 +0100 (MEZ) From: Martin Rex Message-Id: <200202181534.QAA11134@uw1048.wdf.sap-ag.de> Subject: Re: Kerb WG iakerb To: Nicolas.Williams@ubsw.com (Nicolas Williams) Date: Mon, 18 Feb 2002 16:34:25 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <20020215133943.O27171@sm2p1386swk.wdr.com> from "Nicolas Williams" at Feb 15, 2 01:39:44 pm Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > There's no reason why one could not design an API that includes the > ability to prompt the user, like PAM, say, for whatever passwords and > tokens are needed and *still* be compliant with GSS-API on the wire. You got it backwards. GSS-API is explicitly both, on-the-wire and API behaviour. The focus, however, is actually on the API -- one single API and API behaviour for all applications and years to come! GSS-API mechanisms (which define on-the-wire) were supposed to be rev'able and replacable as a design feature of GSS-API from the beginning. In reality, lacking a negotiation and/or migration support in the base requirements for GSS-API mechanisms often makes it difficult to actually replace a mechanism within an installed base, requiring either a mechanism itself to provide interoperability with its successor (version) or a flag day. > > That said, the default behaviour by most implementations can probably be > relied upon to be password-caching. Sigh. The default behaviour *must* be password caching. Ted Ts'o once proposed a GSS-API extension to supply a callback function for actual credential acquisition in order to interactively prompt the user. Such an extension, however, might only be used by future applications to modify the existing (default) behaviour of a GSS-API mechanism. Do you know what happens if you run some program as a Win32 (non-interactive) service and some function suddenly decides to open a dialog box expecting user input? -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 14:19:04 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14358 for ; Mon, 18 Feb 2002 14:19:03 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA24063 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 13:04:26 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA24057 for ; Mon, 18 Feb 2002 13:04:24 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA27560; Mon, 18 Feb 2002 13:04:23 -0600 (CST) Message-ID: <3C715035.944CD513@anl.gov> Date: Mon, 18 Feb 2002 13:04:21 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-krb-wg@anl.gov CC: Jeffrey Schiller , Marcus Leech Subject: IETF KRB-WG Interum meeting Boston 2/12 - 2/13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit An interim meeting to the krb-wg was held at MIT on 2/12 and 2/13 The agenda for the meeting was to work on the revisions document which has been in flux for at least two years, with proposals for additional changes still on the table. Present at the meeting: - Tom Yu (MIT) - Ken Raeburn (MIT) - Sam Hartman (Mekinok) - Jeff Hutzlman (CMU) - Ken Hornstein (NRL) - Jeff Altman (Columbia) - Doug Engert (ANL) - Cliff Newmann (ISI) - John Brezak (Microsoft) - Nicole Williams (Perot Systems) The main outcome of the meeting is to split the "revisions" document into two documents, which would be called "Clarifications" and "Extensions". "Clarifications" would contain most of the features which have been added in various implementations, and which are needed now. This will allow this document to proceed rather quickly, as we have been working on this for two years. "Extensions" will contain most of the other new features which are needed to cleanup the protocol, add extensibility, and true internationalization. The two main concerns where cost of implementation and timeliness. The internationalization changes need to be based on what the DNS people do, and will require changes to the protocol to implement. This would require changes to many of the messages formats. Although this is a good long term goal, it will be costly to implement and test. Yet there are other changes which have been informally agreed upon and implemented in multiple implementations which need to be documented now. Although many of us had been taking notes (and photos) of which features are to be in each document, Cliff has promised to post to his web site a nice formatted list of these in the next few days, along with the "Clarifications" so I will not try and list them here. See http://www.isi.edu/people/bcn/krb-revisions/ is a few days. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 14:31:52 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14913 for ; Mon, 18 Feb 2002 14:31:51 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA29780 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 13:18:02 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA29765 for ; Mon, 18 Feb 2002 13:18:00 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA29379; Mon, 18 Feb 2002 13:14:13 -0600 (CST) Message-ID: <3C715283.B7D503D3@anl.gov> Date: Mon, 18 Feb 2002 13:14:11 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicolas Williams CC: Joncheng Kuo , ietf-krb-wg@anl.gov Subject: Re: Can Authorization Data be retrieved through GSSAPI? References: <3C6D9054.2040807@syr.edu> <20020216170451.X27171@sm2p1386swk.wdr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > > Authz data was always in RFC1510. And no, the GSS-API C Bindings do not > provide an API for getting at the authz data. But GSS is not merely > about the specific bindings. GSS could probably use some revisions. You may wish to look at this document, which has some revisions to GSS-API. http://www.gridforum.org/security/ggf3_2001-10/drafts/draft-ggf-gss-extensions-04.pdf It defines a gss_inquire_context_by_oid to allow access to additional mech specifiy information. The authz data could be one of these. > > Nico > > On Fri, Feb 15, 2002 at 05:48:52PM -0500, Joncheng Kuo wrote: > > Hi, > > > > I'm new to this mail list. > > > > A basic format of Authorization Data has been added to the revision of > > the draft Kerberos standard. Is there any way that this Authorization > > Data can be exposed through GSSAPI? If not, is there any move to make an > > extension on GSSAPI? > > > > Joncheng Kuo > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 14:36:46 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15031 for ; Mon, 18 Feb 2002 14:36:46 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA01565 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 13:22:38 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA01553; Mon, 18 Feb 2002 13:22:37 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA01045; Mon, 18 Feb 2002 13:22:36 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA08831; Mon, 18 Feb 2002 14:22:34 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA02514; Mon, 18 Feb 2002 14:22:34 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA24729; Mon, 18 Feb 2002 14:22:34 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id OAA29453; Mon, 18 Feb 2002 14:22:33 -0500 (EST) To: "Douglas E. Engert" Cc: Nicolas Williams , Joncheng Kuo , ietf-krb-wg@anl.gov Subject: Re: Can Authorization Data be retrieved through GSSAPI? References: <3C6D9054.2040807@syr.edu> <20020216170451.X27171@sm2p1386swk.wdr.com> <3C715283.B7D503D3@anl.gov> From: Sam Hartman Date: 18 Feb 2002 14:22:32 -0500 In-Reply-To: "Douglas E. Engert"'s message of "Mon, 18 Feb 2002 13:14:11 -0600" Message-ID: Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "Douglas" == Douglas E Engert writes: Douglas> It defines a gss_inquire_context_by_oid to allow access Douglas> to additional mech specifiy information. The authz data Douglas> could be one of these. Why is this work going on in terms of Grid Form rather than IETF. I thought they implied they wanted to work with us at a recent meeting. I'd think part of that would be submitting extensions to IETF standards to the IETF especially when such extensions were not specific to their needs. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 14:51:17 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15658 for ; Mon, 18 Feb 2002 14:51:16 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id NAA07569 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 13:36:50 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA07563 for ; Mon, 18 Feb 2002 13:36:49 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA03794; Mon, 18 Feb 2002 13:36:18 -0600 (CST) Message-ID: <3C7157AF.36C8E90A@anl.gov> Date: Mon, 18 Feb 2002 13:36:15 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dinara Suleymanova , ietf-krb-wg@anl.gov Subject: Re: [Fwd: Scheduling a KRB-WG] References: <5.1.0.14.0.20020218121949.02649950@odin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Thanks, it better then Monday. Dinara Suleymanova wrote: > > It's not possible. At least for now. I've rescheduled your slot on Tuesday > (two 1 hour slots). > > At 10:59 AM 2/18/02 -0600, Douglas E. Engert wrote: > >I see that you have scheduled the krb-wg meeting for Monday. > >Monday is not good for many of out working group. If at all possible, > >could we be scheduled for Wednesday or Thursday. > > > >Wednesday 1530-1730 looks good. > > > >Thursday 1300-1500 aslo looks good (assuming the SAAG meeting will be at > >1530-1730.) > > > >I have attached the original request. > > > >Thanks. > > > > > >-------- Original Message -------- > >Subject: Scheduling a KRB-WG > >Date: Wed, 30 Jan 2002 11:34:00 -0600 > >From: "Douglas E. Engert" > >To: agenda@ietf.org > >CC: Jeffrey Schiller ,Marcus Leech > > > > > >Please schedule a (2hr) session for the KRB-WG for the 53rd IETF. > > > >Wednesday afternoon or Thursday morning prefered. > >Please avoid other security area sessions. > > > >Thanks. > > > >-- > > > > Douglas E. Engert > > Argonne National Laboratory > > 9700 South Cass Avenue > > Argonne, Illinois 60439 > > (630) 252-5444 -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 18 15:17:48 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16654 for ; Mon, 18 Feb 2002 15:17:48 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id OAA17702 for ietf-krb-wg-outgoing; Mon, 18 Feb 2002 14:01:37 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA17696 for ; Mon, 18 Feb 2002 14:01:36 -0600 (CST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA09140 for ; Mon, 18 Feb 2002 14:01:36 -0600 (CST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GRQ002O4VMOFP@smtp.fnal.gov> for ietf-krb-wg@anl.gov; Mon, 18 Feb 2002 14:01:36 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id g1IK1ZZ05831 for ; Mon, 18 Feb 2002 14:01:35 -0600 (CST) Date: Mon, 18 Feb 2002 14:01:35 -0600 From: Matt Crawford Subject: Re: Can Authorization Data be retrieved through GSSAPI? In-reply-to: "18 Feb 2002 14:22:32 EST." To: ietf-krb-wg@anl.gov Message-id: <200202182001.g1IK1ZZ05831@gungnir.fnal.gov> Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk > Why is this work going on in terms of Grid Form rather than IETF? Let's explain by indirection: the GGF is meeting right now, and their network is NATted. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 06:35:02 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14386 for ; Tue, 19 Feb 2002 06:35:02 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id FAA15139 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 05:24:26 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id FAA15128; Tue, 19 Feb 2002 05:24:24 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id FAA12792; Tue, 19 Feb 2002 05:24:23 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id MAA00373; Tue, 19 Feb 2002 12:27:58 +0100 (MEZ) From: Martin Rex Message-Id: <200202191123.MAA12853@uw1048.wdf.sap-ag.de> Subject: Re: Can Authorization Data be retrieved through GSSAPI? To: deengert@anl.gov (Douglas E. Engert) Date: Tue, 19 Feb 2002 12:23:51 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <3C715283.B7D503D3@anl.gov> from "Douglas E. Engert" at Feb 18, 2 01:14:11 pm Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit This is more a CAT than a KRB comment... Douglas E. Engert wrote: > > Nicolas Williams wrote: > > > > Authz data was always in RFC1510. And no, the GSS-API C Bindings do not > > provide an API for getting at the authz data. But GSS is not merely > > about the specific bindings. GSS could probably use some revisions. > > You may wish to look at this document, which has some revisions to GSS-API. > > http://www.gridforum.org/security/ggf3_2001-10/drafts/draft-ggf-gss-extensions-04.pdf > > It defines a gss_inquire_context_by_oid to allow access to additional > mech specifiy information. The authz data could be one of these. I just finished reading the suggested document and I'm not very happy about it. The document describes very implementation specific extensions of the native APIs of the authentication mechanisms implemented by GSI. I strongly suggest that the naming and description to be changed so it looks less deceiving about its level of abstraction. These native calls are modeled so that they can re-use data types of the GSS-API and convert between native and GSS-API-style objects. Unfortunately the document creates the expression that it describes an actual abstraction and extension to GSS-API, while it acutally is a very implementation specific extension of a particular mechanism *implementation*. Normally, the IETF only standarized on-the-wire protocols, and even there arises confusion and interoperability problems quite often. GSS-API was unusual for the IETF in that it not only defines the on-the-wire format, but also an API with a limited set of abstract datatypes and detailed but abstract semantics of the API calls so that ultimately portable applications could be plug'n'play with arbitrary gssapi mechanisms. The IETF-defined GSS-API strictly *avoids* to mandate implementation details for gssapi mechanisms (beyond on-the-wire framing and the abstract semantics required by the API), and in particular on the native APIs of the mechanisms and their data types. In fact, if you compare Microsoft's W2K Kerberos and MIT Kerberos, in particular their "(officially) exposed APIs", you will notice that they differ considerably. Microsoft primarily implemented on-the-wire interoperability. However, since GSS-API doesn't mandate implementation details, this shouldn't be a problem. To accomodate for the lack of a real GSS-API, I wrote a wrapper DLL that offers true GSS-API data-types and semantics on top of Microsoft's SSPI and it's quite usable. Portable applications shouldn't notice a difference between Kerberos implementations from MIT or Cybersafe and Microsoft's W2K Kerberos underneath my wrapper DLL. The GSI proposal for GSS-API "extensions" require quite a lot of interoperability on very implementation specific aspects of the particular gssapi implementation, and these extensions will *NOT* fit underneath SPNEGO (not that I personally like SPNEGO, but if an extension doesn't fit underneath, then it probably breaks the abstraction model of GSS-API). One of the more interesting aspects of the document: (1) It tries to offer a policy selection on whether or not context expiration should be enforced. (2) It tries to offer a policy to reliably disable all encryption. (1) So far the Kerberos 5 GSS-API mechanism (rfc1964) is the only gssapi mechanism that I've seen that mandates context expiration. Curiously, this is a part where Microsoft's implementation doesn't comply with the spec. My wrapper DLL tries to workaround that deficiency and enforce context expiration, though. How can a gssapi mechanism "enforce" context expiration at all? For an application that doesn't use message protection after initial context establishment there's nothing a gss-api mechanism can do to stop it. :) The only means for a gssapi mechanism to indicate that a context has expired is to fail any of the remaining calls that an application will use once the security context has been successfully established. These are the message protection/unprotection calls and optionally the context_export/import calls. How difficult is it for a long-running application to deal gracefully with context expiration? Somewhere from hard to extremely difficult. An application will have to perform another context establishment token exchange to create a new security context. The real problem comes from context expiration while protected messages are "in transit", be it on the wire, in network buffers or message queue(s). Although context expiration is a good idea from the security point of view, it is a major PITA for application protocol design and may simply not fit under many of the existing multi-layer application protocol stacks. (2) The purpose of such a policy _really_ puzzles me. Confidentiality during message protection is only applied when the application asks for it when calling gss_wrap(). Since (a) setting a no-encryption policy and (b) calling gss_wrap() with conf_req==FALSE is both a volutary decision of the application, why should we need an extension to implement (a) when (b) is readily available in the base spec and working just fine? A while ago I met a gssapi mechanism implementor that tried to enforce the opposite policy (i.e. always encrypt) within the gssapi for certain users and I just laughed at him. He tried to do so by always applying encryption when an application called gss_wrap(), independent of the conf_request flag. Well, our application uses gss_getmic() when configured for integrity-only protection, and it can also be configured to run with no message-protection at all, so the gssapi mechanism is unable to override the application's configuration. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 09:13:18 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19559 for ; Tue, 19 Feb 2002 09:13:17 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id IAA05314 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 08:02:59 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA05308 for ; Tue, 19 Feb 2002 08:02:57 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA08746 for ; Tue, 19 Feb 2002 08:02:57 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA08455; Tue, 19 Feb 2002 09:02:57 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA21642; Tue, 19 Feb 2002 09:02:56 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA19321; Tue, 19 Feb 2002 09:02:56 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id JAA29866; Tue, 19 Feb 2002 09:02:56 -0500 (EST) To: mrex@sap-ag.de Cc: ietf-krb-wg@anl.gov Subject: Re: Can Authorization Data be retrieved through GSSAPI? References: <200202191123.MAA12853@uw1048.wdf.sap-ag.de> From: Sam Hartman Date: 19 Feb 2002 09:02:56 -0500 In-Reply-To: Martin Rex's message of "Tue, 19 Feb 2002 12:23:51 +0100 (MET)" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "Martin" == Martin Rex writes: Martin> (1) So far the Kerberos 5 GSS-API mechanism (rfc1964) is Martin> the only gssapi mechanism that I've seen that mandates Martin> context expiration. Curiously, this is a part where Martin> Microsoft's implementation doesn't comply with the spec. Martin> My wrapper DLL tries to workaround that deficiency and Martin> enforce context expiration, though. How would you feel about dropping this when we next revisit RFC 1964 to add AES support? From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 09:55:54 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21928 for ; Tue, 19 Feb 2002 09:55:53 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id IAA19924 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 08:42:26 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA19918 for ; Tue, 19 Feb 2002 08:42:24 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA17123 for ; Tue, 19 Feb 2002 08:42:23 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id PAA09316; Tue, 19 Feb 2002 15:45:51 +0100 (MEZ) From: Martin Rex Message-Id: <200202191441.PAA13383@uw1048.wdf.sap-ag.de> Subject: Re: Can Authorization Data be retrieved through GSSAPI? To: hartmans@mit.edu (Sam Hartman) Date: Tue, 19 Feb 2002 15:41:43 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: from "Sam Hartman" at Feb 19, 2 09:02:56 am Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > >>>>> "Martin" == Martin Rex writes: > > Martin> (1) So far the Kerberos 5 GSS-API mechanism (rfc1964) is > Martin> the only gssapi mechanism that I've seen that mandates > Martin> context expiration. Curiously, this is a part where > Martin> Microsoft's implementation doesn't comply with the spec. > Martin> My wrapper DLL tries to workaround that deficiency and > Martin> enforce context expiration, though. > > How would you feel about dropping this when we next revisit RFC 1964 > to add AES support? Please leave it as it is. Jeff Schiller as the Security Area Director required the context expiration for RFC-1964. The reasoning was that no encryption key should be permitted to live forever. The same reasoning was applied to SSL and to IPSEC, and I think its just as valid today. The discussion details is somewhere in the CAT archives, I could dig it up if you're interested. It takes some extra efforts at the application protocol levels to accomodate for expiring security context (something which Microsoft probably chose not to do after the W2K beta2 failed badly with enforced context expiration...) I have added provisions to our application protocols to perform a context renegotiation, but it is not perfect or fail-safe, and it probably has a rough edge that I should improve one of these days... But basically, it works. For asynchronus application communication, the extra negotiation causes some extra complexity. For synchronus app communication (blocking threads) there is little extra complexity but additional stalls for which it might be difficult to define timeouts (but the timeout problems for SSL communication is also an unsolved question already). -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 10:20:35 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23348 for ; Tue, 19 Feb 2002 10:20:35 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA01038 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 09:09:37 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA00863 for ; Tue, 19 Feb 2002 09:09:35 -0600 (CST) Received: from gate2.stm.ubswarburg.com (gate2.stm.ubswarburg.com [151.191.1.12]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA23367 for ; Tue, 19 Feb 2002 09:09:34 -0600 (CST) Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id KAA11643; Tue, 19 Feb 2002 10:09:14 -0500 (EST) Received: from (nine.ubswarburg.com [192.168.0.4]) by gate2 via smap (V2.0/ubsw) id xma011565; Tue, 19 Feb 2002 10:08:58 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA11161; Tue, 19 Feb 2002 10:05:28 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA24657; Tue, 19 Feb 2002 10:08:55 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id KAA21750; Tue, 19 Feb 2002 10:07:39 -0500 (EST) Date: Tue, 19 Feb 2002 10:07:39 -0500 From: Nicolas Williams To: mrex@sap-ag.de Cc: ietf-krb-wg@anl.gov Subject: Re: Kerb WG iakerb Message-ID: <20020219100738.Y27171@sm2p1386swk.wdr.com> Mail-Followup-To: mrex@sap-ag.de, ietf-krb-wg@anl.gov References: <20020215133943.O27171@sm2p1386swk.wdr.com> <200202181534.QAA11134@uw1048.wdf.sap-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200202181534.QAA11134@uw1048.wdf.sap-ag.de>; from martin.rex@sap-ag.de on Mon, Feb 18, 2002 at 04:34:25PM +0100 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Mon, Feb 18, 2002 at 04:34:25PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > There's no reason why one could not design an API that includes the > > ability to prompt the user, like PAM, say, for whatever passwords and > > tokens are needed and *still* be compliant with GSS-API on the wire. > > You got it backwards. > > GSS-API is explicitly both, on-the-wire and API behaviour. I didn't say otherwise. I think that one can meet the spirit of GSS-API without having to stick to the GSS-API C bindings RFCs. If one were to add some extensions to the GSS-API C bindings in some implementation one might still be compliant with RFC2078 even if not with the bindings RFCs. Of course, to the extent that RFC2744 and 2078 disagree today it's hard to be compliant with both (e.g., name string encodings). There is sentiment that the IETF should not be in the business of designing APIs. That said, the spirit of GSS-API, namely the bits about context setup, IMO is worth codifying. Other protocols making use of GSS generally concentrate on the use of gss_init_sec_context() and gss_accept_sec-context() and perhaps they specify service naming, but no such protocols would be broken if an implementation adds a GSS-API extension for authz data handling, say (though better signalling of authentication vs. authorization errors might be appreciated). > The focus, however, is actually on the API -- one single API and > API behaviour for all applications and years to come! Yes. Well. It seems we have to make some serious trade-offs for that to work. E.g., authorization data is hard to abstract, as you point out. And so is credentials handling, and other fun stuff. Some bits of such an API as GSS will have to be fuzzy in order to be workable. Does that mean #ifdefs in portable code? Yeah. Can such an API still help on the portability front? Yes. > GSS-API mechanisms (which define on-the-wire) were supposed to be > rev'able and replacable as a design feature of GSS-API from the > beginning. In reality, lacking a negotiation and/or migration > support in the base requirements for GSS-API mechanisms often > makes it difficult to actually replace a mechanism within an > installed base, requiring either a mechanism itself to provide > interoperability with its successor (version) or a flag day. Right, so let's agree that an API such as GSS-API can help portability, but can't be a complete panacea and let's accept that some mechanism- and implementation-specific mods are needed. > > That said, the default behaviour by most implementations can probably be > > relied upon to be password-caching. Sigh. > > The default behaviour *must* be password caching. You can also just fail when the creds expire. > Ted Ts'o once proposed a GSS-API extension to supply a callback > function for actual credential acquisition in order to interactively > prompt the user. Such an extension, however, might only be used > by future applications to modify the existing (default) behaviour > of a GSS-API mechanism. I'd kinda prefer not putting a callback into GSS-API and instead put in links to other APIs (PAM on *nix, GINA on Windows). > Do you know what happens if you run some program as a Win32 > (non-interactive) service and some function suddenly decides > to open a dialog box expecting user input? Hopefully it fails. > -Martin Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 10:37:03 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24192 for ; Tue, 19 Feb 2002 10:37:03 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA06252 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 09:23:53 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA06241; Tue, 19 Feb 2002 09:23:51 -0600 (CST) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA26647; Tue, 19 Feb 2002 09:23:51 -0600 (CST) Received: from Von-Win2k-Box.mcs.anl.gov (pitcairn.mcs.anl.gov [140.221.9.180]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id JAA113612; Tue, 19 Feb 2002 09:23:13 -0600 Message-Id: <5.1.0.14.2.20020219090052.02a108f0@localhost> X-Sender: welch@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Feb 2002 09:21:31 -0600 To: mrex@sap-ag.de From: Von Welch Subject: Re: Can Authorization Data be retrieved through GSSAPI? Cc: deengert@anl.gov (Douglas E. Engert), ietf-krb-wg@anl.gov In-Reply-To: <200202191123.MAA12853@uw1048.wdf.sap-ag.de> References: <3C715283.B7D503D3@anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Martin, Sam- First, to respond to Sam's earlier question as to why this document is in GGF instead of IETF - We are indeed interested in putting this document through the IETF (which is why we have it in ID draft format instead of GGF format). Yes, we see it going in the CAT working group. About a year ago we approached John Lynn with the idea and got a cold response. Given that we knew the document was still serious evolving we held off. If however we could get interest from Kerberos community as well, we would certainly jump back into the IETF community with this. Martin - in reponse to your comments, I would much rather address your issues of this being mechanism specific than say this is mechanism specific. We (the authors) have a fair amount of Kerberos experience between us and we've tried very hard to at least keep that mechanism in mind when laying out this document since working over it is also serious interest to our project. Could give some specific examples of what you think are mechanism-specific attributes? In response to your specific comments, our attempt to standardize behavior on context expiration is just an attempt to standardize the behavior of the wrap/unwrap calls when context expires and to give the application a way to control this. The idea being that some sites might want to know when the context expires, but finish some action (e.g. a file transfer in progress) before disallowing further activity. The idea behind disabling of encryption is that this allows an application to disable encryption for some policy reason, even if the mechanism supports it. By doing so before context setup, this allows the client to gracefully know this before a wrap call fails. Honestly, we threw this in as a "seems like a good idea". Von At 12:23 PM 2/19/2002 +0100, Martin Rex wrote: >This is more a CAT than a KRB comment... > >Douglas E. Engert wrote: > > > > Nicolas Williams wrote: > > > > > > Authz data was always in RFC1510. And no, the GSS-API C Bindings do not > > > provide an API for getting at the authz data. But GSS is not merely > > > about the specific bindings. GSS could probably use some revisions. > > > > You may wish to look at this document, which has some revisions to GSS-API. > > > > > http://www.gridforum.org/security/ggf3_2001-10/drafts/draft-ggf-gss-extensions-04.pdf > > > > It defines a gss_inquire_context_by_oid to allow access to additional > > mech specifiy information. The authz data could be one of these. > > >I just finished reading the suggested document and I'm not very >happy about it. The document describes very implementation specific >extensions of the native APIs of the authentication mechanisms >implemented by GSI. I strongly suggest that the naming and >description to be changed so it looks less deceiving about >its level of abstraction. > > >These native calls are modeled so that they can re-use data types >of the GSS-API and convert between native and GSS-API-style objects. > >Unfortunately the document creates the expression that it describes >an actual abstraction and extension to GSS-API, while it acutally is >a very implementation specific extension of a particular mechanism >*implementation*. > > >Normally, the IETF only standarized on-the-wire protocols, and even >there arises confusion and interoperability problems quite often. > >GSS-API was unusual for the IETF in that it not only defines >the on-the-wire format, but also an API with a limited set of >abstract datatypes and detailed but abstract semantics of the >API calls so that ultimately portable applications could be >plug'n'play with arbitrary gssapi mechanisms. > > >The IETF-defined GSS-API strictly *avoids* to mandate implementation >details for gssapi mechanisms (beyond on-the-wire framing and the >abstract semantics required by the API), and in particular on the >native APIs of the mechanisms and their data types. > >In fact, if you compare Microsoft's W2K Kerberos and MIT Kerberos, >in particular their "(officially) exposed APIs", you will notice >that they differ considerably. Microsoft primarily implemented >on-the-wire interoperability. However, since GSS-API doesn't >mandate implementation details, this shouldn't be a problem. >To accomodate for the lack of a real GSS-API, I wrote a wrapper >DLL that offers true GSS-API data-types and semantics on top >of Microsoft's SSPI and it's quite usable. Portable applications >shouldn't notice a difference between Kerberos implementations >from MIT or Cybersafe and Microsoft's W2K Kerberos underneath >my wrapper DLL. > >The GSI proposal for GSS-API "extensions" require quite a lot of >interoperability on very implementation specific aspects of the >particular gssapi implementation, and these extensions will *NOT* >fit underneath SPNEGO (not that I personally like SPNEGO, but >if an extension doesn't fit underneath, then it probably breaks the >abstraction model of GSS-API). > > > >One of the more interesting aspects of the document: >(1) It tries to offer a policy selection on whether or not context > expiration should be enforced. >(2) It tries to offer a policy to reliably disable all encryption. > > >(1) So far the Kerberos 5 GSS-API mechanism (rfc1964) is the only > gssapi mechanism that I've seen that mandates context expiration. > Curiously, this is a part where Microsoft's implementation doesn't > comply with the spec. My wrapper DLL tries to workaround that > deficiency and enforce context expiration, though. > > How can a gssapi mechanism "enforce" context expiration at all? > For an application that doesn't use message protection after > initial context establishment there's nothing a gss-api mechanism > can do to stop it. :) > The only means for a gssapi mechanism to indicate that a context > has expired is to fail any of the remaining calls that an application > will use once the security context has been successfully established. > These are the message protection/unprotection calls and optionally > the context_export/import calls. > > How difficult is it for a long-running application to deal gracefully > with context expiration? Somewhere from hard to extremely difficult. > An application will have to perform another context establishment > token exchange to create a new security context. The real problem > comes from context expiration while protected messages are "in transit", > be it on the wire, in network buffers or message queue(s). > Although context expiration is a good idea from the security > point of view, it is a major PITA for application protocol design > and may simply not fit under many of the existing multi-layer > application protocol stacks. > > >(2) The purpose of such a policy _really_ puzzles me. > Confidentiality during message protection is only applied when > the application asks for it when calling gss_wrap(). > Since (a) setting a no-encryption policy and (b) calling > gss_wrap() with conf_req==FALSE is both a volutary decision of > the application, why should we need an extension to implement (a) > when (b) is readily available in the base spec and working just fine? > > A while ago I met a gssapi mechanism implementor that tried to > enforce the opposite policy (i.e. always encrypt) within the > gssapi for certain users and I just laughed at him. > He tried to do so by always applying encryption when an application > called gss_wrap(), independent of the conf_request flag. > Well, our application uses gss_getmic() when configured for > integrity-only protection, and it can also be configured to > run with no message-protection at all, so the gssapi mechanism > is unable to override the application's configuration. > > > >-Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 10:52:38 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24823 for ; Tue, 19 Feb 2002 10:52:32 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA14171 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 09:42:42 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA14165 for ; Tue, 19 Feb 2002 09:42:40 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA01159 for ; Tue, 19 Feb 2002 09:42:40 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA26084; Tue, 19 Feb 2002 10:42:38 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA14526; Tue, 19 Feb 2002 10:38:51 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA07212; Tue, 19 Feb 2002 10:38:51 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA11759; Tue, 19 Feb 2002 10:38:50 -0500 (EST) To: Nicolas Williams Cc: mrex@sap-ag.de, ietf-krb-wg@anl.gov From: Derek Atkins Subject: Re: Kerb WG iakerb References: <20020215133943.O27171@sm2p1386swk.wdr.com> <200202181534.QAA11134@uw1048.wdf.sap-ag.de> <20020219100738.Y27171@sm2p1386swk.wdr.com> Date: 19 Feb 2002 10:38:50 -0500 In-Reply-To: <20020219100738.Y27171@sm2p1386swk.wdr.com> Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Nicolas Williams writes: > > Ted Ts'o once proposed a GSS-API extension to supply a callback > > function for actual credential acquisition in order to interactively > > prompt the user. Such an extension, however, might only be used > > by future applications to modify the existing (default) behaviour > > of a GSS-API mechanism. > > I'd kinda prefer not putting a callback into GSS-API and instead put in > links to other APIs (PAM on *nix, GINA on Windows). You've clearly never written any GUI-based applications, have you? > > Do you know what happens if you run some program as a Win32 > > (non-interactive) service and some function suddenly decides > > to open a dialog box expecting user input? > > Hopefully it fails. But there is no way to may it fail. In the case of callbacks, the application that runs in standalone mode can fail to supply a callback, so when GSSAPI gets to the place where it might need user input, it sees the lack-of-callback and just fails immediately. In the case of PAM integrated directly into the GSSAPI, how would it fail? Follow the same path -- the GSSAPI gets to the place where it might need user input, it calls PAM (or worse, GINA), which prompts the (non-existant) user. GSSAPI blocks, waiting for input. Your application hangs. In UI design, callbacks are ALWAYS the better approach. EVERY UI-based system uses callbacks. GSSAPI should do the same to interface into the UI. The reason: GSSAPI should not make any assumptions about what is required by the UI (or the application). > > -Martin > > Nico -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 10:52:38 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24851 for ; Tue, 19 Feb 2002 10:52:38 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA14133 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 09:42:17 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA14127 for ; Tue, 19 Feb 2002 09:42:15 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA00993 for ; Tue, 19 Feb 2002 09:42:15 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA25830 for ; Tue, 19 Feb 2002 10:42:15 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA13903 for ; Tue, 19 Feb 2002 10:36:18 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA25741 for ; Tue, 19 Feb 2002 10:36:17 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id KAA29931; Tue, 19 Feb 2002 10:36:16 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Re: Can Authorization Data be retrieved through GSSAPI? References: <200202191441.PAA13383@uw1048.wdf.sap-ag.de> From: Sam Hartman Date: 19 Feb 2002 10:36:16 -0500 In-Reply-To: Martin Rex's message of "Tue, 19 Feb 2002 15:41:43 +0100 (MET)" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "Martin" == Martin Rex writes: Martin> Sam Hartman wrote: >> >>>>> "Martin" == Martin Rex writes: >> Martin> (1) So far the Kerberos 5 GSS-API mechanism (rfc1964) is Martin> the only gssapi mechanism that I've seen that mandates Martin> context expiration. Curiously, this is a part where Martin> Microsoft's implementation doesn't comply with the spec. Martin> My wrapper DLL tries to workaround that deficiency and Martin> enforce context expiration, though. >> How would you feel about dropping this when we next revisit >> RFC 1964 to add AES support? Martin> Please leave it as it is. I'm sort of disinclined to do this, or at least am uncomfortable with expiration as short-lived as Kerberos tickets. This is particularly true since the native Kerberos protocol does not have this limit with the krb_priv or krb_safe messages. I'll be sure to talk to Jeff before proposing any change. As you point out this creates significant problems for application protocols. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 11:05:29 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25455 for ; Tue, 19 Feb 2002 11:05:28 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id JAA18917 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 09:54:02 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA18900 for ; Tue, 19 Feb 2002 09:54:00 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA02860; Tue, 19 Feb 2002 09:50:16 -0600 (CST) Message-ID: <3C727434.40C980C4@anl.gov> Date: Tue, 19 Feb 2002 09:50:12 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: Nicolas Williams , Joncheng Kuo , ietf-krb-wg@anl.gov, ietf-cat-wg@lists.stanford.edu, security-wg@gridforum.org Subject: Re: Can Authorization Data be retrieved through GSSAPI? References: <3C6D9054.2040807@syr.edu> <20020216170451.X27171@sm2p1386swk.wdr.com> <3C715283.B7D503D3@anl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Sam Hartman wrote: > > >>>>> "Douglas" == Douglas E Engert writes: > > Douglas> It defines a gss_inquire_context_by_oid to allow access > Douglas> to additional mech specifiy information. The authz data > Douglas> could be one of these. > > Why is this work going on in terms of Grid Form rather than IETF. I > thought they implied they wanted to work with us at a recent meeting. > I'd think part of that would be submitting extensions to IETF > standards to the IETF especially when such extensions were not > specific to their needs. In regards to: http://www.gridforum.org/security/ggf3_2001-10/drafts/draft-ggf-gss-extensions-04.pdf We are working with the IETF. In Minneapolis last year we discussed this with the CAT WG chair to try and get the CAT group interested, but there has not been any CAT group meetings since. We would still like to get the CAT group involved. The GGF security work: http://www.gridforum.org/2_SEC/GSI.htm is based on the Globus Project(tm) http://www.globus.org security component, GSI, which implements a GSS-API over the SSL/TLS protocol with X509 certificates with mutual authentication and delegation. We found that there where a number of missing features from the GSS-API specification which we needed in order to avoid calling the GSI directly, thus subverting the concepts of a GSS. There are additional security drafts from the GGF which are also in the IETF, in particular, "Internet X.509 Public Key Infrastructure Proxy Certificate Profile" http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-01.txt This formalizes the certificates which are used for delegation with the GSS-API. This has received a lot of attention, and we has presented this at least twice. We have submitted to the TLS group some extensions to TLS to allow an additional message type for delegation. I gave a 5 minute presentation in London on this. We have not pushed any of these concepts via the KRB-WG. As you know, the members of the group are very busy with "Clarifications" and "Extensions". But we would like to see these same extensions work with Kerberos too. We have also been active in the SECSH group making sure GSSAPI was added so we could use the GSI with SSH via GSSAPI. I believe we have, in some way, presented every part of the GGF security work at the IETF. This work, http://www.gridforum.org/2_SEC/GSI.htm is based on the Globus Project(tm) http://www.globus.org security component, GSI, which implements a GSS-API over the SSL/TLS protocol with X509 certificates with mutual authentication and delegation. So I would say that the GGF has been working with the IETF, but sometimes it is hard to get the IETF members to listen. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 11:12:44 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25737 for ; Tue, 19 Feb 2002 11:12:44 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA23069 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 10:02:32 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA22884 for ; Tue, 19 Feb 2002 10:02:30 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA06190 for ; Tue, 19 Feb 2002 10:02:29 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id KAA08574; Tue, 19 Feb 2002 10:59:51 -0500 (EST) Received: from (twelve.ubswarburg.com [192.168.0.6]) by gate via smap (V2.0) id xma004315; Tue, 19 Feb 2002 10:54:13 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan3 [192.168.0.6]) by virscan3.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA15348; Tue, 19 Feb 2002 10:50:09 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA05541; Tue, 19 Feb 2002 10:50:46 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id KAA22144; Tue, 19 Feb 2002 10:49:30 -0500 (EST) Date: Tue, 19 Feb 2002 10:49:30 -0500 From: Nicolas Williams To: Derek Atkins Cc: mrex@sap-ag.de, ietf-krb-wg@anl.gov Subject: Re: Kerb WG iakerb Message-ID: <20020219104929.A27171@sm2p1386swk.wdr.com> Mail-Followup-To: Derek Atkins , mrex@sap-ag.de, ietf-krb-wg@anl.gov References: <20020215133943.O27171@sm2p1386swk.wdr.com> <200202181534.QAA11134@uw1048.wdf.sap-ag.de> <20020219100738.Y27171@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from derek@ihtfp.com on Tue, Feb 19, 2002 at 10:38:50AM -0500 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Tue, Feb 19, 2002 at 10:38:50AM -0500, Derek Atkins wrote: > Nicolas Williams writes: > > I'd kinda prefer not putting a callback into GSS-API and instead put in > > links to other APIs (PAM on *nix, GINA on Windows). > > You've clearly never written any GUI-based applications, have you? I don't get this comment. Plenty of GUI apps deal with PAM just fine. What's the problem? Note that I didn't say I don't want callbacks at all, just not in GSS-API :) > > > Do you know what happens if you run some program as a Win32 > > > (non-interactive) service and some function suddenly decides > > > to open a dialog box expecting user input? > > > > Hopefully it fails. > > But there is no way to may it fail. In the case of callbacks, the > application that runs in standalone mode can fail to supply a > callback, so when GSSAPI gets to the place where it might need user > input, it sees the lack-of-callback and just fails immediately. > > In the case of PAM integrated directly into the GSSAPI, how would it > fail? Follow the same path -- the GSSAPI gets to the place where it > might need user input, it calls PAM (or worse, GINA), which prompts > the (non-existant) user. GSSAPI blocks, waiting for input. Your > application hangs. With PAM the app has to provide the conversation callback function for prompting and presumably the app will know if it has a display or TTY on which to do the prompting. If the app is running as a daemon and assuming it was started correctly then it will have neither a TTY nor a display (X11 or otherwise). > > > -Martin > > > > Nico > > -derek Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 11:21:51 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26040 for ; Tue, 19 Feb 2002 11:21:51 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA23548 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 10:04:05 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA23537; Tue, 19 Feb 2002 10:04:03 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA06476; Tue, 19 Feb 2002 10:04:02 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id LAA21775; Tue, 19 Feb 2002 11:07:05 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma019004; Tue, 19 Feb 2002 11:02:53 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA19692; Tue, 19 Feb 2002 10:58:11 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA15802; Tue, 19 Feb 2002 10:59:26 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id KAA22268; Tue, 19 Feb 2002 10:58:05 -0500 (EST) Date: Tue, 19 Feb 2002 10:58:04 -0500 From: Nicolas Williams To: Von Welch Cc: mrex@sap-ag.de, "Douglas E. Engert" , ietf-krb-wg@anl.gov Subject: Re: Can Authorization Data be retrieved through GSSAPI? Message-ID: <20020219105803.B27171@sm2p1386swk.wdr.com> Mail-Followup-To: Von Welch , mrex@sap-ag.de, "Douglas E. Engert" , ietf-krb-wg@anl.gov References: <3C715283.B7D503D3@anl.gov> <200202191123.MAA12853@uw1048.wdf.sap-ag.de> <5.1.0.14.2.20020219090052.02a108f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <5.1.0.14.2.20020219090052.02a108f0@localhost>; from welch@mcs.anl.gov on Tue, Feb 19, 2002 at 09:21:31AM -0600 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Tue, Feb 19, 2002 at 09:21:31AM -0600, Von Welch wrote: > > Martin, Sam- > > In response to your specific comments, our attempt to standardize behavior > on context expiration is just an attempt to standardize the behavior of the > wrap/unwrap calls when context expires and to give the application a way to > control this. The idea being that some sites might want to know when the > context expires, but finish some action (e.g. a file transfer in progress) > before disallowing further activity. As long as the app can reset the option so that the wrap functions are re-anabled after context expiration for the purpose of completing operations in-progress. > The idea behind disabling of encryption is that this allows an application > to disable encryption for some policy reason, even if the mechanism > supports it. By doing so before context setup, this allows the client to > gracefully know this before a wrap call fails. Honestly, we threw this in > as a "seems like a good idea". Sounds like GSS-level negotiation of app-level issues. It would need changes to the existing mechs to be useful. Whereas a generic feature negotiation framework might be useful (particularly if it can work with optimistic mech negotiation and one-round-trip mechs), this seems like too specific a feature. > Von Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 11:24:16 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26151 for ; Tue, 19 Feb 2002 11:24:16 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA24754 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 10:06:43 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA24748 for ; Tue, 19 Feb 2002 10:06:42 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA07117 for ; Tue, 19 Feb 2002 10:06:41 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA28772 for ; Tue, 19 Feb 2002 11:06:41 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA09833 for ; Tue, 19 Feb 2002 11:06:41 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA19745 for ; Tue, 19 Feb 2002 11:03:09 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id LAA29960; Tue, 19 Feb 2002 11:03:09 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Re: Can Authorization Data be retrieved through GSSAPI? References: <200202191441.PAA13383@uw1048.wdf.sap-ag.de> From: Sam Hartman Date: 19 Feb 2002 11:03:08 -0500 In-Reply-To: Sam Hartman's message of "19 Feb 2002 10:36:16 -0500" Message-ID: Lines: 29 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk >>>>> "Sam" == Sam Hartman writes: >>>>> "Martin" == Martin Rex writes: Martin> Sam Hartman wrote: >>> >>>>> "Martin" == Martin Rex writes: >>> Martin> (1) So far the Kerberos 5 GSS-API mechanism (rfc1964) is Martin> the only gssapi mechanism that I've seen that mandates Martin> context expiration. Curiously, this is a part where Martin> Microsoft's implementation doesn't comply with the spec. Martin> My wrapper DLL tries to workaround that deficiency and Martin> enforce context expiration, though. >>> How would you feel about dropping this when we next revisit >>> RFC 1964 to add AES support? Martin> Please leave it as it is. Sam> I'm sort of disinclined to do this, or at least am Sam> uncomfortable with expiration as short-lived as Kerberos Sam> tickets. This is particularly true since the native Kerberos Sam> protocol does not have this limit with the krb_priv or Sam> krb_safe messages. To clarify, I don't tmhink I could follow the spec if I were trying to sell Kerberos. MIT can get away with following the spec because we can more effectively use security arguments to explain why we aren't meeting customer needs than we could if we were getting money from customers. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 11:24:42 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26186 for ; Tue, 19 Feb 2002 11:24:42 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA27645 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 10:14:14 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA27639 for ; Tue, 19 Feb 2002 10:14:13 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA08889 for ; Tue, 19 Feb 2002 10:14:12 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08872; Tue, 19 Feb 2002 11:14:11 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA12472; Tue, 19 Feb 2002 11:14:10 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA28537; Tue, 19 Feb 2002 11:14:09 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA11849; Tue, 19 Feb 2002 11:14:09 -0500 (EST) To: Nicolas Williams Cc: mrex@sap-ag.de, ietf-krb-wg@anl.gov From: Derek Atkins Subject: Re: Kerb WG iakerb References: <20020215133943.O27171@sm2p1386swk.wdr.com> <200202181534.QAA11134@uw1048.wdf.sap-ag.de> <20020219100738.Y27171@sm2p1386swk.wdr.com> <20020219104929.A27171@sm2p1386swk.wdr.com> Date: 19 Feb 2002 11:14:09 -0500 In-Reply-To: <20020219104929.A27171@sm2p1386swk.wdr.com> Message-ID: Lines: 80 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Nicolas Williams writes: > On Tue, Feb 19, 2002 at 10:38:50AM -0500, Derek Atkins wrote: > > Nicolas Williams writes: > > > I'd kinda prefer not putting a callback into GSS-API and instead put in > > > links to other APIs (PAM on *nix, GINA on Windows). > > > > You've clearly never written any GUI-based applications, have you? > > I don't get this comment. Plenty of GUI apps deal with PAM just fine. > What's the problem? The comment was regarding using callbacks in UI-independent libraries that need UI interaction. > Note that I didn't say I don't want callbacks at all, just not in > GSS-API :) That's not what you said.. See quote above. Also, you are now adding a dependency of PAM to _ALL_ your applications, even if they don't want one. You're now saying that every single gssapi application needs to initialize PAM before it calls gssapi? That seems even more broken then providing a single gssapi callback: int (*gss_new_initial_cred) (void *user_data); Note that this API probably needs the be expanded a bit, maybe to include the requested gss name. > With PAM the app has to provide the conversation callback function for > prompting and presumably the app will know if it has a display or TTY on > which to do the prompting. If the app is running as a daemon and > assuming it was started correctly then it will have neither a TTY nor a > display (X11 or otherwise). So you want to add this PAM dependency to _ALL_ applications? That seems kind of broken (or at least extremely unkind). It would certainly break all previous applications that didn't use PAM. Supplying a GSS callback is more programmer friendly. The application can use PAM if it wants to, but GSSAPI should not require it. > Nico -derek PS: ... > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. ... can you turn this crap off when sending to mailing lists? -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 11:38:06 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26550 for ; Tue, 19 Feb 2002 11:38:06 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA01876 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 10:27:55 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA01846 for ; Tue, 19 Feb 2002 10:27:53 -0600 (CST) Received: from gate2.stm.ubswarburg.com (gate2.stm.ubswarburg.com [151.191.1.12]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA12225 for ; Tue, 19 Feb 2002 10:27:52 -0600 (CST) Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id LAA13228; Tue, 19 Feb 2002 11:25:40 -0500 (EST) Received: from (nine.ubswarburg.com [192.168.0.4]) by gate2 via smap (V2.0/ubsw) id xma013132; Tue, 19 Feb 2002 11:25:27 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA16379; Tue, 19 Feb 2002 11:22:01 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA15525; Tue, 19 Feb 2002 11:25:27 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id LAA22433; Tue, 19 Feb 2002 11:24:11 -0500 (EST) Date: Tue, 19 Feb 2002 11:24:10 -0500 From: Nicolas Williams To: Derek Atkins Cc: mrex@sap-ag.de, ietf-krb-wg@anl.gov Subject: Re: Kerb WG iakerb Message-ID: <20020219112409.C27171@sm2p1386swk.wdr.com> Mail-Followup-To: Derek Atkins , mrex@sap-ag.de, ietf-krb-wg@anl.gov References: <20020215133943.O27171@sm2p1386swk.wdr.com> <200202181534.QAA11134@uw1048.wdf.sap-ag.de> <20020219100738.Y27171@sm2p1386swk.wdr.com> <20020219104929.A27171@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from derek@ihtfp.com on Tue, Feb 19, 2002 at 11:14:09AM -0500 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Tue, Feb 19, 2002 at 11:14:09AM -0500, Derek Atkins wrote: > Nicolas Williams writes: > > > On Tue, Feb 19, 2002 at 10:38:50AM -0500, Derek Atkins wrote: > > > Nicolas Williams writes: > > > > I'd kinda prefer not putting a callback into GSS-API and instead put in > > > > links to other APIs (PAM on *nix, GINA on Windows). > > > > > > You've clearly never written any GUI-based applications, have you? > > > > I don't get this comment. Plenty of GUI apps deal with PAM just fine. > > What's the problem? > > The comment was regarding using callbacks in UI-independent libraries > that need UI interaction. > > > Note that I didn't say I don't want callbacks at all, just not in > > GSS-API :) > > That's not what you said.. See quote above. That is what I said. Re-read it please: "I'd kinda prefer not putting a callback into GSS-API and instead put in links to other APIs (PAM on *nix, GINA on Windows)." PAM works with GUIs (it has a callback API). So does GINA. What I meant by "put in links to other APIs", was to have an API to associate a PAM context with a GSS context so that when creds are needed the GSS-API can just call PAM with the app-provided context. > Also, you are now adding a dependency of PAM to _ALL_ your > applications, even if they don't want one. You're now saying that > every single gssapi application needs to initialize PAM before it > calls gssapi? That seems even more broken then providing a single > gssapi callback: I have some experience with PAM. I think it's very easy to design a prompter API that is not general enough. I think it's not worth re-inventing the wheel. > int (*gss_new_initial_cred) (void *user_data); > > Note that this API probably needs the be expanded a bit, maybe to > include the requested gss name. That's an understatement. > So you want to add this PAM dependency to _ALL_ applications? That > seems kind of broken (or at least extremely unkind). It would > certainly break all previous applications that didn't use PAM. It doesn't break them. Currently apps can't get new initiator creds when they expire, not through the GSS-API anyways. > Supplying a GSS callback is more programmer friendly. The application > can use PAM if it wants to, but GSSAPI should not require it. Design it right... > ... can you turn this crap off when sending to mailing lists? I wish. Some list maintainers have asked me to abstain or use an off-work mailbox. I can do that, but I can't participate as much that way. > -derek > Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 12:07:04 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27749 for ; Tue, 19 Feb 2002 12:07:03 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA10645 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 10:56:32 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA10639 for ; Tue, 19 Feb 2002 10:56:31 -0600 (CST) Received: from lin2.andrew.cmu.edu (LIN2.ANDREW.CMU.EDU [128.2.6.35]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA19060 for ; Tue, 19 Feb 2002 10:56:31 -0600 (CST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.2.Beta3/8.12.2.Beta3) with ESMTP id g1JGt6rF014564; Tue, 19 Feb 2002 11:55:06 -0500 Date: Tue, 19 Feb 2002 11:55:06 -0500 Message-Id: <200202191655.g1JGt6rF014564@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: ietf-krb-wg@anl.gov Subject: constructing service principals Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Clients trying to construct service principals is a huge problem that leads to current interoperability problems with Kerberos. * The "standard" situation as it is today: RFC 2743 (GSS) gives an "example" of canonicalizing which is followed by some Kerberos implementations. Sadly, even this example is incomplete: When a reference to a name of this type is resolved, the "hostname" may (as an example implementation strategy) be canonicalized by attempting a DNS lookup and using the fully-qualified domain name which is returned, or by using the "hostname" as provided if the DNS lookup fails. The canonicalization operation also maps the host's name into lower-case characters. Does "attempting a DNS lookup" mean doing a forward lookup (chasing any CNAMEs) or doing a forward lookup followed by a reverse lookup? In our Kerberos 4 implementation (KTH) only a forward is done. In our Kerberos 5 implementation (Heimdal) both a forward and a reverse are done. * Proposed changes? The latest Kerberos revisions draft (draft-ietf-cat-kerberos-revisions-10) has a footnote with the following: 2.2 It is important that the KDC be sent the name as typed by the user, and not only the canonical form of the name. If the domain name system was used to find the canonical name on the client side, the mapping is vulnerable. It's unclear to me where this footnote is referenced. This directly contradicts the "example" in RFC 2743. It is also not clear if it is normative. * Current implementations We have three Kerberos 5 implementations in production here at Computing Services at CMU. All three construct service principals differently: . Heimdal does a forward DNS lookup, a reverse DNS lookup, and then downcases the resulting string. . Microsoft performs no canonicalization on the client. . Sun Java JDK 1.4 does a forward DNS lookup, a reverse DNS lookup, and then uses the resulting string with no further modifications. Needless to say, this causes interoperability headaches today. * What should be done? Hopefully, this is something that clarifications can help with. I believe that footnote 2.2 should be moved into the body of the text. It should be made explicitly normative (as at least a SHOULD and possibly a MUST) and should explicitly say that "when Kerberos is used under a GSS mechanism with host-based service naming, no canonicalization is done". Larry From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 12:08:25 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27804 for ; Tue, 19 Feb 2002 12:08:25 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA11091 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 10:58:12 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA11085 for ; Tue, 19 Feb 2002 10:58:10 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA19394 for ; Tue, 19 Feb 2002 10:58:09 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA10069; Tue, 19 Feb 2002 18:01:41 +0100 (MEZ) From: Martin Rex Message-Id: <200202191657.RAA13791@uw1048.wdf.sap-ag.de> Subject: Re: Kerb WG iakerb To: Nicolas.Williams@ubsw.com (Nicolas Williams) Date: Tue, 19 Feb 2002 17:57:33 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <20020219100738.Y27171@sm2p1386swk.wdr.com> from "Nicolas Williams" at Feb 19, 2 10:07:39 am Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > If one were to add some extensions to the GSS-API C bindings in some > implementation one might still be compliant with RFC2078 even if not > with the bindings RFCs. Of course, to the extent that RFC2744 and 2078 > disagree today it's hard to be compliant with both (e.g., name string > encodings). WHAT? I doubt that there is any real incompatibility between RFC2078 and RFC2743 (RFC2744 is the C-Bindinds document). RFC2743 is only more precise and more consistent. > > There is sentiment that the IETF should not be in the business of > designing APIs. That said, the spirit of GSS-API, namely the bits about > context setup, IMO is worth codifying. Other protocols making use of GSS > generally concentrate on the use of gss_init_sec_context() and > gss_accept_sec-context() and perhaps they specify service naming, but no > such protocols would be broken if an implementation adds a GSS-API > extension for authz data handling, say (though better signalling of > authentication vs. authorization errors might be appreciated). This is just out of experience: - a spec that covers an API is more complex and more prone to discussion than a simple on-the-wire spec - normally the IETF wants to get specs completed within 12-18 months. for APIs this has turned out to be close to impossible. even for complex on-the-wire protocols (Kerberos, IPsec) this turns out to be impossible - it requires a lot of (and a wide scope of) experience to design an abstract API that does not artificially limit the freedom of the implementors, and there are very few engineers with the necessary background involved in the IETF working groups. > > Yes. Well. It seems we have to make some serious trade-offs for that to > work. E.g., authorization data is hard to abstract, as you point out. > And so is credentials handling, and other fun stuff. The GSS-API abstraction of credentials works just fine. > > Some bits of such an API as GSS will have to be fuzzy in order to be > workable. Does that mean #ifdefs in portable code? Yeah. Can such an API > still help on the portability front? Yes. Huh? Truely Portable code means no #ifdefs for any platform and no #ifdefs for any gssapi mechanism and no app code changes for using new gssapi mechanisms with already installed apps. > > > GSS-API mechanisms (which define on-the-wire) were supposed to be > > rev'able and replacable as a design feature of GSS-API from the > > beginning. In reality, lacking a negotiation and/or migration > > support in the base requirements for GSS-API mechanisms often > > makes it difficult to actually replace a mechanism within an > > installed base, requiring either a mechanism itself to provide > > interoperability with its successor (version) or a flag day. > > Right, so let's agree that an API such as GSS-API can help portability, > but can't be a complete panacea and let's accept that some mechanism- > and implementation-specific mods are needed. No, in general they aren't. You're confusing portable applications with formerly native-API applications that try to minimize migration pains to new releases by switching to GSS-API where possible and mixing in native-API where this is not possible. I have no problem with native APIs of a mechanism accepting gssapi datatypes, but polluting GSS-API with implementation specific data types and semantics is not a good idea. > > > Ted Ts'o once proposed a GSS-API extension to supply a callback > > function for actual credential acquisition in order to interactively > > prompt the user. Such an extension, however, might only be used > > by future applications to modify the existing (default) behaviour > > of a GSS-API mechanism. > > I'd kinda prefer not putting a callback into GSS-API and instead put in > links to other APIs (PAM on *nix, GINA on Windows). That's the only possibility to make it work portably with gssapi and it's also the only possibility to limit the exposure of longterm credentials to the absolute minimum. > > > Do you know what happens if you run some program as a Win32 > > (non-interactive) service and some function suddenly decides > > to open a dialog box expecting user input? > > Hopefully it fails. No, it stalls forever -- the popup is displayed on a virtual desktop that is not visible/accessible to the interactive user(s). no-interactive Win32 services reading STDIN are also stalled forever. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 13:04:22 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29593 for ; Tue, 19 Feb 2002 13:04:21 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id LAA26761 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 11:53:42 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA26750; Tue, 19 Feb 2002 11:53:41 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA01817; Tue, 19 Feb 2002 11:53:39 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA20720; Tue, 19 Feb 2002 18:56:42 +0100 (MEZ) From: Martin Rex Message-Id: <200202191752.SAA13988@uw1048.wdf.sap-ag.de> Subject: Re: Can Authorization Data be retrieved through GSSAPI? To: welch@mcs.anl.gov (Von Welch) Date: Tue, 19 Feb 2002 18:52:34 +0100 (MET) Cc: mrex@sap-ag.de, deengert@anl.gov, ietf-krb-wg@anl.gov In-Reply-To: <5.1.0.14.2.20020219090052.02a108f0@localhost> from "Von Welch" at Feb 19, 2 09:21:31 am Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Von Welch wrote: > > Martin - in reponse to your comments, I would much rather address your > issues of this being mechanism specific than say this is mechanism > specific. We (the authors) have a fair amount of Kerberos experience > between us and we've tried very hard to at least keep that mechanism in > mind when laying out this document since working over it is also serious > interest to our project. Could give some specific examples of what you > think are mechanism-specific attributes? I meant to imply that your proposed extensions are *implementation* specific, which is actually worse that being mechanism-specific. When I wrote my wrapper DLL for Microsoft's W2K Kerberos SSP I would have gladly added support for MIT Kerberos keytab -- if there was just an API that allowed me to stuff such credentials into W2K Kerberos -- however there isn't. Some of descriptions in the purpose of the calls confuse me, like the purpose of gss_export_cred()/gss_import_cred(). Although the description makes it sound like a gssapi based app would have some need to export and re-import credentials, this concept is actually totally alien to portable applications and places significant implementation constraints on the nature of credentials. As it is designed, individual credentials are distinguished by (a) the identity they're able to authenticate and optionally (b) the gssapi mechanism (OID) for which they are usable. With the regular GSS-API v2 functionality a portable application can already manage _and_ use an arbitrary number of credentials today. The proposed change for gss_init_sec_context()/gss_accept_sec_context() to accept an initial non-NULL context handle prefilled with policy options would be a significant backwards-incompatible change to the existing GSS-API (and always require significant app code changes to use those features). For the initiator side you could alternatively try to use context-options to indicate your additional desires, which then would be safely ignored by mechanisms that don't implement it and which would would not confuse an existing SPNEGO in between. On the acceptor side I would rather prefer an alternative gss_accept_sec_context_2() that takes context options as an additional input parameter. The original designers probably thought that it would be ok if the acceptor just participated the full handshake and decided after security context establishment whether the result complies with its policy... > > In response to your specific comments, our attempt to standardize behavior > on context expiration is just an attempt to standardize the behavior of the > wrap/unwrap calls when context expires and to give the application a way to > control this. The idea being that some sites might want to know when the > context expires, but finish some action (e.g. a file transfer in progress) > before disallowing further activity. My preferred approach would be to create additional informatory major_status return codes that would be pair-able with either GSS_S_FAILURE or GSS_S_COMPLETE in order to indicate whether there is an advisory or enforced context expiration on the message protection calls, similar to the change that I requested for the message sequencing errors -- just that the sequencing errors were informatory from the beginning and the context expiration has always been a fatal error code. (side note: when a gssapi mechanism actually wants to implement advisory sequencing errors instead of fatal sequencing errors, then it is quite difficult to decide when to stop returning sequencing-related informatory status bits after a sequencing error ...) > > The idea behind disabling of encryption is that this allows an application > to disable encryption for some policy reason, even if the mechanism > supports it. By doing so before context setup, this allows the client to > gracefully know this before a wrap call fails. Honestly, we threw this in > as a "seems like a good idea". Huh? before a wrap call fails? I don't understand, what is that supposed to mean? gss_wrap() will not fail when encryption is requested but not available, it must succeed and return conf_flag==FALSE as long as integrity is available on the security context. getmic()/verifymic() as well as wrap()/unwrap() will work as long as context establishment returns the context flag for availability of integrity protection (GSS_C_INTEG_FLAG?). -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 13:38:04 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00823 for ; Tue, 19 Feb 2002 13:38:04 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA07088 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 12:27:38 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA07069 for ; Tue, 19 Feb 2002 12:27:36 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA08858 for ; Tue, 19 Feb 2002 12:27:36 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA09119; Tue, 19 Feb 2002 19:31:11 +0100 (MEZ) From: Martin Rex Message-Id: <200202191827.TAA14075@uw1048.wdf.sap-ag.de> Subject: Re: Can Authorization Data be retrieved through GSSAPI? To: hartmans@mit.edu (Sam Hartman) Date: Tue, 19 Feb 2002 19:27:02 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: from "Sam Hartman" at Feb 19, 2 11:03:08 am Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > To clarify, I don't think I could follow the spec if I were trying to > sell Kerberos. MIT can get away with following the spec because we > can more effectively use security arguments to explain why we aren't > meeting customer needs than we could if we were getting money from > customers. To clarify my standpoint: Although I know it is difficult to deal with it at the application level (and I tried to explain why), I still think the requirement is ok and should be kept. We sold/shipped our application to MIT in 1996 and of course, they're using their own Kerberos as their gssapi mechanism and it enforces context expiration, so I had to deal with it at the application level. :) The current code is not perfect and I should improve one rough edge one of these days, but it seems to be working. At least I haven't received any complaints so far (once the discovered how it works and that they need to refresh their tickets before they expire in order to make the automatic refresh work. I'm sure, if you allow application designers/implementors to effectively ignore context expiration, almost every implementor an in particular all commercial vendors will *not* implement provisions for a context renegotiation to refresh the session key, resulting in exactly those long-lived session keys that Jeff wants to prevent. And for multi-threaded synchronus applications the additional complexity in implementing context refresh is comparatively small (when compared to the necessary complexity for asynchronus non-blocking applications). Our application is asynchronous non-blocking and I know it is doable. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 19 14:14:17 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01868 for ; Tue, 19 Feb 2002 14:14:17 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA15589 for ietf-krb-wg-outgoing; Tue, 19 Feb 2002 12:58:24 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA15583 for ; Tue, 19 Feb 2002 12:58:23 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA15138 for ; Tue, 19 Feb 2002 12:58:22 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id OAA14725; Tue, 19 Feb 2002 14:01:33 -0500 (EST) Received: from (twelve.ubswarburg.com [192.168.0.6]) by gate via smap (V2.0) id xma012749; Tue, 19 Feb 2002 13:59:22 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan3 [192.168.0.6]) by virscan3.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA00052; Tue, 19 Feb 2002 13:55:24 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA05526; Tue, 19 Feb 2002 13:55:47 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id NAA23647; Tue, 19 Feb 2002 13:54:31 -0500 (EST) Date: Tue, 19 Feb 2002 13:54:31 -0500 From: Nicolas Williams To: mrex@sap-ag.de Cc: ietf-krb-wg@anl.gov Subject: Re: Kerb WG iakerb Message-ID: <20020219135430.D27171@sm2p1386swk.wdr.com> Mail-Followup-To: mrex@sap-ag.de, ietf-krb-wg@anl.gov References: <20020219100738.Y27171@sm2p1386swk.wdr.com> <200202191657.RAA13791@uw1048.wdf.sap-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200202191657.RAA13791@uw1048.wdf.sap-ag.de>; from martin.rex@sap-ag.de on Tue, Feb 19, 2002 at 05:57:33PM +0100 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Tue, Feb 19, 2002 at 05:57:33PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > If one were to add some extensions to the GSS-API C bindings in some > > implementation one might still be compliant with RFC2078 even if not > > with the bindings RFCs. Of course, to the extent that RFC2744 and 2078 > > disagree today it's hard to be compliant with both (e.g., name string > > encodings). > > WHAT? I was referring to minor, yes minor issues like different char sets for gss names. I thought this had been discussed before. And we have to keep in mind that Kerberos i18n will require GSS-API i18n eventually. > > Yes. Well. It seems we have to make some serious trade-offs for that to > > work. E.g., authorization data is hard to abstract, as you point out. > > And so is credentials handling, and other fun stuff. > > The GSS-API abstraction of credentials works just fine. Really? Then why is it that the GSS-for-OpenSSH patches have to go to such troubles to create ccaches? [...] > I have no problem with native APIs of a mechanism accepting > gssapi datatypes, but polluting GSS-API with implementation > specific data types and semantics is not a good idea. Why? As long as those implementation specific data types are treated as opaque pointers and the semantics are simple then it should be tolerable. I think that's fine for ccache stuff and for authorization data, ticket extensions, etc... I can't imagine an easy to use generic C interface to authorization data. > > > Do you know what happens if you run some program as a Win32 > > > (non-interactive) service and some function suddenly decides > > > to open a dialog box expecting user input? > > > > Hopefully it fails. > > No, it stalls forever -- the popup is displayed on a virtual desktop > that is not visible/accessible to the interactive user(s). Oh, that's too bad. > no-interactive Win32 services reading STDIN are also stalled forever. > > > -Martin Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 02:06:05 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23910 for ; Wed, 20 Feb 2002 02:06:05 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id AAA24971 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 00:55:26 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id AAA24965 for ; Wed, 20 Feb 2002 00:55:25 -0600 (CST) Received: from TheWorld.com (pcls3.std.com [199.172.62.105]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id AAA27916 for ; Wed, 20 Feb 2002 00:55:25 -0600 (CST) Received: from host3sy2bx4q (ppp0b167.std.com [208.192.101.167]) by TheWorld.com (8.9.3/8.9.3) with SMTP id BAA02063; Wed, 20 Feb 2002 01:55:20 -0500 Message-ID: <002201c1b9da$dff578a0$01e8a8c0@host3sy2bx4q> From: "Jonathan Trostle" To: Cc: References: <200202141027.LAA14679@uw1048.wdf.sap-ag.de> Subject: Re: Kerb WG iakerb Date: Tue, 19 Feb 2002 22:50:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Martin Rex" To: "Jonathan Trostle" Cc: Sent: Thursday, February 14, 2002 2:27 AM Subject: Re: Kerb WG iakerb > > Jonathan Trostle wrote: > > > > > > > > IAKERB reverses the context establishment between user and IAKERB proxy, > > > so it requires the KDC to issue a service ticket encrypted in the > > > user's long term secret. > > > > The ticket that is targetted at the user is encrypted in the session key > > from the ticket that the user sends to the proxy for the TGS case. Same for > > the AS case, except the proxy obtains the ticket from the AS exchange. The > > fastest way to see this is to look at the diagrams in the spec. > > You mean that it is a user2user authentication? Right. Jonathan > > No, I didn't see that from the diagrams. But as I've mentioned > before, I'm not deeply intimate with Kerberos, just with GSS-API. > > -Martin > From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 02:09:16 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23948 for ; Wed, 20 Feb 2002 02:09:16 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id AAA25356 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 00:57:01 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id AAA25347 for ; Wed, 20 Feb 2002 00:56:59 -0600 (CST) Received: from TheWorld.com (pcls3.std.com [199.172.62.105]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id AAA28091 for ; Wed, 20 Feb 2002 00:56:59 -0600 (CST) Received: from host3sy2bx4q (ppp0b167.std.com [208.192.101.167]) by TheWorld.com (8.9.3/8.9.3) with SMTP id BAA03247; Wed, 20 Feb 2002 01:56:54 -0500 Message-ID: <002801c1b9db$184cfe80$01e8a8c0@host3sy2bx4q> From: "Jonathan Trostle" To: "Nicolas Williams" , Cc: References: <001801c1b4b5$f585c730$01e8a8c0@host3sy2bx4q> <200202131847.TAA11542@uw1048.wdf.sap-ag.de> <20020215133943.O27171@sm2p1386swk.wdr.com> Subject: Re: Kerb WG iakerb Date: Tue, 19 Feb 2002 22:51:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Nicolas Williams" To: Cc: "Jonathan Trostle" ; Sent: Friday, February 15, 2002 10:39 AM Subject: Re: Kerb WG iakerb > There's no reason why one could not design an API that includes the > ability to prompt the user, like PAM, say, for whatever passwords and > tokens are needed and *still* be compliant with GSS-API on the wire. > > GSS-API and GSS-API bindings are not the same thing. > > :) > > That said, the default behaviour by most implementations can probably be > relied upon to be password-caching. Sigh. It's not needed for IAKERB. No long term access to the user's password is needed. Jonathan > > Nico > > > On Wed, Feb 13, 2002 at 07:47:33PM +0100, Martin Rex wrote: > > > > I don't see how you could change that as long as the IAKERB proxy > > uses a service ticket addressed at the user principal encrypted > > with the user's longterm key. GSS-API doesn't have means to > > set or request a password/secret for acquisition of credentials > > or establishment of a security context so the long term secret needs > > to be supplied to IAKERB outside of the GSS-API and cached so > > that when an application is launched and requests the IAKERB > > mechanism the message exchange can actually be performed. > > > > > > -Martin > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 07:18:25 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28110 for ; Wed, 20 Feb 2002 07:18:24 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id GAA10642 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 06:08:06 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id GAA10620 for ; Wed, 20 Feb 2002 06:08:04 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id GAA16510 for ; Wed, 20 Feb 2002 06:08:04 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id NAA03142; Wed, 20 Feb 2002 13:10:54 +0100 (MEZ) From: Martin Rex Message-Id: <200202201206.NAA15633@uw1048.wdf.sap-ag.de> Subject: Re: Kerb WG iakerb To: Nicolas.Williams@ubsw.com (Nicolas Williams) Date: Wed, 20 Feb 2002 13:06:46 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <20020219135430.D27171@sm2p1386swk.wdr.com> from "Nicolas Williams" at Feb 19, 2 01:54:31 pm Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > I was referring to minor, yes minor issues like different char sets for > gss names. I thought this had been discussed before. Huh? There is *no* difference in rfc2078 and rfc2743 in this area. > > And we have to keep in mind that Kerberos i18n will require GSS-API i18n > eventually. i18n support requires only some trivial definitions to be added to GSS-API. There are only very few "printables" in the GSS-API spec anyways: (1) names from gss_display_name() and for gss_import_name() (2) error messages from gss_display_status() Printable Names are already tagged with "Nametype OIDs", so defining additional OIDs for UTF8-encoding should take care of that. Since gss_display_status() also takes an input parameter "status_type" to indicate whether to translate a minor or a major status code, this input parameter could be extended with "major_utf8" and "minor_utf8". The only remaining problem would be to predetermine whether gss_display_name() should be required to return the regular plain-ascii variant for plain-ascii names for updates of a gssapi mechanism that wants to keep its mechanism OID unchanged. > > > > Yes. Well. It seems we have to make some serious trade-offs for that to > > > work. E.g., authorization data is hard to abstract, as you point out. > > > And so is credentials handling, and other fun stuff. > > > > The GSS-API abstraction of credentials works just fine. > > Really? Then why is it that the GSS-for-OpenSSH patches have to go to > such troubles to create ccaches? create ccaches? Wait a minute, that sounds like an extremely implementation specific type of thing. This smells baaaaad. I haven't seen what they do, so I can just guess what they're trying to accomplish: GSS-API has only very simplistic support for credential delegation, and maybe they're trying to write a delegated credential out to a file _above_ the gssapi mechanism level -- which would definitely be an extremely broken design. Whether or not a delegated credential should be written out to a permanent storage so that remains available after the delegated_cred handle has been passed to gss_release_cred(), and similarily whether a delegated credential becomes available to other processes through this is a completely local matter of every individual gssapi mechanism implementation (both in policy and data format). Same for the management and cleanup of (delegated) credentials -- this is explicitly outside of the scope of GSS-API. Implementation specific means that it doesn't need to be the same for two independent implementations of the *same* gssapi mechanism, and as I've said before, you will have serious problems trying to push MIT-Kerberos internal representations of data into Microsoft's W2K Kerberos. > > [...] > > > I have no problem with native APIs of a mechanism accepting > > gssapi datatypes, but polluting GSS-API with implementation > > specific data types and semantics is not a good idea. > > Why? As long as those implementation specific data types are treated as > opaque pointers and the semantics are simple then it should be > tolerable. I think that's fine for ccache stuff and for authorization > data, ticket extensions, etc... I can't imagine an easy to use generic > C interface to authorization data. No, it is not! Leave the native data at the native API. Don't pollute the generic API with lots of native API data that will be very implementation specific and not be usable by portable applications. The proposed extensions are being used to feed the implementation specific data blobs either into native APIs or interpret its contents. This would be a definite breach of the abstraction model, and therefore these extensions belong into the native API of the mechanism, not into the GSS-API part. You're free to accept gss-api data at the API level because there shouldn't be any confusion inside the mechanism about its own gssapi objects, and it will not pollute the gssapi spec. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 11:55:24 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06396 for ; Wed, 20 Feb 2002 11:55:24 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA24396 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 10:41:07 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA24374; Wed, 20 Feb 2002 10:41:03 -0600 (CST) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA14005; Wed, 20 Feb 2002 10:41:04 -0600 (CST) Received: from Von-Win2k-Box.mcs.anl.gov (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id KAA66660; Wed, 20 Feb 2002 10:40:22 -0600 Message-Id: <5.1.0.14.2.20020220082635.02c45e98@localhost> X-Sender: welch@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 10:24:24 -0600 To: mrex@sap-ag.de From: Von Welch Subject: Re: Can Authorization Data be retrieved through GSSAPI? Cc: mrex@sap-ag.de, deengert@anl.gov, ietf-krb-wg@anl.gov, security-internal@globus.org In-Reply-To: <200202191752.SAA13988@uw1048.wdf.sap-ag.de> References: <5.1.0.14.2.20020219090052.02a108f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Let me give a little background on our changes. We, the Globus Project, have been successfully using GSSAPI over SSL in something we call the Grid Security Infrastructure (GSI) for a number of years now. We chose to use the GSSAPI because we knew we would have users that would want to use Kerberos instead of PKI and it has been very successful for us - our code can be linked with either GSSAPI/kerberos or GSI with relatively little work. In doing this we have noticed a couple of things. First, a number of things, especially credential management happen day behind the scenes are are controlled with mechanism-specific magic (e.g. environment variables) that applications need to be aware of. Second, we are just reaching limits for what we need to do to deploy more advanced security systems. Instead of throwing out the GSSAPI or adding to it in a non-GSSAPI manner we are attempting these extensions. In summary our extensions do the following: * Attempt to provide more portable methods to handle things that are currently handled today by mechanism-specific magic (e.g. environment variables). * Separate delegation from authentication and allow an application to put policy (be in some independent, mechanism-specific or application-specific) into delegated credentials. * Allow for the fact there are things beyond identity and lifetime in a credential that are interesting for authorization. * Allow for a method to set options on a GSSAPI context. A couple of our functions use the notion of an oid and a blob of data, where the oid specifies what the blob of data is. This is akin to the get/setsockopt() function calls. The oid can be mechanism specific, in which case the application better know it is running over a particular mechanism (like it does today if it plays with environment variables), or it can be mechanism independent. Some specific comments are below. At 06:52 PM 2/19/2002 +0100, Martin Rex wrote: >Von Welch wrote: > > > > Martin - in reponse to your comments, I would much rather address your > > issues of this being mechanism specific than say this is mechanism > > specific. We (the authors) have a fair amount of Kerberos experience > > between us and we've tried very hard to at least keep that mechanism in > > mind when laying out this document since working over it is also serious > > interest to our project. Could give some specific examples of what you > > think are mechanism-specific attributes? > >I meant to imply that your proposed extensions are *implementation* >specific, which is actually worse that being mechanism-specific. An example would still be appreciated to make sure I understand your statement. >When I wrote my wrapper DLL for Microsoft's W2K Kerberos SSP I would >have gladly added support for MIT Kerberos keytab -- if there was >just an API that allowed me to stuff such credentials into >W2K Kerberos -- however there isn't. > >Some of descriptions in the purpose of the calls confuse me, >like the purpose of gss_export_cred()/gss_import_cred(). >Although the description makes it sound like a gssapi based >app would have some need to export and re-import credentials, >this concept is actually totally alien to portable applications >and places significant implementation constraints on the >nature of credentials. If a GSSAPI-based server, e.g. sshd, accepts a delegated credential and wants to make it available to a spawned process today how does it do this in a portable way? Today credential storage isn't defined, the application just has to assume that it happens and then use knowledge of mechanism-specific environment variables to make it happen. With export_cred() an application can do this explicitly and if the mechanism doesn't support it, it learns that in which case it has a problem the user probably wants to know about. >As it is designed, individual credentials are distinguished >by (a) the identity they're able to authenticate and >optionally (b) the gssapi mechanism (OID) for which they >are usable. With the regular GSS-API v2 functionality >a portable application can already manage _and_ use an >arbitrary number of credentials today. > > >The proposed change for gss_init_sec_context()/gss_accept_sec_context() >to accept an initial non-NULL context handle prefilled with policy >options would be a significant backwards-incompatible change to >the existing GSS-API (and always require significant app code >changes to use those features). For the initiator side you >could alternatively try to use context-options to indicate >your additional desires, which then would be safely ignored >by mechanisms that don't implement it and which would >would not confuse an existing SPNEGO in between. > >On the acceptor side I would rather prefer an alternative >gss_accept_sec_context_2() that takes context options as an >additional input parameter. The original designers probably >thought that it would be ok if the acceptor just participated >the full handshake and decided after security context establishment >whether the result complies with its policy... That certainly sounds like a reasonable suggestion. > > > > In response to your specific comments, our attempt to standardize behavior > > on context expiration is just an attempt to standardize the behavior of > the > > wrap/unwrap calls when context expires and to give the application a > way to > > control this. The idea being that some sites might want to know when the > > context expires, but finish some action (e.g. a file transfer in progress) > > before disallowing further activity. > >My preferred approach would be to create additional informatory major_status >return codes that would be pair-able with either GSS_S_FAILURE or >GSS_S_COMPLETE in order to indicate whether there is an >advisory or enforced context expiration on the message protection calls, >similar to the change that I requested for the message sequencing errors >-- just that the sequencing errors were informatory from the beginning >and the context expiration has always been a fatal error code. Again, a reasonable suggestion. >(side note: when a gssapi mechanism actually wants to implement > advisory sequencing errors instead of fatal sequencing errors, > then it is quite difficult to decide when to stop returning > sequencing-related informatory status bits after a sequencing error ...) > > > > > The idea behind disabling of encryption is that this allows an application > > to disable encryption for some policy reason, even if the mechanism > > supports it. By doing so before context setup, this allows the client to > > gracefully know this before a wrap call fails. Honestly, we threw this in > > as a "seems like a good idea". > >Huh? before a wrap call fails? >I don't understand, what is that supposed to mean? Currently an acceptor has no way to tell the GSSAPI library it doesn't want to allow confidentiality, it's totally up to the mechanism. All it can do is signal an application-level error if encrypted data arrives. The idea here is this allows the acceptor to disable this at context establishment. The mechanism may just record this state or it may actually change it's protocol. Von >gss_wrap() will not fail when encryption is requested but not available, >it must succeed and return conf_flag==FALSE as long as integrity >is available on the security context. > >getmic()/verifymic() as well as wrap()/unwrap() will work as >long as context establishment returns the context flag for >availability of integrity protection (GSS_C_INTEG_FLAG?). > > >-Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 14:02:26 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16255 for ; Wed, 20 Feb 2002 14:02:25 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA00171 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 12:42:19 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA00165 for ; Wed, 20 Feb 2002 12:42:17 -0600 (CST) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA11206 for ; Wed, 20 Feb 2002 12:42:18 -0600 (CST) Received: from Von-Win2k-Box.mcs.anl.gov (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id MAA127488; Wed, 20 Feb 2002 12:41:18 -0600 Message-Id: <5.1.0.14.2.20020220122804.02c32008@localhost> X-Sender: welch@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 12:31:56 -0600 To: mrex@sap-ag.de From: Von Welch Subject: Re: Kerb WG iakerb Cc: Nicolas.Williams@ubsw.com (Nicolas Williams), ietf-krb-wg@anl.gov In-Reply-To: <200202201206.NAA15633@uw1048.wdf.sap-ag.de> References: <20020219135430.D27171@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk At 01:06 PM 2/20/2002 +0100, Martin Rex wrote: >Nicolas Williams wrote: > > > > > > Yes. Well. It seems we have to make some serious trade-offs for that to > > > > work. E.g., authorization data is hard to abstract, as you point out. > > > > And so is credentials handling, and other fun stuff. > > > > > > The GSS-API abstraction of credentials works just fine. > > > > Really? Then why is it that the GSS-for-OpenSSH patches have to go to > > such troubles to create ccaches? > >create ccaches? Wait a minute, that sounds like an extremely implementation >specific type of thing. This smells baaaaad. > >I haven't seen what they do, so I can just guess what they're trying >to accomplish: > >GSS-API has only very simplistic support for credential delegation, >and maybe they're trying to write a delegated credential out to >a file _above_ the gssapi mechanism level -- which would definitely >be an extremely broken design. > >Whether or not a delegated credential should be written out to a >permanent storage so that remains available after the delegated_cred >handle has been passed to gss_release_cred(), and similarily >whether a delegated credential becomes available to other processes >through this is a completely local matter of every individual gssapi >mechanism implementation (both in policy and data format). >Same for the management and cleanup of (delegated) credentials >-- this is explicitly outside of the scope of GSS-API. I think applications need to be able to control this, or at least know if it has or has not been done. >Implementation specific means that it doesn't need to be the same >for two independent implementations of the *same* gssapi mechanism, >and as I've said before, you will have serious problems trying to >push MIT-Kerberos internal representations of data into >Microsoft's W2K Kerberos. > > > > > > [...] > > > > > I have no problem with native APIs of a mechanism accepting > > > gssapi datatypes, but polluting GSS-API with implementation > > > specific data types and semantics is not a good idea. > > > > Why? As long as those implementation specific data types are treated as > > opaque pointers and the semantics are simple then it should be > > tolerable. I think that's fine for ccache stuff and for authorization > > data, ticket extensions, etc... I can't imagine an easy to use generic > > C interface to authorization data. > > >No, it is not! > >Leave the native data at the native API. Don't pollute the >generic API with lots of native API data that will be very implementation >specific and not be usable by portable applications. > >The proposed extensions are being used to feed the implementation specific >data blobs either into native APIs or interpret its contents. >This would be a definite breach of the abstraction model, and therefore >these extensions belong into the native API of the mechanism, not >into the GSS-API part. The idea of the extensions is not to be specific to our implementation or mechanism. The idea is any implementation or mechanism could use this function. Some stuff may be mechanism or implementation specific, in which case the application needs to know this, like they do today when they play with Kerberos or GSI environment variables. One could also define things that are common across multiple mechanisms. Not all mechanisms may support it, but at least this gives applications a standard way of discovering that. Von >You're free to accept gss-api data at the API level because >there shouldn't be any confusion inside the mechanism about its >own gssapi objects, and it will not pollute the gssapi spec. > > >-Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 19:54:11 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25113 for ; Wed, 20 Feb 2002 19:54:10 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id SAA14485 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 18:39:38 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA14434; Wed, 20 Feb 2002 18:39:34 -0600 (CST) Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id SAA27158; Wed, 20 Feb 2002 18:39:34 -0600 (CST) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06699; 20 Feb 2002 19:39 EST Date: Wed, 20 Feb 2002 19:39:11 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: mrex@sap-ag.de MMDF-Warning: Parse error in original version of preceding line at minbar.fac.cs.cmu.edu cc: Von Welch , deengert@anl.gov, ietf-krb-wg@anl.gov MMDF-Warning: Parse error in original version of preceding line at minbar.fac.cs.cmu.edu Subject: Re: Can Authorization Data be retrieved through GSSAPI? In-Reply-To: <200202191752.SAA13988@uw1048.wdf.sap-ag.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Tue, 19 Feb 2002, Martin Rex wrote: > Von Welch wrote: > > > > Martin - in reponse to your comments, I would much rather address your > > issues of this being mechanism specific than say this is mechanism > > specific. We (the authors) have a fair amount of Kerberos experience > > between us and we've tried very hard to at least keep that mechanism in > > mind when laying out this document since working over it is also serious > > interest to our project. Could give some specific examples of what you > > think are mechanism-specific attributes? > > I meant to imply that your proposed extensions are *implementation* > specific, which is actually worse that being mechanism-specific. Um. You do realize that RFC2744 and RFC2853 define standardized C and Java language bindings for GSS-API, right? The MIT Kerberos distribution includes a GSS-API library which implements RFC2744. The Microsoft SSPI does _not_ implement RFC2744, though it does produce messages which are wire-compatible with those defined in the GSSAPI. IMHO, RFC2744, RFC2853, and their predecessors were a mistake. The term "GSSAPI" is a misnomer; GSSAPI isn't an API at all; it is a protocol building block which defines some protocol elements and an abstract functional description of how application protocols and authentication mechanisms work together. That's good. RFC2744 and RFC2853, however, _are_ API's. In particular, they are C and Java API's which are intended to be implemented by someone providing a GSSAPI mechanism (or multi-mechanism switch), and called by code implementing a GSSAPI-using application protocol. IMNSHO, the IETF should not be in the business of defining such API's. Not only is it completely out of scope, but we're also lousy at it. I'd very much like to see GSSAPI extended to handle authorization data and actually try to address the naming problems in a reasonable way. This is pretty hairy work that should properly be done in CAT, which has been dormant for some time now. A few of us would like to "wake up" the CAT group and start doing some work on GSSAPI, but really don't have time to start such an effort until kerberos-revisions is finished. -- Jeff From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 21:38:28 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27298 for ; Wed, 20 Feb 2002 21:38:27 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id UAA12227 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 20:28:36 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA12211 for ; Wed, 20 Feb 2002 20:28:34 -0600 (CST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA14774 for ; Wed, 20 Feb 2002 20:28:34 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA08887 for ; Wed, 20 Feb 2002 21:28:34 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA12930; Wed, 20 Feb 2002 21:28:33 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id VAA07048; Wed, 20 Feb 2002 21:28:33 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id VAA05046; Wed, 20 Feb 2002 21:28:33 -0500 To: ietf-krb-wg@anl.gov Subject: GSS-API and UTF-8 (was Re: Kerb WG iakerb) References: <200202201206.NAA15633@uw1048.wdf.sap-ag.de> From: Ken Raeburn Date: 20 Feb 2002 21:28:33 -0500 In-Reply-To: <200202201206.NAA15633@uw1048.wdf.sap-ag.de> Message-ID: Lines: 60 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Huh? You mean the strings I get aren't already using my native {UTF-8, iso8859-999, EBCDIC}? Martin Rex writes: > Printable Names are already tagged with "Nametype OIDs", so defining > additional OIDs for UTF8-encoding should take care of that. Eww. While AFAICT RFC 2743 says nothing about character set encoding, the C bindings in RFC 2744 (section 3.2.2) do specify ISO Latin 1 for "certain multiple-word data items" including printable strings. And the Java bindings (RFC 2853) use String objects of "two-byte Unicode characters". So, where would these new OIDs be specified, and what would be the effect in the various language bindings? Would C and Java code get different name types for names that fit in "two-byte Unicode" but not in ISO Latin 1? Seems to me the encoding should maybe have been one of those implementation-defined details, like which "pointer or arithmetic type" is used for gss_cred_id_t. Either one can make it impossible for independent implementations to work together at the ABI level. (Though, granted, character set encoding changes can imply more than a simple recompile, at least in C.) If we open the door to encoding-specific OIDs, what're the chances someone will propose a way of importing or exporting UCS-2 or UCS-4 names without UTF-8 conversions? How many character sets would an application need to know how to display? > Since gss_display_status() also takes an input parameter "status_type" > to indicate whether to translate a minor or a major status code, > this input parameter could be extended with "major_utf8" and "minor_utf8". Would this just be an extension at the C bindings layer? The GSS-API uses an integer for status_type, and specifies values 1 and 2 for major and minor respectively; the C bindings just indicate how the integer value is passed in (what type and where in the argument list). So the revised i18n C bindings would do what? Map from a set of integers (from RFC 2743) and desired encodings to another set of integers (to use in application C code)? Add some flags in the high bits and hope that the generic API is never extended so as to use those bits? (And remember, it's an "int" in the C bindings so we can only assume 16 bits are available in all.) Or do we extend it at the GSS-API layer? If so, the extension is meaningless in a set of language bindings that specifies UTF-8, but maybe that's okay. But see above re UCS-2 extensions. > The only remaining problem would be to predetermine whether > gss_display_name() should be required to return the regular plain-ascii > variant for plain-ascii names for updates of a gssapi mechanism that > wants to keep its mechanism OID unchanged. Also ISO Latin 1 strings that are not plain ASCII. Ken From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 21:40:24 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27334 for ; Wed, 20 Feb 2002 21:40:24 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id UAA12854 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 20:30:48 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA12848 for ; Wed, 20 Feb 2002 20:30:47 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA15096 for ; Wed, 20 Feb 2002 20:30:47 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA21735 for ; Wed, 20 Feb 2002 21:30:47 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA12589; Wed, 20 Feb 2002 21:30:46 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id VAA07487; Wed, 20 Feb 2002 21:30:46 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id VAA05052; Wed, 20 Feb 2002 21:30:46 -0500 To: ietf-krb-wg@anl.gov Subject: GSS and credential delegation (was Re: Kerb WG iakerb) References: <200202201206.NAA15633@uw1048.wdf.sap-ag.de> From: Ken Raeburn Date: 20 Feb 2002 21:30:46 -0500 In-Reply-To: <200202201206.NAA15633@uw1048.wdf.sap-ag.de> Message-ID: Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Martin Rex writes: > create ccaches? Wait a minute, that sounds like an extremely implementation > specific type of thing. This smells baaaaad. > > I haven't seen what they do, so I can just guess what they're trying > to accomplish: > > GSS-API has only very simplistic support for credential delegation, > and maybe they're trying to write a delegated credential out to > a file _above_ the gssapi mechanism level -- which would definitely > be an extremely broken design. > > Whether or not a delegated credential should be written out to a > permanent storage so that remains available after the delegated_cred > handle has been passed to gss_release_cred(), and similarily > whether a delegated credential becomes available to other processes > through this is a completely local matter of every individual gssapi > mechanism implementation (both in policy and data format). > Same for the management and cleanup of (delegated) credentials > -- this is explicitly outside of the scope of GSS-API. Still needs to be done somehow, somewhere. How would you suggest we set up something like an ssh server that can receive credentials and make them available to the login session (or other random process to which we can't just hand off the GSS context handle)? To make it interesting, let's assume for the sake of argument that it's handling multiple incoming connections, and thus isn't changing any global state like its uid that the underlying GSS mechanism can key off of. We added a routine to our implementation of the krb5 GSS mechanism to copy out the delegated credentials to a krb5 ccache. I believe Heimdal has the same addition; at least, that was the plan when we discussed it with Assar. (Would this count as a "native API" by your definition? Or would it have to be in the krb5 library instead and lose the "gss_" name prefix?) > Implementation specific means that it doesn't need to be the same > for two independent implementations of the *same* gssapi mechanism, > and as I've said before, you will have serious problems trying to > push MIT-Kerberos internal representations of data into > Microsoft's W2K Kerberos. Absolutely. > > > I have no problem with native APIs of a mechanism accepting > > > gssapi datatypes, but polluting GSS-API with implementation > > > specific data types and semantics is not a good idea. Doesn't that imply that the "native APIs" might have to know about the internals of the GSS-API implementation as well as the specific mechanism(s) it cares about? If the GSS-API library is a glue layer that negotiates and dynamically loads "real" mechanisms, might some of the objects it returns be wrapped versions of mechanism-specific objects? Or is it not possible to do such a thing without the mechanism knowing those details already? Ken From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 22:42:17 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29115 for ; Wed, 20 Feb 2002 22:42:16 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id VAA26254 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 21:26:46 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA26248 for ; Wed, 20 Feb 2002 21:26:45 -0600 (CST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA24155 for ; Wed, 20 Feb 2002 21:26:45 -0600 (CST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id WAA28552; Wed, 20 Feb 2002 22:26:14 -0500 (EST) Date: Wed, 20 Feb 2002 22:26:14 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Ken Raeburn Cc: ietf-krb-wg@anl.gov Subject: Re: GSS-API and UTF-8 (was Re: Kerb WG iakerb) In-Reply-To: Your message of 20 Feb 2002 21:28:33 -0500 Message-ID: Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk > If we open the door to encoding-specific OIDs, what're the chances > someone will propose a way of importing or exporting UCS-2 or UCS-4 > names without UTF-8 conversions? How many character sets would an > application need to know how to display? UTF-8 vs UCS-2 vs UCS-4 vs UTF-16 vs UTF-32 is not a big deal if it is at the application layer. The bigger issue is ensuring that the normalization rules are consistent. The rules we are using for Kerberos may or may not be appropriate for all mech-types. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 20 22:58:18 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29276 for ; Wed, 20 Feb 2002 22:58:17 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id VAA01307 for ietf-krb-wg-outgoing; Wed, 20 Feb 2002 21:46:16 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA01289 for ; Wed, 20 Feb 2002 21:46:15 -0600 (CST) Received: from gate2.stm.ubswarburg.com (gate2.stm.ubswarburg.com [151.191.1.12]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA27314 for ; Wed, 20 Feb 2002 21:46:15 -0600 (CST) Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id WAA21388; Wed, 20 Feb 2002 22:44:19 -0500 (EST) Received: from (nine.ubswarburg.com [192.168.0.4]) by gate2 via smap (V2.0/ubsw) id xma021379; Wed, 20 Feb 2002 22:44:09 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id WAA18882; Wed, 20 Feb 2002 22:40:45 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id WAA26733; Wed, 20 Feb 2002 22:44:12 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id WAA01877; Wed, 20 Feb 2002 22:42:52 -0500 (EST) Date: Wed, 20 Feb 2002 22:42:52 -0500 From: Nicolas Williams To: mrex@sap-ag.de Cc: ietf-krb-wg@anl.gov Subject: Re: Kerb WG iakerb Message-ID: <20020220224250.M27171@sm2p1386swk.wdr.com> Mail-Followup-To: mrex@sap-ag.de, ietf-krb-wg@anl.gov References: <20020219135430.D27171@sm2p1386swk.wdr.com> <200202201206.NAA15633@uw1048.wdf.sap-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200202201206.NAA15633@uw1048.wdf.sap-ag.de>; from martin.rex@sap-ag.de on Wed, Feb 20, 2002 at 01:06:46PM +0100 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk On Wed, Feb 20, 2002 at 01:06:46PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > > > Yes. Well. It seems we have to make some serious trade-offs for that to > > > > work. E.g., authorization data is hard to abstract, as you point out. > > > > And so is credentials handling, and other fun stuff. > > > > > > The GSS-API abstraction of credentials works just fine. > > > > Really? Then why is it that the GSS-for-OpenSSH patches have to go to > > such troubles to create ccaches? > > create ccaches? Wait a minute, that sounds like an extremely implementation > specific type of thing. This smells baaaaad. Well, let's see, the only consumers of Kerberos must be GSS apps, right? No, wrong, and users expect their tickets to be useable, so we need to be able to interface GSS apps using the Kerberos mech to non-GSS apps also using Kerberos. And there may be several ways a user may want to name ccaches. And some apps may need memory-only ccaches. And some OSs require specific ccache naming conventions for their secure filesystem stuff to work (hint, one such vendor's name starts with 'S'). > I haven't seen what they do, so I can just guess what they're trying > to accomplish: > > GSS-API has only very simplistic support for credential delegation, > and maybe they're trying to write a delegated credential out to > a file _above_ the gssapi mechanism level -- which would definitely > be an extremely broken design. No, it's called realpolitik. > Whether or not a delegated credential should be written out to a > permanent storage so that remains available after the delegated_cred or not-permanent storage, for that matter. It's not just the type of storage, but the naming (not just how to specify a ccache name, but how to determine the name of a ccache so it can be passed to other apps). > handle has been passed to gss_release_cred(), and similarily > whether a delegated credential becomes available to other processes > through this is a completely local matter of every individual gssapi > mechanism implementation (both in policy and data format). > Same for the management and cleanup of (delegated) credentials > -- this is explicitly outside of the scope of GSS-API. If it's out of scope then either GSS-API can't cope and its users must not be able to do useful things with GSS creds OR there must be a mech- or impl-specific interface. I prefer the latter. > Implementation specific means that it doesn't need to be the same > for two independent implementations of the *same* gssapi mechanism, Doh. > and as I've said before, you will have serious problems trying to > push MIT-Kerberos internal representations of data into > Microsoft's W2K Kerberos. Clearly. I wouldn't want to. Face it, there are real differences between the various platforms, and we (the users, developers, sysadmins, implementors) may not want to settle for the lowest common denominator that can be abstracted 100% portably. I can deal with a few #ifdefs, clearly so can the MIT folk :) Look at Simon's GSS-for-OpenSSH patches. Pretty simple. Very clean, not unduly full of #ifdefs. It would be simpler if there was some interface between the GSS-API C bindings and specific implementations. Simon's code manages to work with two mechanisms and three different implementations (two of the Kerberos mech, one of the GSI mech). So there's proof that: a) GSS-API is decent and b) GSS-API is not good enough. > > > I have no problem with native APIs of a mechanism accepting > > > gssapi datatypes, but polluting GSS-API with implementation > > > specific data types and semantics is not a good idea. > > > > Why? As long as those implementation specific data types are treated as > > opaque pointers and the semantics are simple then it should be > > tolerable. I think that's fine for ccache stuff and for authorization > > data, ticket extensions, etc... I can't imagine an easy to use generic > > C interface to authorization data. > > > No, it is not! > > Leave the native data at the native API. Don't pollute the But if you stick to the GSS-API as it stands today it's very hard to interface correctly with the local native APIs. That's the point, you have to resort to acrobatics to handle ccache stuff correctly, say. I can't wait to see a pure abstraction on all the intersting things one might do with authorization data. > generic API with lots of native API data that will be very implementation > specific and not be usable by portable applications. Nah, #ifdefs are terribly useful in writing portable code :) :) :) Mind you, I'm no fan of C/C++, but we'll have to make do for now. > The proposed extensions are being used to feed the implementation specific > data blobs either into native APIs or interpret its contents. > This would be a definite breach of the abstraction model, and therefore > these extensions belong into the native API of the mechanism, not > into the GSS-API part. I guess I'm skeptical about the possibility of GSS evolving into a swiss army knife abstraction layer that can really do everything desired of it. > > > -Martin Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 21 15:51:19 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03596 for ; Thu, 21 Feb 2002 15:51:18 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id OAA01341 for ietf-krb-wg-outgoing; Thu, 21 Feb 2002 14:35:01 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA01335 for ; Thu, 21 Feb 2002 14:34:59 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA05338 for ; Thu, 21 Feb 2002 14:34:58 -0600 (CST) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA22643; Thu, 21 Feb 2002 21:38:33 +0100 (MEZ) From: Martin Rex Message-Id: <200202212034.VAA23352@uw1048.wdf.sap-ag.de> Subject: Re: GSS-API and UTF-8 (was Re: Kerb WG iakerb) To: raeburn@mit.edu (Ken Raeburn) Date: Thu, 21 Feb 2002 21:34:24 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: from "Ken Raeburn" at Feb 20, 2 09:28:33 pm Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit I have the impression that quite many people only think of the most simplistic usage scenario where one single or a fixed set of predetermined/preknown gssapi mechanism is linked to an application and the application knows about the exact characteristics before its being compiled and linked to it. The "portable" applications that the GSS-API spec specifically tries to address and support is significantly different. Portable applications will be faced with arbitrary unknown GSS-API mechanism implementations at runtime, or even with a set of several different gssapi mechanisms with differing characteristics, an in some scenarios the selection of a particular mechanism may be a result of an SPNEGO negotiation. In these scenario, a portable application will have to restrict itself to the well-defined behaviour and characteristics of GSS-API. Ken Raeburn wrote: > > Huh? You mean the strings I get aren't already using my > native {UTF-8, iso8859-999, EBCDIC}? Today it is implementation defined what encoding is being used; rfc 2743/44 talk of "printable octet strings" only. On ASCII-machines the 7-bit ASCII characters should be safe. Everything else is implementation defined and may change with (language) environment/configuration. On EBCDIC machines this probably is EBCDIC (but since the ISO Latin1 characters exist in 13 slightly different variants for individual western european countries you're probably limited to *LESS* than ASCII 7-bit...) In our application we don't prevent use of 8-bit chars, but clearly discourage their use. The customer may try to use it and it may work... Unfortunately, in the past few years our codebase was reengineered to allow the use of Unicode (UCS2 internally). However this actually creates a problem for the use of 8-bit chars at the GSS-API because now we would have to know about the local encoding of 8-bit chars to be able to show those printable strings to human users or accept them from users through our own Unicode-enabled UIs... This is where the "local matter" really hurts and new tags that indicate UTF8 encoding would *REALLY* help. > > Martin Rex writes: > > Printable Names are already tagged with "Nametype OIDs", so defining > > additional OIDs for UTF8-encoding should take care of that. > > Eww. While AFAICT RFC 2743 says nothing about character set encoding, > the C bindings in RFC 2744 (section 3.2.2) do specify ISO Latin 1 for > "certain multiple-word data items" including printable strings. And > the Java bindings (RFC 2853) use String objects of "two-byte Unicode > characters". > > So, where would these new OIDs be specified, and what would be the > effect in the various language bindings? Would C and Java code get > different name types for names that fit in "two-byte Unicode" but not > in ISO Latin 1? Additional generic nametypes that indicate UTF8-encoding should be added to the High-level spec (rfc2743). It's up to the language binding to be more precise about the encoding of the existing generic nametypes. I think it's perfectly ok for the JAVA bindings to always use Unicode here. If the C-Bindings actually mention ISO Latin 1, then this is an error, probably not backwards compatible with GSS-API v1 C-Bindings (rfc1509) and a bad idea for the few EBCDIC-dinosaurs that are still around. Implementations have been very liberal in defining the "local character set". I've met two different gssapi mechanisms that were returning Japanese multibyte text from gss_display_status() and I think that is ok. > > Seems to me the encoding should maybe have been one of those > implementation-defined details, like which "pointer or arithmetic > type" is used for gss_cred_id_t. Either one can make it impossible > for independent implementations to work together at the ABI level. > (Though, granted, character set encoding changes can imply more than a > simple recompile, at least in C.) Well, that is impossible. In those few places where gssapi has "printable octet strings", these are meant to be treated and processed as strings, i.e. read from configuration files, written to logs, presented to users thru UIs or passed along from user input. We need to be explicit about the encoding or portable applications must limit themselves to the small safe subset of 7-bit ASCII chars (or some chars less on EBCDIC). > > If we open the door to encoding-specific OIDs, what're the chances > someone will propose a way of importing or exporting UCS-2 or UCS-4 > names without UTF-8 conversions? How many character sets would an > application need to know how to display? Huh -- Where do you see a problem? There is no limit on mechanims-specific and implementation-specific nametypes in GSS-API, and most gssapi mechanisms offer several implementation specific nametypes today. Acutally, every gssapi mechanism will require a private, non-generic, well-specified nametype. The Kerberos 5 gssapi mechanism (rfc1964) specifies such a mechanism-specific nametype, the Kerberos principal name. SPKM (rfc2025) lacks that nametype, that's why all independent implementations of SPKM1 mechanisms fail to interoperate on printable names... Although I complained loudly, LIPkey was published with the same flaw (lack of a well-defined mechanism specific nametype). > > > Since gss_display_status() also takes an input parameter "status_type" > > to indicate whether to translate a minor or a major status code, > > this input parameter could be extended with "major_utf8" and "minor_utf8". > > Would this just be an extension at the C bindings layer? > > The GSS-API uses an integer for status_type, and specifies values 1 > and 2 for major and minor respectively; the C bindings just indicate > how the integer value is passed in (what type and where in the > argument list). I would add it to both, High-level and C-Bindings as a "v2 mechanism SHOULD implement", i.e. major_utf8 = 3, minor_utf8 and allow the language binding to omit the *_utf8 variants when it already uses Unicode characters by default (e.g. the JAVA bindings). > > So the revised i18n C bindings would do what? Map from a set of > integers (from RFC 2743) and desired encodings to another set of > integers (to use in application C code)? Add some flags in the high > bits and hope that the generic API is never extended so as to use > those bits? (And remember, it's an "int" in the C bindings so we can > only assume 16 bits are available in all.) The generic layer doesn't use bits! It's just a simple integer value, more like an enum > > > The only remaining problem would be to predetermine whether > > gss_display_name() should be required to return the regular plain-ascii > > variant for plain-ascii names for updates of a gssapi mechanism that > > wants to keep its mechanism OID unchanged. > > Also ISO Latin 1 strings that are not plain ASCII. That is one of the problems. But changing the behaviour of a gssapi mechanism that is already deployed would cause interoperability problems if suddenly the semantics of gss_display_name() change with a newer version. In order to provide the most backwards compatibility we will probably need a seperate call "gss_display_name_utf8()", which might not be needed for the language (bindings) such as JAVA. -Martin From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 21 21:10:55 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09317 for ; Thu, 21 Feb 2002 21:10:55 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id UAA00768 for ietf-krb-wg-outgoing; Thu, 21 Feb 2002 20:00:12 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA00743 for ; Thu, 21 Feb 2002 20:00:10 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA08342 for ; Thu, 21 Feb 2002 20:00:10 -0600 (CST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA29316 for ; Thu, 21 Feb 2002 21:00:10 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA15063; Thu, 21 Feb 2002 21:00:09 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id VAA00834; Thu, 21 Feb 2002 21:00:09 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id VAA02943; Thu, 21 Feb 2002 21:00:09 -0500 To: ietf-krb-wg@anl.gov Subject: Re: GSS-API and UTF-8 (was Re: Kerb WG iakerb) References: <200202212034.VAA23352@uw1048.wdf.sap-ag.de> From: Ken Raeburn Date: 21 Feb 2002 21:00:09 -0500 In-Reply-To: <200202212034.VAA23352@uw1048.wdf.sap-ag.de> Message-ID: Lines: 84 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Martin Rex writes: > I have the impression that quite many people only think of the > most simplistic usage scenario where one single or a fixed set > of predetermined/preknown gssapi mechanism is linked to an > application and the application knows about the exact characteristics > before its being compiled and linked to it. Not at all. I try to think in terms of a GSS-API implementation that consists of a config file parser and a dynamic loader, with the rest up to the whim of the system administrator. However, the Kerberos-only scenario is the only one I have any practical experience with, so it's hard for me to escape that box enough to see what assumptions I'm making that don't apply elsewhere. If you have a pointer to any *good* documentation on GSS-API, better than the RFCs, I'd like to see it. > If the C-Bindings actually mention ISO Latin 1, then this is an > error, probably not backwards compatible with GSS-API v1 C-Bindings > (rfc1509) and a bad idea for the few EBCDIC-dinosaurs that are > still around. Implementations have been very liberal in defining > the "local character set". I've met two different gssapi mechanisms > that were returning Japanese multibyte text from gss_display_status() > and I think that is ok. RFC 2744, section 3.2.2. Actually, it says some items "may be regarded as simple ISO Latin-1 character strings"; how much "may be regarded as" affects actual coding requirements, I can't say. If it's an error, perhaps an update should be issued. But what should it say instead? "Local character set"? "Implementation-defined"? > > If we open the door to encoding-specific OIDs, what're the chances > > someone will propose a way of importing or exporting UCS-2 or UCS-4 > > names without UTF-8 conversions? How many character sets would an > > application need to know how to display? > > Huh -- Where do you see a problem? We also have some mechanism-specific name types. The problem I see is they're (somewhat?) independent axes; we could easily get a request for an OID for a Kerberos principal name using EBCDIC encoding. Which names in this multidimensional matrix should be considered "portable across GSS-API version A.B implementations", or "portable across implementations of mechanism X", or "portable across implementations on operating system Y", or whatever other classifications you might want? > There is no limit on mechanims-specific and implementation-specific > nametypes in GSS-API, And the use of either makes an application less portable in one way or the other. > > Would this just be an extension at the C bindings layer? > > > > The GSS-API uses an integer for status_type, and specifies values 1 > > and 2 for major and minor respectively; the C bindings just indicate > > how the integer value is passed in (what type and where in the > > argument list). > > > I would add it to both, High-level and C-Bindings as a > "v2 mechanism SHOULD implement", i.e. major_utf8 = 3, minor_utf8 > and allow the language binding to omit the *_utf8 variants when > it already uses Unicode characters by default (e.g. the JAVA bindings). I'm still a newbie to the whole Unicode/UCS/UTF situation (again, mostly 'cause I never use any of it in real life), but my impression is that Java uses UCS-2, and that covers just 16 bits worth, whereas Unicode is much bigger. A UTF-16 encoding has been put forth that can encode code points from 16 more planes in two UTF-16 "characters" (i.e., 20 bits from four bytes), but you'd still have to know to do the conversion. So the Java bindings might want major_utf16 and minor_utf16, whereas they'd probably be uninteresting under the C bindings unless you have 16-bit chars, or rewrite the API to use wchar_t, and even then only if wchar_t is 16 bits and not 32, which gets us back to implementation-specific options. Of course, I may be completely wrong. My experience with Java and Unicode is about as limited as my experience with non-Kerberos GSS-API. Ken From owner-ietf-krb-wg@atalanta.ctd.anl.gov Mon Feb 25 04:34:43 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03435 for ; Mon, 25 Feb 2002 04:34:42 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id DAA11122 for ietf-krb-wg-outgoing; Mon, 25 Feb 2002 03:21:54 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id DAA11116 for ; Mon, 25 Feb 2002 03:21:52 -0600 (CST) Received: from localhost ([218.51.132.59]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id DAA04537 for ; Mon, 25 Feb 2002 03:21:49 -0600 (CST) Message-Id: <200202250921.DAA04537@dns2.anl.gov> Reply-To: young@kimcad.co.kr From: フ措檣蘿葬葆馨冂 To: ietf-krb-wg@anl.gov Subject: [惜堅]措骯議萄議蛤寰陛薑辨(ピ儅辨)薑ゴ ⑸滌陛爾晝 Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 25 Feb 2002 17:55:43 +0900 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk 偃檣辨(020218)

措骯議萄議蛤寰 ⑸滌陛陛薑辨(ピ儅辨)薑ゴ爾晝

﹥ ⑸癒

- AutoCAD諦翕橾フ貲滄橫

- AutoCAD曖賅萇幗瞪婁曄寞ユ龱�

- AutoCAD諦⻏餌フ嬴檜夔餌辨

﹥ 偃嫦餌(檣蘿葬囀葬嬴) 模偃

- (衙橾唳薯褐僥,醞晦羶,骯濠睡)辦熱漸籀煎摹薑(2001喇)

- (瞪措唳薯檣翱ベ�,措薯骯機Ё溘營欽) 嶸蜂漸籀 20偃晦機縑摹薑(2001喇)

- (フ措唳薯褐僥)漸籀葬渦 50檣縑摹薑(2001喇)

- (骯機濠錳睡)骯機Ё溘渠� 渠鱔滄鼻熱鼻(2000喇)

- (薑爾鱔褐睡)S/W 奢賅渠瞪辦熱鼻熱鼻(2000喇)

﹥ 鼻機辨(模綠濠陛 90虜錳)婁棻艇薄

-VBA(Visual Basic Application)薯諼

-檜嘐雖鳶殮晦棟薯諼

-3D 晦棟薯フ瞳歜.

﹥ が陛匸(羹レ匸)擎

が陛匸擎棻擠,塭檜囀蝶,縞冖蝶,萄葡嬪鍔,膠橫錚橫囀葬嬴(嬴檜援葬),フ嘐腦,褕葆棲,爾僭撰,喘隴堅,

⺕試闡蛔曖濠猿褒斜楚ヌ婦溼縑憮棻遴煎萄ビ褒熱氈蝗棲棻.

http://www.kimcad.co.kr/download/cadian_web_eval.exe

﹥ 薯ゴ滌陛問ォ

薯ゴ貲	薯ゴ掘撩	陛問	綠堅
CADian LT	CD+掖營1掏	25,000錳	AutoCAD 渠擬
CADian LT ARCH	CD+掖營2掏	45,000錳	勒蹴撲啗辨
CADian LT MECH	CD+掖營2掏	60,000錳	晦啗睡ゴ5,000虜偃頂濰

≦ ESD煎掘衙ビ衛賊 5,000錳ブ檣.

﹥ 掘殮寞徹

函'フ措檣蘿葬葆馨冂'曖 �［檜雖 www.kimcad.co.kr曖 陛薑辨塭檜摹蝶 縑憮褐羶

刻フ旋婁闡タ攪,⺕試闡,爾僭撰,膠橫錚橫囀葬嬴(嬴檜援葬) ,模ヅ⑷綠蟒-MSshop 蛔曖檣攪喘澗ヒ

路醞 ESD 傳朝 棻遴煎萄憧 囀傘縑憮掘殮

http://www.koreasoft.com/viewSoftware.jsp?pcode=ESD1005260

≦ESD : Electronic Software Delivery(棻遴煎萄煎掘衙)

券憮選衛頂渠И憮薄(謙煎,艙シ,囀縈蝶曖憮選僥堅蛔)縑憮掘殮

掘殮僥曖:フ措檣蘿葬葆馨冂
http://www.kimcad.co.kr
E-Mail : young@kimcad.co.kr
瞪�:(02)6436-3685

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Tue Feb 26 22:39:00 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00941 for ; Tue, 26 Feb 2002 22:38:59 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id VAA06371 for ietf-krb-wg-outgoing; Tue, 26 Feb 2002 21:19:41 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA06365 for ; Tue, 26 Feb 2002 21:19:40 -0600 (CST) Received: from localhost ([211.217.173.10]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id VAA06774 for ; Tue, 26 Feb 2002 21:19:38 -0600 (CST) Message-Id: <200202270319.VAA06774@dns2.anl.gov> Reply-To: gotours@dreamwiz.com From: 罹ヤ陛濠 To: ietf-krb-wg@anl.gov Subject: [檜漸⑷惜堅]鼠猿 �錳陛殮ビ衛賊ボ諼鼠猿罹ヤ掏擊萄董棲棻. Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 27 Feb 2002 12:16:24 +0900 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk 罹ヤ陛濠螃テ晦喃戲煎 �錳陛殮衛 [鷓措,ノ葬ネ,餌檜匸] 鼠猿ボ諼罹ヤ掏擊萄董棲棻.

[檜漸⑷1] = 罹ヤ陛濠 �［檜雖螃テ晦喃戲煎 �錳陛殮衛 [鷓措,ノ葬ネ,餌檜匸]
鼠猿ボ諼罹ヤ掏擊萄董棲棻. [ホ奢掏滌紫 ]
晦除 : 2002喇 2錯18橾 ~ 4錯 30橾梱雖渠鼻 : 罹ヤ陛濠褐敘�錳陛殮濠瞪錳隸薑

[檜漸⑷2] = 輿嬪曖唸�ビ衛朝碟菟縑啪盪⻣罹ヤ陛濠蒂模偃衛麵輿敷憮褐�罹ヤ檜
啗擒腎賊啗擒婁翕衛縑啗謝煎橾旎 50,000錳擊殮旎ボ萄董棲棻.
(欽薯輿紫褐�罹ヤ擎 20,000錳)
罹ヤ陛濠 �［檜雖夥煎陛晦

敝ビ曖蝓塊橈檜 �爾撩瞪濠辦ぇ擊爾頂啪脹薄薑醞ɛ 餌婁萄董棲棻.
薑爾鱔褐蜂檜辨襠霞徹敘薑擊遽熱ビ罹惜堅詭橾歜擊ォ衛ビ艘戲貊, 熱褐剪睡濰纂蒂葆溼ビ堅氈蝗棲棻.
敝ビ曖瞪濠辦ぇ輿模朝檣攪喘鼻曖奢偃脹濰模縑憮蝗菜ビ艘戲貊, 盪⻣朝敝ビ曖瞪濠辦ぇ輿模諼橫集フ偃檣薑爾紫陛雖堅氈雖彊戲嘎煎寰褕ビ衛晦夥奧棲棻. 熱褐擊錳纂彊戲衛賊 蒂贗葛ボ輿褊衛蹂.

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 27 00:30:02 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03372 for ; Wed, 27 Feb 2002 00:30:01 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id XAA13702 for ietf-krb-wg-outgoing; Tue, 26 Feb 2002 23:15:41 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id XAA13696 for ; Tue, 26 Feb 2002 23:15:40 -0600 (CST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id XAA25490 for ; Tue, 26 Feb 2002 23:15:40 -0600 (CST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA17231; Wed, 27 Feb 2002 00:15:39 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA00707; Wed, 27 Feb 2002 00:15:39 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA26516; Wed, 27 Feb 2002 00:15:39 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id AAA00049; Wed, 27 Feb 2002 00:15:38 -0500 (EST) Date: Wed, 27 Feb 2002 00:15:38 -0500 (EST) Message-Id: <200202270515.AAA00049@tir-na-nogth.mit.edu> From: Sam Hartman To: iesg@ietf.org CC: ietf-krb-wg@anl.gov Subject: Comments on draft-ietf-cat-kerberos-set-passwd-06.txt Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk I have three major concerns with the set-password draft: 1) It modifies the Kerberos protocol . It seems that an application of Kerberos should not modify the Kerberos protocol in the process of specification of that application. 2) International passwords set using this protocol will be compatible neither with current implementations nor with revisions to the protocol likely to come out of the working group. In addition, the proposal is likely to break as Unicode normalization rules and character sets change over time. 3) The protocol misuses ASN.1 and does not properly specify extensibility behavior; this will mean that future extensions will likely need to be new protocols. 4) The client, rather than the KDC chooses random keys for services. I will provide details about these concerns, but first I would like to apologize that I am bringing these issues to the attention of the IESG at such a late date and that they were handled badly within the WG last call. Some of the issues (#1, parts of #3, and #4) were brought up during one of the two working group last calls on this document. However many of the people bringing forward these issues have been focusing on the Kerberos protocol itself rather than auxiliary documents like the password changing protocol. From my perspective it seems like people did take the time to review the document and bring up comments but did not manage to find time to follow through on their comments, and so these issues are still present. Issue Details Changes to Kerberos Protocol: In section four of the document, the protocol says that a recipient should ignore the sender address: KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted using the subsession key from the authenticator in the AP-REQ. The authenticator MUST contain a subsession key. The timestamp and usec fields of the KRB-PRIV message MUST be present, and the data values MUST be copies of the same data values from the authenticator. The recipient should ignore the sender address field in the KRB-PRIV message. However, according to RFC 1510, this check is not optional: The recipient verifies that the operating system's report of the sender's address matches the sender's address in the message, and (if a recipient address is specified or the recipient requires an address) that one of the recipient's addresses appears as the recipient's address in the message. A failed match for either case generates a KRB_AP_ERR_BADADDR error. We can resolve this inconsistency either by claiming that the set password protocol revises the Kerberos protocol and amends RFC 1510 or claiming that since the Kerberos protocol mandates the check, all vendors have a good reason for violating the should in the password protocol and thus the should clause has no effect. From my standpoint making either claim is undesirable and the password protocol should either wait for a Kerberos protocol that does not mandate address checks or should work with the existing protocol. Internationalization: The set-password protocol transports passwords, encoded as UTF-8 strings in ASN.1 octet strings. No mention is made of UTF-8 normalization rules, character set repertoire, etc. This presents two problems. First, there are significant issues using Unicode passwords with existing Kerberos implementations. Most of these issues are discussed in draft-ietf-krb-wg-info-ascii-00.txt. It would be easy for a user of this protocol to change to a password that clients in the realm cannot use. This might be acceptable. However, I'm much more concerned about the evolution of this protocol as Kerberos adopts a real internationalization solution. It seems likely that Kerberos will adopt a profile for stringprep (draft-hoffman-stringprep-00.txt) as part of the internationalization solution. In the terms of section 6 of that draft, passwords are stored strings. Interoperability problems can result if a codepoint that is mapped out, prohibited or allowed ever moves to another category. For stored strings, interoperability problems can result if an unassigned codepoint is used in a stored string. Since the set password draft uses Unicode without specifying normalization or mapping rules, it seems very likely that both of these types of interoperability problems will eventually result when a real internationalization solution is adopted. That is, passwords set with this protocol may stop working as clients begin to implement the Kerberos normalization and mapping rules. ASN.1 and Extensibility uses: Section 4 of the document requires that servers and clients be prepared for extensions to the structures: For forward compatibility, the server should be prepared to ignore fields after targrealm in the structure that it does not understand. Unfortunately, the ASN.1 sequence is defined without an extension marker. As we are finally discovering with the base Kerberos protocol many ASN.1 implementations will reject an encoding of a sequence containing unexpected fields . While there has been some debate within the working group on how important it is to fix the ASN.1 in the Kerberos protocol, it seems clear that standardizing protocols that have known broken ASN.1 is a bad idea. In addition, the contents of the salt and salt type fields (and their use) is unspecified. There seems to be an impression in the draft that salt strings are enctype specific and that salt types are not needed with current crypto systems. The hope seems to be (expressed more clearly in list discussion than the draft) that future crypto system documents will make it clear what to put in these fields. These assumptions are inconsistent both with existing practice and with draft-ietf-krb-wg-crypto-00.txt. Salt types are not defined in that draft, but the usage of the salt string is defined. The salt string is crypto system independent; significant effort was recently made to maintain the crypto system independence of salts even for AES. I do not see any document that is likely to come forward and clarify these fields in the set-password protocol in the future; as such I am concerned that these fields will confuse vendors and implementers. I suspect we will have interoperability problems because salt type is a well-defined concept in several implementations, so it is likely the field will be used with conflicting/different/non-standard values. Security of keys (issue 4): I'll warn that I seem to be the primary proponent of this issue. It may well be there is not working group consensus on this issue; no one has disagreed with me on the list that this is important, but no one picked up the issue when I became too busy to follow through with the author. Traditionally Kerberos KDCs have chosen random keys for services (possibly excluding the Microsoft implementation). The security of the Kerberos authentication protocol depends on the quality of the KDC's randomly generated session keys, so assuming that the KDC is able to generate service keys of high quality seems not unreasonable. Certainly it seems reasonable to assume the KDC will have better entropy than a random service machine. Ideally the service would also be able to contribute entropy to the key setup, but this is not current practice for several implementations. In such implementations it often requires less privilege to set a key to a random value than it does to set a key to an explicit value. This prevents services from choosing weak keys. The current set-password proposal allows a service to request that the KDC contribute entropy to a key it is choosing. However the client ultimately gets to choose what key is written to the database, so the client can choose a weak key. I have two concerns. First, it would be nice if a mechanism were provided to give the KDC the final decision about which key was used, so that the privilege distinction between set to explicit key and set to random key can be maintained. More importantly, the current structure of the protocol seems to increase the likelihood that clients will simply implement the one-exchange set-key using only client entropy rather than the more complex variant allowing the KDC to contribute entropy. It might have been more reasonable to make this variant required on both client and server, or required on client and optional on server than the current MUST for server and no recommendation for client. Thanks for consideration, --Sam From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 27 03:25:23 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13697 for ; Wed, 27 Feb 2002 03:25:22 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id CAA02692 for ietf-krb-wg-outgoing; Wed, 27 Feb 2002 02:14:06 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id CAA02662 for ; Wed, 27 Feb 2002 02:14:04 -0600 (CST) Received: from assaris.sics.se (ASTRAL-VINE.MIT.EDU [18.101.1.27]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id CAA23578 for ; Wed, 27 Feb 2002 02:14:03 -0600 (CST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id JAA77207; Wed, 27 Feb 2002 09:14:27 +0100 (CET) (envelope-from assar) From: assar@kth.se To: Sam Hartman Cc: iesg@ietf.org, ietf-krb-wg@anl.gov Subject: Re: Comments on draft-ietf-cat-kerberos-set-passwd-06.txt References: <200202270515.AAA00049@tir-na-nogth.mit.edu> Date: 27 Feb 2002 09:14:26 +0100 In-Reply-To: Sam Hartman's message of "Wed, 27 Feb 2002 00:15:38 -0500 (EST)" Message-ID: <5lbsebxrx9.fsf@assaris.sics.se> Lines: 41 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Sam Hartman writes: > I have three major concerns with the set-password draft: > > 1) It modifies the Kerberos protocol . It seems that an application > of Kerberos should not modify the Kerberos protocol in the process > of specification of that application. > > 2) International passwords set using this protocol will be compatible > neither with current implementations nor with revisions to the > protocol likely to come out of the working group. In addition, > the proposal is likely to break as Unicode normalization rules and > character sets change over time. > > 3) The protocol misuses ASN.1 and does not properly specify > extensibility behavior; this will mean that future extensions will > likely need to be new protocols. I see Sam's issues (1) - (3) as a general problem, namely that this protocol is between rfc1510 and the future rfc on Kerberos 5. While being based on RFC1510, it tries to be compatible with some future enhancements that are believed will arrive in the new RFC. This seems like a bad idea. Either it should be solely based on 1510 or wait for the new RFC to come and be based on that. What will be status of this protocol if the issues are not resolved in the forseen way in the upcoming new Kerberos RFC? Trying to be compatible with a future standard leaves dangling threads (such as the unspecified and `unused' salt fields). This document also brings up new issues not handled in either 1510 or the current i-d on kerberos revisions, such as a preferred ordering of keys for a principal. I think that is something that should be described in the Kerberos rfc and not in the change/set password one. The `key version' in the user-data portion of the reply message is only 16 bits. The specification of that same quantity is unlimited in 1510, and while still unlimited in the revisions i-d, there seems to be consensus around a 32 bit value. I believe a common implementation uses 32 bits for key version numbers and if that's the case it seems bad to limit the field in this protocol to 16 bits. /assar From owner-ietf-krb-wg@atalanta.ctd.anl.gov Wed Feb 27 12:48:35 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06040 for ; Wed, 27 Feb 2002 12:48:35 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id LAA20997 for ietf-krb-wg-outgoing; Wed, 27 Feb 2002 11:37:20 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA20805 for ; Wed, 27 Feb 2002 11:37:19 -0600 (CST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA08761 for ; Wed, 27 Feb 2002 11:37:18 -0600 (CST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GS700GI8CY6X9@smtp.fnal.gov> for ietf-krb-wg@anl.gov; Wed, 27 Feb 2002 11:37:18 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id g1RHbFZ16349; Wed, 27 Feb 2002 11:37:15 -0600 (CST) Date: Wed, 27 Feb 2002 11:37:15 -0600 From: Matt Crawford Subject: Re: Comments on draft-ietf-cat-kerberos-set-passwd-06.txt In-reply-to: "27 Feb 2002 00:15:38 EST." <200202270515.AAA00049@tir-na-nogth.mit.edu> To: Sam Hartman Cc: iesg@ietf.org, ietf-krb-wg@anl.gov Message-id: <200202271737.g1RHbFZ16349@gungnir.fnal.gov> Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk > 4) The client, rather than the KDC chooses random keys for services. > [...] > However the client ultimately gets to choose what key is written to > the database, so the client can choose a weak key. Worse, the client could choose a key that is derivable from a weak password. Maybe this is what you meant, but I think it's worse than a client with a poor RNG -- a realm supporting this service would be completely unable to enforce a password quality policy! From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 28 07:30:45 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19302 for ; Thu, 28 Feb 2002 07:30:45 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id GAA21639 for ietf-krb-wg-outgoing; Thu, 28 Feb 2002 06:09:41 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id GAA21627 for ; Thu, 28 Feb 2002 06:09:38 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id GAA00790 for ; Thu, 28 Feb 2002 06:09:37 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18264; Thu, 28 Feb 2002 07:08:00 -0500 (EST) Message-Id: <200202281208.HAA18264@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-krb-wg@anl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-krb-wg-kerberos-clarifications-00.txt Date: Thu, 28 Feb 2002 07:08:00 -0500 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberos WG Working Group of the IETF. Title : The Kerberos Network Authentication Service (V5) Author(s) : C. Neuman et al. Filename : draft-ietf-krb-wg-kerberos-clarifications-00.txt Pages : Date : 27-Feb-02 This document provides an overview and specification of Version 5 of the Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-krb-wg-kerberos-clarifications-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020227125312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-krb-wg-kerberos-clarifications-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020227125312.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 28 07:31:17 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19333 for ; Thu, 28 Feb 2002 07:31:17 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id GAA21638 for ietf-krb-wg-outgoing; Thu, 28 Feb 2002 06:09:41 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id GAA21626 for ; Thu, 28 Feb 2002 06:09:38 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id GAA00789 for ; Thu, 28 Feb 2002 06:09:37 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18245; Thu, 28 Feb 2002 07:07:56 -0500 (EST) Message-Id: <200202281207.HAA18245@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-krb-wg@anl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-krb-wg-utf8-profile-00.txt Date: Thu, 28 Feb 2002 07:07:56 -0500 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberos WG Working Group of the IETF. Title : Stringprep Profile for Kerberos UTF-8 Strings Author(s) : J. Altman Filename : draft-ietf-krb-wg-utf8-profile-00.txt Pages : Date : 27-Feb-02 This document describes how to prepare UTF-8 strings in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This is a profile of the stringprep protocol developed in the IDN working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-utf8-profile-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-krb-wg-utf8-profile-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-krb-wg-utf8-profile-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020227125301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-krb-wg-utf8-profile-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-krb-wg-utf8-profile-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020227125301.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 28 12:43:10 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07699 for ; Thu, 28 Feb 2002 12:43:10 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id LAA25770 for ietf-krb-wg-outgoing; Thu, 28 Feb 2002 11:26:00 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA25764 for ; Thu, 28 Feb 2002 11:25:52 -0600 (CST) Received: from localhost ([211.199.252.73]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id LAA07857 for ; Thu, 28 Feb 2002 11:25:51 -0600 (CST) Message-Id: <200202281725.LAA07857@dns2.anl.gov> Reply-To: tnshfdma@hamir.com From: 熱啾擠罹ヤ餌 To: ietf-krb-wg@anl.gov Subject: [惜堅]薯輿2夢3橾婦惜ホ奢蹂旎戲煎~~~~ Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 1 Mar 2002 02:20:33 +0900 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk

≧薯輿罹ヤ≧

薯輿熱啾擠罹ヤ餌

ョ塊橈檜詭橾爾頂啪腎橫賸歎ベ棲棻, 椒縑渠フ薑爾朝詭橾輿模諼縑朝瞪Б橈擰棲棻

褐�罹ヤ僥曖

橾奩彐酈雖

ホ奢ブ檣

フ塭骯蛔奩

3錯 4錯 5錯褐�罹ヤ蕨擒嫡擠!!

薯輿熱啾擠彐酈雖(橾奩)

橾薑ォ諦蹂旎

SNU,彐酈雖2夢3橾(2橾婦惜,3橾婦惜)橾薑ォ

2橾婦惜

2錯.23.25.26.28.

3錯2,4.5.7.8.9.11.12.13.14.15.16.18.19.20.21

.22.23.25.26.27.28.29.30

@3錯檣唳辦:螃瞪轎嫦橾,8,15,22,29, 陳瞼葆棻衛除檜褻旎噶棻落棲棻,

嬪橾擊薯諼フ轎嫦衛除擎, 12衛瞪�諦 15衛瞪�陛腆匙殮棲棻

3橾婦惜:

2錯,26.27.28.

3錯3橾,10,17,24,31, (3橾婦惜轎嫦擎螃瞪7衛瞪�殮棲棻)

2橾婦惜唳綠:167.300錳(橾奩龱蘿) *梯け轎嫦12,07衛瞪�,

3橾婦惜唳綠:175.300錳(橾奩龱蘿) *梯け轎嫦07衛瞪�

@,婦惜龱蘿檣唳辦 1檣,25000錳蹺陛

2橾婦惜囀蝶

﹥ 1橾簞: 薯輿奢ホ紫雜天>霜錳虜陴天>熨模檜翕 (濠嶸衛除)

2橾簞 : 措董團樓夢僭婦天>蹂獎紫煎天>骯寞骯天>醞衝天>罹嘐雖衝僭錳天>

輿鼻瞰葬渠天>擒繭餌天>婦惜堯錳天>繭雖翱げけ天>5.16紫煎天>熨模

3橾簞 : 骯推睡葬天>薑戮ホ奢婦天>撩擰團樓葆擊天>醞衝天>撥雖囀雖天>澗

ヒ天>羹レ橫濰天>薯輿ボ喪ホ橾晦喃婦天>堯熱骯僭霜衙濰天> 奢ホ

3橾婦惜囀蝶

1橾簞 : 措董團樓夢僭婦天>蹂獎紫煎天>骯寞骯天>醞衝天>罹嘐雖衝僭錳天>

輿鼻瞰葬渠天>擒繭餌天>婦惜堯錳天>繭雖翱げけ天>5.16紫煎天>熨模

2橾簞:フ塭骯蛔奩(8衛除模蹂)->辨舒懍->餌塭瑰⑷楚韁�熨模->濠嶸衛除

3橾簞 : 骯推睡葬天>薑戮ホ奢婦天>撩擰團樓葆擊天>醞衝天>撥雖囀雖天>澗

ヒ天>羹レ橫濰天>薯輿ボ喪ホ橾晦喃婦天>堯熱骯僭霜衙濰天> 奢ホ

@,けヘ頂羲,

2橾婦惜, 衝餌4�, 薯輿瞪橾薑殮濰蹂旎

3橾婦惜,衝餌5�,
http://www.sunolum.co.kr

翱塊籀 : 064)721-1210, 064)724-8884,

獄詭橾擎薑爾鱔褐睡掏堅餌ホ縑曖剪薯跡縑 [惜堅]塭ォ衛脹惜堅詭橾殮棲棻幗⑹擊贗葛ビ衛賊熱褐剪睡籀葬陛檜瑞橫餵棲棻.

From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Feb 28 20:57:33 2002 Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28988 for ; Thu, 28 Feb 2002 20:57:32 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id TAA22608 for ietf-krb-wg-outgoing; Thu, 28 Feb 2002 19:47:08 -0600 (CST) Received: from dns2.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA22602 for ; Thu, 28 Feb 2002 19:47:07 -0600 (CST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA01403 for ; Thu, 28 Feb 2002 19:47:06 -0600 (CST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Feb 2002 17:45:41 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Feb 2002 17:45:41 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 17:45:40 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 17:45:39 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 28 Feb 2002 17:43:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Comments on draft-ietf-krb-wg-kerberos-clarifications-00.txt Date: Thu, 28 Feb 2002 17:43:46 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD03969497@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Comments on draft-ietf-krb-wg-kerberos-clarifications-00.txt Thread-Index: AcHAwumnUWb/WG7KTUeG0wMclU1UbA== From: "John Brezak" To: , X-OriginalArrivalTime: 01 Mar 2002 01:43:46.0471 (UTC) FILETIME=[8707D370:01C1C0C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by atalanta.ctd.anl.gov id TAA22603 Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit A few comments/nits: 1) Section 1.4.1 - 3rd paragraph - The server behavior is described, what about the KDC? For the KDC is the SHOULD a MUST? 2) Are we leaving anonymous tickets in? 3) Section 2.9 - text says "three additional options", but only 2 are enumerated. 4) Section 3.1.4 - residual reference to "e-cksum". 5) Section 3.6.1 - To remain compatible with MIT and Heimdal, the encrypted part of the KERB-CRED message in a GSSAPI initial context token is encrypted with the null enctype. Microsoft does use the null enctype when either des-cbc-crc or des-cbc-md5 is used to retain compat with other implementations. For rc4-hmac, the encrypted part of the kerb-cred is encrypted with rc4-hmac. 6) Section5.2.1 - Is it necessary to suggest the use of CHOICE anymore? I would suggest removing the 4th and 5th paragraphs. 7) Section 5.2.1 - Paragraph 8. As I understand it, there is no escape sequence for using UTF-8 in GeneralString at all. So everything beyond the 2nd sentence should be removed. 8) Section 5.2.7 - The padata-type for pa-etype-info should be 11 (not 10) in the table. 9) Section 5.2.7.4 - There is a comment about "not clear whether ETYPE-INFO or PW-SALT should take precedence if they conflict". I do not believe there is currently a case where they conflict. PW-SALT is only included in a pa-data of a AS-REP while ETYPE-INFO is ever only in the e-data of a KRB-ERROR. PW-SALT is only used when preauth is not required. I would like to see use of PW-SALT depricated because it can only tell you about a single salt value per enctype. In this case providing an ETYPE-INFO can be in a non-preauth case of an AS-REP and server the same purpose as the PW-SALT. 10) Section 5.3.1 - "authorization-data" - The second paragraph implies that authorization-data carried in the Authenticator is added to the ticket in the case of the TGS-REQ. Is this correct? 11) Section 5.4.1 - "CANONICALIZE" flag - How about this description instead - "The CANONICALIZE option indicates that the client will accept the return of a principal name different from the principal names in the request. This can apply to either the cname or sname fields. If the KDC does not support name-canonicalization, the option is ignored and the appropriate KDC_ERR_C_PRINCIPAL_UNKNOWN or KDC_ERR_S_PRINCIPAL_UNKNOWN error is returned. 12) Section 5.4.1 - "till" - Since till is no longer optional, the text implying that it is should be removed and the special value used for the time included. I will find out what value Windows2000 uses for "maximum till time allowed by realm". 13) Section 5.4.2 - padata - refers to section 6.3.2 - should be 5.2.7.3 14) Section 6.2 - Add note about when it is appropriate for the KDC to return a KDC-ERR-BAD-PVNO error. I would recommend that it is never an appropriate error especially given that we agree that the pvno field in the messages is not useful. So anything other than "5" is a badly formed request and should be dropped. 15) Section 6.2 - Include a note about a KDC never returning a KRB_AP_ERR_REPEAT. It must always return a response to a request (regardless of transport mechanism). 16) Section 7.2 - NT-SMTP-NAME (7) and NT-ENTERPRISE (10) are both defined. NT-ENTERPRISE is used in Kerb-Referrals. What is NT-SMTP-NAME (7) used for? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak * mailto:jbrezak@microsoft.com Microsoft Corporation * 425-706-2602 One Microsoft Way Redmond, WA 98052

2.1. Initial, pre-authenticated, and hardware authenticated -tickets

2.1. Initial, pre-authenticated, and hardware authenticated tickets

2.9. Other KDC options

1.4. Environmental assumptions

1.4. Extensibility Model

1.4.1. Compatibility with RFC 1510

1.4.2. Sending Extensible Messages

1.4.3. Receiving Extensible Messages

1.5. Authenticating Cleartext Portions of Messages

1.6. Environmental assumptions

1.5. Glossary of terms

1.7. Glossary of terms

掖鱔餌堅 爾鼻鼻氬 寰頂

1.4. Environmental assumptions

1.4. Extensibility Model

1.4.1. Compatibility with RFC 1510

1.4.2. Sending Extensible Messages

1.4.3. Receiving Extensible Messages

1.4. Extending Kerberos Without Breaking Interoperability

1.5. Authenticating Cleartext Portions of Messages

1.6. Environmental assumptions

1.5. Glossary of terms

1.7. Glossary of terms

2.1. Initial, pre-authenticated, and hardware authenticated -tickets

2.1. Initial, pre-authenticated, and hardware authenticated tickets

2.9. Other KDC options

3.1. The Authentication Service Exchange

3.1.1. Generation of KRB_AS_REQ message

3.1.2. Receipt of KRB_AS_REQ message

3.1.3. Generation of KRB_AS_REP message

3.1.4. Generation of KRB_ERROR message

3.1.5. Receipt of KRB_AS_REP message

3.2.3. Receipt of KRB_AP_REQ message

3.2.5. Receipt of KRB_AP_REP message

3.2.6. Using the encryption key

3.3.1. Generation of KRB_TGS_REQ message

3.3.2. Receipt of KRB_TGS_REQ message

3.6.2. Receipt of KRB_CRED message

掖鱔餌堅爾鼻鼻氬寰頂