Subject: RE: secdir review: draft-ietf-cat-kerberos-pk-init-30.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 12 Dec 2005 23:48:19 -0800

Gregory, first, thanks for the review and the comments. Here are my
comments, I omitted those editorial points/changes, please shout if I
miss any MUST-to-have changes/points. Thanks.

> 1.0 - great succinct explanation of Kerberos basics. text-based
graphics are good, and one would compliment the text quite well. Some
simple functional 
> blocks -- with client, AS and TGS, and loose coupling around them both
(noting that they are usually combined), the Service, and the basic
exchanges -- 
> labeled would help anyone not previously too familiar with Kerberos'
guts (as I).

The reader of this ID is assumed to be familiar with RFC4120. If anyone
comes with good text arts, we can include them.

 >  - Para 5 - the assertion PK crypto & PKI "permit authentication
without prior registration with a KDC" is misleading, and I'd like to
see it re-
> written. It sounds like you are saying is that you will use PK to wave
a magic wand and make disappear any pre-configuration of a user/group
into the 
> kerberos system. In fact, the complex task of describing in the
Kerberos system the users/groups that will be allowed to access, and
some information > 

> about them, MUST be done whether or not there is PK involved. 

Points taken, 

I changed to have the following:

   Conversely, an established Public Key Infrastructure (PKI) already
   provides key management and key distribution mechanisms that are
   sufficient to establish authentication and secure communication.
   Adding public-key cryptography to Kerberos allows Kerberized
   applications to leverage these existing services.  In addition, human
   users can avoid the inconvenience of managing strong passwords, by
   using randomly generated strong public and private key pairs.

Does this look good to you?

>  - step 3a - is "KDC's signature key" a pre-existing term from 4210,
or is this a signature key based from a PK that KDC is using in this
case? Please > 
> clarify in text.

I added the following into section 2

   In this protocol, both the client and the KDC have a public-private
   key pair in order to prove their identities to each other over the
   open network.  The client's key pair is used to authenticate the
   client to the KDC, and the KDC's key pair is used to authenticate the
   KDC to the client.  The term "signature key" is used to refer to the
   private key of the key pair being used.

>   - step 4 - to my point earlier, this model suggests that upon first
connection, the client already has the KDC's signature. This implies
some 
> "registration" step has already occured, in which at least one by
product was the securing of the KDC's public key for authenticating it's
signatures, 
> or, at least, the acquisition and validation of a certifier's public
key,  by which the KDC will be certified.
>    I would like to see some discussion of the work that must be done
ahead of the first connection in order to make that first connection
work.

This is deployment specific. Fortunately Appendix C provides some
examples.

>      - Interoperability Note - the first sentence is awkward, I think
because of "may not be able to" and then "BER but not DER;".  Suggested
> change:  drop the "but not DER".

Agreed.

> 3.1.3 - which of these suites are MUST? Which are SHOULD? Which are
MAY? 
> Which are on their way out and only added for backwards compatibility?

> Which ones are not widely supported YET, but are expected to be the
next MUST? Give some guidance to implementors, and deployers.

3.1.1 lists all the MUST.

> 3.2.1 - is this to be a bit-wise comparison of the entire DN in the
cert (as opposed to some subset of DN that the kerberos system might use
to match > 
> policy, e.g. a CN that equates to a group name, or an email address
that is used to do a user lookup)? If so, best to explicitly state it.

Either none or all.

>        - point 8, pg 9&10 - i assume that the type codes for the
various DH groups (2, 14, 16) you will support are enumerated in 3279? I
couldn't find > it when I looked quickly. Is there any reason not to
enumerate them here, given there are only three?

There is no type code here, the domain parameters are identified by an
OID followed by the parameters p, q, g, not by an integer number/code.
An exception is that when a wellknown ECC curve is used, the curve
parameters do not have to be sent over the wire.

> 3.2.2, page 12, point 1 - This is a very tricky area. As it turns out,
if you leave the text this general, you may get stuck with interop
problems. 

Understood, we could not provide one solution that fits all, so we ended
up allowing additional vendor specfic mappings, if there is any relief,
we do specify a mapping that all implementations must
understand/process.

