RE: Exportable encryption & Kerberos

["Mike Swift (NT)" <[e-mail]>]

I agree that my suggesting is not the ultimate for negotiating encryption.
The current Kerberos AP protocol does not allow for much negotiation,
unfortunately. I hesitate to start relying on something like PKINIT for
everyday operations - it adds a whole new layer to the already complex
enough setup for Kerberos.

The solution I propose does allow for upgrade and downgrade attacks by rogue
servers & clients. I'm not too worried about downgrade attacks because a
client or server can always just expose the information. As for an upgrade
attack, only servers are vulnerable because the client would get to choose
the key in this case. The only way around this that I know of is for either
a new encryption type to be defined or for a standard way to inspect a key
and tell how strong it is, neither of which seem practical.

- Mike

> -----Original Message-----
> From:	[e-mail] [SMTP:[e-mail]]
> Sent:	Tuesday, January 13, 1998 2:47 PM
> To:	Mike Swift (NT)
> Cc:	[e-mail]
> Subject:	Re: Exportable encryption & Kerberos
> 
> Item Subject: Exportable encryption & Kerberos
>      The proposed scheme does provide additional information, but it does 
>      not address the problem of clients and servers with different crypto 
>      capabilities interoperating.  Having either the client or server 
>      blindly trust the other presents problems. A rogue could force the
> use 
>      of crypto that is too weak or too strong for a particular
> environment. 
>       
>      
>      It would be desirable to have a client that is capable of both strong
> 
>      and weak crypto.  There are several types of servers the client may 
>      interoperate with.
>      
>      1. Generic server -- the client must use weak crypto
>      2. Approved Server -- the server has characteristics (such as key 
>      recovery and key escrow) that allow for the use of stronger 
>      cryptography.
>      3. Approved Sever in an Approved Institution -- the institution which
> 
>      is using this server is approved for stronger crypto.
>      
>      It is therefore essential that the client have a means of identifying
> 
>      the cryptographic allowances of the server it is talking to.  I 
>      believe there is an SSL mechanism in practice that allows for a 
>      special certificate to be returned by the server to the client which 
>      proves that the server can use stronger crypto (If someone could
> point 
>      me to the details of these "special certificates" I would be 
>      grateful).  Current proposals in kerberos could be used in a similar 
>      way to help with this problem.
>      
>      The current PKINIT proposal allows the server to return a
> certificate. 
>      This certificate could provide the assurance of the capability to do 
>      stronger crypto.  However, this only identifies the KDC which may be 
>      sufficient for meeting government regulations in case 3.  It may
> cause 
>      problems with case 2 because there is no guarantee that the 
>      application server is participating in key management.  In this case
> I 
>      do not know of a specification to return a certificate from an 
>      application server (I don't think either PKTAPP or PKDA apply), one 
>      would probably have to be invented.  
>      
>      I'd appreciate any comments on this, I am coming from a US point of 
>      view.  The CAT working group may not be the best place to focus on 
>      these issues.  If there is a better forum let me know.  The problem
> of 
>      cryptographic restrictions is much broader than US export
> regulations. 
>       
>      Joe Salowey
>      WRQ Software
>      [e-mail]
>      
> 
> 
> 

Date: Sat, 17 Jan 1998 00:40:32 -0500
From: "Theodore Y. Ts'o" <[e-mail]>
To: "Mike Swift" <[e-mail]>
Cc: Ken Hornstein <[e-mail]>, [e-mail]
Subject: Re: Exportable encryption & Kerberos
Address: 1 Amherst St., Cambridge, MA 02139
Phone: [phone]

   From: "Mike Swift (NT)" <[e-mail]>
   Date: Fri, 16 Jan 1998 10:58:32 -0800

   I agree that the words "domestic" and "exportable" were poor choices - how
   about "strong" and "weak", so that there are no doubts about what is being
   offered? I thought about extending the AP request to include additional enc
   types. However, negotiating both a key & and encryption type at the same
   time is difficult - the thing to do might be to expand the key in the AP_REQ
   to be a sequence of keys, and the server replies with they key it chose or
   its own key. 

I'm still not convinced this is a good thing to put into the protocol
like this.  What if the government decides six months from now that 40
bits is pathetically weak, and allows us to use 48 bits instead?  What
if France requires us to use 16 bits of keying material?  Do we put yet
another hack into the protocol for that?

There is substantial consensus within the IETF that we should not
compromise our protocols for the sake of meeting the requirements of
some transient national government's regulations with respect to export
control.  The IETF, after all, is an International standards body, and
if the U.S. government wants to cripple the ability for U.S. companies
to sell competently written, secure products outside the U.S., that's
the U.S. government's problem.  

This question came up with IPSEC, and when we took a straw poll at the
open IESG meeting, the overwhelming consensus by the IETF engineers was
that we should not compromise our protocols in this fashion.  Hence, in
order to compliant with IPSEC and IPV6 you MUST support strong crypto.
If you do not, you cannot call yourself compliant with those standards.
Companies in the E.U. are free to develop and market IPSEC software with
strong crypto to the E.U., and there are companies that are doing
precisely that.  U.S. companies who don't like this restriction in where
they can market their software are encouraged to lobby the
U.S. government to fix this, and to not bother trying to lobby the IETF
to bless a technically incorrect design choice.

In any case, because of this strong consensus within both the IETF and
the IESG, I have no doubt that any attempt to try to standardize
insecure crypto will be rejected by the IESG.  So I believe it's really
a waste of time to pursue this any further.

Indeed, my big worry right now with respect to Kerberos is that 56 bits
of DES is not strong enough for anything really serious, and that we
should be moving to 112 bit triple-DES keys ASAP.

						- Ted

Date: Sat, 17 Jan 1998 10:13:14 -0800 (PST)
From: Mike Eisler <[e-mail]>
Reply-To: Mike Eisler <[e-mail]>
Subject: Re: Exportable encryption & Kerberos
To: "Theodore Y. Ts'o" <[e-mail]>
Cc: Mike Swift <[e-mail]>, Ken Hornstein <[e-mail]>,
        [e-mail]


> In any case, because of this strong consensus within both the IETF and
> the IESG, I have no doubt that any attempt to try to standardize
> insecure crypto will be rejected by the IESG.  So I believe it's really

The most recent TLS draft has "exportable" cipher suites in it. If nothing
else, I would hope IESG is consistent in its treatment of the output from one
WG versus another.

> a waste of time to pursue this any further.

The practical reality is that these laws exist. Without some written
definition of weak cryto, what will happen is various implementers will
implement non-interoperable schemes. An Informational RFC on 40 bit
Kerberos V5 privacy would be useful for that reason.

	-mre

Date: Sat, 17 Jan 1998 21:24:07 -0500 (EST)
From: Richard Salz <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Exportable encryption & Kerberos
Cc: [e-mail], [e-mail], [e-mail]

> An Informational RFC on 40 bit
>Kerberos V5 privacy would be useful for that reason.

If the members of the IETF decide it's useful to standardize emasculated
crypto to ensure interoperability, then I hope we'll all be very blatant
and define things such that the "naught bits" (n>41:) are sent in the clear
by the protocol(s) in question.  In no way should this be sugar-coated.
	/r$

To: Mike Eisler <[e-mail]>
Cc: "Theodore Y. Ts'o" <[e-mail]>, Mike Swift <[e-mail]>,
        Ken Hornstein <[e-mail]>, [e-mail]
Subject: Re: Exportable encryption & Kerberos
X-Emacs: 19.34
From: [e-mail] (Johan Danielsson)
Date: 18 Jan 1998 09:08:56 +0100
Lines: 10

Mike Eisler <[e-mail]> writes:

> Without some written definition of weak cryto, what will happen is
> various implementers will implement non-interoperable schemes.

I almost find this a feature. It is more obvious to people that they
are buying crap software if it doesn't interoperate with anything
else.

/Johan

Return-Path: <[e-mail]>
From: [e-mail]
Date: Sun, 18 Jan 1998 19:11:37 -0800 (PST)
X-Sender: [e-mail] (Unverified)
To: Richard Salz <[e-mail]>
Subject: Re: Exportable encryption & Kerberos
Cc: [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail]

        Rich Salz <[e-mail]> opined:

>If the members of the IETF decide it's useful to standardize emasculated
>crypto to ensure interoperability, then I hope we'll all be very blatant
>and define things such that the "naught bits" (n>41:) are sent in the clear
>by the protocol(s) in question.  In no way should this be sugar-coated.

        Damn right!  Bell, whistles, popup windows, and bad smells wherever
available should be used to alert the user and clearly indicate that the
encryption being used is very very weak.

        Could the WG or the IESG mandate such an overt warning in the
implementation?  Maybe with an explicit recommendation that the user seek
to negotiate more secure crypto with his correspondent(s) ...if possible
and legal, and if he or she requires more than minimal protection for the
confidentiality and integrity of the transmitted data?

        That would be neat for several reasons -- not least of which
because it would maybe let J.S. and the IESG and/or the IAB go head-to-head
with the US govt. directly.

        And that, in turn, might get the user and the vendors out of the
line of fire and lessen the temptation of various IETF activists to scorn
useful _Interoperability_ standards -- which seem to necessarily reference
(and require, for universal connectivity) the weak crypto which is the
strongest the feds allow to be freely exported by US-based vendors.

        That new banker's suit becomes you, Mr. Salz.
        ;-)
   Suerte,
                     _Vin


Return-Path: <[e-mail]>
Date: Mon, 19 Jan 1998 07:21:20 -0800 (PST)
From: Mike Eisler <[e-mail]>
Reply-To: Mike Eisler <[e-mail]>
Subject: Re: Exportable encryption & Kerberos
To: Johan Danielsson <[e-mail]>
Cc: Mike Eisler <[e-mail]>,
        "Theodore Y. Ts'o" <[e-mail]>, Mike Swift <[e-mail]>,
        Ken Hornstein <[e-mail]>, [e-mail]

> Mike Eisler <[e-mail]> writes:
> 
> > Without some written definition of weak cryto, what will happen is
> > various implementers will implement non-interoperable schemes.
> 
> I almost find this a feature. It is more obvious to people that they
> are buying crap software if it doesn't interoperate with anything
> else.

