Commit Graph

14 Commits

Author SHA1 Message Date
Nicolas Williams
1eda4920c8 krb5: Fix coverity warnings 2022-01-19 23:38:27 -06:00
Luke Howard
15f37ce09b krb5: fix hx509_free_error_string() usage
Fix build error in 7fb4698a: hx509_free_error_string() does not take a context
argument.

Change-Id: Ib24713d2425f53eb69fc9ebfc7cc1af3272b6271
2022-01-17 10:24:44 +11:00
Jeffrey Altman
7fb4698aa3 lib/krb5: gen_priv_key do not leak error string
hx509_get_error_string() returns an allocated string that must
be freed with hx509_free_error_string().

Change-Id: Ib24713d2425f53eb69fc9ebfc7cc1af3272b6271
2022-01-16 17:48:13 -05:00
Jeffrey Altman
c844a1c62b lib/krb5: load_priv_key do not leak error string
hx509_get_error_string() returns an allocated string that must
be freed with hx509_free_error_string().

Change-Id: I58d160ce1b09c48b587e8adce74277f6da469ceb
2022-01-16 17:45:21 -05:00
Nicolas Williams
fb553dde1d krb5: Fix warnings 2022-01-14 17:10:16 -06:00
Nicolas Williams
05e8c0ede6 Check HMAC_Init_ex() return value 2022-01-14 12:48:32 -06:00
Nicolas Williams
5f63215d0d Always perform == or != operation on cmp function result
Although not required to address bad code generation in
some versions of gcc 9 and 10, a coding style that requires
explicit comparison of the result to zero before use is
both clearer and would have avoided the generation of bad
code.

This change converts all use of cmp function usage from

```
    if (strcmp(a, b) || !strcmp(c, d)) ...
```

to

```
    if (strcmp(a, b) != 0 || strcmp(c, d)) == 0
```

for all C library cmp functions and related:

 - strcmp(), strncmp()
 - strcasecmp(), strncasecmp()
 - stricmp(), strnicmp()
 - memcmp()

Change-Id: Ic60c15e1e3a07e4faaf10648eefe3adae2543188
2021-11-24 22:30:44 -05:00
Nicolas Williams
c2bf9b9e71 kx509: Improve start_realm logic 2021-03-31 22:59:38 -05:00
Jeffrey Altman
afc9ebe08b fix calling conventions
When a function is assigned to a function pointer that is declared
with a particular calling convention, then the assigned function
must be declared with that calling convention as well.  Otherwise,
kaboom!!!

The following functions are fixed by this change:

kuser/kx509.c
  validate1()
  add1_2chain()

lib/base/log.c
  log_syslog()
  close_syslog()
  log_file()
  close_file()

lib/gssapi/mech/context.c
  gss_set_log_function()

lib/krb5/kx509.c
  certs_export_func()

Change-Id: Ib68abf739e3385e98136fa4e4f5a0240e9fce033
2020-05-26 11:48:45 -05:00
Nicolas Williams
64d5f86ec3 Fix warnings (some bugs, some spurious)
Many spurious VC warnings not quieted though.
2020-03-12 21:02:09 -05:00
Nicolas Williams
575c67806b Add bx509d 2019-12-04 21:34:44 -06:00
Roland C. Dowdeswell
62d13ebf28 lib/krb5/kx509.c: fix memory leak in an error case. 2019-11-26 13:38:17 -06:00
Nicolas Williams
dfada0ccad kx509: Add CSR support
This commit adds support for proof of posession to the kx509 protocol by
using PKCS#10 CSRs.

This allows conveyance of extReq CSR attributes requesting desired
Certificate Extensions.
2019-10-09 20:53:30 -05:00
Nicolas Williams
6a7e7eace6 Add kx509 client and revamp kx509 service
This commit adds support for kx509 in libkrb5, and revamps the KDC's
kx509 service (fixing bugs, adding features).

Of note is that kx509 is attempted optimistically by the client, with
the certificate and private key stored in the ccache, and optionally in
an external PEM or DER file.

NOTE: We do not optimistically use kx509 in krb5_cc_store_cred() if the
      ccache is a MEMORY ccache so we don't generate a key when
      accepting a GSS context with a delegated credential.

kx509 protocol issues to be fixed in an upcoming commit:

 - no proof of possession (this is mostly not too bad, but we'll want to
   fix it by using CSRs)
 - no algorithm agility (only plain RSA is supported)
 - very limited (no way to request any options in regards to the
   requested cert)
 - error codes are not very useful

Things we're adding in this commit:

 - libkrb5 kx509 client
 - automatic kx509 usage hooked in via krb5_cc_store_cred() of start TGT
 - per-realm templates on the KDC side
 - per-realm issuer certificates
 - send error messages on the KDC side
   (this is essential to avoid client-side timeouts on error)
 - authenticate as many error messages
 - add a protocol probe feature so we can avoid generating a
   keypair if the service is not enabled
   (once we add support for ECC algorithms we won't need this
    anymore; the issue is that RSA keygen is slow)
 - support for different types of client principals, not just username:

    - host-based service and domain-based service, each with its own
      template set per-{realm, service} or per-service

   (the idea is to support issuance of server certificates too, not
    just client/user certs)
 - more complete support for SAN types
 - tests (including that PKINIT->kx509->PKINIT works, which makes it
   possible to have "delegation" of PKIX credentials by just delegating
   Kerberos credentials)
 - document the protocol in lib/krb5/kx509.c

Future work:

 - add option for longer-ticket-lifetime service certs
 - add support for ECDSA, and some day for ed25519 and ed448
 - reuse private key when running kinit
   (this will require rethinking how we trigger optimistic kx509
    usage)
 - HDB lookup for:
    - optional revocation check (not strictly necessary)
    - adding to certificates those SANs listed in HDB
       - hostname aliases (dNSName SANs)
       - rfc822Name (email)
       - XMPP SANs
       - id-pkinit-san (a user could have aliases too)
 - support username wild-card A RRs, ala OSKT/krb5_admin
    i.e., if a host/f.q.d.n principal asks for a certificate for
    some service at some-label.f.q.d.n, then issue it
   (this is not needed at OSKT sites because OSKT already
    supports keying such service principals, which means kx509
    will issue certificates for them, however, it would be nice
    to be able to have this independent of OSKT)
   (a better way to do this would be to integrate more of OSKT
    into Heimdal proper)
 - a kx509 command, or heimtools kx509 subcommand for explicitly
   attempting use of the kx509 protocol (as opposed to implicit, as is
   done in kinit via krb5_cc_store_cred() magic right now)

Issues:

 - optimistically trying kx509 on start realm TGT store -> timeout issues!
    - newer KDCs will return errors because of this commit; older ones
      will not, which causes timouts
    - need a separate timeout setting for kx509 for optimistic case
    - need a [realm] config item and DNS SRV RR lookup for whether a
      realm is expected to support kx509 service
2019-10-08 21:26:50 -05:00