Subject: RFC 1964 and Kerberos crypto framework

From: Ken Raeburn <[email-masked]>
Date: Wed, 05 Mar 2003 22:50:43 -0500

Okay, I've fit my ideas into the draft I had started a while back,
based on the 3des draft I had done even earlier.  There are still some
rough spots and open issues, but it should be good enough to show what
I've got in mind and get some discussion going.

This is *NOT* an attempt to add AES directly into the RFC 1964
framework.  Given that Kerberos already has a crypto framework, I
think updating the RFC 1964 mechanism separately for each new
encryption scheme is pointless.  The idea is to use any encryption or
checksum algorithm from the Kerberos cipher suite directly, and in
such a way that we should not need to update it again.  (Except for
DES-based algorithms -- see the section on backwards compatibility.)

I still don't think this is going to give us an ideal Kerberos
mechanism for GSSAPI.  There are still other issues we could address,
either in the GSSAPI mechanism directly, or in kerberos-extensions
messages upon which a new and much simpler mechanism could be based.
But the need to get better protection into GSSAPI right away means a
backwards-compatible but more easily extensible mechanism is highly
desirable in the short term.

Microsoft also has a draft they've started on, based in part I think
on some of our past discussions.  I've only glanced at it so far,
still need to evaluate it; it's possible they've got it further along
in some ways than mine, I don't know.

It's too late for either draft to get published before the San
Francisco meeting, but we can probably discuss it briefly then if we
get things rolling now.

Ken
(stop me before I ramble on for another hour...)

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 Mar 2003 22:14:04 -0600

IMO, If we can fix the new Kerberos V GSS mech so that we never have to
again, we should.