You and I have the same technical opinion regarding 40 bit privacy, but the
reality is that there is a proven market for it: the United States.
Most U.S. residents use 40 bit encryption in their web browser, even though they
don't have to. I wonder if 40 bit web browsers are similarly popular in other
countries.

	-mre


Return-Path: <[e-mail]>
To: Mike Eisler <[e-mail]>
Cc: "Theodore Y. Ts'o" <[e-mail]>, Mike Swift <[e-mail]>,
        Ken Hornstein <[e-mail]>, [e-mail]
Subject: Re: Exportable encryption & Kerberos
X-Emacs: 19.34
From: [e-mail] (Johan Danielsson)
Date: 19 Jan 1998 20:54:30 +0100
Lines: 15

Mike Eisler <[e-mail]> writes:

> Most U.S. residents use 40 bit encryption in their web browser, even
> though they don't have to.

Yes, but doesn't SSL have standardized support for using weak crypto?

> I wonder if 40 bit web browsers are similarly popular in other
> countries.

I would say that 0 bit web browsing is far more popular. Those that
actually use SSL for something real, either use a local strong crypto
proxy, or use some other device as a complement, SecurID or similar.

/Johan

Return-Path: <[e-mail]>
From: "Mike Swift (NT)" <[e-mail]>
To: Richard Salz <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Exportable encryption & Kerberos
Date: Mon, 19 Jan 1998 15:23:47 -0800

I am very open to other suggestions on how best to implement weakened
encryption in Kerberos. I proposed a solution that is of limited scope but
will work. If anybody else has other concrete suggestions I would very much
like to hear them.

- Mike

> -----Original Message-----
> From:	Richard Salz [SMTP:[e-mail]]
> Sent:	Saturday, January 17, 1998 6:24 PM
> To:	[e-mail]; [e-mail]
> Cc:	[e-mail]; [e-mail]; Mike Swift (NT)
> Subject:	Re: Exportable encryption & Kerberos
> 
> > An Informational RFC on 40 bit
> >Kerberos V5 privacy would be useful for that reason.
> 
> If the members of the IETF decide it's useful to standardize emasculated
> crypto to ensure interoperability, then I hope we'll all be very blatant
> and define things such that the "naught bits" (n>41:) are sent in the
> clear
> by the protocol(s) in question.  In no way should this be sugar-coated.
> 	/r$

Return-Path: <[e-mail]>
To: "Mike Swift (NT)" <[e-mail]>
Cc: [e-mail]
Subject: Re: Exportable encryption & Kerberos 
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<|um5yP<ea#^"SJK;C*}fMI;Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Tue, 20 Jan 1998 01:12:53 -0500
From: Ken Hornstein <[e-mail]>

>I am very open to other suggestions on how best to implement weakened
>encryption in Kerberos. I proposed a solution that is of limited scope but
>will work. If anybody else has other concrete suggestions I would very much
>like to hear them.

Okay, politics aside:

- The binary values of "strong" and "weak" bother me.  Not enough room for
  expansion or adaptation (what if X version of Kerberos implements
  "weak", circa 1998, but Y implements "weak" circa 2002?).  I really
  think these should be new encryption types.
- I still think that a general framework for negotiating encryption
  types in an AP_REQ would be useful, for a number of reasons (for
  example, when 3DES gets into MIT Kerberos, I'd like to be able to
  use it as quickly as possible, but not have to upgrade all of
  our application servers).  I know, this is tricky ... but I still
  think it's solvable.

--Ken

Return-Path: <[e-mail]>
From: [e-mail]
X-Lotus-Fromdomain: IRIS
To: [e-mail]
Cc: [e-mail]
Date: Tue, 20 Jan 1998 11:02:00 -0500
Subject: Re: GSS-API per msg prot negotiation
Content-Disposition: inline

Martin writes (regarding requiring that both ends of a
context get the same confidentiality support information):

>More or less obvious mechanism spec and/or implementation issues:
>
>- If a gssapi mechanism spec doesn't mandate confidentiality,
>  it must provide a handshake during context establishment so
>  that independent implemenations may figure out availability
>  of a common confidentiality mechanism.
>
>- If a gssapi mechanism spec doesn't mandate confidentiality,
>  a one-way authentication with confidentiality can not meet
>  the interoperability requirement.
>
>- If a gssapi mechanism spec mandates confidentiality,
>  a one-way authentication with confidentiality would be limited to
>  the mandated confidentiality algorithm(s).


The latter two issues aren't quite correct - one-way authentication
is a service, and is what you get when you don't set the MUTUAL_REQ
bit to GSS_INIT_SEC_CONTEXT; it doesn't necessarily map to a single
message, but can be implemented as a series of messages between
initiator and acceptor.  So the above should read something like:

- If a gssapi mechanism spec doesn't mandate confidentiality,
  a single-message context establishment can not provide
  interoperable confidentiality.

- If a gssapi mechanism spec mandates confidentiality,
  a single-message context establishment exchange would be limited to
  the mandated confidentiality algorithm(s).


>On top of that, I think such requirements have to be extended
>to QOP values:
>
>- If a gssapi mechanism spec allows optional confidentiality
>  or integrity mechanisms to be selected by the application
>  by using an explicit QOP parameter, the context establishment
>  must provide for negotiation of common QOP values.
>
>- When using an optional QOP value that is known to the local
>  gssapi implementation but not by the peer and therefore not
>  available for the established security context, the failure
>  of the gss_getmic() or gss_wrap() must not interfere with
>  the context validity, sequence protection or replay protection
>  as provided by the gssapi mechanism.

I think I understand the above, but the wording is confusing (for
a start, "confidentiality/integrity mechanisms" haven't been defined,
and I can't think of a clear concise definition that captures what I
think you're after). Would the following restrictions do what you want:

    A) If a gssapi mechanism spec allows for optional support of
       particular QOP values, then either:

       i) All implementations are required to be capable of
          processing messages protected using any QOP value,
          regardless of whether they can apply protection
          corresponding to that QOP,

       or

       ii) The set of mutually-supported receiver QOP values
           must be determined during context establishment,
           and messages may be protected by either peer
           using only QOP values from this mutually-supported
           set.

       NOTE: (i) is just a special-case of (ii), where
             implementations are required to support
             all QOP values on receipt.


    B) A failure of gss_getmic() or gss_wrap() due to an attempt
       to use an unsupported QOP will not interfere with context
       validity, nor shall such a failure impact the ability of the
       application to subsequently invoke gss_getmic() or
       gss_wrap() using a supported QOP; in particular, any
       state information concerning sequencing of outgoing
       messages shall be unchanged by an unsuccesful call
       of gss_getmic() or gss_wrap().

       NOTE: should the last clause (after the semilcolon) be
             true in general - shouldn't any failure of gss_getmic()
             or gss_wrap() leave sequencing state alone?


John (note my new E-mail address)


Return-Path: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Exportable encryption & Kerberos 
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<|um5yP<ea#^"SJK;C*}fMI;Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Tue, 20 Jan 1998 13:01:41 -0500
From: Ken Hornstein <[e-mail]>

>If negotiation is required, the question is where to perform the
>negotiation: either within Kerberos or using SNEGO, which means outside
>Kerberos.

Oh, sure ... I was putting off reading the SNEGO draft, but now you're
making me do it! :-)

Well, I had understood that SNEGO was for the GSS-API.  It would be
nice if we could have something that would work for non-GSS apps (i.e. -
telnet).  Or are you talking about applying the general negotiation
to that SNEGO does to "raw Kerberos" as well?

--Ken

Return-Path: <[e-mail]>
From: "Mike Swift (NT)" <[e-mail]>
To: Ken Hornstein <[e-mail]>
Cc: [e-mail]
Subject: RE: Exportable encryption & Kerberos 
Date: Tue, 20 Jan 1998 12:31:22 -0800

As an alternative, we could extend that AUTHENTICATOR by allowing the subkey
to be a sequence. This would allow the client to propose a list of subkeys
and allow the server to select a subkey to return in the AP reply. This
would allow the introduction of new encryption types of various strengths.
The client can propose keys for the various encryption types it supports (if
it was weakened, then only weak encryption types) and the server could
select an encryption type it considered acceptible. This requires that the
client do mutual authentication and ask for an AP reply, though.


Authenticator ::=    [APPLICATION 2] SEQUENCE    {
               authenticator-vno[0]          INTEGER,
               crealm[1]                     Realm,
               cname[2]                      PrincipalName,
               cksum[3]                      Checksum OPTIONAL,
               cusec[4]                      INTEGER,
               ctime[5]                      KerberosTime,
-->            subkey[6]                     SEQUENCE OF EncryptionKey
OPTIONAL,
               seq-number[7]                 INTEGER OPTIONAL,
               authorization-data[8]         AuthorizationData OPTIONAL
                     }

- Mike
> -----Original Message-----
> From:	Ken Hornstein [SMTP:[e-mail]]
> Sent:	Monday, January 19, 1998 10:13 PM
> To:	Mike Swift (NT)
> Cc:	[e-mail]
> Subject:	Re: Exportable encryption & Kerberos 
> 
> >I am very open to other suggestions on how best to implement weakened
> >encryption in Kerberos. I proposed a solution that is of limited scope
> but
> >will work. If anybody else has other concrete suggestions I would very
> much
> >like to hear them.
> 
> Okay, politics aside:
> 
> - The binary values of "strong" and "weak" bother me.  Not enough room for
>   expansion or adaptation (what if X version of Kerberos implements
>   "weak", circa 1998, but Y implements "weak" circa 2002?).  I really
>   think these should be new encryption types.
> - I still think that a general framework for negotiating encryption
>   types in an AP_REQ would be useful, for a number of reasons (for
>   example, when 3DES gets into MIT Kerberos, I'd like to be able to
>   use it as quickly as possible, but not have to upgrade all of
>   our application servers).  I know, this is tricky ... but I still
>   think it's solvable.
> 
> --Ken

Return-Path: <[e-mail]>
From: Martin Rex <[e-mail]>
Subject: Re: Exportable encryption & Kerberos
To: [e-mail]
Date: Tue, 20 Jan 1998 21:39:06 +0100 (MEZ)
Cc: [e-mail]
Reply-To: [e-mail]

Denis Pinkas wrote:
> 
> > - I still think that a general framework for negotiating encryption
> >   types in an AP_REQ would be useful, for a number of reasons (for
> >   example, when 3DES gets into MIT Kerberos, I'd like to be able to
> >   use it as quickly as possible, but not have to upgrade all of
> >   our application servers).  I know, this is tricky ... but I still
> >   think it's solvable.
> 
> If negotiation is required, the question is where to perform the
> negotiation: either within Kerberos or using SNEGO, which means outside
> Kerberos.
> 
> I would recommend the use of SNEGO (soon to be closed) which allows to
> negotiate all Kerberos flavours as soon as you suffix the Kerberos
> mechanism with some identifier.

I strongly recommend NOT to use SNEGO but define some QOP handshake and
default to the "strongest" algorithms from this handshake.

This is much easier to handle for the application -- since the app isn't
actually bothered with it -- especially when all other "characteristics"
remain unchanged, like:
   - namespace
   - number of message exchanges for context establishment
   - availability of message integrity
   - availability of message confidentiality

When an application offers provisions to deal with gssapi mechanisms
of completely different nature (X.500 DNs and such), it tries to recognize
them by mechanism OID, and if you change that all the time, it will become
a real pain to update and maintain such mechanism OIDs in the application.


SPNEGO may be useful to select among a bunch of completely different
mechanisms with completely differing mechanism OIDs as part of
an infrastructure  (SPKM, Kerberos5, DASS(rip), MS-NTLM, ...).
which includes a standardized mapping between the differing native
namespaces.

-Martin

Return-Path: <[e-mail]>
Date: Tue, 20 Jan 1998 14:05:33 -0800
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
To: Ken Hornstein <[e-mail]>
Cc: "Mike Swift (NT)" <[e-mail]>, [e-mail]
Subject: Re: Exportable encryption & Kerberos

(deleted stuff)

> Okay, politics aside:
 
(deleted stuff)

> - I still think that a general framework for negotiating encryption
>   types in an AP_REQ would be useful, for a number of reasons (for
>   example, when 3DES gets into MIT Kerberos, I'd like to be able to
>   use it as quickly as possible, but not have to upgrade all of
>   our application servers).  I know, this is tricky ... but I still
>   think it's solvable.

If negotiation is required, the question is where to perform the
negotiation: either within Kerberos or using SNEGO, which means outside
Kerberos.

I would recommend the use of SNEGO (soon to be closed) which allows to
negotiate all Kerberos flavours as soon as you suffix the Kerberos
mechanism with some identifier.

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [e-mail]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Return-Path: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: GSSAPI-SPKM
Date: Tue, 20 Jan 1998 18:13:57 -0500

Hi Douglas,

>----------
>From: 	Doug Engert[SMTP:[e-mail]]
>Sent: 	Friday, January 09, 1998 9:37 AM
>To: 	Carlisle Adams
>Cc: 	[e-mail]
>Subject: 	GSSAPI-SPKM
>
>Carlisle,
>
>Are there any implementations of GSSAPI which implement
>SPKM - RFC-2025? Either comercial products or source code? 

None that I can think of off-hand.  I've heard of many projects that
have begun, but I don't know of products or reference implementations.

>Is the Entrust product RFC-2025 compliant? 

Yes, it is.

>If there are more then one, has there been an
>interoperability testing? 

I remember that we did limited interoperability testing some time ago
with another company, but I don't know if that company ever completed
their SPKM work (I think it's priority dropped as they shifted their
focus on to other things).

In any case, other implementations and interoperability testing are
necessary if the IETF might ever consider moving SPKM from Proposed to
Draft.  If there are volunteers out there, I'm sure Entrust would be
interested in participating in some interoperability testing
activities...


--------------------------------------------
Carlisle Adams
Entrust Technologies
[e-mail]
--------------------------------------------


Return-Path: <[e-mail]>
Date: Wed, 21 Jan 1998 03:48:26 +0200 (EET)
From: Tatu Ylonen <[e-mail]>
To: "Mike Swift (NT)" <[e-mail]>
Cc: Richard Salz <[e-mail]>, [e-mail], [e-mail],
        [e-mail], [e-mail]
Subject: RE: Exportable encryption & Kerberos
Organization: SSH Communications Security, Finland

> I am very open to other suggestions on how best to implement weakened
> encryption in Kerberos. I proposed a solution that is of limited scope but
> will work. If anybody else has other concrete suggestions I would very much
> like to hear them.

If I've understood right, Kerberos (the version distributed by MIT)
only implements weak encryption (i.e., single DES).  If this is no
longer the case, why not just revert to the single DES method used
earlier?  Single DES is demonstrably breakable even by groups of
amateurs on the internet.

Or do you want something that is so weak that it can be broken by
individual university undergraduates?  What would be the point of
using encryption that is so weak?  It would no longer protect
passwords or other data.

There is also a Kerberos implementation freely available from Sweden
that supports both DES and 3DES.  If you cannot export, why not just
use that?

Best regards,

    Tatu

-- 
SSH Communications Security	      http://www.ssh.fi/
SSH IPSEC Toolkit		      http://www.ssh.fi/ipsec.html
Free Unix SSH                         http://www.cs.hut.fi/ssh/

Return-Path: <[e-mail]>
Date: Tue, 20 Jan 1998 22:07:49 -0500
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Exportable encryption & Kerberos
From: [e-mail]
Address: 1 Amherst St., Cambridge, MA 02139
Phone: [phone]

   Date: Sat, 17 Jan 1998 10:13:14 -0800 (PST)
   From: Mike Eisler <[e-mail]>

   The most recent TLS draft has "exportable" cipher suites in it. If
   nothing else, I would hope IESG is consistent in its treatment of the
   output from one WG versus another.

TLS has an optional "exportable" cipher suite, which standardized
existing practice.  The mandatory-to-implement cipher suite in TLS does
use crypto that takes longer than two hours to break.

We have indeed standardizing existing practice before; most notably in
the ONCRPC specs, where we documented an existing scheme which has the
unfortunate property of taking 45 minutes of CPU time to break all
possible keys used in that particular system.  However, that's different
from standardizing a new protocol extension which uses weak crypto.

   The practical reality is that these laws exist. Without some written
   definition of weak cryto, what will happen is various implementers will
   implement non-interoperable schemes. An Informational RFC on 40 bit
   Kerberos V5 privacy would be useful for that reason.

Well, if we're going to do weak crypto, we should at least do it right,
which means defining a new Kerberos V5 encryption type, instead of using
the kludge which Mike was suggesting.  (Mike, speaking of which, I need
to talk to you off-line; the hack you guys are using in NT 5.0 Beta 1 to
indicate a NTLM string-to-key algorithm with an unregistered,
undocumented encryption type is *really* not the best way to do
things...)

It's not clear wheather or not the IESG will published such an
Informational RFC, but I do understand the argument that there should be
one broken way of doing insecure crypto.

However, we should all note that an implementation can't be called
Kerberos-compliant unless it implements the mandatory-to-implement
encryption algorithms --- and this position *is* consistent with the
stand that the IESG has taken in the past on IPSEC, TLS, etc.

						- Ted

Return-Path: <[e-mail]>
Date: Tue, 20 Jan 1998 22:08:53 -0500
From: "Theodore Y. Ts'o" <[e-mail]>
To: "Mike Swift" <[e-mail]>
Cc: Ken Hornstein <[e-mail]>, [e-mail]
Subject: Re: Exportable encryption & Kerberos
Address: 1 Amherst St., Cambridge, MA 02139
Phone: [phone]

   From: "Mike Swift (NT)" <[e-mail]>
   Date: Tue, 20 Jan 1998 12:31:22 -0800

   As an alternative, we could extend that AUTHENTICATOR by allowing the subkey
   to be a sequence. This would allow the client to propose a list of subkeys
   and allow the server to select a subkey to return in the AP reply. 

This won't work, because the result will be completely incompatible with
existing implementations, that won't be expecting an ASN.1 sequence
there.

					- Ted

Return-Path: <[e-mail]>
Date: Wed, 21 Jan 1998 12:11:47 -0500
From: Fengmin Gong <[e-mail]>
Organization: MCNC, Advanced Networking
To: [e-mail]
Subject: Questions on RFC2078

Hi there,

I am planning to use GSS-API and IDUP-GSS-API in a DARPA
project.  The gist of the project is to create a GSS-API
/IDUP-GSS-API mechanisms implementation which actually
utilizes other security mechansims (ATM cell encryptor,
IPSEC, crypto accellerator etc) to satisfy certain security
service needs of network applications.  Those security
mechanisms are typically distributed among different protocol
layers or across the network.  We want to be able to
utilize them in a dynamic fashion.

Ok, here are my specific questions/suggestions regarding
the GSS-API V2 as specified by RFC2078.  I may be ignorant
of any new development in the CAT group on GSS-API.  I will
appreciate very much the feedback from the active developers
of the spec.  I have sent my subscription to 
[e-mail], but please copy me specifically
in your reply just to be sure.

1) RFC2078 does not inlcude any input parameters for indicating
applications' desire regarding the services or QoP in the
context initilization call.  Those parameters are deferred to
the per-message calls.  It seems reasonable to expect the
applications to have some idea of what they would like to do
with the context when they try to establish one.  In my
project scenario, most of the setup and coordination would
take place at context establishment time but I do not have
those important information to go with.  I have found out that
IDUP-GSS-API draft (dated March 25, 1997) does include such
parameters for the environment establishment call, shouldn't
GSS-API do the same?  It should be pointed out that having
the similar parameters at the per-message level is still a
good idea and should be kept there.

2) The kind of scenarios I face also desire another
feature that is missing from RFC2078 spec, i.e., a kind
of "delegation mode" per-message protection call. For example,
a GSS_Wrap_and_send() call will do all the things that
GSS_Wrap() does now, but in addition will send the wrapped
message out of the network protocol stack instead of
returning it to the caller.  Although I could make do by 
returning the original message to the caller as appropriate, 
it does have some efficiency implication.

I realize that this requirement seems to run against the
GSS-API principle of "protocol environment independence"
but I can also argue otherwise.  Availability of such 
delegation feature will be mechasnism dependent, similar
to QoP support; it can be made known to the applications
at context establishment item using those service flags;
separate per-message calls avoid changing any of the
existing calls.

Thanks for your attention,
Fengmin

--
Fengmin Gong, D.Sc.			E-mail: [e-mail]
Manager, Advanced Networking Research	Phone:  [phone]
MCNC, P.O.Box 12889			FAX:    [phone]
3021 Cornwallis Rd., RTP, NC 27709	WWW:	http://www.mcnc.org

Return-Path: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>,
        "'Graham Bland'"
	 <[e-mail]>
Subject: RE: IDUP Compatibility of call sets
Date: Wed, 21 Jan 1998 14:09:06 -0500

Hi Graham,

>----------
>From: 	Graham Bland[SMTP:[e-mail]]
>Sent: 	Thursday, January 15, 1998 5:31 AM
>To: 	[e-mail]
>Subject: 	IDUP Compatibility of call sets
>
>Another question or change:
>
>When generating evidence by the EV call subset evidence_check is returned as 
>an octet string (implemented as a gss_buffer_t) which will be opaque to the 
>caller.
>
>When the EV calls are used for the verification of the evidence this is 
>passed to idup_ev_xxbuffer_startverify() in the same format.  However if the 
>GP calls are used for the verify I cannot see how  the evidence_check 
>contents can be mapped onto the parameters of the idup_start_unprotect call.
>
>Can anybody help or is this a change to the specification ?

The corresponding entity in the GP calls is the (input parameter)
service_verification_info in Unprot_Service.  This is specified in IDUP
to be of type Service_Verification_Info, which is described as a
mechanism-defined parameter bundle.

I tried to make this as general as possible (in keeping with the GP
calls themselves), by allowing total freedom in number and type of
parameters in the Service_Verification_Info bundle.  However, in
practice I think that most mechanism specifications will simply define a
single parameter which is an opaque OCTET STRING, thereby allowing what
you are proposing above (i.e., that evidence may be generated by an EV
call and verified by a GP call, or vice versa).


--------------------------------------------
Carlisle Adams
Entrust Technologies
[e-mail]
--------------------------------------------


Return-Path: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>,
        "'Graham Bland'"
	 <[e-mail]>
Subject: RE: GSS and IDUP
Date: Wed, 21 Jan 1998 14:19:15 -0500

Hi Graham,

>----------
>From: 	Graham Bland[SMTP:[e-mail]]
>Sent: 	Wednesday, January 14, 1998 9:12 AM
>To: 	[e-mail]
>Subject: 	GSS and IDUP
>
>Firstly apology on two counts.
>The timing of these comments is poor following last call, however at that 
>time I had no comments.
>
>Secondly the length, this is a collection of comments and issues rather than 
>sending each as a seperate email I have collated them together.
>
>The background from most of these has come from looking at an environment 
>which will support both GSS and GSS-IDUP.  All are based on the latest 
>documents.

Thank you for the detailed comments and for your interest in an
environment that supports GSS and IDUP together.

I hope to issue a revised IDUP draft over the next few weeks (taking
into account input from various conversations at the Washington IETF
meeting in December).  At that time I will respond to, and incorporate,
your comments as best I can.  If you don't mind just being patient for a
couple of weeks while I finish up some other work, I would really
appreciate it...

Thanks again!


--------------------------------------------
Carlisle Adams
Entrust Technologies
[e-mail]
--------------------------------------------


Return-Path: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Fengmin Gong'" <[e-mail]>
Subject: RE: Questions on RFC2078
Date: Wed, 21 Jan 1998 16:15:32 -0500

Fengmin Gong writes, excerpting:

> 1) RFC2078 does not inlcude any input parameters for indicating
> applications' desire regarding the services or QoP in the
> context initilization call.  Those parameters are deferred to
> the per-message calls.  It seems reasonable to expect the
> applications to have some idea of what they would like to do
> with the context when they try to establish one.  In my
> project scenario, most of the setup and coordination would
> take place at context establishment time but I do not have
> those important information to go with.  I have found out that
> IDUP-GSS-API draft (dated March 25, 1997) does include such
> parameters for the environment establishment call, shouldn't
> GSS-API do the same?  It should be pointed out that having
> the similar parameters at the per-message level is still a
> good idea and should be kept there.
> 
The current working draft successor to rfc2078
(draft-ietf-cat-rfc2078bis-01.txt) adds conf_req_flag and integ_req_flag
inputs to gss_init_sec_context().  These service request indicators,
unlike QOP values, can be provided in a mechanism-independent fashion
and (given that bindings represent the flags as bits within an already
existing word) were possible to add in a backward-compatible fashion.
QOP requests would be mechanism-specific and would require
less-compatible changes to the call signature. 

> 2) The kind of scenarios I face also desire another
> feature that is missing from RFC2078 spec, i.e., a kind
> of "delegation mode" per-message protection call. For example,
> a GSS_Wrap_and_send() call will do all the things that
> GSS_Wrap() does now, but in addition will send the wrapped
> message out of the network protocol stack instead of
> returning it to the caller.  Although I could make do by 
> returning the original message to the caller as appropriate, 
> it does have some efficiency implication.
> 
> I realize that this requirement seems to run against the
> GSS-API principle of "protocol environment independence"
> but I can also argue otherwise.  Availability of such 
> delegation feature will be mechasnism dependent, similar
> to QoP support; it can be made known to the applications
> at context establishment item using those service flags;
> separate per-message calls avoid changing any of the
> existing calls.
> 
Mechanism dependence issues aside, this sort of coupling could also be
specific not only to protocol environments but also to the communication
access APIs used within an end system. If appropriate in a particular
environment, it's certainly possible to wrap GSS calls within a veneer
which also bundles invocation of communications-level calls; would the
incremental efficiency obtainable by implementing such a veneer below
the declared GSS boundary be sufficiently motivating relative to a
separate modular layer above GSS?

> Thanks for your attention,
> Fengmin
> 
--jl

Return-Path: <[e-mail]>
Date: Thu, 22 Jan 1998 09:36:54 GMT
From: [e-mail] (Guang Li)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Questions on RFC2078
X-Sun-Charset: US-ASCII


Fengmin Gong & jl writes, excerpting:

	> 2) The kind of scenarios I face also desire another
	> feature that is missing from RFC2078 spec, i.e., a kind
	> of "delegation mode" per-message protection call. For example,
	> a GSS_Wrap_and_send() call will do all the things that
	> GSS_Wrap() does now, but in addition will send the wrapped
	> message out of the network protocol stack instead of
	> returning it to the caller.  Although I could make do by 
	> returning the original message to the caller as appropriate, 
	> it does have some efficiency implication.
	> 
	> I realize that this requirement seems to run against the
	> GSS-API principle of "protocol environment independence"
	> but I can also argue otherwise.  Availability of such 
	> delegation feature will be mechasnism dependent, similar
	> to QoP support; it can be made known to the applications
	> at context establishment item using those service flags;
	> separate per-message calls avoid changing any of the
	> existing calls.
	> 
	Mechanism dependence issues aside, this sort of coupling could also be
	specific not only to protocol environments but also to the communication
	access APIs used within an end system. If appropriate in a particular
	environment, it's certainly possible to wrap GSS calls within a veneer
	which also bundles invocation of communications-level calls; would the
	incremental efficiency obtainable by implementing such a veneer below
	the declared GSS boundary be sufficiently motivating relative to a
	separate modular layer above GSS?

this is indeed the case for many GSS applications, notably the
OMG's SECIOP. BTW, GSS manages its own buffers, which introduces
unnecessary message copys, and is apparently againest high-performance
protocol design principles.

Dr. Guang X. Li
Information Technology
SBC Warburg Dillon Read
Swiss Bank Corporation
1 Finsbury Avenue
London EC2M 2PP
	

Return-Path: <[e-mail]>
From: Martin Rex <[e-mail]>
Subject: Re: Questions on RFC2078
To: [e-mail] (Guang Li)
Date: Mon, 26 Jan 1998 19:44:56 +0100 (MEZ)
Cc: [e-mail]
Reply-To: [e-mail]


Guang Li wrote:
> 
> this is indeed the case for many GSS applications, notably the
> OMG's SECIOP. BTW, GSS manages its own buffers, which introduces
> unnecessary message copys, and is apparently againest high-performance
> protocol design principles.

Those "unecessary" message copies make the gss-api much simpler and
more robust as an API, both in the gssapi mechanism and the application.
Neither has to care about alignment, blocksize, padding and the case
that the supplied buffer is too small.  The performance impact should
in general be less than 2%, so basically insignificant.

For message integrity only one could use gss_getmic()/gss_verifymic(),
which doesn't copy the message, for confidentiality protection
the extra copy is really in the noise of the encryption.

-Martin

Return-Path: <[e-mail]>
From: "Mike Swift (NT)" <[e-mail]>
To: [e-mail]
Subject: Proposed draft on name referrals in Kerberos
Date: Mon, 26 Jan 1998 13:48:35 -0800

Here is the initial draft of a proposal on handling name referrals in
Kerberos. I haven't decided yet whether this should be put through the CAT
group or simply published as an information draft about the Microsoft
implementation of Kerberos. However, I'm interested in people's feedback on
the mechanism in general.

------------------------------------------------------------------------


CAT Working Group                           Michael M. Swift
INTERNET-DRAFT                                     Microsoft
<draft-ietf-cat-init-kerb-referrals-00.txt >
Expires July 15, 1998                       January 15, 1998



                  Generating KDC Referrals


STATUS OF THIS MEMO

This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress".

To learn the current status of any Internet-Draft, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West
Coast).

Distribution of this document is unlimited.  Please send
comments to the CAT working group at [e-mail] or the
authors.

ABSTRACT

The draft proposes a new method for a Kerberos Key
Distribution Center (KDC) to respond to client requests for
tickets. The KDC will handle requests for principals in
other realms by returning either a referral error or a cross-
realm TGT to another realm on the referral path.

Table of Contents

1.      Introduction                    2

2.      Security Considerations         2

3.      References                      2




1.   Introduction

The Kerberos TGS and AS protocols, as defined in RFC 1510
[1], require that client software be able to parse principal
names into a realm and an account portion. However, if a
site want to deploy a Kerberos realm infrastructure
separately from its DNS infrastructure, Kerberos must be
able to handle the case where the client software does not
know what realm contains a given service or user principal
name. In addition, the current protocol requires the client
to know the hierarchy of realms by explicitly asking for a
referral to a specific realm rather than letting the KDC
pick the next realm on the referral path.

To rectify these problems, this draft introduces three new
kinds of KDC referrals:

1.   AS ticket referrals, in which the client doesnt know
     which realm contains a user account.
2.   TGS ticket referrals, in which the client doesnt know
     which realm contains a server account.
3.   Cross realm shortcut referrals, in which the KDC
     chooses the next path on a referral chain


2.   Realm Organization Model

This draft assumes that the world of principals is arranged
on multiple levels: the realm, the enterprise, and the
world. A KDC may issue tickets for any principal in its
realm or cross-realm tickets for realms with which it has a
direct trust relationship. A realm has access to a directory
or name service that can resolve any name from within its
enterprise into a realm. In addition, at the top of an
enterprise hierarchy there is a list of trusted enterprises
in the world and information on what names are owned by
those enterprises.

For example, consider the following configuration, where
lines indicate trust relationships:

              MS.COM ---------------------- MIT.EDU
            /       \                     /         \
          /           \                 /            \
     OFFICE.MS.COM  NT.MS.COM      LCS.MIT.EDU ATHENA.MIT.EDU

In this configuration, all users in the MS.COM enterprise
could have a principal name such as [e-mail], with the
same realm portion, and all users in the MIT.EDU enterprise
could have principal names as [e-mail]. In addition,
servers at MS.COM should be able to have DNS host names from
any DNS domain independent of what Kerberos realm their
principal resides in. Finally, users from the MIT.EDU and
MS.COM enterprises should be able to authenticate to
services in the other enterprise.

In this model, all realms in the MS.COM enterprise must end
in MS.COM and all realms in the MIT.EDU enterprise must
end in MIT.EDU. While it is not necessary that all names
in both enterprise end in these postfixes, names that dont
will not be usable from the other enterprise.


3.   Name Types

In order to indicate to the KDC that a name may not be
present in its realm, this protocol introduces a new name
type: KRB_NT_ENTERPRISE_PRINCIPAL = 10, indicating that the
name is an enterprise principal and may not exist in the
target domain. In addition and unlike other principal names,
the entire name is transmitted rather than separating it
into name parts. This allows the whole name to be looked up
as it was entered without any processing on the client.

4.   AS Ticket Referrals

The simplest form of ticket referral is for a user
requesting an AS ticket. In this case, the client machine
will send the AS request to a convenient realm, probably
either the realm of the client machine or the realm portion
of the name. In the case of the name [e-mail], the
client may optimistically choose to send the request to
MS.COM. The client will send both Alice and ms.com in
the principal name field. The KDC will try to lookup the
name in its local account database. If the account is
present, it will return a KDC reply structure with the
appropriate ticket. If the account is not present, it will
try to lookup the entire name ([e-mail]) in the
enterprise directory. If this lookup is unsuccessful, it
will return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. The
client realm field will contain the realm of the root of the
enterprise. If the lookup is successful, it will return an
error KRB_ERR_WRONG_REALM (0x44) and in the error message,
the cname and crealm field will contain the client name and
the true realm of the client.

If the client receives a KDC_ERR_WRONG_REALM error, it will
issue a new AS request to the realm specified by the crealm
field of the error message. In this case, the client should
fail if it receives another referral. This error indicates
an authoritative referral  the account really is in the
domain specified.

If the client received a KDC_ERR_C_PRINCIPAL_UNKNOWN error
and a crealm other than the realm of the original KDC, it
should issue an AS request against that realm. The error
indicates that the client can expect another referral from
this request. Typically, the original realm will refer the
client to the root of the enterprise, which will then refer
the client to the root of another enterprise, which will
then refer the client to the correct realm in the other
enterprise. This may require that enterprise by pre-
configured for trust or that the KDC is able to locate a KDC
in another realm from the DNS portion of a name in order to
do public-key cross-realm trust.


5.   TGS Referrals

The TGS referral mechanism is a bit more complex than the AS
referral mechanism. The primary problem is that the KDC must
return a referral ticket rather than an error message, so it
must include in the TGS response information about what
realm contains the service. This is done by returning
information about the server name in the pre-auth data field
of the KDC reply.
There are two types of referrals: authoritative referrals,
in which the original KDC knows what realm contains a
service,and non-authoritative referrals, in which the KDC
doesnt know issues a referral to a realm that may know
where the service is located.

5.1  Authoritative TGS Referrals

In this case, the KDC has successfully resolved the server
principal name into a Kerberos realm. In this case, the KDC
will return the a server realm as a PA data type. The data
itself is an asn.1 encoded Realm and the following type:

#define KRB5_PADATA_SERVER_REALM   19

The client can use this information to request follow a
chain of cross-realm TGTs until it reaches this realm, and
can then expect to receive a valid service ticket.


5.2  Non-Authoritative TGS referrals

In the case that the KDC cant resolve the name but can
determine that it probably comes from another enterprise
(the realm portion of the name has a different postfix). In
this case, the KDC will return a referral ticket to a realm
closer on the route to the other enterprise, which will
generally be either the parent of the domain or a domain in
the other enterprise. The KDC will also return the name of a
realm in which the client should try to resolve the name in
a pre-auth data field:
#define KRB5_PADATA_SERVER_REFERRAL_REALM    20


5.3  Client Operations

In both the authoritative and non-authoritative referral
case, the client should follow the referral chain until it
hits the KDC for the realm specified by the original TGS
response. At that point it should attempt to get a TGS
ticket to the server principal name. If the original
referral was authoritative, the client can expect this to
return the correct ticket. If the original referral was not
authoritative, the client should expect this request to
return another referral realm and another cross-realm TGT.

Non-authoritative referrals have the possibility of becoming
a goose chase in which each realm refers the client to
another realm without ever terminating. In this case, the
client code will have to decide when to terminate the search
by bounding the number of non-authoritative referrals it
follow. If enterprises directly trust each other, it is
suggested that a client follow no more than two non-
authoritative referrals.


6.   Cross Realm Routing

The current Kerberos protocol requires the client libraries
to explicitly request a cross-realm TGT for each pair of
realms on a referral chain. As a result, the client machines
need to be aware of the trust hierarchy and of any short-cut
trusts (those that arent parent-child trusts). This
requires a lot of configuration on the client. Instead, the
client should be able to request a TGT to the target realm
from each realm on the route. The KDC will determine the
best path for the client and return a cross-realm TGT. The
client software has to be aware that a request for a cross-
realm TGT may return a TGT for a realm different from the
one requested.

7.   Security Considerations

The original Kerberos specification stated that the server
principal name in the KDC reply was the same as the server
name in the request. These protocol changes break that
assumption, so the client may be vulnerable to a denial of
service attack by an attacker that replays replies from
previous requests. It can verify that the request was one
its own by checking the client-address field or authtime
field, though, so the damage is limited.


8.    References

  [1]  J. Kohl, C. Neuman.  The Kerberos Network
     Authentication Service(V5).  Request for Comments 1510.
  [2]  J. Linn.  The Kerberos Version 5 GSS-API Mechanism.
     Request for Comments 1964
  [3] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J.
     Trostle, Public Key Cryptography for Initial
     Authentication in Kerberos, draft-ietf-cat-kerberos-pk-
     init-04.txt.
  [4] M. Swift, User to User Kerberos Authentication using
     GSS-API, draft-ietf-cat-user2user-01.txt.




Authors Address:
Michael Swift
Microsoft
1 Microsoft Way
Redmond, Washington, 98052, U.S.A.
Email: [e-mail]


Return-Path: <[e-mail]>
To: "Mike Swift (NT)" <[e-mail]>
Cc: [e-mail]
Subject: Re: Proposed draft on name referrals in Kerberos
X-Emacs: 19.34
From: [e-mail] (Johan Danielsson)
Date: 27 Jan 1998 17:58:19 +0100
Lines: 6


Couldn't this more easily be solved with some `mail address' to
principal conversion database? For hosts such a database is already in
widespread use.

/Johan

Return-Path: <[e-mail]>
From: "Mike Swift (NT)" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Proposed draft on name referrals in Kerberos
Date: Tue, 27 Jan 1998 09:55:20 -0800

The problem is that there is not a mapping between the domain portion of the
email name and the Kerberos realm. As a result, it is not possible for a
client machine to discover the correct realm for a particular name. In
addition, as this mechanism is used for obtaining the initial ticket, the
name mapping from a meta-directory cannot be trusted. By integrating the
mapping with the Kerberos protocol the client can trust the KDC to perform
the mapping properly.

- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, January 27, 1998 8:58 AM
To: Mike Swift (NT)
Cc: [e-mail]
Subject: Re: Proposed draft on name referrals in Kerberos



Couldn't this more easily be solved with some `mail address' to
principal conversion database? For hosts such a database is already in
widespread use.

/Johan

Return-Path: <[e-mail]>
From: "Mike Swift (NT)" <[e-mail]>
To: [e-mail]
Subject: Kerberos over TCP/IP
Date: Tue, 27 Jan 1998 10:13:52 -0800

I think that we should add a method for the KDC to return an error to the
client indicating that the client needs to use a different transport. For
example, if the client tries to do PKINIT over UDP and the KDC discovers
that the response won't fit in a datagram, the KDC should be able to return
an error indicating that the client should switch to TCP. We don't
necessarily need to code exactly that message, but perhaps a new error code,
such as KDC_ERR_RESPONSE_TOO_BIG, indicating that the transport can't handle
the size of the response. The client would then be responsible for finding a
transport that could handle a larger message.

In addition, another scenario in which the KDC would want the client to
change transports is if it knows it won't be able to respond within the
timeout for UDP. It is conceivable that with PK-CROSS, in which the KDC may
need to locate and communicate with a KDC in another realm, that it won't be
able to respond within the client's timeout. Perhaps we could formalize a
mechanism for the KDC to return a keep-alive, indicating that the client
should wait longer. One way to do this would be for the KDC to return a
KRB-ERROR message with an error KDC_ERR_PENDING, and a e-data value
indicating how long the client shoud wait. That would allow longer running
transactions to work reasonably over UDP.

- Mike

Return-Path: <[e-mail]>
X-Sender: [e-mail]
Date: Tue, 27 Jan 1998 10:29:55 -0800
To: "Mike Swift (NT)" <[e-mail]>, [e-mail]
From: Matt Hur <[e-mail]>
Subject: Re: Proposed draft on name referrals in Kerberos

<x-rich>At 01:48 PM 1/26/98 -0800, you wrote:

>Here is the initial draft of a proposal on handling name referrals in

>Kerberos. I haven't decided yet whether this should be put through the CAT

>group or simply published as an information draft about the Microsoft

>implementation of Kerberos. However, I'm interested in people's feedback on

>the mechanism in general.

>


 ...


>6.   Cross Realm Routing

>

>The current Kerberos protocol requires the client libraries

>to explicitly request a cross-realm TGT for each pair of

>realms on a referral chain. As a result, the client machines

>need to be aware of the trust hierarchy and of any short-cut

>trusts (those that arent parent-child trusts). This

>requires a lot of configuration on the client. Instead, the

>client should be able to request a TGT to the target realm

>from each realm on the route. The KDC will determine the

>best path for the client and return a cross-realm TGT. The

>client software has to be aware that a request for a cross-

>realm TGT may return a TGT for a realm different from the

>one requested.

>

 ...



PKCROSS specifies the following:


    Optionally, the local KDC may add another TicketExtention where

       te-type equals 5 for TE-TYPE-DEST-HOST

    and

       te-data is ASN.1 encoding of DestHost.

    A client could then rely on the local KDC to provide a referral to

    the remote KDC, thus removing the need for the client to maintain

    local host/realm mapping information.


    DestHost ::= SEQUENCE {

           DNSHostname [0]    OCTET STRING,

                              -- authoritative DNS hostname

           HostAddr    [1]    HostAddress OPTIONAL

                              -- as defined by RFC 1510

    }



I think that it would be preferable for your implementation to use this mechanism.


--Matt



<italic><color><param>0000,0000,ffff</param>---------------------------------------------------------------

Matt Hur                      CyberSafe

[e-mail]        1605 NW Sammamish Road, Suite 310

[phone] x154 voice     Issaquah, WA 98027-5378

[phone] fax            http://www.cybersafe.com

</color></italic>

</x-rich>
Return-Path: <[e-mail]>
From: "Mike Swift (NT)" <[e-mail]>
To: Matt Hur <[e-mail]>, [e-mail]
Subject: RE: Proposed draft on name referrals in Kerberos
Date: Tue, 27 Jan 1998 10:41:02 -0800

It seemed to me that the suggestion from PK-CROSS was a starting point but
not sufficient. It let the client know what server to talk to but not what
realm, and as a result the client can't take advantage of existing
cross-realm TGTs in its cache. In addition, I'm not convinced that the KDC
is the best service to be returning the address of a KDC to the client. In
the case where you have a multiple widely distributed realm, it may be that
there is another KDC closer that could be looked up in DNS. 
 
- Mike

 -----Original Message-----
From: Matt Hur [mailto:[e-mail]]
Sent: Tuesday, January 27, 1998 10:30 AM
To: Mike Swift (NT); [e-mail]
Subject: Re: Proposed draft on name referrals in Kerberos



At 01:48 PM 1/26/98 -0800, you wrote: 

>Here is the initial draft of a proposal on handling name referrals in 
>Kerberos. I haven't decided yet whether this should be put through the CAT 
>group or simply published as an information draft about the Microsoft 
>implementation of Kerberos. However, I'm interested in people's feedback on

>the mechanism in general. 
> 

... 

>6. Cross Realm Routing 
> 
>The current Kerberos protocol requires the client libraries 
>to explicitly request a cross-realm TGT for each pair of 
>realms on a referral chain. As a result, the client machines 
>need to be aware of the trust hierarchy and of any short-cut 
>trusts (those that arent parent-child trusts). This 
>requires a lot of configuration on the client. Instead, the 
>client should be able to request a TGT to the target realm 
>from each realm on the route. The KDC will determine the 
>best path for the client and return a cross-realm TGT. The 
>client software has to be aware that a request for a cross- 
>realm TGT may return a TGT for a realm different from the 
>one requested. 
> 
... 


PKCROSS specifies the following: 

Optionally, the local KDC may add another TicketExtention where 
te-type equals 5 for TE-TYPE-DEST-HOST 
and 
te-data is ASN.1 encoding of DestHost. 
A client could then rely on the local KDC to provide a referral to 
the remote KDC, thus removing the need for the client to maintain 
local host/realm mapping information. 

DestHost ::= SEQUENCE { 
DNSHostname [0] OCTET STRING, 
-- authoritative DNS hostname 
HostAddr [1] HostAddress OPTIONAL 
-- as defined by RFC 1510 
} 


I think that it would be preferable for your implementation to use this
mechanism. 

--Matt 


--------------------------------------------------------------- 
Matt Hur CyberSafe 
[e-mail] 1605 NW Sammamish Road, Suite 310 
[phone] x154 voice Issaquah, WA 98027-5378 
[phone] fax http://www.cybersafe.com 

Return-Path: <[e-mail]>
To: "Mike Swift (NT)" <[e-mail]>
Cc: [e-mail]
Subject: Re: Proposed draft on name referrals in Kerberos
X-Emacs: 19.34
From: [e-mail] (Johan Danielsson)
Date: 27 Jan 1998 21:28:01 +0100
Lines: 19

"Mike Swift (NT)" <[e-mail]> writes:

> The problem is that there is not a mapping between the domain
> portion of the email name and the Kerberos realm.

Not an obvious, no. That's what you need a database for.

> In addition, as this mechanism is used for obtaining the initial
> ticket, the name mapping from a meta-directory cannot be trusted.

No, but you don't have to. You can at most accomplish denial of
service.

> By integrating the mapping with the Kerberos protocol the client can
> trust the KDC to perform the mapping properly.

How can you know that it ism't a fake KDC you are talking to?

/Johan

Return-Path: <[e-mail]>
From: "Renard, Kenneth" <[e-mail]>
To: [e-mail], "'Mike Swift (NT)'" <[e-mail]>
Subject: RE: Kerberos over TCP/IP
Date: Tue, 27 Jan 1998 15:41:53 -0500

A KDC_ERR_PENDING message would be pretty useful for high-latency
transactions such as One-Time-Password (OTP) pre-authentication.
Current scenario:
	
	AS client (kinit) sends request to primary KDC
	Primary KDC starts up high-latency preauth check (e.g. SecurID
code)
	AS client times out and sends request to secondary KDC
	Secondary KDC starts preauth check [This is now the 2nd time the
OTP is
		used, the 2nd attempt will fail, the 1st attempt may
fail now too]
	Race to see which KDC (primary KDC with auth success(?) or
secondary with 		failure) comes back first

A KDC_ERR_PENDING message would do the trick.  Should this type of
message [and timeout value] be signed by the KDC (encrypted with user
key)?

Unfortunately, for all AS and TGS transactions, the KDC process blocks.
If KDC throughput is an issue, you want to stay away from these.  Anyone
want to write a Multi-Threaded KDC??

-Ken Renard

> ----------
> From: 	Mike Swift (NT)[SMTP:[e-mail]]
> Sent: 	Tuesday, January 27, 1998 1:13 PM
> To: 	[e-mail]
> Subject: 	Kerberos over TCP/IP
> 
> I think that we should add a method for the KDC to return an error to
> the
> client indicating that the client needs to use a different transport.
> For
> example, if the client tries to do PKINIT over UDP and the KDC
> discovers
> that the response won't fit in a datagram, the KDC should be able to
> return
> an error indicating that the client should switch to TCP. We don't
> necessarily need to code exactly that message, but perhaps a new error
> code,
> such as KDC_ERR_RESPONSE_TOO_BIG, indicating that the transport can't
> handle
> the size of the response. The client would then be responsible for
> finding a
> transport that could handle a larger message.
> 
> In addition, another scenario in which the KDC would want the client
> to
> change transports is if it knows it won't be able to respond within
> the
> timeout for UDP. It is conceivable that with PK-CROSS, in which the
> KDC may
> need to locate and communicate with a KDC in another realm, that it
> won't be
> able to respond within the client's timeout. Perhaps we could
> formalize a
> mechanism for the KDC to return a keep-alive, indicating that the
> client
> should wait longer. One way to do this would be for the KDC to return
> a
> KRB-ERROR message with an error KDC_ERR_PENDING, and a e-data value
> indicating how long the client shoud wait. That would allow longer
> running
> transactions to work reasonably over UDP.
> 
> - Mike
> 

Return-Path: <[e-mail]>
To: "Renard, Kenneth" <[e-mail]>
Cc: [e-mail]
Subject: Re: Kerberos over TCP/IP 
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<|um5yP<ea#^"SJK;C*}fMI;Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Wed, 28 Jan 1998 22:34:56 -0500
From: Ken Hornstein <[e-mail]>

>A KDC_ERR_PENDING message would be pretty useful for high-latency
>transactions such as One-Time-Password (OTP) pre-authentication.

I thought that one of the design criteria of the KDC was that it
it was stateless ... it looks like to me that adding this would require
keeping track of state to the KDC.

And I have yet to understand why SecurID takes so long to perform
authentication, anyway :-)

--Ken

Return-Path: <[e-mail]>
From: Ewald Kamp <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: unsubscribe
Date: Thu, 29 Jan 1998 09:29:54 +-100

unsubscribe

Return-Path: <[e-mail]>
From: "Wiebe,Philip" <[e-mail]>
To: [e-mail]
Subject: unsubscribe
Date: Thu, 29 Jan 1998 08:31:00 -0500

     unsubscribe

Return-Path: <[e-mail]>
From: Ewald Kamp <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: unsubscribe
Date: Thu, 29 Jan 1998 16:32:52 +-100

unsubscribe