>   - page 13 E/KU - ugghh. The EKU stuff can be really hard. Instead of
trying to describe it all, I'm going to just point you to the text in
our 
> document about this stuff. But let me warn you, we've spent 1.5 years
on this text, and you'll find as many PKI experts with different
opinions on what 
> to do with E/KU as you will find PKI experts. Good luck.
>         draft-ietf-pki4ipsec-ikecert-profile-06.txt , 4.1.3, 4.1.3.2,
and 4.1.3.12.

These points are assumed to be covered by RFC3280.

> - 3.2.3.1, point 7 - "(see section 3.2.3.1)". this is that section,
no?
Removed

> You may want to give implementors a hint that an override for
validation is very helpful

are you making a call to change to a MUST from a SHOULD?  I would rather
not to change this since it already passed the consenus.

> - pls expand to explain HOW windows clients verify the issuer of the
KDC. What information do they use, and what fields / config is needed in
order to > 
> perform the verification? How do you recommend deployers get this data
into the clients in an efficient and scalable manner?

It is my belief that one should consult the product manual the level of
details you are looking for.

Here is the diff output

---
> Internet-Draft                   PKINIT                    December
2005
141,146c141,147
<    Conversely, public-key cryptography (in conjunction with an
<    established Public Key Infrastructure) permits authentication
without
<    prior registration with a KDC.  Adding it to Kerberos allows the
<    widespread use of Kerberized applications by clients without
<    requiring them to register first with a KDC--a requirement that has
<    no inherent security benefit.
---
>    Conversely, an established Public Key Infrastructure (PKI) already
>    provides key management and key distribution mechanisms that are
>    sufficient to establish authentication and secure communication.
>    Adding public-key cryptography to Kerberos allows Kerberized
>    applications to leverage these existing services.  In addition,
human
>    users can avoid the inconvenience of managing strong passwords, by
>    using randomly generated strong public and private key pairs.
163d163
<    In this document, the encryption key used to encrypt the enc-part

171a172,179
>    In this protocol, both the client and the KDC have a public-private
>    key pair in order to prove their identities to each other over the
>    open network.  The client's key pair is used to authenticate the
>    client to the KDC, and the KDC's key pair is used to authenticate
the
>    KDC to the client.  The term "signature key" is used to refer to
the
>    private key of the key pair being used.
> 
>    In this document, the encryption key used to encrypt the enc-part
209a218,227

299,300c314,315
<    wrapped CMS objects encoded with BER but not DER; specifically,
they
<    may not be able to decode indefinite length encodings.  To maximize
---
>    wrapped CMS objects encoded with BER; specifically, they may not be
>    able to decode indefinite length encodings.  To maximize

770,772c797,799
<    The digitalSignature key usage bit MUST be asserted when the
intended
<    purpose of the client certificate is restricted with the id-pkinit-
<    KPClientAuth EKU.
---
>    The digitalSignature key usage bit [RFC3280] MUST be asserted when
>    the intended purpose of the client's X.509 certificate is
restricted
>    with the id-pkinit-KPClientAuth EKU.
780,787d806
< 
< 

941c968
<           serverDHNonce           [1] DHNonce OPTIONAL
---
>           serverDHNonce           [1] DHNonce OPTIONAL,
943a971
>           ...

1049,1059c1077,1087
<        choose to reuse its DH keys (see Section 3.2.3.1).  If the
server
<        reuses DH keys then it MUST include an expiration time in the
<        dhKeyExpiration field.  Past the point of the expiration time,
<        the signature over the type DHRepInfo is considered expired/
<        invalid.  When the server reuses DH keys then it MUST include a
<        serverDHNonce at least as long as the length of keys for the
<        symmetric encryption system used to encrypt the AS reply.  Note
<        that including the serverDHNonce changes how the client and
<        server calculate the key to use to encrypt the reply; see below
<        for details.  The KDC SHOULD NOT reuse DH keys unless the
<        clientDHNonce field is present in the request.
---
>        choose to reuse its DH keys.  If the server reuses DH keys then
>        it MUST include an expiration time in the dhKeyExpiration
field.
>        Past the point of the expiration time, the signature over the
>        type DHRepInfo is considered expired/invalid.  When the server
>        reuses DH keys then it MUST include a serverDHNonce at least as
>        long as the length of keys for the symmetric encryption system
>        used to encrypt the AS reply.  Note that including the
>        serverDHNonce changes how the client and server calculate the
key
>        to use to encrypt the reply; see below for details.  The KDC
>        SHOULD NOT reuse DH keys unless the clientDHNonce field is
>        present in the request.

<    In this case, the PA-PK-AS-REP contains an encKeyPack structure
where
---
>    In this case, the PA-PK-AS-REP contains the encKeyPack field where
1147a1172,1179

1268,1270c1301,1303
<    The digitalSignature key usage bit MUST be asserted when the
intended
<    purpose of KDC certificate is restricted with the id-pkinit-KPKdc
<    EKU.
---
>    The digitalSignature key usage bit [RFC3280] MUST be asserted when
>    the intended purpose of the KDC's X.509 certificate is restricted
>    with the id-pkinit-KPKdc EKU.

The full text of -32 is also attached.

-----Original Message-----
From: Gregory M Lebovitz [mailto:[email-masked]] 
Sent: Monday, December 12, 2005 10:15 PM
To: [email-masked]; Liqiang(Larry) Zhu; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Sam Hartman
Subject: Re: secdir review: draft-ietf-cat-kerberos-pk-init-30.txt

==Disclaimers:
  - I was asked to review -29, but in doing so I found -30, so I
reviewed that.
  - I'm not very familiar with Kerberos or 4210. I am familiar with
trying to get PKI and 3280 to work with a real world exchange (IKE,
IKEv2), which I guess is why I was asked to review.
  - Some of my comments and questions may be due to lack of Kerberos
understanding

==COMMENTS
==General:
  - there are a lot of sub numbering of points under section numbers,
and sometimes multiple such enumerated lists under one section heading.
Why not just use sub points to the section number? example, 3.2.3.1 has
two such enumberated lists.

==Specific:
1.0 - great succinct explanation of Kerberos basics. text-based graphics
are good, and one would compliment the text quite well. Some simple
functional blocks -- with client, AS and TGS, and loose coupling around
them both (noting that they are usually combined), the Service, and the
basic exchanges -- labeled would help anyone not previously too familiar
with Kerberos' guts (as I).

   - Para 5 - the assertion PK crypto & PKI "permit authentication
without prior registration with a KDC" is misleading, and I'd like to
see it re-written. It sounds like you are saying is that you will use PK
to wave a magic wand and make disappear any pre-configuration of a
user/group into the kerberos system. In fact, the complex task of
describing in the Kerberos system the users/groups that will be allowed
to access, and some information about them, MUST be done whether or not
there is PK involved. 
PK does not take away the need to describe users/groups in the Kerberos
system. PK will allow you to do LESS configuration on the Kerberos
system (or any system) about the user/group, e.g. admin will not have to
enter secrets for those users or groups individually. However,
experience over the past years w/ PK has shown us that the system that
uses the PK still needs policy definitions about which users/groups have
what sorts of accesses into the system, and that this information need
be in the PK-using system before user's first contact. Often, users get
brought up 1 by 1 in such a system as they find they need access, and
put a request into the system operator. Sometimes users/groups are
brought in all at once. But they are always "brought in" to the system's
definition before first use, either as a user or as a group, via some
out of band contact. So, in a way, a slightly less heavy "registration"
will exist. It will be done by the admin of the Kerberos system, at the
users' request(s), and the admin will not have to enter Keys for each
user.
      If we do not make this distinction, then we get applications
asking PKIs to be the end all be all for their own policy descriptions,
and then PKI gets so overloaded that nobody can remember how to actually
use it quickly and easily anymore (a condition we may have already
encountered).
      If I've not been clear on this distinction, feel free to ask a
question to help me clarify.

3.0
  - step 3a - is "KDC's signature key" a pre-existing term from 4210, or
is this a signature key based from a PK that KDC is using in this case?
Please clarify in text.

  - step 4 - to my point earlier, this model suggests that upon first
connection, the client already has the KDC's signature. This implies
some "registration" step has already occured, in which at least one by
product was the securing of the KDC's public key for authenticating it's
signatures, or, at least, the acquisition and validation of a
certifier's public key,  by which the KDC will be certified.
    I would like to see some discussion of the work that must be done
ahead of the first connection in order to make that first connection
work.

3.1.1 - I'm assuming that crypto guys have already reviewed and advised
that CTS is preferred over CBC or CTR?
     - I assume you have a story or plan for how to make this adhere to
the security ADs' recent mandate about cipher agility, given the horizon
for SHA1?

3.1.2 - the error codes are well thought out. This will make life easier
than we had it in IKE. ;-)

      - Interoperability Note - the first sentence is awkward, I think
because of "may not be able to" and then "BER but not DER;".  Suggested
change:  drop the "but not DER".

      - Interop Note, last sentence - for interop success, I recommend
the SHOULD be changed to a MUST. But, if you have already hacked through
this on the list, and this is the consensus, then just leave it.

3.1.3 - which of these suites are MUST? Which are SHOULD? Which are MAY?

Which are on their way out and only added for backwards compatibility? 
Which ones are not widely supported YET, but are expected to be the next
MUST? Give some guidance to implementors, and deployers.

3.2.1 - is this to be a bit-wise comparison of the entire DN in the cert
(as opposed to some subset of DN that the kerberos system might use to
match policy, e.g. a CN that equates to a group name, or an email
address that is used to do a user lookup)? If so, best to explicitly
state it.

         - for readability, add under pkAuthenticator
                 -- a SEQUENCE, described below

         - supportedCMSTypes - "in order of (decreasing) preference" -
this is a nice include. We got into trouble without this in IKE. Well
done!

         - point 8, pg 9&10 - i assume that the type codes for the
various DH groups (2, 14, 16) you will support are enumerated in 3279? I
couldn't find it when I looked quickly. Is there any reason not to
enumerate them here, given there are only three?

3.2.2, page 12, point 1 - This is a very tricky area. As it turns out,
if you leave the text this general, you may get stuck with interop
problems. 
The reason we have found in IKE is that we needed more explicit rules
about extracting fields out of the cert, and then matching that data to
something in a policy on the (in this case) Kerberos system. For
example, what fields MUST an implementation be able to parse in a cert
when looking for an identity match? A CN? Multiple CNs? the email name?
the O, OU, C, etc attributes? the entire DN as a bit for bit match? On
of the SubjectAlternativeNames? Some combination of the above?
      For example, in a policy in the kerberos system, the administrator
may want to set a rule that allows access for all people where O=Widget
Corp, and OU=Sales, where SubjectAltName / rfc822Name or dNSName
contains the string "widgetcorp.com".
     To get interop here, IMHO, you'll need to:
         - clearly specify which unique fields the implementation needs
to be able to "investigate".
         - In PKI4IPsec we have settled on:  FQDN =
SubjectAltName/dNSName, email address = SubjectAltName/rfc822Name, and
any combination of the DN's CN, O, OU, and C fields. We came to these
three because experience has shown us that from an administrative
perspective, people ID users and groups in IKE/IPsec systems using only
these items. This is to say these are the only areas really used as
building blocks in defining user/group policies in the VPN systems. And
if they match on, say, rfc822Name, they may only really match on some
portion of the field's contents, e.g. the domain name
"@widgetcorp.com". Like IKE, it is probably not practical in the
Kerberos admin system to enter a user's entire DN, without making it
very cumbersome, or incurring a lot of typos. When polled, the community
really only seamed to be matching (i.e. defining policy based upon) on a
small subset of the DN attributes: CN, O, and OU. There was some corner
case (which now I've forgotten) why someone needed C as well, so we
included it too.
         - define the compliant implementations SHOULD offer UI that
allows users to build policy based on exact matches of these fields from
the certificate, or on any wildcarded substring thereof (eg.
[email-masked]"
         - make these in addition to the
SubjectAltName/GeneralName/KRB5PrincipalName that you've defined.
         - specifying support for the above described fields will allow
existing issued certs for other applications to have a *better* chance
of working as is w/ your app.
         - make sense?

  - page 13 E/KU - ugghh. The EKU stuff can be really hard. Instead of
trying to describe it all, I'm going to just point you to the text in
our document about this stuff. But let me warn you, we've spent 1.5
years on this text, and you'll find as many PKI experts with different
opinions on what to do with E/KU as you will find PKI experts. Good
luck.
         draft-ietf-pki4ipsec-ikecert-profile-06.txt , 4.1.3, 4.1.3.2,
and 4.1.3.12.

- 3.2.3.1, point 7 - "(see section 3.2.3.1)". this is that section, no?

- around 3.2.4 ish - about this time i realize that it would be nice to
see a text graphic abbreviating the exchange with and without the pkinit
pieces included, and use a "*" or such to demonstrate which items are
optional and which are not.  I would lead with this up front in the
document, and then refer to it when expanding upon certain payloads.

3.2.4 - saying "the KDC's X.509 certificate MUST be validated..." can be
dangerous. Yes, we want to validate it in most production networks, but
implementations almost always need to function in places where doing so
is not convenient, e.g. trade shows, customer labs, interop tests,
partner certification labs, etc. You may want to give implementors a
hint that an override for validation is very helpful, and clarify that
default behavior should be to validate.

         - re: EKU - I'm going to defer to Russ Housley and Sam on this,
but I'm not sure in this day and age if it is better to assume you can
use a cert offered to you during an application exchange unless the cert
explicitly marks its applicability as limited, or if it is better to
specify via e/ku's the finite set of uses for cert. (I believe the
former is better for interop cert usability, but others believe the
opposite).

Security considerations -
         - para 6 - how do you propose that one verify that the KDC
cert's issuing CA is authorized to issue KDC certs for the target realm?
This seems an essential point of the security model, and you offer only
cursory recommendations. This probably ought to be a section in the
document, not just in security considerations, no?  I think the answer
lies back in my opening remark about the "magic wand". In reality, the
client will likely need a configuration package which downloads and
installs into the kerberized app the appropriate CA cert for the KDC's
issuer. Recommend you give more concrete direction to the PKI deployer
on this point, and keep it based in reality, not PKI "could be
someday"s.
         - 1st para on page 25 - If we expect the admins to "ensure the
KDC certificates are only issued to KDC's and that clients can ascertain
this using their local policy" then you need to provide direction as to
the local policy levers and knobs that the implementors need to use so
that orgs can ensure it. What are the configuration options that will be
needed? 
Provide some best-common-practice-type information and examples for
implementors to follow, otherwise the industry will take 5 - 7 years to
figure it out the hard way.
         - 2nd para on pg 25, last sentence - not only "inappropriate"
but will not conform to certain industry-mandated standards, like FIPS
140.
         - on "return routability" - there is a way to address this.
IKEv2 uses a cookie mechanism in message 2. The responder signals to the
initiator to essentially resend the stuff that was sent in the first
message so that responder (a) doesn't have to keep state on first, and
possiblly forged, packets, and (b) so that the initiator has to be able
to receive, process and respond to a message, thus provining itself
reachable, and not a spoofed address. Would you guys want to consider
plugging this vulnerability at this late stage with a like mechanism?

- Appendix A and B - I did not review these sections
- Appendix C - pg 36, last para - Thanks for including this section.
It's VERY practical.
         - pls expand to explain HOW windows clients verify the issuer
of the KDC. What information do they use, and what fields / config is
needed in order to perform the verification? How do you recommend
deployers get this data into the clients in an efficient and scalable
manner?

That's it. Hope it helps,
Gregory.

At 07:40 PM 11/16/2005, Sam Hartman wrote:

>HI.  I'd like to ask you to review pkinit by December 5.  Comments 
>should be sent to [email-masked] and to [email-masked].  Unless 
>otherwise stated comments may be cited publically.
>
>--Sam

+++++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
W - +1 408 936 8002

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Dec 2005 16:51:56 -0600

> comes with good text arts, we can include them.

How about:

x.  Kerberos V Refresher

   NOTE:  This section is purely informative and not intended to be a
	  complete or accurate description of the Kerberos V Network
	  Authentication Protocol.  For a normative description see
	  RFC4120.

   The Kerberos V protocol involves use of a trusted third party known
   as a Key Distribution Service (KDC) to negotiate shared session keys
   between clients and services and provide mutual authentication
   between them.  This involves message exchanges between clients and
   KDCs and clients and services.  These exchanges are as follows:

    - Authentication Service (AS) exchange

      Clients obtain "initial" Ticket, typically a Ticket Granting
      Ticket (TGT).  KDCs typically require that clients
      "pre-authenticate" to the AS, typically using a password-based
      mechanism known as "encrypted timestamp" -- PKINIT is a form of
      pre-authentication, therefore most PKINIT-related messages are
      used in Kerberos V AS exchange PDUs (AS-REQ and AS-REP).

    - Ticket Granting Service (TGS) exchange

      Clients use TGTs to authenticate to the TGS (part of the KDC, like
      the AS) and obtain a service ticket for a particular service.

    - AP exchange

      Clients make an AP-REQ, consisting of a service Ticket and an
      Authenticator that authenticates the client's possession of the
      Ticket's session key.  AP exchanges typically negotiate
      sub-session [symmetric] keys.

   See figure 1 below.

   The corner-stone of Kerberos V is the Ticket and AP-REQ.

   A Ticket names a service principal in an envelope; the contents of
   Ticket are encrypted with a symmetric key shared between the service
   principal and the issuing KDC.  The encrypted part of a Ticket names
   a client principal and contains a session key known also to the
   client (amongst other items).

   KDC replies (AS-REP and TGS-REP) deliver a Ticket to the client and,
   in an encrypted portion of the KDC reply, the session key inside the
   Ticket's encrypted part.  The KDC reply messages' encrypted parts are
   encrypted in symmetric keys shared between the client and the KDC.
   The KDC reply messages' encrypted part encryption key relates to the
   pre-authentication mechanism used.  In the case of TGS exchanges the
   pre-authentication mechanism consists of an AP exchange involving a
   client's TGT, while in the case of AS exchanges the
   pre-authentication mechanism is one that mutually authenticates a
   client principal to a KDC.

   PKINIT is, essentially, a new pre-authentication mechanism for AS
   exchanges.

   Finally, Kerberos V has a notion of "realm" and realm crossing.  For
   more information see "The Kerberos Network Authentication Service
   (V5)" [RFC4120].

       Figure 1:  Kerberos V PDU exchange recap

                           +--------------+
                +--------->|  KDC         |
        AS-REQ /   +-------|              |
              /   /        +--------------+
             /   /          ^           |
            /    |AS-REP   /            |
           |     |        / TGS-REQ     + TGS-REP
           |     |       /             /
           |     |      /             /
           |     |     /   +---------+
           |     |    /   /
           |     |   /   /
           |     |  /   /
           |     v /   v
          ++-------+------+             +-----------------+
          |Client         +------------>|  Application    |
          |               |    AP-REQ   |  Server         |
          |               |<------------+                 |
          +---------------+    AP-REP   +-----------------+

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Dec 2005 17:13:28 -0600

Some more ASCII art:

   +-------------------------+
   |AS-REQ                   |
   | +----------------------+|
   | |PA-DATA (pre-auth)    ||  +------------------------------------+
   | |+-------------------+ ||  |PA-PK-AS-REQ                        |
   | ||PA-DATA element #0 |---->| signedAuthPack                     |
   | ||                   | ||  | +-------------------------------+  |
   | |+-------------------+ ||  | |ContentInfo                    |  |
   | |..................... ||  | | contentType: id-signed-data   |  |
   | +----------------------+|  | | eConType: id-pkinit-authData  |  |
   | +----------------------+|  | | eContent: AuthPack--+         |  |
   | |AS-REQ-BODY           ||  | |                     |         |  |
   | | [cname], realm,      ||  | +---------------------|---------+, |
   | | [sname], [from],     ||  | [trustedCertifiers[]],|            |
   | | till, [rtime], nonce,||  | [kdcPkId]             |            |
   | | etype, [addresses],  ||  +-----------------------|------------+
   | | [enc-authz-data],    ||     ......................
   | | [additional-tickets] ||     |
   | +----------------------+|     |
   +-------------------------+     v
                  +----------------------------------------------+
                  |pkAuthenticator, clientPublicKeyValue,        |
                  || supportedCMSTypes, clientDHNonce            |
                  ||  +-----------------------------------------+|
                  |+->|PKAuthenticator                          ||
                  |   | cusec, ctime, nonce, paChecksum, ...    ||
                  |   +-----------------------------------------+|
                  +----------------------------------------------+