At Connectathon `03 Sam, Tom and I discussed the possibility of doing
one Kerberos extensions thing in the rfc1964 AES revamp, a decent
KRB-SAFE-X / MIC thing which is, correct me if I'm wrong, pretty much
the one thing that we really need to have a new mech defined solely in
terms of Kerberos concepts.

Cheers,

Nico

> (stop me before I ramble on for another hour...)

Content-Description: rfc1964 update for generic krb5 crypto
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kerberos Working Group                                         K. Raeburn
> Category: Standards Track?                                            MIT
> Updates: RFC 1964                                           March 5, 2003
> Document: draft-ietf-krb-wg-gssapi-crypto-XX.txtexpires September 5, 2003
> 
>                  General Kerberos Cryptosystem Support
>                   for the Kerberos 5 GSSAPI Mechanism
> 
> Abstract
> 
>    The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] sets up a
>    framework for enumerating encryption and checksum types,
>    independently of how such schemes may be used in Kerberos.  Kerberos
>    itself defines an encryption and checksum framework [KCRYPTO].  This
>    document describes an update to [GSSAPI-KRB5] to allow the use of
>    Kerberos-defined cryptosystems directly in GSSAPI messages, without
>    requiring further changes for each new encryption or checksum
>    algorithm that complies with the framework specifications.
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026 [1]. 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."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
> 1. Introduction
> 
>    Blah blah blah, etc.
> 
> 
> 
> 
> 
> 
> 
> 
> Raeburn                                                         [Page 1]
> 
> INTERNET DRAFT                                                March 2003
> 
> 
> 2. New Algorithm Identifiers
> 
>    Two new sealing algorithm numbers and one new signing algorithm
>    number are defined, for use in MIC, Wrap and Delete tokens.
> 
> 
>                  type          name          octet values
>                  -----------------------------------------
>                  seal   KERBEROS5-ENCRYPT       00 01
>                  sign   KERBEROS5-CHECKSUM      00 01
>                  sign          NONE             ff ff
> 
> 
>    The KERBEROS5-ENCRYPT algorithm encrypts using the Kerberos
>    encryption type [KCRYPTO] indicated by the encryption key type (using
>    the session key or initiator's subkey, as described in [GSSAPI-
>    KRB5]), with a key usage value KG_USAGE_SEAL, defined below.  All
>    Kerberos encryption types provide for integrity protection, and
>    specify any padding that might be required; neither needs to be done
>    at the GSS mechanism level when KERBEROS5-ENCRYPT is used.  When
>    KERBEROS5-ENCRYPT is used as the seal algorithm, the sign algorithm
>    must be NONE.
> 
>    The signing algorithm value NONE must only be used with a sealing
>    algorithm that incorporates integrity protection; currently,
>    KERBEROS5-ENCRYPT is the only such sealing algorithm.
> 
>    The KERBEROS5-CHECKSUM signing algorithm may be used in other cases.
>    The contents of the SGN_CKSUM field are determined by computing a
>    Kerberos checksum [KCRYPTO], using the session key or subkey, and a
>    key usage value of KG_USAGE_SIGN.  The Kerberos checksum algorithm
>    used is be the required-to-implement checksum algorithm associated
>    with the encryption key type.  It should be noted that the checksum
>    input data in this case is not the same as the "to-be-signed data"
>    described in section 1.2.1.1 of [GSSAPI-KRB5]; see below.
> 
>    The encryption or checksum output incorporated in the MIC and Wrap
>    tokens is the output from the corresponding operation in [KCRYPTO];
>    in particular, it is not the EncryptedData or Checksum object in
>    [KrbClar].
> 
>    For purposes of key derivation, we add two new usage values to the
>    list defined in [KrbClar]; one for signing messages, and one for
>    sealing messages:
> 
> 
> 
> 
> 
> 
> 
> Raeburn                                                         [Page 2]
> 
> INTERNET DRAFT                                                March 2003
> 
> 
>                                name        value
>                            ----------------------
>                            KG_USAGE_SEAL    22
>                            KG_USAGE_SIGN    23
> 
> 
> 3. Adjustments to Previous Definitions
> 
> 3.1. Quality of Protection
> 
>    The GSSAPI specification [GSSAPI] says that a zero QOP value
>    indicates the "default".  The original specification for the Kerberos
>    5 mechanism says that a zero QOP value (or a QOP value with the
>    appropriate bits clear) means DES encryption.
> 
>    Since the quality of protection cannot be improved without fully
>    reauthenticating with a stronger key type, the QOP value is now
>    ignored.
> 
> 3.2. Message Layout
> 
>    The definitions of the MIC and Wrap tokens in [GSSAPI-KRB5] assumed
>    an 8-byte checksum size, and a CBC-mode block cipher with an 8-byte
>    block size, without integrity protection.  In the crypto framework
>    described in [KCRYPTO], integrity protection is built into the
>    encryption operations.  CBC mode is not assumed, and indeed there may
>    be no initial vector to supply.  While the operations are performed
>    on messages of specific sizes, the underlying cipher may be a stream
>    cipher.
> 
>    We modify the message definitions such that the portions after the
>    first 8 bytes (which specify the token identification and the signing
>    and sealing algorithms) are defined by the algorithms chosen.  The
>    remaining bytes must convey sequence number and direction
>    information, and must protect the integrity of the token id and
>    algorithm indicators.  For the DES-based algorithms specified in
>    [GSSAPI-KRB5], the definition for the remaining data is backwards
>    compatible.
> 
>    The revised message descriptions are thus as follows:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Raeburn                                                         [Page 3]
> 
> INTERNET DRAFT                                                March 2003
> 
> 
>                                 MIC token
>           Byte #    Name         Description
>           -------------------------------------------------------
>             0..1    TOK_ID       Identification field (01 01).
>             2..3    SGN_ALG      Integrity algorithm indicator.
>             4..7    Filler       Contains ff ff ff ff
>           If SGN_ALG is 0000, 0100, 0200:
>             8..15   SND_SEQ      Sequence number/direction
>                                  field, encrypted.
>            16..23   SGN_CKSUM    Checksum of bytes 0..7 and
>                                  application data, as described
>                                  in [GSSAPI-KRB5].
>           If SGN_ALG is 0001:
>             8..15   SND_SEQ      Sequence number/direction
>                                  field, NOT encrypted.
>            16..N    SGN_CKSUM    Checksum of bytes 0..15 and
>                                  application data, with key
>                                  usage KG_USAGE_SIGN.
> 
> 
>    The filler bytes are included in the checksum calculation for
>    simplicity.  There is no security benefit from including them.
> 
>    In the Wrap token, the initial bytes, sequence number and direction
>    are incorporated into the data to be encrypted.  In most cases, this
>    is likely to be more efficient in terms of space and computing power
>    than using unencrypted sequence number and direction fields, adding a
>    checksum, and doing the additional work to authenticate that the
>    checksum and encrypted data are part of the same message.
> 
>       Q: Only the application data really needs to be encrypted.
>       However, if we don't encrypt them, we need to protect them with a
>       separate checksum.  Changing [KCRYPTO] to have "encrypt data, and
>       protect integrity of it and some additional data" instead of
>       "encrypt data and protect its integrity" probably wouldn't be
>       hard, but it's pretty late in the process.  Should we look into it
>       anyways?
> 
>    The length is also included, as a 4-byte value in network byte order,
>    because the decryption operation in the Kerberos crypto framework
>    does not recover the exact length of the original input.  Thus,
>    messages with application data larger than 4 gigabytes are not
>    supported.
> 
> 
> 
> 
> 
> 
> 
> 
> Raeburn                                                         [Page 4]
> 
> INTERNET DRAFT                                                March 2003
> 
> 
>                                 Wrap token
>         Byte #    Name         Description
>         ------------------------------------------------------------
>           0..1    TOK_ID       Identification field (02 01).
>           2..3    SGN_ALG      Integrity algorithm indicator.
>           4..5    SEAL_ALG     Sealing algorithm indicator.
>           6..7    Filler       Contains ff ff
>         If SEAL_ALG is 0000, 0100, 0200:
>           8..15   SND_SEQ      Encrypted sequence number field.
>          16..23   SGN_CKSUM    Checksum of plaintext padded data,
>                                calculated according to algorithm
>                                specified in SGN_ALG field.
>          24..N    Data         Encrypted or plaintext padded data.
>         If SEAL_ALG is 0001:
>           8..N    Data         Encrypted bytes 0..5, 2-byte
>                                direction flag, sequence number,
>                                4-byte data length, and data.
> 
> 
>    The direction flag, as in [GSSAPI-KRB5], is made up of bytes
>    indicating the party sending the token: 00 for the context initiator,
>    or hex FF for the context acceptor.  In the KERBEROS5-ENCRYPT case,
>    only two bytes are used, and they replace the fixed filler bytes of
>    the token header, which need no protection; this reduces slightly the
>    redundancy of the data transmitted.
> 
>    The context-deletion token is essentially a MIC token with no user
>    data and a different TOK_ID value.  Thus, its modification is
>    straightforward.
> 
> 
>                           Context deletion token
>           Byte #    Name         Description
>           -------------------------------------------------------
>             0..1    TOK_ID       Identification field (01 02).
>             2..3    SGN_ALG      Integrity algorithm indicator.
>             4..7    Filler       Contains ff ff ff ff
>           If SGN_ALG is 0000, 0100, 0200:
>             8..15   SND_SEQ      Sequence number/direction
>                                  field, encrypted.
>            16..23   SGN_CKSUM    Checksum of bytes 0..7, as
>                                  described in [GSSAPI-KRB5].
>           If SGN_ALG is 0001:
>             8..15   SND_SEQ      Sequence number/direction
>                                  field, NOT encrypted.
>            16..N    SGN_CKSUM    Checksum of bytes 0..15, with
>                                  key usage KG_USAGE_SIGN.
> 
> 
> 
> 
> Raeburn                                                         [Page 5]
> 
> INTERNET DRAFT                                                March 2003
> 
> 
> 4. Backwards Compatibility Considerations
> 
>    The context initiator should request of the KDC credentials using
>    session-key cryptosystem types supported by that implementation; if
>    the only types returned by the KDC are not supported by the mechanism
>    implementation, it should indicate a failure.  This may seem obvious,
>    but early implementations of both Kerberos and the GSSAPI Kerberos
>    mechanism supported only DES keys, so the cryptosystem compatibility
>    question was easy to overlook.
> 
>    Under the current mechanism, no negotiation of algorithm types
>    occurs, so server-side (acceptor) implementations cannot request that
>    clients not use algorithm types not understood by the server.
>    However, administration of the server's Kerberos data (e.g., the
>    service key) has to be done in communication with the KDC, and it is
>    from the KDC that the client will request credentials.  The KDC could
>    therefore be given the task of limiting session keys for a given
>    service to types actually supported by the Kerberos and GSSAPI
>    software on the server.
> 
>    This does have a drawback for cases where a service principal name is
>    used both for GSSAPI-based and non-GSSAPI-based communication (most
>    notably the "host" service key), if the GSSAPI implementation does
>    not understand (for example) AES but the Kerberos implementation
>    does.  It means that AES session keys cannot be issued for that
>    service principal, which keeps the protection of non-GSSAPI services
>    weaker than necessary.
> 
>    It would also be possible to have clients attempt to get DES session
>    keys before trying to get AES session keys, and have the KDC refuse
>    to issue the DES keys only for the most critical of services, for
>    which DES protection is considered inadequate.  However, that would
>    eliminate the possibility of connecting with the more secure
>    cryptosystem to any service that can be accessed with the weaker
>    cryptosystem.  We thus recommend the former approach, putting the
>    burden on the KDC administration and gaining the best protection
>    possible for GSSAPI services, possibly at the cost of weaker
>    protection of non-GSSAPI Kerberos services running earlier versions
>    of the software.
> 
> 5. Security Considerations
> 
>    Various tradeoffs arise regarding the mixing of new and old software,
>    or GSSAPI-based and non-GSSAPI Kerberos authentication.  They are
>    discussed in section 4.
> 
> 
> 
> 
> 
> 
> Raeburn                                                         [Page 6]
> 
> INTERNET DRAFT                                                March 2003
> 
> 
> 6. Normative References
> 
>    [GSSAPI]
>       Linn, J., "Generic Security Service Application Program Interface
>       Version 2, Update 1", RFC 2743, January, 2000.
> 
>    [GSSAPI-KRB5]
>       Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
>       June, 1996.
> 
>    [KCRYPTO]
>       draft-ietf-krb-wg-crypto-XX ...
> 
>    [KrbClar]
>       draft-ietf-krb-wg-kerberos-clarifications-XX ...
> 
> 7. Author's Address
> 
>    Kenneth Raeburn
>    Massachusetts Institute of Technology
>    77 Massachusetts Avenue
>    Cambridge, MA 02139
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works.  However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
> 
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assigns.
> 
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> 
> 
> 
> Raeburn                                                         [Page 7]
> 
> INTERNET DRAFT                                                March 2003
> 
> 
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
> 
> Document Change History
> 
> Version -00:
> 
>    Initial revision.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Raeburn                                                         [Page 8]

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 07 Mar 2003 05:06:15 -0500

> terms of Kerberos concepts.

Yes, that's the one missing piece that Kerberos Clarifications doesn't
give us.  Doing it as an extension to the existing mechanism seems a
lot clunkier than doing it in a new mechanism.  (If the session key is
DES you use this DES encryption and checksum, otherwise you include
this ASN.1 message?)  Simply updating the crypto handling seems a lot
cleaner, although it's still not very pretty.

Are we ready to settle on a form for this "KRB-SAFE-X" message for
Kerberos extensions?  Will it be a new message type, or KRB-SAFE with
the user data made optional?  Or is it not going to be in extensions,
and defined solely for GSSAPI?

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Mar 2003 10:55:07 -0600

> cleaner, although it's still not very pretty.

As things stand today, pretty much every new Kerberos enctype/sumtype
requires a new GSS mech.  So why not make the leap.  We still have time,
let's do it right once and for all; let's have one mech that will work
with new enctypes and sumtypes.

> and defined solely for GSSAPI?

I think so.  Tom?  Sam?

Options:

 - design KRB-MIC (with same extensions as planned for KRB-SAFE-X)
 - design KRB-SAFE-X with data made optional

Then let extensions pick up this one message from the updated mech
(either repeated verbatim or imported from the ASN.1 module [ha! the
mech has no ASN.1 module!]).

That reminds me, I'd like such things as channel bindings, GSS flags,
KRB-CRED, PROT_READY[1] and what not to be handled correctly (read
cleanly).

Channel bindings?  Yes.  Network address channel bindings are pretty
much useless, as we all know by now, but over the last week+ we've
discovered that it we really, really need channel bindings to lower
network layers that provide integrity and/or privacy protection (this is
where "transformed representations of encryption keys", from section
1.1.6 of rfc2743 comes in).  Perhaps we can leave the channel bindings
stuff as is in rfc1964 but update to use the Kerberos sumtypes instead
of MD5, or perhaps the updated mech should use the HostAddress
functionality in Kerberos for channel bindings, but it will be better to
define the ASN.1 equivalent of gss_channel_bindings_struct (from
rfc2744), which will be needed anyways for rfc2025 (SPKM), which has an
OCTET STRING for channel bindings and fails to specify the structure of
the contents of that field.

Specifically, channel bindings to IPsec/IKEv2/SSHv2 layers are needed
for NFS w/ RPCSEC_GSS if we want to scale well past 10Gb/s.  I direct
you to the NFSv4 list archives[2] at this point.

[1] RFC1964 does not support PROT_READY in the MUTUAL + SEQUENCE case.
    Sam tells me that it makes little sense for the server to have to
    assign its sequence number in the AP-REP (or mech reply token), that
    the client should generate both sequence numbers.  I don't see how
    we can fix that in the mech if we also decide to use more primitives
    from 1510/clarifications/extensions unless we also change the AP
    exchange in this draft, which I don't think is worthwhile.  So
    perhaps we cannot do PROT_READY even in the updated mech until
    extensions, but I'm quite willing to accept that, as long as it
    happens automatically with extensions, which would, in fact, happen
    IF the updated mech used KRB-PRIV and defined KRB-SAFE-X or KRB-MIC.

[2] The NFSv4 list archives are down at this time.  They will be hosted
    at the IETF soon.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Sat, 08 Mar 2003 21:39:28 -0500

Nicolas Williams <[email-masked]> writes:
> requires a new GSS mech.

Not really; we (MIT) managed to get 3des in without creating a new
mech, though we did impose some constraints on the Kerberos
configuration for services not yet supporting 3des GSS.  Microsoft
extended it for RC4.  Extending to add AES or generic-crypto can be
done in the same way (with the same added constraints).

Creating a new Kerberos-based mech pretty much will require SPNEGO, or
ugly "restart the connection and try a different mech" approaches.

>  So why not make the leap.  We still have time,

If we're going to go in this direction, we should take the time to do
it right, yes.  But some people want that AES support right now.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Mar 2003 09:58:28 -0600

> ugly "restart the connection and try a different mech" approaches.

I disagree.  The "new" mech can be associted with "new" enctypes; the
enctype of tickets' session keys being the determinant.

> it right, yes.  But some people want that AES support right now.

If the only thing standing in the way of doing it right is a KRB-MIC or
KRB-SAFE-X then we can do it now, expecially now that we have ASN.1
extensibility markers (KRB-SAFE-X could be defined in the new mech's
spec and reused in extensions, and if it needs some additional fields
then then they can be added when we come to that bridge).

Cheers,

Nico
--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 10 Mar 2003 10:43:54 -0600

> enctype of tickets' session keys being the determinant.

I tend to agree with Sam. adding a new "mech" may have concequences with 
older applicaitons. They may require changes, or will not beable to use
the new "mech". If you can get AES under the current mech as was done with 
3des and RC4 that would help in this situation. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Martin Rex <[email-masked]>
Date: Mon, 10 Mar 2003 18:06:32 +0100 (MET)

> enctype of tickets' session keys being the determinant.

_Ken_ is correct -- defining a new Kerberos GSS-API mechanims (=new mech-OID)
will definitely require a fail-back mode at the app-level or SPNEGO.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Mar 2003 11:18:34 -0600

> will definitely require a fail-back mode at the app-level or SPNEGO.

Who said anything about a new OID?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Mar 2003 11:18:04 -0600

> 3des and RC4 that would help in this situation. 

[Note, it was Ken, not Sam...]

Er, from the application perspective the "new" mech would remain the
same, provided that it keeps the same OID (and I see no reason to change
it), has the same basic features as the original mech and can only be
used with "new" enctypes.  I'm not proposing that the OID change...
Any new or updated Kerberos mech MUST remain transparent to GSS-API
applications that use the existing Kerberos mech.

But the existing mech has to have somewhat different MIC, wrap and
checksum field value message formats for different enctypes and sumtypes
(because 1964 fixes the width of the fields of the messages it defines
without respect for advances in cryptographic technology), whereas the
the ASN.1 syntax of the Kerberos messages is the same no matter what the
enctypes and sumtypes that are used.

Is this feature of 1964's bytes-on-the-wire description bad enough to
make it worthwhile to specify the AES mech in a different way?  I'm not
sure; perhaps a look at what the updated mech would look like may make
it easier to understand how much of the code path can be shared with DES
and 3DES paths.  But certainly, a clean mech based on 1510/clarified
messages would be easier to implement than 1964.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 10 Mar 2003 14:25:25 -0500

> used with "new" enctypes.  I'm not proposing that the OID change...

I think we're losing on terminology here.  I'd say mechanisms are
identified by their OIDs, so if you're talking about rewriting the
post-initiation protocol to be entirely dependent on the enctype and
keeping the same OID, by my definition you're talking about a major
rewriting of the existing mechanism, and not a new one.  I suppose,
since we've got multiple OIDs in use for the one Kerberos mechanism,
my definition kind of falls short, but that's how I was interpreting
your message.

Note that the initiator token can't really change much if you keep the
same OID, since the implementation has to pull the ticket and session
key out for either type, unless you want implementations to have to
try parsing it twice, and cause new messages sent to old
implementations (presumably through configuration errors) to
completely fail to parse the message instead of parsing it and
reported an unknown encryption type.

> applications that use the existing Kerberos mech.

I'm not convinced that's true (or false, for that matter) for the long
term, if we decide we've got good reason to redo the mechanism from
scratch, or come up with a message format that's the same for all
encryption types, so we can phase out the old forms.  But for
short-term updates, certainly I expect a new OID to be a problem.

> enctypes and sumtypes that are used.

Yes, and the proposal I made based on the Kerberos crypto framework
does as well.  (Though without encryption with authenticated
plaintext, both our schemes clearly fail to allow for some existing
advances in crypto technology.)

> and 3DES paths.

You mean just add some numbers for AES and change some field sizes?
Yes, that's what I started looking at, once upon a time, until the
annoyance of updating definitions for every new encryption type
convinced me otherwise.  (And I've still got a rough draft around I
could polish up, if you want.)

I don't expect AES to be the last enctype we add to Kerberos, but it
may be for long enough that this approach would give us time to
properly revisit the GSS mechanism issues.

The approach I started writing up was basically: Use the regular HMAC
like we're defining for the Kerberos enctype, and for encryption,
steal the key derivation steps but don't add a confounder or checksum.
At least, I think the confounder was omitted.  Field sizes and padding
grow as needed, though we could use CTS to reduce the padding.  But
the encrypted sequence numbers would probably need to double in size.

>   But certainly, a clean mech based on 1510/clarified

Maybe, but (1) few programs are currently exercising the messages
we're talking about, so implementations may be broken or incompatible,
(2) for an implementation that's had no need for KRB-SAFE and
KRB-PRIV, perhaps because it's only doing GSSAPI, they may be more
complex to implement than the RFC 1964 messages, and (3) see above
about the context establishment exchange.

If we redo the context establishment exchange now, shouldn't we also
consider enhancements like PFS?  If we don't reexamine the context
establishment exchange now, will we want to later?

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Mar 2003 14:09:39 -0600

> my definition kind of falls short, but that's how I was interpreting

*nod*

I'll use "re-specified" or "re-written" to refer to the re-designed
mechanism.

> reported an unknown encryption type.

Agreed.  Certainly a re-designed mech's initial token will have to start
with the OID, a TOK_ID and an AP-REQ;  I see no reason to change that,
though one could try to move the stuff that's currently sent in the
checksum field to a wrapped token placed after the AP-REQ (I don't care
much either way about that; I'm merely pointing out one way in which the
initial token could be different from rfc1964 and yet be workable).

> short-term updates, certainly I expect a new OID to be a problem.

Oh yes, a new mech OID would NOT be transparent to applications.  I
don't want the OID to change.

> advances in crypto technology.)

We have a mechanism for extending Kerberos.  It involves negotiation in
the KDC exchanges.

Similarly, we have a way to extend rfc1964, and it too involves
negotiation in the KDC exchanges, though in the case of rfc1964 the
determinant is the enctype of the session key of a ticket.

But if we're willing to extend Kerberos to fix its problems, shouldn't
we also be willing to fix the GSS mechanism as well?  Here's our chance.

> could polish up, if you want.)

No, please, I don't want it :)

But do tell us what the current approach is.

> properly revisit the GSS mechanism issues.

Sure.  But I'd like the WG to consider re-designing 1964 so that wrapped
and MIC tokens are based on Kerberos messages (again, KRB-SAFE-X would
be needed).

> the encrypted sequence numbers would probably need to double in size.

How is defining and using KRB-SAFE-X and using KRB-PRIV not cleaner than
this?

> about the context establishment exchange.

(1) I'm not sure I understand this point.
(2) Yes, it is possible to have a pure GSS-API implementation of
    Kerberos and thus not have an implementation of KRB-SAFE or
    KRB-PRIV.  Are there any such implementations?  (Keep in mind that
    the set-passwd protocol uses KRB-PRIV.)
(3) See above for my response; I don't think that the context
    establishment tokens need change in terms of overall structure (OID
    + TOK_ID + Kerberos PDU)

> establishment exchange now, will we want to later?

No.  PFS will come with Kerberos extensions.  As long as the mech is
defined in terms of Kerberos PDUs then it will automatically benefit
from extensions.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 10 Mar 2003 17:18:40 -0500

> and MIC tokens are based on Kerberos messages (again, KRB-SAFE-X would

Yes, I'd agree.  I'll throw out this idea:

If the enctype is new enough, ship KRB-SAFE/KRB-SAFE-X and KRB-PRIV
messages, with direction-type addresses and optional sequence numbers,
[Q: encapsulated or not?]; in the application-data payload, use
something like the TOK_ID scheme, but with new numbers to identify the
type, followed by the real data.  Require that KRB-PRIV be used for
Wrap messages if confidentiality is requested.

The lack of application data in the MIC and Delete tokens is the main
reason I can think of for including the TOK_ID in a wrapper.  I think
we want to be able to distinguish them by examination, rather than by
trying a few checksums to see which TOK_ID value fits.

> How is defining and using KRB-SAFE-X and using KRB-PRIV not cleaner than

Oh, I think both approaches we're discussing are cleaner than that.
That's why I didn't pursue it, and went for the crypto framework
version as a smaller change from where we are than going all the way
to Kerberos messages that don't exist yet.

> (1) I'm not sure I understand this point.

In both (1) and (2), getting from broken or missing implementations to
correct and interoperable implementations may be more difficult than
just doing an encryption.  Not by a lot, perhaps.  But I don't agree
with your assertion that going with the Clarifications messages is
always easier to implement.

>     KRB-PRIV.  Are there any such implementations?

No clue, but it wouldn't surprise me.
Does Microsoft implement KRB-SAFE?

>  (Keep in mind that

Yes, it's KRB-SAFE I'm a bit more concerned about.

> defined in terms of Kerberos PDUs then it will automatically benefit

I don't think that's the way IETF protocol specifications are supposed
to work.  If we redefine the Kerberos GSSAPI mechanism in terms of
Kerberos 6.2, and then we define Kerberos 6.3, the Kerberos GSSAPI
mechanism definition is still in terms of 6.2, unless explicitly
updated.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Mar 2003 16:41:01 -0600

> Wrap messages if confidentiality is requested.

Exactly what I had in mind.  Plus, when sequence numbers are optional
the timestamps can be used instead for replay protection.

> trying a few checksums to see which TOK_ID value fits.

Exactly.  GSS-API doesn't really provide a way to figure out that a given
token is a context token to be passed to gss_process_context_token(),
which is a problem if apps never expect them.  So GSS-API apps need to
correctly encapsulate tokens to properly deal with context deletion
tokens OR the GSS-API should provide a way to tell context deletion
tokens from others (a special major status code would suffice).

In any case, we should keep the TOK_ID wrapper, but maybe not the OID,
for tokens other than those emitted by krb5_gss_init/accept_sec_context();
what a waste of space that OID is.

[...]
> to Kerberos messages that don't exist yet.

Ah.

> always easier to implement.

I have to better visualize how the mech code paths have to change with
either approach to decide which is more difficult to implement.  I'm not
sure yet.

> Does Microsoft implement KRB-SAFE?

They have to implement KRB-PRIV.  A re-designed mech that works with
Kerberos PDUs would not use KRB-SAFE anyways; it would use KRB-SAFE-X.

> Yes, it's KRB-SAFE I'm a bit more concerned about.

Right.  But then, see above.  None of us have implemented KRB-SAFE-X;
nor should KRB-SAFE-X be very much harder (if at all) to implement than
KRB-PRIV.

> mechanism definition is still in terms of 6.2, unless explicitly

Perhaps some of extensions could be used transparently.  Why keep the
same outer tags if not to allow the use of extended Kerberos with older
protocols that only referenced rfc1510?

Besides, what's the point of making extended Kerberos extensible if we
must bind apps/protocols that use Kerberos to one particular version of
the protocol?

No, I'm tempted to conclude that Kerberos extensions are meant to apply
transparently at the very least to protocols which specifically envision
the use of extended Kerberos and perhaps to protocols which didn't when
they were specified [because Kerberos extensions hadn't been thought up
yet, say].

With respect to PFS specifically, I certainly might agree that GSS-API
ought to have a flag for requesting the use of PFS, that perhaps it
should not automatically be used just because the underlying mech one
day supports it.  But certainly we can re-design rfc1964 such that PFS
will come from extended Kerberos and not from the re-design of rfc1964
itself.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 10 Mar 2003 20:38:52 -0500

>> mechanism definition is still in terms of 6.2, unless explicitly

(typo, obviously, should've been 5.2, 5.3)

> protocols that only referenced rfc1510?

Because implementations of the new protocol can parse messages of the
old protocol, so we can pretend we've updated the dependent protocols,
as long as we're careful to avoid using the newer messages with older
implementations.  But we haven't really updated those other
specifications.

> must bind apps/protocols that use Kerberos to one particular version of

Basing application protocols on 5.3 means they'd have to support the
future extensions, if only by ignoring the extra fields added later.
But the ASN.1 for 5.2 isn't marked as extensible.  A correct and
strict implementation of 5.2, and protocols based on it, would reject
extended messages.

> they were specified [because Kerberos extensions hadn't been thought up

They're designed so that we can be backward compatible this way.
That's different from actually updating the specifications.

> will come from extended Kerberos and not from the re-design of rfc1964

Agreed.  *If* we update the mechanism again to use Kerberos 5.3.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 01:14:15 -0600

> implementations.  But we haven't really updated those other

Right and granted.  Note that support for new vs. old Kerberos is
negotiated in the KDC exchanges and has little or nothing to do with
protocols using Kerberos AP exchanges (particularly since clients don't
tell the KDC what protocols they intend to use the requested tickets for
nor can the KDC glean that from service principal names).

Case in point: PROT_READY.

RFC1964 came before PROT_READY (which was added with GSS-API v2 [before
update 1]).

So, does rfc1964 support PROT_READY?  Looking at the way the sequence
numbers are exchanged and the one-round-trip-max nature of the mech I
think so.

Should implementations of protocols that use GSS-APIv1 (e.g., specified
before v2 came out) use PROT_READY?  No.  Use or non-use of PROT_READY
is not transparent to protocols that use Kerberos.

Can protocols that use GSS-APIv2 be designed to support PROT_READY?
Yes.  Can implementations of such protocols expect the Kerberos
mechanism to support PROT_READY?  They shouldn't care one way or the
other, but if the mech implementation supports it, then yes.

One example of such a protocol that uses GSS-APIv2 where the use of
PROT_READY would be ok given the wire messages defined in it, but which
is otherwise iffy, is SPNEGO.  SPNEGO does not forbid the use of the
mechListMIC before the context is established, but it says the
mechListMIC should (not caps; SPNEGO predates use of SHOULD/MUST/MAY) be
sent only when the context is established (this being the reason use of
PROT_READY with SPNEGO is iffy).  But SPNEGO could have explicitly
allowed the use of PROT_READY and RFC1964 initiator implementations that
support PROT_READY should have been able to use SPNEGO and 1964 with
acceptor implementations that don't (though this is an accident of the
one-round-trip-max nature of Kerberos AP exchanges; see below).

> future extensions, if only by ignoring the extra fields added later.

Yes, but not just by ignoring extensions; all those new typed holes
count too, as do the criticality rules for typed hole data.  Most new
features will be added via typed holes, not via protocol syntax
extensions.

> strict implementation of 5.2, and protocols based on it, would reject

Yes, but 5.0 or 5.1 (aside: can we use 5.0 and 5.1 or otherwise settle
on some such major.minor version numbers please?  it's getting
confusing) or whatever version (another aside: if we get extensions
right there won't be a 5.2 for a looong time) is negotiated in the KDC
exchanges.  For protocols that use AP exchanges the AP-REQs and AP-REPs
and KRB-ERRORs are just PDUs and those protocols don't care about the
inner structure of the AP messages.

So, extensions will generally be transparent to protocols/apps that only
deal in AP exchanges (KDC exchanges usually being an under-the-hood
detail of how Kerberos functions which does not impinge on the reality
of apps that only care about the AP exchange).  If not, then why bother
with extensions? (Yes, fairly few protocols use Kerberos, so if they
could not be used with extended Kerberos [but they will be able to]
it'd not be a big tragedy.)

> That's different from actually updating the specifications.

Granted.  See above with respect to my PROT_READY example.  Clearly, a
specification that comes before extensions and which does not make
allowance for certain new features expected in extensions may not
benefit from support for all those features in extensions; but I do
think it's quite reasonable to allow today's specs to be forward
looking.

Now, PFS really is transparent, its only outward effects being:

 - PROT_READY either cannot be supported with PFS in the Kerberos mech,
   or pre-GSS_S_COMPLETE, PROT_READY MICs/wraps cannot use PFS (but
   post- can)

 - AP w/ PFS exchanges are a bit slower than AP w/o PFS exchanges

Mind you, GSS-API should be extended to have a flag for requesting PFS.

> Agreed.  *If* we update the mechanism again to use Kerberos 5.3.

I think the mechanism can be specified in a forward looking manner.
Certainly with respect to PFS.

[NOTE to KINK lurkers: the same applies to KINK.]

If the ability of existing protocols to use extended AP exchanges within
the basic parameters of the original Kebreros V be controversial then
we'd better settle the issue soon.  By basic parameters I'm referring to
the one-round-trip-max nature of Kerberos V AP exchanges, for example.

But, for example, signed KRB-ERRORs will, in fact, be usable, in my
view, in the context of older protocols whose implementations happen to
be using extended Kerberos.  For this to be so their library
implementations must support extended Kerberos [remember that the
negotiation for old vs. extended Kerberos will happen in the KDC
exchanges]; that KRB-ERRORs may be signed will remain transparent to the
initiator and acceptor, which, IMO, should be the test for whether an
extensions feature can be used in pre-extensions protocols.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 12:44:10 +0100 (MET)

> tokens from others (a special major status code would suffice).

I suggest that you forget about the context deletion tokens altogether.
They're mostly useless, and in GSS-API v2 they're optional and
de-facto deprecated.  I've not met a single gss-api mechanism that
used them and I expect *ZERO* applications to actually request
and transfer them (Remember: when the application doesn't provide
an return parameter for context deletion then the mechanism simply
can not return one!)

The one sensible way to indicate "end-of-session" in the application
context that I know is how GSS-API extensions to FTP does it:
It transfers a protected zero-length message.

Really, since the context deletion token is purely optional and hardly
implemented for both gssapi mechanism and gssapi aware applications
it is quite useless.  If we ever move GSS-API v2 to draft standard,
that "feature" should be completely dropped along with the
"process_context_token()" call.

> Kerberos PDUs would not use KRB-SAFE anyways; it would use KRB-SAFE-X.

Even when they have it implemented internally, the current documentation
(SSPI spec) provides *ONLY* rfc-1964-compliant tokens and services
to applications.  And that's an awfully large installed base...

> will come from extended Kerberos and not from the re-design of rfc1964

PFS = Perfect Forward Secrecy?
Adding a context-feature flag "pfs_req_flag" to the GSS-API spec
would be simple and straight-forward.

Unfortunately, gss_accept_sec_context() doesn't have a context
feature request input parameter, so having the acceptor request
PFS (or any other context feature for that matter) is a local
matter -- i.e. implementation defined API extension or implementation
defined external (policy) configuration setting).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 13:59:19 +0100 (MET)

PROT_READY was requested from Bob Blakley (1995@IBM) for use
with Kerberos on an UDP-type protocol with a single request-reply
message pair (for both, security context establishment and
application data exchange).  Of course, this special constraint
limits the number of usable GSS-API mechanisms.  Any mechanism
that derives the message protection key from a handshake between
both peers will not work with an application that requires
the single request-reply plus PROT_READY characteristics. 

SPNEGO and PROT_READY are mutually exclusive.  Really.  I mean it.

The purpose of SPNEGO is to be able to >>negotiate<< a mechanism
since it is not known which of the available mechanisms a target
understands, and the promise of SPNEGO is that it will work
**transparently** for the application.

However SPNEGO doesn't promise that it will complete a security
context establishment in a single round-trip -- in general it will
incur additional roundtrips.
E.g. when the optimistic initial context token is *NOT* implemented
by a particular SPNEGO (which is perfectly OK!) it will always require
an additional round-trip, and also when the chosen optimistic mechanism
is not supported or preferred by the acceptor. 

Remember -- the PROT_READY flag is an indication to the application
that it can make (an arbitrary number!) of message protection calls
as soon as the flag is returned from gss_init_sec_context() -- which
may be iteration call 2, 3, 4, whatever, not only the initial call.
It is also a matter of the application to transfer all those seperate
protected message tokens to the peer.  Now if an SPNEGO would pass
along the PROT_READY flag from the underlying optimistic mechanism
initial call to gss_init_sec_context() to the application, then
what should SPNEGO do if the acceptor doesn't like the optimistic
mechanism?  Therefore an SPNEGO implementation MUST *NOT* pass along
the PROT_READY flag from an underlying mechanism to the calling
application before the negotiation is complete -- which is at earliest
at the beginning of the second context token round-trip.

-Martin

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 11 Mar 2003 09:53:12 -0500

Nicolas Williams <[email-masked]> writes:
> confusing)

RFC 1510 section 9.1 says it's 5.1.
Section 8.1 of the kerberos-clarifications draft says it's 5.2.
So extensions would be 5.3.

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 16:57:42 +0100 (MET)

> the contents of that field.

Channel bindings in GSS-API is probably underspecified.  It is primarily
to be used by the application, and the mechanism should basically
consider the Channel bindings as an OCTET STRING.  Since the use of
channel bindings is optional and at the discretion of the calling
application, as is the specific nature of the channel bindings,
the GSS-API mechanism should actually NOT interpret the contents
at all.

If a Kerberos GSS-API mechanism would check app-supplied channel bindings
and use it to check Host-Addresses in tickets if they were IPv4-Addresses,
then this mechanism implementation would IMHO clearly violate the
GSS-API abstraction.  Checking rfc-1964 I noticed that it suggest
this behaviour but indicates that such behavious is "under discussion"
and "subject to change".  I don't remember any discussion around
this on CAT, but I may just have forgotten since I'm primarily
an gssapi-aware application writer and never cared about
channel-bindings.  Anyway -- I strongly object to the current
recommendation in rfc-1964 and I definitely think it breaks
the GSS-API abstraction (in the way channel bindings are
defined in the GSS-API spec!).

Keep in mind that e.g. Microsoft's W2K Kerberos doesn't implement
channel bindings at all, and most applications will not provide
channel binding information anyway.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 17:28:37 +0100 (MET)

Nicolas Williams wrote:
> 
>                              Perhaps we can leave the channel bindings

I just checked rfc-2025 and rfc-2744 -- and this is the result:
rfc-2025 fails to define the exact transformation of the channel bindings
data structure into the octet string ChannelID.

Quoting rfc-2744 section 3.11 (pg. 18):
: 
: 3.11. Channel Bindings
: 
:    GSS-API supports the use of user-specified tags to identify a given
:    context to the peer application.  These tags are intended to be used
:    to identify the particular communications channel that carries the
:    context.  Channel bindings are communicated to the GSS-API using the
:    following structure:
: 
:    typedef struct gss_channel_bindings_struct {
:       OM_uint32       initiator_addrtype;
:       gss_buffer_desc initiator_address;
:       OM_uint32       acceptor_addrtype;
:       gss_buffer_desc acceptor_address;
:       gss_buffer_desc application_data;
:    } *gss_channel_bindings_t;
:  ...
:    Note that these symbols name address families rather than specific
:    addressing formats.  For address families that contain several
:    alternative address forms, the initiator_address and acceptor_address
:    fields must contain sufficient information to determine which address
: 
:    Conceptually, the GSS-API concatenates the initiator_addrtype,
:    initiator_address, acceptor_addrtype, acceptor_address and
:    application_data to form an octet string.  The mechanism calculates a
:    MIC over this octet string, and binds the MIC to the context
:    establishment token emitted by gss_init_sec_context. The same
:    bindings are presented by the context acceptor to
:    gss_accept_sec_context, and a MIC is calculated in the same way. The
:    calculated MIC is compared with that found in the token, and if the
:    MICs differ, gss_accept_sec_context will return a GSS_S_BAD_BINDINGS
:    error, and the context will not be established.  Some mechanisms may
:    include the actual channel binding data in the token (rather than
:    just a MIC); applications should therefore not use confidential data
:    as channel-binding components.
: 

initiator_address, acceptor_address and application_data are octet
stings at the GSS-API level, so concatenating them is straight-forward.
However, since the type fields are integers of an unspecified size
(and host byte-order), we definitely need an explicit transformation
for interoperability.

Unfortunately, a similar paragraph as in rfc-1964 suggests that gssapi
mechanisms perform their own constraints checking on supplied channel
bindings:

:
:    Individual mechanisms may impose additional constraints on addresses
:    and address types that may appear in channel bindings.  For example,
:    a mechanism may verify that the initiator_address field of the
:    channel bindings presented to gss_init_sec_context contains the
:    correct network address of the host system.  Portable applications
:    should therefore ensure that they either provide correct information
:    for the address fields, or omit addressing information, specifying
:    GSS_C_AF_NULLADDR as the address-types.

Since channel bindings are optional for applications, not implemented
by some gssapi mechanisms (like Microsoft's W2K Kerberos) and even
underspecified for mechanisms like rfc-2025, the end result is that
*portable* applications should not and will not use them at all in
order to avoid operational and interoperability problems.

So Channel Bindings are another "feature" of GSS-API that needs to
be removed from the spec when it is advanced to draft standard,
since it's underspecified, hardly used, hardly implemented and
a very likely cause of operational and interoperability problem
and finally it provides very litte but questionable value anyway.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 10:44:25 -0600

> the single request-reply plus PROT_READY characteristics. 

Right.  Now the question to you is: does rfc1964 support PROT_READY?

(Remember, PROT_READY came after rfc1964.)

> SPNEGO and PROT_READY are mutually exclusive.  Really.  I mean it.

Yes.  You misunderstood me.  I never said that SPNEGO could support
PROT_READY.  I'm asking whether SPNEGO can use a PROT_READY mech to send
the mechListMIC earlier than otherwise.  Very different things.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 10:49:57 -0600

> an return parameter for context deletion then the mechanism simply

I think post-context establishment context tokens could have been done
right, and it would have provided a way for one peer to request
delegated creds from the other on demand.  But I agree, context deletion
tokens don't work.

> to applications.  And that's an awfully large installed base...

An awfully large installed base that could not support AES just because
we specify it.  It will need updating to support AES.  We're talking
about which way to go about adding AES support to the Kerberos
mechanism.  The way that I'm proposing requires implementors to
implement a variation of KRB-SAFE, a variation not currently supported
by any implementor, but which is reasonably simple to implement for
those who implement KRB-PRIV, which at first glance seems to be all of
us, including Microsoft.

> would be simple and straight-forward.

Yes.

> defined external (policy) configuration setting).

Oh, sigh.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 10:59:53 -0600

> the GSS-API mechanism should actually NOT interpret the contents

RFC2743 discusses channel bindings and leaves their definition to the C
bindings (!) (rfc2744).

RFC1964 defines channel bindings in terms of the structure defined in
rfc2744.

RFC2025 defines channel bindings as an OCTET STRING.  This will only do
for "transformed representations of encryption keys" and not for network
address bindings (the latter have little security value, except in the
context of IPsec w/o NAT, where IPsec guarantees the IP addresses).

> GSS-API abstraction.

Never mind my suggestion of using HostAddresses.  It's not appropriate.

>                       Checking rfc-1964 I noticed that it suggest

Huh?  RFC1964 has the initiator make an MD5 checksum of the rfc2744
channel bindings structure and send that; the acceptor has only to
verify the MD5.

What's wrong with that?  (besides the awful way in which the sum is
specified, which is in part due to the fact that a C structure is not a
canonical encoding that can be used as input to a checksum function;
this is why the channel bindings should have been defined as an ASN.1
type in rfc2743).

> channel binding information anyway.

Channel bindings are optional.  I'm not suggesting that this be changed.

What I would like to see here is:

a) a generic ASN.1 type for channel bindings
b) the re-designed Kerberos mech should use this new type
c) a draft indicating that ChannelId values in rfc2025 are to be the DER
   encoding of this new type

I would not have brought this up if interest in channel bindings
(particularly of the "transformed representations of encryption keys"
kind) had not just increased significantly.  When the NFSv4 list
archives come back I will point you at the relevant posts.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 17:57:23 +0100 (MET)

> the mechListMIC earlier than otherwise.  Very different things.

OK, I'm sorry.

I would say that it definitely SHOULD NOT, even though the SPNEGO spec
seems to allow it.

IMHO, the mechListMIC should ONLY be sent included in the final SPNEGO token,
at which point the security context establishment call from the underlying
mechanism has just returned GSS_C_COMPLETE so that the state of PROT_READY
becomes irrelevant.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 11:12:01 -0600

> mechanism has just returned GSS_C_COMPLETE so that the state of PROT_READY

Now what about rfc1964; can it be said to support PROT_READY? (in the
context of GSS-APIv2 apps that know about and want PROT_READY)

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 11:10:33 -0600

On Tue, Mar 11, 2003 at 05:28:37PM +0100, Martin Rex wrote:
> : [...]

Yes, we need to define an ASN.1 type for channel bindings.

> mechanisms perform their own constraints checking on supplied channel

RFC1964 checksums the channel bindings, but does not use an ASN.1
encoding, but a rather ad-hoc "encoding," if we can call it that.

> and finally it provides very litte but questionable value anyway.

No!  Channel bindings MUST NOT be removed.  They have turned out to be
very useful in RPCSEC_GSS.  I'd like to point you at the relevant posts;
I will when the NFSv4 lists go back up.

Suffice it to summarize as follows:

 - a new, trivial pseudo-mechanism (tentatively called CCM) will be
   defined as a trivial wrapper around the underlying mech's tokens

 - this new mech will require that channel bindings be used and that
   GSS-API not be used for integrity or privacy protection

    - because the underlying channel to which the GSS context is bound
      provides the integrity/privacy protection.

 - without this NFS w/ RPCSEC_GSS servers are condenmed to support the
   use of thousands of GSS contexts per-server, whereas with this new
   mechanism and channel bindings it is possible to rely on IPsec (or
   even SSHv2) to provide the integrity/privacy protection at the cost
   of one crypto context (SA in IPsec) per client/server pair.  Which
   scales better?

 - the correct thing to do is to bind GSS contexts to HASH_I|HASH_R in
   the case of IKEv1 (dunno yet for IKEv2), or the key exchange hash in
   the case of SSHv2; works with NAT even.

We've found a use for channel bindings; don't take them away.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 18:16:32 +0100 (MET)

> this is why the channel bindings should have been defined as an ASN.1

Agreed! This would have significantly improved interoperability,
at least for those gssapi mechanism that actually implement them...

> archives come back I will point you at the relevant posts.

If the NFSv4 guys really think about using channel bindings (or even
requiring channel bindings) then they're heading off the beaten path
of GSS-API.  Channel bindings in GSS-API are a total wilderness
for non-Kerberos mechanisms, and considering that Microsoft's
W2K Kerberos doesn't have them, even Kerberos isn't a safe bet.

As you indicated, rfc-2025 fails to specify interoperable channel
bindings and no-one knows who actually implements them at all,
so the only reasonable conclusion for portable application callers is:
STAY AWAY from gssapi channel bindings.

If an application really cares about "channel bindings", then it
should instead roll its own method and use the message protection primitives
to protect them.  That is the only solution that will reliably work with
every existing and future gssapi mechanism.  And it will work with
predictable side effects for the application; no gssapi mechanism
will interfere with constraints and policy on the channel bindings contents.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 11:22:04 -0600

> W2K Kerberos doesn't have them, even Kerberos isn't a safe bet.

Firstly, channel bindings *DO* work with rfc1964.

> STAY AWAY from gssapi channel bindings.

Secondly, I intend to fix SPKM.  I will write a draft revising SPKM so
as to define the meaning of ChannelId.

No, I think channel bindings are a crucial feature (even if noone had a
need for them till now).  You have not convinced me that there is any
fatal flaw to channel bindings, nor have you tried.  You've merely
pointed out the same things as I have, namely that channel bindings are
not workable today with SPKM (and LIPKEY) and that it would be nice if
they were defined more generically.

> will interfere with constraints and policy on the channel bindings contents.

If we agree to this then we cannot do this in the context of RPCSEC_GSS
and still use the GSS-API.  See above.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 18:52:13 +0100 (MET)

> Yes, we need to define an ASN.1 type for channel bindings.

Beware: changing the channel bindings of rfc-1964 would make the
situation significantly worse, because it would completely break
interoperability with existing implementations (and I would consider
it an unacceptable change to rfc-1964).

You may be able to improve the situation for other mechanisms
(like rfc-2025) somewhat, but don't hold you breath.

> encoding, but a rather ad-hoc "encoding," if we can call it that.

rfc1964 uses "ad-hoc encoding" in several places, and actually that
is one of the good things about rfc1964.

> We've found a use for channel bindings; don't take them away.

Sorry, I don't buy this.

Channel bindings can easily be implemented at the application level
using the GSS-API primitives.  As said before, very few existing gssapi
mechanisms actually implement channel bindings and specs like rfc-2025 will
cause interoperability problems for those few that do implement it,

The best bet for the NFSv4 and RPCSEC_GSS crowd is to roll their own
channel bindings at the application level using the getmic/verifymic calls.
That way it will reliably work and interoperate and it's only a tiny
extra bit of protocol spec and code.

The general rule about GSS-API is that EVERY feature that carries the
word optional is a potential interoperability problem and will limit
the number of gssapi mechanism that will be usable.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 19:02:22 +0100 (MET)

> Firstly, channel bindings *DO* work with rfc1964.

When it works, then changing the definition would spoil this.
Unfortunately there's an awful large installed base of rfc1964 implementations
that lack channel bindings.  Calling them "not-rfc1964-compliant" and
their users "loosers" is not a good idea.

There are several protocol features in SSL/TLS which are nice, but
in order to interoperate with the installed base of broken implementations
one has to implement non-compliant behaviour -- like the
TLS version rollback protection that MSIE breaks.

> as to define the meaning of ChannelId.

That will neither add channel bindings to implementations that don't
have them at all, and it won't fix (turn interoperable) those implementations
that have it.

Face it: if you want to write *USEFUL* specs for the real world, you should
neither ignore the real world nor the installed base.

> and still use the GSS-API.  See above.

Of course this could be done in RPCSEC_GSS!  Why not?

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 12:08:19 -0600

> it an unacceptable change to rfc-1964).

I'm not proposing any changes for rfc1964 and am not proposing any
semantic changes from rfc2744 and rfc1964 for the re-designed Kerberos
AES mech.

I'm only proposing that an ASN.1 type semantically equivalent to the
rfc2744 gss_channel_bindings_struct struct be defined and used as the
value of rfc2025's ChannelId and in the re-designed Kerberos AES mech.

Martin, stop reading things into my words that I haven't said :)

> (like rfc-2025) somewhat, but don't hold you breath.

We have all the room needed to improve rfc2025, precisely because
noone could have used rfc2025's ChannelId interoperably.

> is one of the good things about rfc1964.

I disagree vehemently.  It is precisely because of this ad-hoc stuff in
1964 that we are now talking about re-designing it so we can do AES (and
we have to re-design it; the only argument is about how).

> cause interoperability problems for those few that do implement it,

It's too late to re-design RPCSEC_GSS to implement channel bindings at
the application level and not GSS-API.  Sorry.

> extra bit of protocol spec and code.

Can't be done.

> the number of gssapi mechanism that will be usable.

I think channel bindings work and are workable with rfc1964.  That MS
does not support channel bindings is irrelevant - they do not implement
RPCSEC_GSS and so are not likely to need channel bindings till they do.

You have yet to provide a convincing reason for removing channel bindings.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 19:21:53 +0100 (MET)

Nicolas Williams wrote:
> 
> Now the question to you is: does rfc1964 support PROT_READY?
> 

That question doesn't apply.

The support of PROT_READY is implementation-specific, and
can only be determined by the application caller at runtime
by presence or absence of the PROT_READY flag of a context
establishment call that returns GSS_S_CONTINUE_NEEDED.

rfc-1964 doesn't mention PROT_READY at all, so each implementation
of Kerberos 5 can do whatever it feels like without the risk of
being call "rfc-1964-incompliant".

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 19:34:28 +0100 (MET)

> as to define the meaning of ChannelId.

In case you really plan to revise SPKM -- this spec has several severe
flaws that make the underspecified channel bindings look insignificant.

At the very minimum, all of the bullshit about "non-repudiation" should
be purged from the document since it's completely inappropriate in
this spec.  The use of digital signatures with the identity certificate
for message protection services should be deprecated and a replacement
secure and required integrity protection algorithm should be added,
DES-MAC is probably rather weak.
(but the last already exceeds my expertise).

The most annoying interoperability problem about SPKM is the
lack of a mechanism-defined namespace, syntax and canonical format.
This makes it impossible to mix independent implementations in a
distributed environment (which uses ACLs with such names).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 12:41:00 -0600

NFSv4 and RPCSEC_GSS require support for LIPKEY (and therefore SPKM-3),
but not for SPKM-1/2.  Given this I don't think we need to fix the other
SPKM issues you mention in one go, just the channel bindings bit.

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 12:53:48 -0600

> their users "loosers" is not a good idea.

I just answered this in a separate post.  To repeat: I'm proposing that
for the re-designed Kerberos w/ AES mech we re-define the encoding of
the channel bindings, but not the semantics; I'm not proposing any
changes to the existing rfc1964 (w/ DES, 3DES or RC4).

> have them at all, and it won't fix (turn interoperable) those implementations

Channel bindings are optional.

The new pseudo-mechanism being discussed on the NFSv4 WG will make
channel bindings mandatory in the context of that pseudo-mechanism,
which, in turn, is meant to be used in the context of RPCSEC_GSS and
NFSv4.

> neither ignore the real world nor the installed base.

I am not.  I am not even remotely asking that channel bindings support
be made a requirement for Microsoft or any other implementor.

In the context of NFSv4, RPCSEC_GSS and the new pseudo-mech the channel
bindings offer a way to negotiate leaving session crypto to the network
layer.

> Of course this could be done in RPCSEC_GSS!  Why not?

Because RPCSEC_GSS would require significant surgery to implement
channel bindings at its level rather than at the GSS-API layer.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 19:53:59 +0100 (MET)

> the application level and not GSS-API.  Sorry.

As I've described extensively, the current RPCSEC_GSS MUST be prepared
to deal with mechanisms that don't implement channel bindings, since
they've always been optional and are hardly implemented.

I haven't read the spec, but it would be real stupid if someone had
blindly relied on a purely optional feature *and* without having performed
a reality check which would have clearly revealed that channel
bindings are just vaporware.

> > extra bit of protocol spec and code.

Why not?  Is the spec really so bad that it cannot be extended?

> RPCSEC_GSS and so are not likely to need channel bindings till they do.

Huh?

If RPCSEC_GSS is what it sounds like, then it can be implemented
as soon as you have the GSS-API mechanism -- which is what is available
on W2K Kerberos.  There shouldn't be a need to wait for Microsoft to
ship a proprietary RPCSEC_GSS implementation, I guess -- just go ahead
and glue your own to their gssapi mechanism.

The reason to drop channel bindings is automatic.
When a protocol spec is to be advanced from proposed to draft on the
standards track in the IETF, those features that are not being used
or which can not shown to provide interoperability ought to be removed
from the spec.  This clearly applies to the GSS-API channel bindings.

That doesn't mean that channel bindings will completely evaporate --
it only means that *NO* other spec may require such a feature
since it would obviously create a severe interoperability problem.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 13:02:49 -0600

> they've always been optional and are hardly implemented.

It is.  Martin, you're reading things into what I'm saying that I
haven't said.

> bindings are just vaporware.

Noone is going to rely on an optional feature.  A trivial
pseudo-mechanism is being designed which, together with NFSv4's existing
facility for negotiating GSS-API mechanisms will allow the negotiation
of channel bindings support.

See?  Channel bindings will remain forever optional, but NFSv4 w/
RPCSEC_GSS will be able to negotiate the use of channel bindings.
Which in turn will allow the offloading of session crypto to lower
levels, where fewer session contexts will translate in to lower hardware
crypto co-processor latency and higher throughput.

> Why not?  Is the spec really so bad that it cannot be extended?

Even if it can be extended, the current proposal is far simpler to
implement than implementing channel bindings at the RPCSEC_GSS level.

You need to see that we're not talking about making channel bindings
mandatory, that it's a feature that will be negotiated (and it just so
happens that NFSv4 has the ability to negotiate GSS-API mechanisms;
RPCSEC_GSS does not).

> and glue your own to their gssapi mechanism.

Exactly.  The glue here is a pseudo-mechanism which will allow NFSv4 w/
RPCSEC_GSS to negotiate the use of channel bindings.

The pseudo-mechanism is trivial.  RPCSEC_GSS needs no changes to use it.
The NFSv4 spec needs no changes either.

> from the spec.  This clearly applies to the GSS-API channel bindings.

This clearly is about to not apply to GSS channel bindings :)

> since it would obviously create a severe interoperability problem.

See above.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Mar 2003 20:18:01 +0100 (MET)

> crypto co-processor latency and higher throughput.

Good.  So where is the problem in updating that spec so that the
channel-bindings are supplied in an app-level MIC-ed token instead
of being part of context-establishment, so that offloading of the
crypto can be done independent of the features of the gssapi mechanism.
That would be a sensible and logical step.

> happens that NFSv4 has the ability to negotiate GSS-API mechanisms;

Yes, but why jump hoops in order to cover 5% of the installed base
if you can get 100% with just a tiny bit more work.

As rfc-2744 explains, a simple MIC on the contents of the
channel bindings is sufficient, so that is really easy to implement.

There's no need to do full ASN.1 to the contents of the channel bindings
structure -- three of the elements are already canonical octet strings
anyway, so you just need to define how to encode the two integers/enums
and how to compose the flat memory image.  Then a simple gss_getmic()
on one side and a verify_mic() on the other and you're done.
It's really as simple as that.

What puzzles me a little: if the all of the crypto (integrity&confidentiality)
is done at the lower network layers, will this open vulnerabilities?
I have the feeling that yes.  With the help of the individual security
contexts each and every message will be authenticated and protected against
replay.  Now if all communication between two hosts are bundled, the
seperation of data streams is probably less secure as if each was
individually protected. 

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 13:29:05 -0600

> That would be a sensible and logical step.

Neither the RPCSEC_GSS spec nor the NFSv4 spec will have to change an
iota for this.  A new GSS-API pseudo-mechanism is introduced that can be
negotiated at the NFSv4 layer and is, like any other GSS-API mechanism,
support at the RPCSEC_GSS layer.

> if you can get 100% with just a tiny bit more work.

I don't understand.  Modifying RPCSEC_GSS would be jumping through
hoops, whereas adding a pseudo-mechanism isn't.

> channel bindings is sufficient, so that is really easy to implement.

Yes, but you need a canonical encoding of the channel bindings, which
rfc2744 does not provide and which rfc2743 should have provided.

> It's really as simple as that.

It's easier to use ASN.1 to define a syntax for channel bindings and DER
to define the encoding.  Yes, it is.  I realize that you may not be a
fan of ASN.1, but if that's so then we're merely arguing about how to
define such an encoding and not about the need for it and here we'll
just have to agree to disagree.

> seperation of data streams is probably less secure as if each was

That's the point of channel bindings.  By using channel bindings one can
make sure that there are no men in the middle.

The peers both have to maintain local security to avoid abuse by one
user of other's locally available GSS credentials.  But this is true
regardless of whether channel bindings are in use or not and whether
session crypto is pushed to the lower layers.

The key security issue when pushing session crypto from layer to another
is to make sure that there are no men in the middle.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 14:01:55 -0600

The channel bindings discussion is not very relevant to how the Kerberos
w/ AES mech should be designed.  So we may want to continue the channel
bindings discussion in another thread, possibly on the CAT list.

The channel bindings discussion arose because I thinkoed and thought it
might be possible to use HostAddress to implement channel bindings
purely in terms of Kerberos, but there is not, in fact, a way to do
that, so channel bindings still have to be defined at the mechanism.

I would like to get an idea for how hard it might be to implement each
of the two proposed designs for the Kerberos w/ AES mechanism.  Or I'd
like to find a fatal flaw with the define-the-mech-in-terms-of-Kerberos
approach.  This way we can reach consensus on the updated mech design.

BTW, one nice side-effect of defining KRB-SAFE-X in the updated mech is
that if new fields are needed for extensions but not added in the
updated mech then we can show ASN.1 extensibility markers in action and
have multiple implementations of the same.

Cheers,

Nico
--