Return-Path: <[e-mail]>
From: "Mike Swift (NT)" <[e-mail]>
To: "Renard, Kenneth" <[e-mail]>,
        "'Ken Hornstein'"
	 <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: Kerberos over TCP/IP 
Date: Thu, 29 Jan 1998 09:16:05 -0800

The Microsoft KDC is multi-threaded and may need to support longer-running
requests - hence my interest in adding a pending message. In addition, I
think the error for indicating that the response message is too big to fit
in a UDP message is useful unless clients know to try TCP first, which they
may not want to for performance reasons.

- Mike
-----Original Message-----
From: Renard, Kenneth [mailto:[e-mail]]
Sent: Thursday, January 29, 1998 7:41 AM
Subject: RE: Kerberos over TCP/IP 

...

Hmmm... a multi-threaded KDC sounds pretty cool!  Any ideas/issues?

	> --Ken

-Ken R.

Return-Path: <[e-mail]>
To: "Renard, Kenneth" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: Kerberos over TCP/IP 
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<|um5yP<ea#^"SJK;C*}fMI;Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Thu, 29 Jan 1998 12:33:18 -0500
From: Ken Hornstein <[e-mail]>

>Hmmm... a multi-threaded KDC sounds pretty cool!  Any ideas/issues?

I'm not sure this is appropriate for cat-ietf, buuuttt ...

Currently under Unix, threads present portability problems.  If you're
using one of the many userspace threads packages, you probably shouldn't
even bother, since they're non-preemptive and you'll just end up with
an event-driven KDC like you have now.

Even when you have kernel support for threads, the implementations I've
seen don't actually get you concurrency unless you have a multiprocessor
machine.

--Ken

Return-Path: <[e-mail]>
Date: Thu, 29 Jan 1998 13:33:30 -0500 (EST)
From: Richard Salz <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Kerberos over TCP/IP
Cc: [e-mail], [e-mail]

>The Microsoft KDC is multi-threaded and may need to support longer-running
>requests - hence my interest in adding a pending message. In addition, I
>think the error for indicating that the response message is too big to fit
>in a UDP message is useful unless clients know to try TCP first, which they
>may not want to for performance reasons.

This sounds like a big step down the slippery slope of re-implementing
an industrial-strength RPC system.  I don't think it's something
for this working group or this specification.
	/r$

Return-Path: <[e-mail]>
From: "Mike Swift (NT)" <[e-mail]>
To: Richard Salz <[e-mail]>
Cc: [e-mail]
Subject: RE: Kerberos over TCP/IP
Date: Thu, 29 Jan 1998 10:39:32 -0800

True, it is a rathole. However, will the Kerberos protocol function with the
new heavyweight extensions if something like this isn't added? I know DCE
went to RPC for the KDC, which resolves all these problems. The question is
how best to fix this for MIT kerberos - incrementally adding robustness
features or switch wholesale to a new transport protocol.

-----Original Message-----
From: Richard Salz [mailto:[e-mail]]
Sent: Thursday, January 29, 1998 10:34 AM
To: [e-mail]; [e-mail]; Mike Swift (NT)
Cc: [e-mail]; [e-mail]
Subject: RE: Kerberos over TCP/IP


>The Microsoft KDC is multi-threaded and may need to support longer-running
>requests - hence my interest in adding a pending message. In addition, I
>think the error for indicating that the response message is too big to fit
>in a UDP message is useful unless clients know to try TCP first, which they
>may not want to for performance reasons.

This sounds like a big step down the slippery slope of re-implementing
an industrial-strength RPC system.  I don't think it's something
for this working group or this specification.
	/r$

Return-Path: <[e-mail]>
Date: Thu, 29 Jan 1998 13:57:21 -0500 (EST)
From: Richard Salz <[e-mail]>
To: [e-mail]
Subject: RE: Kerberos over TCP/IP
Cc: [e-mail]

>True, it is a rathole. However, will the Kerberos protocol function with the
>new heavyweight extensions if something like this isn't added? I know DCE
>went to RPC for the KDC, which resolves all these problems. The question is
>how best to fix this for MIT kerberos - incrementally adding robustness
>features or switch wholesale to a new transport protocol.

I believe the best fix is to say "use another protocol" or "try TCP first."
This can be a "note to implementors" part of the spec.

I firmly believe this WG should not start down this path.  The slope is
way too steep.  Adding "in progress" (I prefer the ISO RPC name indy,
for I'm Not Dead Yet:) packets is a big step toward breaking the lockstep
request/reply nature of the protocol.  Especially because within 48 hours
of accepting this concept, someone will say that they are developing a
smart client and would like to ping the KDC themselves.  Etc.  The
slippery slope has a pretty steep slope, in my view.
	/r$

Return-Path: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'CAT-WG List'" <[e-mail]>
Subject: draft-ietf-cat-rfc2078bis-02.txt enroute
Date: Thu, 29 Jan 1998 14:29:42 -0500

CAT/2078bis fanciers:

Along with this message, and per plan as declared at the DC meeting, I'm
sending a new revision of 2078bis to the secretariat, to become
draft-ietf-cat-rfc2078bis-02.txt, largely to respond to discussion at
the December CAT meeting refining and closing specific points re GSS-V2,
whose scope has been stable for some time.  I believe that we're very
close to convergence, but a few points (noted below) remain pending.
Please review the changes as summarized below, and identify any other
issues requiring resolution before submission of GSS-V2 Update 1 to the
IESG on behalf of the WG, to be considered for the status of a new
Proposed Standard to succeed RFC-2078.  I hope that we can achieve
closure on the remaining points shortly (in particular, by Friday, 5
February), as input to revising the document specifically against those
points and submitting the result to a CAT-WG Last-Call period to begin
later in February and to conclude before the March-April IETF meeting in
Los Angeles. 

Remaining open points are as follows:

[From DC minutes] "It was recognized that current GSS-API specifications
do not prescribe the error which should be returned if a reflected token
(a token received by the endpoint which generated it) is detected.  Many
existing mechanisms' protocols include provisions for detecting such
tokens, and it seems reasonable that a major_status code should be
selected to indicate this situation."  Martin Rex posted a comment about
this issue to the list on 8 December, proposing use of
GSS_S_DUPLICATE_TOKEN if a per-message call detects a reflected token
and recommending that such detection be mandated when the replay
detection service is provided, but I don't believe that follow-up
discussion ensued.  

[From DC minutes] "An additional RFC2078bis topic had been identified
for discussion, but was not considered within the time available and
therefore remains outstanding: should GSS_S_NO_CRED be returned by
per-message calls if credential elements are needed but unavailable in
order to complete an operation?"  

List discussion (21-26 January) included suggestions for (a) facilities
to indicate QoP preferences during context initiation and (b) new calls
coupling per-message protection with transmission of protected data over
the network protocol stack to the context's peer. I believe that
inclusion of (a) would violate the backward compatibility assumptions
which have guided us in scoping GSS-V2 changes, and that (b) would
represent a demonstrably contentious scope change at this time.  My
working assumption, therefore, is that consensus does not now exist for
reflection of these suggestions within rfc2078bis. 

List discussion, 15-20 January, re GSS-API per-message protection
negotiation; needs closure and evaluation of any resulting consideration
within documents. 

Note: Need either to add "changes from 2078" section, or merge
additional 2078bis changes into the existing "changes from GSS-V1"
section.

Changes made in 2078bis-02 relative to 2078bis-01 are as follows:

Re GSS_Inquire_sec_context(), stated that src_name and targ_name are not
returned unless the context being reported is in GSS_S_COMPLETE state,
to avoid ambiguity as to whether or not a name object is being returned
(and, therefore, whether or not the caller needs to release it).  [Done
in 2078bis-02]

Per 21 Nov discussion, removed CONTEXT_EXPIRED as error from
inquire_context, replacing with EXPIRED lifetime return value.  Stated
obligation to maintain inquirable context data on expired context until
released by caller, even though underlying crypto elements may be
deleted.  [Done in 2078bis-02]

The sense of December meeting attendees confirmed that
GSS_Inquire_context() would be aligned with the C bindings to add a
result value indicating whether or not a context was fully open.
Expired contexts are to be indicated with a reserved "lifetime" value
rather than by returning the fatal CONTEXT_EXPIRED error.  [Reflected in
2078bis-02]

Attendees confirmed list discussion regarding the indication of
informational sequencing errors along with GSS_S_COMPLETE and
GSS_S_FAILURE major_status: consistent with the C bindings, 2078bis will
reflect that the sequencing error status codes may be indicated along
with either COMPLETE or FAILURE for per-message calls; while this is
syntactically possible for context establishment calls as well, return
of sequencing error status along with COMPLETE (or CONTINUE_NEEDED) will
remain semantically prohibited during the context establishment phase.
[Reflected in 2078bis-02, sec. 1.2.1.1]

Regarding side effects, it was considered appropriate to state that
invocation of GSS-API calls incurs no side effects visible at the
GSS-API level (it being considered implausibly broad to rule out side
effects on other aspects of system behavior).  [Reflected in 2078bis-02,
sec. 1.2.8]

For GSS_Acquire_cred() and GSS_Add_cred(), GSS_S_NO_CRED, rather than
GSS_S_FAILURE as at present, is to be returned if an authorization
failure is encountered upon credential acquisition. This decision
reconciles previous inconsistent choices in the direction of informative
error reporting. [Reflected in 2078bis-02]

In discussion at the DC meeting, the idea of making provision of a
target name to GSS_Init_sec_context() optional was accepted; the
specific working proposal was to recommend that mechanisms accept
GSS_C_NO_NAME as an input target_name type.  [Added this recommendation
in 2078bis-02, in the discussion of GSS_Init_sec_context(); also added a
small GSS_C_NO_NAME section 4.8, alongside the descriptions of other
name types.]

If an exported name object is imported with GSS_Import_name() and the
enclosed mechanism type is not recognized or unsupported, it was
considered (consistent with list discussion) that GSS_S_BAD_MECH should
be returned.  [Reflected in 2078bis-02]

Discussion at the session confirmed that RFC2078bis is to be aligned
with the C bindings by removing (rather than deprecating, as is
currently the case) GSS_S_CREDENTIALS_EXPIRED as a return value from
per-message protection, context_time, and inquire_context calls.
[Reflected in 2078bis-02]

Regarding the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials
with explicit names, it was considered at the DC meeting that an
explicit name as returned from GSS_Inquire_context() should be
acceptable as an input to credential acquisition.  It is important to
recognize that the explicit name which is yielded by resolution of a
reference to "default" may change over time, e.g., as a result of local
credential element management operations outside GSS-API. [Reflected in
2078bis-02, in texts for GSS_Acquire_cred() and GSS_Add_cred().]

--jl


John Linn ([e-mail])
RSA Laboratories East, Bedford, MA, USA

Return-Path: <[e-mail]>
To: "Mike Swift (NT)" <[e-mail]>
Cc: Richard Salz <[e-mail]>, [e-mail]
Subject: Re: Kerberos over TCP/IP 
Date: Thu, 29 Jan 1998 16:36:49 -0500
From: Bill Sommerfeld <[e-mail]>

To inject some facts into the discussion, the decision to have DCE use
RPC in addition to (not instead of!) UDP/IP for KDC communication was
in many ways a political one and had nothing to do with the size of
the messages possible over UDP, or other properties of the transport
protocol.

DCE was intended to be transport-protocol independant, with all the
per-transport-protocol hair localized within RPC and all communication
done over RPC.  Sort of like IP, only at a slightly higher layer in
the stack.

So, in the case of Kerberos, the byte string containing the datagram
to be sent via UDP was instead passed as a byte array parameter in an
RPC...

I question the wisdom of bloating kerberos messages to the point where
they won't fit in a sub-path-MTU udp datagram... but if you have to do
that, the Right Answer is clearly to just use TCP...  but that adds
significant complexity to the KDC due to (among other things)
connection management and flow control issues..

				- Bill
				(DCE implementor...)

Return-Path: <[e-mail]>
X-Sender: [e-mail]
Date: Thu, 29 Jan 1998 15:00:04 -0800
To: "Mike Swift (NT)" <[e-mail]>, [e-mail]
From: Matt Hur <[e-mail]>
Subject: RE: Proposed draft on name referrals in Kerberos

<x-rich>I believe that the PKCROSS specification is sufficient.  Please see embedded comments.


At 10:41 AM 1/27/98 -0800, Mike Swift (NT) wrote:

>It seemed to me that the suggestion from PK-CROSS was a starting point but

>not sufficient. It let the client know what server to talk to but not what

>realm, and as a result the client can't take advantage of existing


The realm is in the message returned from the KDC.


>cross-realm TGTs in its cache. In addition, I'm not convinced that the KDC


I'm not sure what you mean about taking advantage of existing cross realm tickets.  You want the client, upon receiving a cross realm TGT from the KDC, to then take advantage of a cross realm ticket that it has cached?


>is the best service to be returning the address of a KDC to the client. In

>the case where you have a multiple widely distributed realm, it may be that

>there is another KDC closer that could be looked up in DNS. 


There is no guarantee that DNS will map accordingly.


--Matt



> 

>- Mike

>

> -----Original Message-----

>From: Matt Hur [mailto:[e-mail]]

>Sent: Tuesday, January 27, 1998 10:30 AM

>To: Mike Swift (NT); [e-mail]

>Subject: Re: Proposed draft on name referrals in Kerberos

>

>

>

>At 01:48 PM 1/26/98 -0800, you wrote: 

>

>>Here is the initial draft of a proposal on handling name referrals in 

>>Kerberos. I haven't decided yet whether this should be put through the CAT 

>>group or simply published as an information draft about the Microsoft 

>>implementation of Kerberos. However, I'm interested in people's feedback on

>

>>the mechanism in general. 

>> 

>

>... 

>

>>6. Cross Realm Routing 

>> 

>>The current Kerberos protocol requires the client libraries 

>>to explicitly request a cross-realm TGT for each pair of 

>>realms on a referral chain. As a result, the client machines 

>>need to be aware of the trust hierarchy and of any short-cut 

>>trusts (those that arent parent-child trusts). This 

>>requires a lot of configuration on the client. Instead, the 

>>client should be able to request a TGT to the target realm 

>>from each realm on the route. The KDC will determine the 

>>best path for the client and return a cross-realm TGT. The 

>>client software has to be aware that a request for a cross- 

>>realm TGT may return a TGT for a realm different from the 

>>one requested. 

>> 

>... 

>

>

>PKCROSS specifies the following: 

>

>Optionally, the local KDC may add another TicketExtention where 

>te-type equals 5 for TE-TYPE-DEST-HOST 

>and 

>te-data is ASN.1 encoding of DestHost. 

>A client could then rely on the local KDC to provide a referral to 

>the remote KDC, thus removing the need for the client to maintain 

>local host/realm mapping information. 

>

>DestHost ::= SEQUENCE { 

>DNSHostname [0] OCTET STRING, 

>-- authoritative DNS hostname 

>HostAddr [1] HostAddress OPTIONAL 

>-- as defined by RFC 1510 

>} 

>

>

>I think that it would be preferable for your implementation to use this

>mechanism. 

>

>--Matt 

>

>

>--------------------------------------------------------------- 

>Matt Hur CyberSafe 

>[e-mail] 1605 NW Sammamish Road, Suite 310 

>[phone] x154 voice Issaquah, WA 98027-5378 

>[phone] fax http://www.cybersafe.com 

>

>

>

<italic><color><param>0000,0000,ffff</param>---------------------------------------------------------------

Matt Hur                      CyberSafe

[e-mail]        1605 NW Sammamish Road, Suite 310

[phone] x154 voice     Issaquah, WA 98027-5378

[phone] fax            http://www.cybersafe.com

</color></italic>

</x-rich>
Return-Path: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-recovery-00.txt
Date: Fri, 30 Jan 1998 09:41:02 -0500

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		: Public Key Cryptography for KDC Recovery in Kerberos V5
	Author(s)	: J. Trostle
	Filename	: draft-ietf-cat-kerberos-pk-recovery-00.txt
	Pages		: 7
	Date		: 29-Jan-98
	
   This document defines extensions to the Kerberos protocol
   specification (RFC 1510, ''The Kerberos Network Authentication
   Service (V5)'', September 1993) to enable the recovery of a
   compromised Kerberos V5 KDC using public key cryptography.
   The document specifies the recovery protocol which uses
   preauthentication data fields and error data fields in Kerberos
   messages to transport recovery data.

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-pk-recovery-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerberos-pk-recovery-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: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-cat-kerberos-pk-recovery-00.txt".
	
NOTE:	The mail server at ds.internic.net 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.

<ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerberos-pk-recovery-00.txt>
Return-Path: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-cat-rfc2078bis-02.txt
Date: Fri, 30 Jan 1998 09:51:23 -0500

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		: Generic Security Service Application 
                          Program Interface Version 2, Update 1
	Author(s)	: J. Linn
	Filename	: draft-ietf-cat-rfc2078bis-02.txt
	Pages		: 94
	Date		: 29-Jan-98
  	
   The Generic Security Service Application Program Interface (GSS-API),
   Version 2, as defined in [RFC-2078], provides security services to
   callers in a generic fashion, supportable with a range of underlying
   mechanisms and technologies and hence allowing source-level
   portability of applications to different environments. This
   specification defines GSS-API services and primitives at a level
   independent of underlying mechanism and programming language
   environment, and is to be complemented by other, related
   specifications:
 
      documents defining specific parameter bindings for particular
      language environments
 
      documents defining token formats, protocols, and procedures to be
      implemented in order to realize GSS-API services atop particular
      security mechanisms
 
   This Internet-Draft revises [RFC-2078], making specific, incremental
   changes in response to implementation experience and liaison
   requests. It is intended, therefore, that this draft or a successor
   version thereto will become the basis for subsequent progression of
   the GSS-API specification on the standards track.

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-rfc2078bis-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-rfc2078bis-02.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: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-cat-rfc2078bis-02.txt".
	
NOTE:	The mail server at ds.internic.net 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.

<ftp://ds.internic.net/internet-drafts/draft-ietf-cat-rfc2078bis-02.txt>
Return-Path: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "[e-mail]" <[e-mail]>,
        "'[e-mail]'"
	 <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: GSS-API per msg prot negotiation
Date: Fri, 30 Jan 1998 15:53:19 -0500

John Wray wrote, excerpting: 

> Would the following restrictions do what you want:
> 
>     A) If a gssapi mechanism spec allows for optional support of
>        particular QOP values, then either:
> 
>        i) All implementations are required to be capable of
>           processing messages protected using any QOP value,
>           regardless of whether they can apply protection
>           corresponding to that QOP,
> 
>        or
> 
>        ii) The set of mutually-supported receiver QOP values
>            must be determined during context establishment,
>            and messages may be protected by either peer
>            using only QOP values from this mutually-supported
>            set.
> 
>        NOTE: (i) is just a special-case of (ii), where
>              implementations are required to support
>              all QOP values on receipt.
> 
This seems like a clarifying statement which would be useful to be able
to include within 2078bis, probably within the QOP section (1.2.4).  To
consider one mechanism, RFC-1964 would need some changes to align with
(i); of three QOP-selectable integrity algorithms, it states that one
may not be supported by all implementations and the section's text is
silent about support requirements for the other two.  What's the group
sentiment about including the statement and aligning mechanism specs
accordingly?

>     B) A failure of gss_getmic() or gss_wrap() due to an attempt
>        to use an unsupported QOP will not interfere with context
>        validity, nor shall such a failure impact the ability of the
>        application to subsequently invoke gss_getmic() or
>        gss_wrap() using a supported QOP; in particular, any
>        state information concerning sequencing of outgoing
>        messages shall be unchanged by an unsuccesful call
>        of gss_getmic() or gss_wrap().
> 
>        NOTE: should the last clause (after the semilcolon) be
>              true in general - shouldn't any failure of gss_getmic()
>              or gss_wrap() leave sequencing state alone?
> 
I think that discussion in this area would logically fall into 2078bis's
Sec. 1.2.8 (Implementation Robustness).  John's note seems right to me;
what's the group sentiment about including two separate statements: the
clause up to the semicolon, and a separate sentence beginning with the
words "any state information..."?

--jl