From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 1 15:03:27 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA06610; Mon, 1 Jun 98 15:03:27 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id MAA03687; Mon, 1 Jun 1998 12:03:19 -0700 (PDT) Date: Mon, 1 Jun 1998 12:03:19 -0700 (PDT) Message-Id: <199806011903.MAA03687@lists.Stanford.EDU> To: cat-ietf-archive@bitsy.MIT.EDU From: Majordomo@lists.Stanford.EDU Subject: Welcome to ietf-cat-wg Reply-To: Majordomo@lists.Stanford.EDU -- Welcome to the ietf-cat-wg mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo@lists.Stanford.EDU" with the following command in the body of your email message: unsubscribe ietf-cat-wg Here's the general information for the list you've subscribed to, in case you don't already have it: This is the info file for ietf-cat-wg. Further information will be provided by the owner of this list who can be contacted at: ietf-cat-wg-owner@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 2 09:05:35 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA25350; Tue, 2 Jun 98 09:05:35 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id FAA18297 for ietf-cat-wg-out720680; Tue, 2 Jun 1998 05:37:00 -0700 (PDT) Received: from tholian.securid.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id FAA18292 for ; Tue, 2 Jun 1998 05:36:58 -0700 (PDT) Received: from mail.securid.com by tholian.securid.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 2 Jun 1998 12:38:36 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id IAA26026; Tue, 2 Jun 1998 08:40:56 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Tue, 2 Jun 1998 08:39:40 -0400 Message-Id: From: "Linn, John" To: "'CAT-WG List'" Cc: "'Cynthia Clark'" Subject: CAT mailing list has moved Date: Tue, 2 Jun 1998 08:37:11 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk CAT List fanciers: Thanks to the generous support of Bob Morgan and Booker Bense at Stanford University, we've now transitioned the CAT-WG mailing list into Majordomo management at Stanford. The new address for list traffic is: Ietf-cat-wg@lists.stanford.edu Adminstrative requests should go to: Ietf-cat-wg-request@lists.stanford.edu The forwarding pointers at cat-ietf[-request]@mit.edu are being changed to redirect to these addresses. --jl ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 2 10:02:33 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA26324; Tue, 2 Jun 98 10:02:33 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id GAA19263 for ietf-cat-wg-out720680; Tue, 2 Jun 1998 06:27:18 -0700 (PDT) Received: from tholian.securid.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id GAA19256 for ; Tue, 2 Jun 1998 06:27:16 -0700 (PDT) Received: from mail.securid.com by tholian.securid.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 2 Jun 1998 13:28:54 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id JAA27690; Tue, 2 Jun 1998 09:30:45 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Tue, 2 Jun 1998 09:29:29 -0400 Message-Id: From: "Linn, John" To: "'Jeff Schiller'" , "'Marcus Leech'" Cc: "'CAT-WG List'" Subject: CAT WG requests IESG consideration of idup-gss-11 for Proposed St andard Date: Tue, 2 Jun 1998 09:26:59 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Jeff and Marcus, On behalf of the CAT WG, I would like to request that the IESG consider draft-ietf-cat-idup-gss-11.txt, "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)" for the status of Proposed Standard. Successive versions of this draft have been the subject of ongoing review and discussion within the WG for some time, and it has been agreed WG intent to pursue advancement of IDUP to Proposed Standard. The current version resolves identified issues and I believe represents consensus for an advancement recommendation among the community of WG participants who have been involved with the development and consideration of this document. Thanks, --jl ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 2 10:21:26 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA26674; Tue, 2 Jun 98 10:21:26 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id GAA19653 for ietf-cat-wg-out720680; Tue, 2 Jun 1998 06:40:29 -0700 (PDT) Received: from tholian.securid.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id GAA19648 for ; Tue, 2 Jun 1998 06:40:27 -0700 (PDT) Received: from mail.securid.com by tholian.securid.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 2 Jun 1998 13:42:05 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id JAA27973 for ; Tue, 2 Jun 1998 09:44:25 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Tue, 2 Jun 1998 09:43:09 -0400 Message-Id: From: "Linn, John" To: "'CAT-WG List'" , "Linn, John" Subject: RE: CAT mailing list has moved Date: Tue, 2 Jun 1998 09:40:39 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At the risk of being redundantly administrivial, but to avoid possible confusion if any recipients have not received autosubscribe messages from the Stanford majordomo: the set of active subscribers has been carried over from the previous exploder, so there is no need to resubscribe. --jl ---------- From: Linn, John [SMTP:jlinn@securitydynamics.com] Sent: Tuesday, June 02, 1998 8:37 AM To: 'CAT-WG List' Cc: 'Cynthia Clark' Subject: CAT mailing list has moved CAT List fanciers: Thanks to the generous support of Bob Morgan and Booker Bense at Stanford University, we've now transitioned the CAT-WG mailing list into Majordomo management at Stanford. The new address for list traffic is: Ietf-cat-wg@lists.stanford.edu Adminstrative requests should go to: Ietf-cat-wg-request@lists.stanford.edu The forwarding pointers at cat-ietf[-request]@mit.edu are being changed to redirect to these addresses. --jl ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 2 13:45:00 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA00267; Tue, 2 Jun 98 13:45:00 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id KAA26929 for ietf-cat-wg-out720680; Tue, 2 Jun 1998 10:07:10 -0700 (PDT) Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id KAA26922 for ; Tue, 2 Jun 1998 10:07:06 -0700 (PDT) Message-Id: <199806021806.TAA23328@ns0.zergo.com> Received: forwarded by SMTP 3.0.6. From: Ian Roberts Date: Tue, 2 Jun 1998 19:06:28 +0000 To: Ietf-cat-wg@lists.stanford.edu Subject: gss_inquire_cred question Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Should the cred_name returned by gss_inquire_cred contain all the name =20 elements passed in the desired_name parameter to gss_acquire_cred or =20 should it contain only name elements relating to mechanisms in the =20 desired_mechs parameter of the original gss_acquire_cred call? =20 ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 2 16:27:15 1998 Received: from [171.64.14.232] by bitsy.MIT.EDU with SMTP id AA03084; Tue, 2 Jun 98 16:27:15 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id MAA04474 for ietf-cat-wg-out720680; Tue, 2 Jun 1998 12:43:57 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id MAA04469 for ; Tue, 2 Jun 1998 12:43:53 -0700 (PDT) Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP id AA22714; Tue, 2 Jun 98 15:43:43 EDT Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.sap-ag.de (out) with SMTP id VAA29738; Tue, 2 Jun 1998 21:43:28 +0200 (MESZ) Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA13902; Tue, 2 Jun 1998 21:42:10 +0200 Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id VAA05199; Tue, 2 Jun 1998 21:42:14 +0200 (METDST) From: Martin Rex Message-Id: <199806021942.VAA05199@hw1464.wdf.sap-ag.de> Subject: Re: gss_inquire_cred question To: iroberts@zergo.com (Ian Roberts) Date: Tue, 2 Jun 1998 21:42:13 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <199806021806.TAA23328@ns0.zergo.com> from "Ian Roberts" at Jun 2, 98 07:06:28 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ian Roberts wrote: > > Should the cred_name returned by gss_inquire_cred contain all the name > elements passed in the desired_name parameter to gss_acquire_cred or > should it contain only name elements relating to mechanisms in the > desired_mechs parameter of the original gss_acquire_cred call? The current spec leaves this basically implementation defined. For compliance you may choose whatever you can implement the easiest and most robust. What effect (if any) this has on applications largely depends on what applications actually care to do with the resulting gss_name_t (by itself it's just an abstract handle). If the application tries to display it, it might be helpful if only the meaningful parts of the internal name are retained and displayed. Personally, I would suggest that you only copy/retain the meaningful parts in your credentials object. -Martin ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Jun 3 06:38:22 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA18322; Wed, 3 Jun 98 06:38:22 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id DAA06475 for ietf-cat-wg-out720680; Wed, 3 Jun 1998 03:02:12 -0700 (PDT) Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id DAA06470 for ; Wed, 3 Jun 1998 03:02:08 -0700 (PDT) Message-Id: <199806031101.MAA25514@ns0.zergo.com> Received: forwarded by SMTP 3.0.6. From: Ian Roberts Date: Wed, 3 Jun 1998 12:02:25 +0000 To: Ietf-cat-wg@lists.stanford.edu Subject: gss_add_cred question Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I am looking at the semantics of gss_add_cred with GSS_C_NO_CREDENTIAL =20 specified as input_cred_handle=2E In this case the document states =20 "gss_add_cred() will create the credential referenced by its =20 output_cred_handle based on default behaviour=2E That is, the call will =20 have the same effect as if the caller had previously called =20 gss_acquire_cred(), specifying the same usage and passing GSS_C_NO_NAME =20 as the desired_name parameter=2E=2E=2E" later it also states "The same inp= ut =20 desired_name, or default reference, should be used on all =20 gss_acquire_cred() and gss_add_cred() calls corresponding to a particular =20= =20 credential=2E" >From these statements I have drawn the following conclusion; If the input_cred_handle is GSS_C_NO_CREDENTIAL then the desired_name =20 must be GSS_C_NO_NAME (since the effect is the same "as if the caller had =20= =20 previously called gss_acquire_cred(), specifying the same usage and =20 passing GSS_C_NO_NAME as the desired_name parameter" and "the same input =20 desired_name, or default reference, should be used on all =20 gss_acquire_cred() and gss_add_cred() calls corresponding to a particular =20= =20 credential") - is this correct? Also, it does not explicitly specify which desired_mechs are used - I =20 presume the 'default behaviour' would be an empty set which selects a =20 system-defined default=2E However from this I would assume that any call to gss_add_cred, using =20 GSS_C_NO_CREDENTIAL where the mechanism is within the system-defined =20 default set of mechanisms would return GSS_S_DUPLICATE_ELEMENT - is this =20 correct? Finally "The same input desired_name, or default reference, should be =20 used on all gss_acquire_cred() and gss_add_cred() calls corresponding to =20 a particular credential" appears to be difficult to detect (this is =20 related to my earlier question on credentials name elements) - but if it =20 is detected what should be returned - GSS_S_BAD_NAME? =20 ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Jun 3 11:05:11 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA22928; Wed, 3 Jun 98 11:05:11 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id HAA12005 for ietf-cat-wg-out720680; Wed, 3 Jun 1998 07:32:28 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id HAA12000 for ; Wed, 3 Jun 1998 07:32:25 -0700 (PDT) Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP id AA12298; Wed, 3 Jun 98 10:32:09 EDT Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.sap-ag.de (out) with SMTP id QAA15152; Wed, 3 Jun 1998 16:31:53 +0200 (MESZ) Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA23386; Wed, 3 Jun 1998 16:30:35 +0200 Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id QAA17378; Wed, 3 Jun 1998 16:30:22 +0200 (METDST) From: Martin Rex Message-Id: <199806031430.QAA17378@hw1464.wdf.sap-ag.de> Subject: Re: gss_add_cred question To: iroberts@zergo.com (Ian Roberts) Date: Wed, 3 Jun 1998 16:30:22 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <199806031101.MAA25514@ns0.zergo.com> from "Ian Roberts" at Jun 3, 98 12:02:25 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ian Roberts wrote: > > From these statements I have drawn the following conclusion; > > If the input_cred_handle is GSS_C_NO_CREDENTIAL then the desired_name > must be GSS_C_NO_NAME (since the effect is the same "as if the caller had > previously called gss_acquire_cred(), specifying the same usage and > passing GSS_C_NO_NAME as the desired_name parameter" and "the same input > desired_name, or default reference, should be used on all > gss_acquire_cred() and gss_add_cred() calls corresponding to a particular > credential") - is this correct? IMO, this is a recommendation for application programmers rather than an constraint for the gssapi mechanism designers/implementers. "The same" in this situation should not meant to be taken literally. The idea is that compare_name(orig_name,next_name)==TRUE, or with other words, the GSS-API spec strongly discourages creating composite credentials that refer to knowingly distinct identities/principals. Such a collision would be obvious where the administrative user space spans several mechanisms, or where a gssapi implementations uses distinct INITIATE and ACCEPT credentials and the application requests to create/compose a BOTH credential. For example a Kerberos implementation should not compose a BOTH credential handle that will authenticate as usera@FOO.EDU when used with gss_init_sec_context() and authenticate as host/host.f.q.d.n@FOO.EDU when used with gss_accept_sec_context(). If a Kerberos gssapi mech implementation did that, and the application called inquire_cred() on such a credential, what is supposed to happen if the resulting owner_name is passed to gss_compare_name() ? i.e. gss_compare_name( inquire_cred( BOTH ), "usera@FOO.EDU") gss_compare_name( inquire_cred( BOTH ), "host/host.f.q.d.n@FOO.EDU" ) gss_compare_name( "usera@FOO.EDU", "host/host.f.q.d.n@FOO.EDU" ) > > Also, it does not explicitly specify which desired_mechs are used - I > presume the 'default behaviour' would be an empty set which selects a > system-defined default. > > However from this I would assume that any call to gss_add_cred, using > GSS_C_NO_CREDENTIAL where the mechanism is within the system-defined > default set of mechanisms would return GSS_S_DUPLICATE_ELEMENT - is this > correct? Unfortunately, that is what the spec says. I'm not particularly happy about it either. The apparent impossibility to create a credential with less than the default components looks slightly like a defect of gss_add_cred(). > > Finally "The same input desired_name, or default reference, should be > used on all gss_acquire_cred() and gss_add_cred() calls corresponding to > a particular credential" appears to be difficult to detect (this is > related to my earlier question on credentials name elements) - but if it > is detected what should be returned - GSS_S_BAD_NAME? See above. The same wasn't meant to be taken literally here. The idea is to prevent composition of self-conflicting gss_name_t as the owner name for a credential. -Martin ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Jun 3 14:36:12 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA26534; Wed, 3 Jun 98 14:36:12 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id LAA20971 for ietf-cat-wg-out720680; Wed, 3 Jun 1998 11:10:56 -0700 (PDT) Received: from dmzsmtp01.cybersafe.com (dmzsmtp01.cybersafe.com [192.156.168.5]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id LAA20965 for ; Wed, 3 Jun 1998 11:10:53 -0700 (PDT) Received: from CyberSafe.COM dmzsmtp01.cybersafe.com id LAA24476; Wed, 3 Jun 1998 11:10:04 -0700 Received: from fw1.cybersafe.com(192.156.168.6) by dmzsmtp01.cybersafe.com via smap (V2.0) id xma024474; Wed, 3 Jun 98 11:09:58 -0700 Received: by fw1.cybersafe.com; id LAA26791 Received: from admsvc02.cybersafe.com(10.2.2.52) by fw1.cybersafe.com via smap (4.0a) id xma026767; Wed, 3 Jun 98 11:08:46 +0800 Received: from CyberSafe.COM kerby.cybersafe.com id LAA29413; Wed, 3 Jun 1998 11:05:48 -0700 (PDT) Received: by CyberSafe.com (SMI-8.6/SMI-SVR4) id LAA09030; Wed, 3 Jun 1998 11:05:25 -0700 From: "David Miller" Message-Id: <980603110525.ZM9028@engsol01.cybersafe.com> Date: Wed, 3 Jun 1998 11:05:25 -0700 In-Reply-To: Ian Roberts "gss_add_cred question" (Jun 3, 12:02pm) References: <199806031101.MAA25514@ns0.zergo.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Ian Roberts , Ietf-cat-wg@lists.Stanford.EDU Subject: Re: gss_add_cred question Cc: david.miller@CyberSafe.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Jun 3, 12:02pm, Ian Roberts wrote: > Subject: gss_add_cred question > I am looking at the semantics of gss_add_cred with GSS_C_NO_CREDENTIAL > specified as input_cred_handle. In this case the document states > "gss_add_cred() will create the credential referenced by its > output_cred_handle based on default behaviour. That is, the call will > have the same effect as if the caller had previously called > gss_acquire_cred(), specifying the same usage and passing GSS_C_NO_NAME > as the desired_name parameter..." later it also states "The same input > desired_name, or default reference, should be used on all > gss_acquire_cred() and gss_add_cred() calls corresponding to a particular > credential." > > >From these statements I have drawn the following conclusion; > > If the input_cred_handle is GSS_C_NO_CREDENTIAL then the desired_name > must be GSS_C_NO_NAME (since the effect is the same "as if the caller had > previously called gss_acquire_cred(), specifying the same usage and > passing GSS_C_NO_NAME as the desired_name parameter" and "the same input > desired_name, or default reference, should be used on all > gss_acquire_cred() and gss_add_cred() calls corresponding to a particular > credential") - is this correct? > I understand what you're saying here, although it seems if I step back and just ask "What is the common sense action?" in this situation, the above verbage just doesn't describe it. I would think that if the input_cred_handle is not supplied, that I should merely add the cred described by the desired_mech, cred_usage, and desired_name. What does defaulting the cred handle have to do with defaulting the identity of the principal for which you desire a cred? > Also, it does not explicitly specify which desired_mechs are used - I > presume the 'default behaviour' would be an empty set which selects a > system-defined default. > I'm reading the spec to say that desired mech is non-optional. So a single mech must be specified. > However from this I would assume that any call to gss_add_cred, using > GSS_C_NO_CREDENTIAL where the mechanism is within the system-defined > default set of mechanisms would return GSS_S_DUPLICATE_ELEMENT - is this > correct? > I'm not sure I follow this. How can it be decided that a cred is a duplicate of another if that other cred is not there? I assume that, if the input_cred_handle is defaulted that one can never get a return value of DUPLICATE. Along those lines, I was confused about duplicate element being implied by "overlapping cred_usage and validity time specifiers." Am I supposed to deem the request to be a duplicate if the input_cred_handle refers to a cred good for 2 more hours, even if the validity time specifiers indicate a desire for a cred good for 4 more hours? > Finally "The same input desired_name, or default reference, should be > used on all gss_acquire_cred() and gss_add_cred() calls corresponding to > a particular credential" appears to be difficult to detect (this is > related to my earlier question on credentials name elements) - but if it > is detected what should be returned - GSS_S_BAD_NAME? > I never assumed that the spec implied that implementors were supposed to detect this. In fact, I don't know how that could be done. David Miller CyberSafe, Inc. > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu >-- End of excerpt from Ian Roberts -- David S. Miller david.miller@cybersafe.com CyberSafe Corporation 425.391.6000 Disclaimer: Opinions expressed here do not necessarily reflect those of the Cybersafe Corporation. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Jun 3 14:59:27 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA26915; Wed, 3 Jun 98 14:59:27 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id LAA22301 for ietf-cat-wg-out720680; Wed, 3 Jun 1998 11:35:56 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id LAA22296 for ; Wed, 3 Jun 1998 11:35:53 -0700 (PDT) Received: from gf.gf.org by MIT.EDU with SMTP id AA23682; Wed, 3 Jun 98 14:35:43 EDT Received: from inside-www.gf.org by firewall.ext via smtpd (for SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) with SMTP; 3 Jun 1998 18:35:40 UT Received: from firewall.gf.org by www.gf.org with smtp (Smail3.1.29.1 #2) id m0yhIAt-000TgRC; Wed, 3 Jun 98 14:22 EDT Message-Id: Received: from jlefevre.dialup.access.net ([166.84.194.85]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 3 Jun 1998 18:35:33 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 03 Jun 1998 14:37:06 -0400 To: cat-ietf@mit.edu From: Michael Smith Subject: Java binding for GSS v. 2 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Anybody else interested in helping define a Java binding for GSS Version 2? This is something my company needs to do (or have done) in any case, so it occurred to me that it would be nice if this could feed into the GSS standardization process. Participation by somebody or somebodies whose understanding of GSS is deeper than mine would certainly be beneficial. So.... any takers? Or does anyone know of work already under way? --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Jun 4 05:50:39 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA13189; Thu, 4 Jun 98 05:50:39 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id CAA28316 for ietf-cat-wg-out720680; Thu, 4 Jun 1998 02:12:03 -0700 (PDT) Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id CAA28310 for ; Thu, 4 Jun 1998 02:11:57 -0700 (PDT) Message-Id: <199806041011.LAA28214@ns0.zergo.com> Received: forwarded by SMTP 3.0.6. From: Ian Roberts Date: Thu, 4 Jun 1998 11:12:12 +0000 To: david.miller@CyberSafe.COM Cc: Ietf-cat-wg@lists.Stanford.EDU Subject: RE: gss_add_cred question Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > On Jun 3, 12:02pm, Ian Roberts wrote: > > Subject: gss_add_cred question > > I am looking at the semantics of gss_add_cred with > > GSS_C_NO_CREDENTIAL specified as input_cred_handle=2E > > In this case the document states "gss_add_cred() will > > create the credential referenced by its > > output_cred_handle based on default behaviour=2E > > That is, the call will have the same effect as if > > the caller had previously called gss_acquire_cred(), > > specifying the same usage and passing GSS_C_NO_NAME > > as the desired_name parameter=2E=2E=2E" later it also > > states "The same input desired_name, or default > > reference, should be used on all gss_acquire_cred() > > and gss_add_cred() calls corresponding to a particular > > credential=2E" > > > >From these statements I have drawn the following conclusion; > > > > If the input_cred_handle is GSS_C_NO_CREDENTIAL then the > > desired_name must be GSS_C_NO_NAME (since the effect is > > the same "as if the caller had previously called > > gss_acquire_cred(), specifying the same usage and > > passing GSS_C_NO_NAME as the desired_name parameter" and > > "the same input desired_name, or default reference, > > should be used on all gss_acquire_cred() and > > gss_add_cred() calls corresponding to a particular > > credential") - is this correct? > > Dave Miller replied: > I understand what you're saying here, although it seems if I step > back and just ask "What is the common sense action?" in this > situation, the above verbage just doesn't describe it=2E I am hoping to implement what is specified - not what is common sense :-) Dave Miller continued: > I would think that if the input_cred_handle is not supplied, > that I should merely add the cred described by the > desired_mech, cred_usage, and desired_name=2E What does > defaulting the cred handle have to do with defaulting > the identity of the principal for which you desire a cred? "Add the cred described" to what? This is the issue=2E > > Also, it does not explicitly specify which desired_mechs > > are used - I presume the 'default behaviour' would be > > an empty set which selects a system-defined default=2E > > > > I'm reading the spec to say that desired mech is non-optional=2E So a > single mech must be specified=2E 'desired_mechs' is a parameter on the gss_aquire_cred call, 'desired_mech' is a parameter on the gss_add_cred call=2E > > However from this I would assume that any call to > > gss_add_cred, using GSS_C_NO_CREDENTIAL where the > > mechanism is within the system-defined default set > > of mechanisms would return GSS_S_DUPLICATE_ELEMENT > > - is this correct? > > > > I'm not sure I follow this=2E How can it be decided that a cred is a > duplicate of another if that other cred is not there? I assume that, > if the input_cred_handle is defaulted that one can never get a return > value of DUPLICATE=2E Calling add_cred with GSS_C_NO_CREDENTIAL is not adding an element to 'no credential' (i=2Ee=2E to create a credential with only that element'), but instead adds the given element to a credential "=2E=2E=2Eas if the caller had previously called gss_acquire_cred(), specifying the same usage and passing GSS_C_NO_NAME as the desired_name parameter=2E=2E=2E" But it does not define the value of desired_mechs for this 'as if' call - if this is considered to be the 'system-defined default' then, if the mechanism specified in the desired_mech parameter of the 'add_cred' call is within the set of 'system-defined default' mechanisms, then there will be a duplicate element=2E > Along those lines, I was confused about duplicate element > being implied by "overlapping cred_usage and validity > time specifiers=2E" Am I supposed to deem the request to > be a duplicate if the input_cred_handle refers > to a cred good for 2 more hours, even if the validity > time specifiers indicate a desire for a cred good > for 4 more hours? Yes - if a credential element relating to the desired mechanism already exists in the credential=2E A credential is a collection of credential elements - each element relating to a specific mechanism=2E Duplicate should be returned if an operation would cause two elements for the same mechanism with overlapping usage and validity times=2E > > Finally "The same input desired_name, or default reference, > > should be used on all gss_acquire_cred() and > > gss_add_cred() calls corresponding to a > > particular credential" appears to be difficult to detect > > (this is related to my earlier question on credentials > > name elements) - but if it is detected what should be > > returned - GSS_S_BAD_NAME? > > > > I never assumed that the spec implied that implementors were supposed > to detect this=2E In fact, I don't know how that could be done=2E My earlier question was "should the name received from an inquire cred have all the name elements that were in the name input to the acquire_cred, or the subset restricted by the desired_mechs" martin=2Erex@sap-ag=2Ede replied that the answer was implementation defined=2E If the answer is "yes" then a more rigorous name comparison (i=2Ee=2E all elements, not just any element) would detect this=2E If the answer is "no" then it cannot be detected except in the cases where the desired_name omits elements that were previously included=2E The hybrid case (where the credential "maintains" all the name elements, but inquire_cred has its output filtered) has the same answer as "yes"=2E In the first and last cases, the desired_name parameter on add_cred becomes redundant=2E -- Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, UK Tel: + 44 (0) 1442 342 600 Fax: +44 (0) 1256 812 901 Website: http://www=2Ezergo=2Ecom ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sun Jun 14 22:44:13 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA12171; Sun, 14 Jun 98 22:44:13 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id TAA20371 for ietf-cat-wg-out720680; Sun, 14 Jun 1998 19:10:42 -0700 (PDT) Received: from ntg.cisco.com (ntg.cisco.com [171.69.98.9]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id TAA20366 for ; Sun, 14 Jun 1998 19:10:40 -0700 (PDT) Received: from jtrostle-ultra.cisco.com (jtrostle-ultra.cisco.com [171.69.96.180]) by ntg.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id TAA25777; Sun, 14 Jun 1998 19:10:38 -0700 (PDT) Received: from jtrostle-ultra.cisco.com by jtrostle-ultra.cisco.com (SMI- 8.6/SMI-SVR4) id TAA05426; Sun, 14 Jun 1998 19:10:37 -0700 Message-Id: <199806150210.TAA05426@jtrostle-ultra.cisco.com> Date: Sun, 14 Jun 1998 19:10:37 -0700 (PDT) From: Jonathan Trostle Reply-To: Jonathan Trostle Subject: Proposed Internet draft for extending Kerberos intial authentication To: Ietf-cat-wg@lists.stanford.edu Cc: jtrostle@cisco.com, mikesw@microsoft.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: CIA9ytGzybSXVB4nnves5w== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk We would like to solicit comments from the cat group on this proposed Internet draft. Thanks, Jonathan INTERNET-DRAFT Jonathan Trostle draft-ietf-cat-kerberos-extra-tgt-00.txt Cisco Systems Updates: RFC 1510 Michael M. Swift expires December 20, 1998 Microsoft Extension to Kerberos V5 For Additional Initial Encryption 0. Status Of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in pro- gress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- dow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as draft-ietf-cat-kerberos-extra-tgt-00.txt, and expires December 20, 1998. Please send comments to the authors. 1. Abstract This document defines an extension to the Kerberos protocol specification (RFC 1510) [1] to enable a preauthentication field in the AS_REQ message to carry a ticket granting ticket. The session key from this ticket granting ticket will be used to cryptographically strengthen the initial exchange in either the conventional Kerberos V5 case or in the case the user stores their encrypted private key on the KDC [2]. 2. Motivation In Kerberos V5, the initial exchange with the KDC consists of the AS_REQ and AS_REP messages. For users, the encrypted part of the AS_REP message is encrypted in a key derived from a password. Although a password policy may be in place to prevent dictionary attacks, brute force attacks may still be a concern due to insufficient key length. This draft specifies an extension to the Kerberos V5 protocol to allow a ticket granting ticket to be included in an AS_REQ message preauthentication field. The session key from this ticket granting ticket will be used to cryptographically strengthen the initial exchange in either the conventional Kerberos V5 case or in the case the user stores their encrypted private key on the KDC [2]. The session key from the ticket granting ticket is combined with the user password key (key K2 in the encrypted private key on KDC option) using HMAC to obtain a new triple des key that is used in place of the user key in the initial exchange. 3. The Extension The following new preauthentication type is proposed: PA-EXTRA-TGT 22 The preauthentication-data field contains a ticket granting ticket encoded as an ASN.1 octet string. The server realm of the ticket granting ticket must be equal to the realm in the KDC-REQ-BODY of the AS_REQ message. In the absence of a trust relationship, the local Kerberos client should send the AS_REQ message without this extension. In the conventional (non-pkinit) case, we require the RFC 1510 PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message. If neither it or the PA-PK-KEY-REQ preauthentication field is included in the AS_REQ message, the KDC will reply with a KDC_ERR_PREAUTH_FAILED error message. We propose the following new etypes: des3-cbc-md5-xor 16 des3-cbc-sha1-xor 17 The encryption key is obtained by: (1) Obtaining an output M from the HMAC-SHA1 function [3] using the user password key (the key K2 in the encrypted private key on KDC option of pkinit) as the text and the triple des session key as the K input in HMAC: M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1. The session key from the accompanying ticket granting ticket must be a triple des key when one of the triple des xor encryption types is used. (2) Concatenate the output M (20 bytes) with the first 8 non-parity bits of the triple-des ticket granting ticket session key to get 168 bits that will be used for the new triple-des encryption key. (3) Set the parity bits of the resulting key. The resulting triple des key is used to encrypt the timestamp for the PA-ENC-TIMESTAMP preauthentication value (or in the encrypted private key on KDC option of pkinit, it is used in place of the key K2 to both sign in the PA-PK-KEY-REQ and for encryption in the PA-PK-KEY-REP preauthentication types). If the KDC decrypts the encrypted timestamp and it is not within the appropriate clock skew period, the KDC will reply with the KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if the above ticket granting ticket fails to decrypt properly, or if it is not a valid ticket. The KDC will create the shared triple des key from the ticket granting ticket session key and the user password key (the key K2 in the encrypted private key on KDC case) using HMAC as specified above and use it to validate the AS_REQ message and then to encrypt the encrypted part of the AS_REP message (use it in place of the key K2 for encryption in the PA-PK-KEY-REP preauthentication field). We propose to add an optional bit to the KDC database for each user to indicate whether the new preauthentication type is required. A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a preauthentication field containing a ticket granting ticket, a randomly generated subkey encrypted in the session key from the ticket, and a timestamp structure encrypted in the user password and then the randomly generated subkey was proposed. Some advantages of the current proposal are that the KDC has two fewer decryptions to perform per request and the client does not have to generate a random key. 4. Bibliography [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5). Request for Comments 1510. [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle. Public Key Cryptography for Initial Authentication in Kerberos. ftp://ds.internic.net/internet-drafts/ draft-ietf-cat-kerberos-pkinit-06.txt [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments 2104. [4] J. Pato. Using Pre-authentication to Avoid Password Guessing Attacks. OSF DCE SIG Request for Comments 26.0. 5. Authors' Addresses Jonathan Trostle 170 W. Tasman Dr. San Jose, CA 95134, U.S.A. Email: jtrostle@cisco.com Phone: (408) 527-6201 Michael Swift Microsoft One Microsoft Way Redmond, Washington, 98052, U.S.A. Email: mikesw@microsoft.com ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 15 00:09:34 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA13628; Mon, 15 Jun 98 00:09:34 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id UAA22390 for ietf-cat-wg-out720680; Sun, 14 Jun 1998 20:40:41 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id UAA22385 for ; Sun, 14 Jun 1998 20:40:39 -0700 (PDT) Received: from excalibur.cmf.nrl.navy.mil (kenh@excalibur.cmf.nrl.navy.mil [134.207.6.17]) by ginger.cmf.nrl.navy.mil (8.8.5/8.8.5) with ESMTP id XAA07258 for ; Sun, 14 Jun 1998 23:40:25 -0400 (EDT) Message-Id: <199806150340.XAA07258@ginger.cmf.nrl.navy.mil> To: Ietf-cat-wg@lists.stanford.edu Subject: Re: Proposed Internet draft for extending Kerberos intial authentication In-Reply-To: Your message of "Sun, 14 Jun 1998 19:10:37 PDT." <199806150210.TAA05426@jtrostle-ultra.cisco.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Sun, 14 Jun 1998 23:40:23 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >We would like to solicit comments from the cat group on this proposed Internet >draft. If the motivation is to strengthen the key length of the initial ticket request, why not just define a new keytype that's longer? (I would think triple-des would be long enough, though). Or perhaps use Marc Horowitz's key derivation draft? And maybe I'm missing something else .... but where do you get the TGT that you place in the AS_REQ? --Ken ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 15 17:13:34 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA01244; Mon, 15 Jun 98 17:13:34 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id NAA18441 for ietf-cat-wg-out720680; Mon, 15 Jun 1998 13:36:52 -0700 (PDT) Received: from ntg.cisco.com (ntg.cisco.com [171.69.98.9]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id NAA18436 for ; Mon, 15 Jun 1998 13:36:50 -0700 (PDT) Received: from jtrostle-ultra.cisco.com (jtrostle-ultra.cisco.com [171.69.96.180]) by ntg.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id NAA19712; Mon, 15 Jun 1998 13:36:49 -0700 (PDT) Received: from jtrostle-ultra.cisco.com by jtrostle-ultra.cisco.com (SMI- 8.6/SMI-SVR4) id NAA06727; Mon, 15 Jun 1998 13:36:49 -0700 Message-Id: <199806152036.NAA06727@jtrostle-ultra.cisco.com> Date: Mon, 15 Jun 1998 13:36:49 -0700 (PDT) From: Jonathan Trostle Reply-To: Jonathan Trostle Subject: Re: Proposed Internet draft for extending Kerberos intial authentication To: kenh@cmf.nrl.navy.mil Cc: Ietf-cat-wg@lists.Stanford.EDU Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: UMudDn+mXom1I/9j2wml1g== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Users may have difficulty remembering longer keys. The TGT could be obtained from a workstation logon to the realm. Jonathan > X-SMAP-Received-From: outside > To: Ietf-cat-wg@lists.Stanford.EDU > Subject: Re: Proposed Internet draft for extending Kerberos intial authentication > X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` > Date: Sun, 14 Jun 1998 23:40:23 -0400 > From: Ken Hornstein > > >We would like to solicit comments from the cat group on this proposed Internet > >draft. > > If the motivation is to strengthen the key length of the initial > ticket request, why not just define a new keytype that's longer? > (I would think triple-des would be long enough, though). Or perhaps > use Marc Horowitz's key derivation draft? > > And maybe I'm missing something else .... but where do you get the > TGT that you place in the AS_REQ? > > --Ken > ========================================================================== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 16 02:01:06 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA10825; Tue, 16 Jun 98 02:01:06 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id WAA03594 for ietf-cat-wg-out720680; Mon, 15 Jun 1998 22:28:22 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id WAA03588 for ; Mon, 15 Jun 1998 22:28:20 -0700 (PDT) Received: from excalibur.cmf.nrl.navy.mil (kenh@excalibur.cmf.nrl.navy.mil [134.207.6.17]) by ginger.cmf.nrl.navy.mil (8.8.5/8.8.5) with ESMTP id BAA14176; Tue, 16 Jun 1998 01:28:16 -0400 (EDT) Message-Id: <199806160528.BAA14176@ginger.cmf.nrl.navy.mil> To: Jonathan Trostle Cc: Ietf-cat-wg@lists.stanford.edu Subject: Re: Proposed Internet draft for extending Kerberos intial authentication In-Reply-To: Your message of "Mon, 15 Jun 1998 13:36:49 PDT." <199806152036.NAA06727@jtrostle-ultra.cisco.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 16 Jun 1998 01:28:12 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >Users may have difficulty remembering longer keys. Well, I think that's easily solved ... just call it a "passphrase" :-) But seriously .... I think password quality checking can be applied to reasonably solve this problem. But I see where this could be useful (not for our site, because most of our users come in from machines outside of our realm). >The TGT could be obtained from a workstation logon to the realm. So, my workstations have to keep getting TGT's all the time? That somehow seems less than optimal. Why not make it something like PA-ENC-TIMESTAMP but using the workstation's key instead? That would save you the trouble of getting a TGT. Of course, that has some security implications (but I'm not sure if they're worse than using the TGT session key). It might be useful if you added a note to your draft that the TGT could possibly come from a stored host key (it wasn't obvious to me, but perhaps I'm simply a dumbass :-) ). Also, I'm not sure of the implications of allowing _any_ random TGT to be used; perhaps that should go under "Security Considerations"? It might make sense to allow only host/* (or whatever)'s TGT to be used as a preauth. --Ken ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 16 20:04:41 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA29861; Tue, 16 Jun 98 20:04:41 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id QAA29406 for ietf-cat-wg-out720680; Tue, 16 Jun 1998 16:34:26 -0700 (PDT) Received: from ntg.cisco.com (ntg.cisco.com [171.69.98.9]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id QAA29401 for ; Tue, 16 Jun 1998 16:34:24 -0700 (PDT) Received: from jtrostle-pc1 (dhcp-n-45-236.cisco.com [171.71.45.236]) by ntg.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id QAA06489; Tue, 16 Jun 1998 16:33:50 -0700 (PDT) Message-Id: <3.0.5.32.19980616163349.009b6220@ntg.cisco.com> X-Sender: jtrostle@ntg.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Jun 1998 16:33:49 -0700 To: Ken Hornstein From: Jonathan Trostle Subject: Re: Proposed Internet draft for extending Kerberos intial authentication Cc: Ietf-cat-wg@lists.stanford.edu In-Reply-To: <199806160528.BAA14176@ginger.cmf.nrl.navy.mil> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Right, password quality controls help solve the problem of bad passwords. It's really the problem of using a key longer than a 56 bit DES key for users without making users remember long passwords. That's an interesting idea to use the workstation host key. The advantage is that TGT's do not have to be obtained by the workstation, but the disadvantage is that a compromise of such a key exposes past session keys. I will add some words to the draft with respect to which TGT's should be used. Thanks for your points, Jonathan At 01:28 AM 6/16/98 -0400, you wrote: >>Users may have difficulty remembering longer keys. > >Well, I think that's easily solved ... just call it a "passphrase" :-) >But seriously .... I think password quality checking can be applied >to reasonably solve this problem. But I see where this could be >useful (not for our site, because most of our users come in from >machines outside of our realm). > >>The TGT could be obtained from a workstation logon to the realm. > >So, my workstations have to keep getting TGT's all the time? That >somehow seems less than optimal. Why not make it something like >PA-ENC-TIMESTAMP but using the workstation's key instead? That >would save you the trouble of getting a TGT. Of course, that has >some security implications (but I'm not sure if they're worse than >using the TGT session key). > >It might be useful if you added a note to your draft that the TGT >could possibly come from a stored host key (it wasn't obvious to >me, but perhaps I'm simply a dumbass :-) ). Also, I'm not sure of >the implications of allowing _any_ random TGT to be used; perhaps >that should go under "Security Considerations"? It might make >sense to allow only host/* (or whatever)'s TGT to be used as a >preauth. > >--Ken > > ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 30 10:11:24 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA10714; Tue, 30 Jun 98 10:11:24 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id GAA27776 for ietf-cat-wg-out720680; Tue, 30 Jun 1998 06:37:03 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id GAA27771 for ; Tue, 30 Jun 1998 06:37:00 -0700 (PDT) Received: from odin.ietf.org by MIT.EDU with SMTP id AA20753; Tue, 30 Jun 98 09:36:59 EDT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA14151; Tue, 30 Jun 1998 09:36:56 -0400 (EDT) Message-Id: <199806301336.JAA14151@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-extra-tgt-00.txt Date: Tue, 30 Jun 1998 09:36:55 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Extension to Kerberos V5 For Additional Initial Encryption Author(s) : J. Trostle, M. Swift Filename : draft-ietf-cat-kerberos-extra-tgt-00.txt Pages : 3 Date : 29-Jun-98 This document defines an extension to the Kerberos protocol specification (RFC 1510) [1] to enable a preauthentication field in the AS_REQ message to carry a ticket granting ticket. The session key from this ticket granting ticket will be used to cryptographically strengthen the initial exchange in either the conventional Kerberos V5 case or in the case the user stores their encrypted private key on the KDC [2]. Internet-Drafts are 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-cat-kerberos-extra-tgt-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-kerberos-extra-tgt-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerberos-extra-tgt-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: <19980629135615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-extra-tgt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-extra-tgt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980629135615.I-D@ietf.org> --OtherAccess-- --NextPart-- ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu