Re: RFC 4121 & acceptor subkey use in MIC token generation

[Jeffrey Hutzelman]

The gss-keyex userauth method is just an optimization; it prevents you
having to actually run the GSSAPI exchange again after you've already used
one of the GSSAPI-based keyex methods. The real win is in the GSSAPI-based
keyex methods themselves, which are useful (and exist) because they avoid
having to pick one of these:

1. Jump in blindly and hope there's no MITM on the first connection
2. Distribute copies of all the host public keys to all possible clients
3. Operate a PKI for identifying hosts

Of course, lots of people do (1); ssh has encouraged that since its
earliest days. And around the time I was first working on what became
RFC4462, I was also building 2-3 generations of tooling for (2).

On Thu, Oct 26, 2023 at 5:59 PM Ken Hornstein via Kerberos 
wrote:

> >> Unfortunately, ANOTHER one of the "fun" rules I live under is, "Thou
> >> shall have no other PKI than the DoD PKI".  And as much as I can
> >> legitimately argue for many of the unusual things that I do, I can't get
> >> away with that one; [...]
> >
> >A CA that issues short-lived certificates (for keys that might be
> >software keys) is morally equivalent to a Kerberos KDC.  You ought to be
> >able to deploy such online CAs that issue only short-lived certs.
>
> You know that.  I know that.  But remember: "if you're explaining,
> you're losing".  When asked I can honestly say, "Kerberos is not
> a PKI" and that's good enough, but I can't say with a straight
> face, "This X.509 CA over here is not a PKI".
>
> >Presumably OpenSSH CAs are a different story because they're not x.509?
> :)
>
> Strangely enough, I am not aware of anyone in the DoD that uses OpenSSH
> CAs (there probably are, I just don't know them).  I could see it being
> argued both ways.  The people I know who use OpenSSH are (a) using
> gssapi-with-mic like us, (b) just using passwords, or (c) using their
> client smartcart key as a key for RSA authentication and they call that
> "DOD PKI authentication".  Again, you know and I know that isn't really
> using PKI certificates, but the people up the chain aren't really smart
> enough to understand the distinction; they see that you're using the
> smartcard and that's good enough for them.
>
> >> We _do_ do PKINIT with the DoD PKI today; that is relatively
> >> straightforward with the exception of dealing with certificate
> >> revocation (last time I checked the total size of the DOD CRL package
> >> was approximately 8 million serial numbers, sigh).
> >
> >Don't you have OCSP responders?
>
> We _do_, it's just a pain to find an OCSP responder that can handle that
> many.  If the official ones go offline that breaks our KDC so we run our
> own locally.
>
> >One of the problems I'm finding is that SSHv2 client implementations are
> >proliferating, and IDEs nowadays tend to come with one, and not one of
> >them supports GSS-KEYEX, though most of them support gssapi-with-mic, so
> >it makes you want to give up on GSS-KEYEX.
>
> Right, part of the problem there is that people want to "use Kerberos
> with ssh", and they don't understand the difference between gssapi-with-mic
> and gss-keyex.
>
> --Ken
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: RFC 4121 & acceptor subkey use in MIC token generation

[Jeffrey Hutzelman]

On Thu, Oct 26, 2023 at 3:41 PM Nico Williams  wrote:

>
> So what can you do?  Well, you could build an online kerberized CA that
> vends short-lived OpenSSH-style certificates, then use that for SSH.
>

OpenSSH apparently does not support X.509 certificates because they believe
there is too much complexity. This is roughly the same problem we had with
getting GSS support into OpenSSH -- they are afraid of security technology
they didn't invent.

This is truly unfortunate, because we already have an onlike Kerberized CA
that vends short-lived X.509 certificates



> Perhaps you'll find that easier to do than to send a PR for hard-coding
> mechanism OID->name mappings, and even if not, you may find it better
> for the long term anyways because it's fewer patches to maintain.
>
> Though credential delegation becomes hairy since all you can do then is
> ssh-agent forwarding, and if you need Kerberos credentials on the target
> end well, you won't get them unless you build yet another bridge where
> you have your online kerberized CA vend certificates for use with PKINIT
> so that you can kinit w/ PKINIT using a private key accessed over the
> forwarded ssh-agent.
>

The problem with this, of course, is that one must be careful not to permit
credentials to be renewed indefinitely by simply having the KDC and KCA
repeatedly issue new credentials. Fortunately, kx509 is careful not to
issue certificates valid past the ticket lifetime, and I believe compliant
PKINIT implementations don't issue tickets valid past the certificate "Not
After" time.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: RFC 4121 & acceptor subkey use in MIC token generation

[Jeffrey Hutzelman]

On Wed, Oct 25, 2023, 11:59 Nico Williams  wrote:

> On Wed, Oct 25, 2023 at 08:51:29AM -0400, Ken Hornstein wrote:
> > I think we've lost the thread here; I do not think that any krb5
> > mechanism today ever asserts PROT_READY before GSS_S_COMPLETE, but I
> > would love to be proven wrong.
>
> That's the whole point of being able to use the initiator sub-session
> key: to allow the Kerberos GSS mechanism to assert PROT_READY on the
> first call to GSS_Init_sec_context() even when mutual auth is requested.
>
> Yes, RFC 4121 didn't say so, but it's the point.
>

Yeah; IIRC that was to allow cases where the initiator would send the first
context token in the same packet/message with early data, such as a MIC
binding the exchange to some channel. In retrospect, perhaps it has caused
more trouble than it was worth. We didn't use this in RFC 4462 userauth,
which doesn't use mutual anyway.

In any case, I think the behavior Ken is seeing is that the initiator
doesn't even assert a subkey -- it always uses the ticket session key. That
seems... unfortunate.

-- Jeff

>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos protocol transition with unconstrained delegation (i.e. TGT impersonation)

[Jeffrey Hutzelman]

Ah, I didn't realize MIT Kerberos had grown the "KDB" keytab method.
That's similar to Jonathan's idea of using the kadmin libraries to extract
the client's key from the kdb, but didn't require wiring custom code. It
does require colocating with a KDC, but I agree with Russ; it's probably
best to do that anyway.

-- Jeff

On Fri, Oct 28, 2022, 00:06 Greg Hudson  wrote:

> On 10/27/22 12:36, Jeffrey Hutzelman wrote:
> > You don't need libkadm5 for any of this -- all you need to print a
> service
> > ticket (even a TGT) is the service's key. Heimdal comes with a program,
> > kimpersonate, which does this and could easily be used as a basis for
> your
> > impersonation service.
>
> MIT krb5 has a sort-of equivalent: "kinit -k -t KDB: username".  The KDC
> is still in the loop, but no password or keytab for the user is
> required.  (Add "-S krbtgt/OTHERREALM" for a cross-realm TGT.)
>
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos protocol transition with unconstrained delegation (i.e. TGT impersonation)

[Jeffrey Hutzelman]

You don't need libkadm5 for any of this -- all you need to print a service
ticket (even a TGT) is the service's key. Heimdal comes with a program,
kimpersonate, which does this and could easily be used as a basis for your
impersonation service. Naturally, you should be cautious about giving an
application the key for the TGS (even a cross-realm TGS); as Russ points
out, this makes that application equivalent to a KDC.

-- Jeff

On Thu, Oct 27, 2022 at 11:59 AM Russ Allbery  wrote:

> Jonathan Calmels via Kerberos  writes:
>
> > So far, the only hack we can think of is replicating the AD users into
> > the MIT KDC and writing some kind of GSS service that would issue TGTs
> > for those (given the proper service ticket).  Something like:
>
> >   1.  The scheduler does protocol transition with the AD UPN it got from
> >   the CI/CD
> >   2.  The scheduler contacts this GSS service with the resulting service
> >   ticket
> >   3.  The GSS service converts the UPN from the AD realm to its MIT
> >   realm counterpart
> >   4.  If everything checks out, it sends back a TGT for the user (this
> >   might involve some unconventional calls to libkadm5)
> >   5.  The scheduler forwards this TGT as usual
>
> Yup, this is also what I would do given your constraints.  (You have a
> fairly weird security corner case that requires arbitrary user
> impersonation with no chain of authentication back to the user being
> impersonated, which Kerberos doesn't really natively support for somewhat
> obvious reasons.)
>
> > Is there a cleaner alternative? Ideally, one that doesn't involve
> > replicating users.
>
> You possibly could cheat by giving the GSS service access to the
> cross-realm key so that it can forge TGTs that look to the MIT Kerberos
> KDC as if they were issued by AD.  I think this would be roughly
> equivalent from a security standpoint (either way, the GSS service is
> essentially a KDC and has full access to the entirety of your MIT realm),
> but would avoid the need to create principals in your KDC database for
> every user.
>
> The drawback of this approach is that you're likely to need to write some
> low-level Kerberos code to forge the tickets, whereas in your plan above
> you can just generate keytab files for every user and store them on disk
> (again, the GSS service is functionally equivalent to a KDC, so this is
> just the KDC database in another format), and then your GSS service can
> generate TGTs through normal libkrb5 calls using the keytab and doesn't
> have to do anything special.
>
> --
> Russ Allbery (ea...@eyrie.org) 
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using an alternate principal for ssh

[Jeffrey Hutzelman]

On Tue, May 31, 2022 at 3:36 PM Carson Gaspar  wrote:

> On 5/31/2022 12:16 PM, Jeffrey Hutzelman wrote:
> > That code should not actually used on a properly-configured PAM-based
> > system. Typical configuration for such systems should enable UsePAM and
> > KbdInteractiveAuthentication and disable PasswordAuthentication and
> > ChallengeResponseAuthentication. This causes all password verification to
> > go through PAM. Then all you need is a PAM module that can be configured
> to
> > behave as you desire. I believe Russ Allbery's pam_krb5 has all the knobs
> > you need.
>
> I agree about the sshd config options, but looking at the source code
> for Russ's pam_krb5, I don't think it will work as-is without changing
> the username provided by the client (see my previous post).
>

It will. You want something like
alt_auth_map=%s/ssh@REALM
only_alt_auth=true



> > For true Kerberos authentication (i.e. using Kerberos tickets, not a
> > password), you can control which principals are allowed to log in as a
> user
> > by means of the user's .k5login file.
>
> Please, no - set up a localname mapping instead of trying to manage a
> bajilion k5login files.


Yeah, a mapping is probably better for this application.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using an alternate principal for ssh

[Jeffrey Hutzelman]

That code should not actually used on a properly-configured PAM-based
system. Typical configuration for such systems should enable UsePAM and
KbdInteractiveAuthentication and disable PasswordAuthentication and
ChallengeResponseAuthentication. This causes all password verification to
go through PAM. Then all you need is a PAM module that can be configured to
behave as you desire. I believe Russ Allbery's pam_krb5 has all the knobs
you need.

For true Kerberos authentication (i.e. using Kerberos tickets, not a
password), you can control which principals are allowed to log in as a user
by means of the user's .k5login file.

-- Jeff

On Tue, May 31, 2022 at 3:10 PM Greg Hudson  wrote:

> On 5/31/22 12:05, Dan Mahoney wrote:
> > On most of our boxes, ssh is the ONLY kerberized app, but there's no
> provision in krb5.conf to say what the default principal based on a
> username is.  None of the PAM modules seem to be able to set it, either.  I
> conjured up an elaborate way to do this by forcing the .k5logindir to be
> something the users couldn't touch, and forcing a create for each user, but
> this doesn't help the password case.
> >
> > Does anyone know of a simple way to accomplish this?  There are some
> clients, like mobile ones, where, VPN or no, kinit'ing is not an option.
>
> The OpenSSH sshd code decides the principal name, not libkrb5.  Looking
> at the OpenSSH auth-krb5.c, I don't think there's any configurability;
> it picks a principal name of
> authctxt->pw->pw_name (except on AIX), parses that, and calls
> krb5_get_init_creds_password().
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Admin session expiry

[Jeffrey Hutzelman]

The max_life setting in kdc.conf is only a global maximum lifetime for any 
ticket the KDC issues. The actual lifetime of issued tickets is also affected 
by the client request, the maximum ticket lifetime settings on both the client 
and service principals in the database, and (for TGS requests), the expiration 
time of the existing TGT.


Examine the database entries for both kadmin/admin and your admin user.


From: Yegui Cai 
Sent: Tuesday, March 26, 2019 1:17 PM
To: Jeffrey Hutzelman
Cc: John Devitofranceschi; Greg Hudson; kerberos@mit.edu
Subject: Re: Admin session expiry

I did some experiments with admin session expiration. The sessions expires 
within around 6 minutes no matter what is set in max_life in kdc.conf.
My guess is it is some hard coded value in KDC source code determines the 
expiry.


On Mon, Mar 11, 2019 at 11:55 AM Jeffrey Hutzelman 
mailto:jh...@cmu.edu>> wrote:

No, kadmin is never authenticated by a password. It's a Kerberos-authenticated 
service and generally requires initial tickets, which means you can't use a tgt 
to get a ticket for it.  Instead, in the usual case, the kadmin client will 
obtain an initial ticket for kadmin/admin, for which purpose it generally needs 
to prompt you for a password. The ticket it obtains is kept in memory and not 
ever written to a file where you can see it, but it does exist.  And, like all 
tickets, it has a lifetime.




From: Yegui Cai mailto:caiye...@gmail.com>>
Sent: Monday, March 11, 2019 11:42
To: Jeffrey Hutzelman
Cc: John Devitofranceschi; Greg Hudson; 
kerberos@mit.edu<mailto:kerberos@mit.edu>
Subject: Re: Admin session expiry

Hi Jeffrey.

I did some experiments with kadmin. It looks like by default, remote admin 
sessions are authenticated with admin password. And in that case, the sessions 
will never expired because there is no tickets in the system.

Does it mean I need to disable kadmin password authentication? if it is do-able?

Thanks,
Yegui

On Sun, Jan 13, 2019 at 11:33 AM Jeffrey Hutzelman 
mailto:jh...@cmu.edu>> wrote:
It's not necessary to disable the admin principal or expire the session to get 
this effect. The admin service is itself a Kerberos-authenticated service, and 
Kerberos tickets expire. Without valid tickets for the admin service, it is not 
possible to make a request, regardless of whether or not you happen to have a 
TCP connection open to the server.


By setting the max ticket lifetime for admin principals and/or the kadmin/admin 
service principal, you can limit the time these tickets are valid, and this the 
time during which it is possible to make admin requests.


-- Jeff


From: John Devitofranceschi mailto:j...@optonline.net>>
Sent: Sunday, January 13, 2019 10:34
To: Greg Hudson
Cc: kerberos@mit.edu<mailto:kerberos@mit.edu>
Subject: Re: Admin session expiry

On Jan 13, 2019, at 1:49 AM, Greg Hudson 
mailto:ghud...@mit.edu>> wrote:
>
> On 1/11/19 11:08 AM, Yegui Cai wrote:
>> Any plan to add the capability of expiring admin sessions into a future
>> release?
>
> We can consider it, although it would come at a complexity cost in the
> network code.  Can you describe why that feature is important in your
> deployment?
> 
> Kerberos mailing list   Kerberos@mit.edu<mailto:Kerberos@mit.edu>
> https://mailman.mit.edu/mailman/listinfo/kerberos

Banks and other highly regulated environments have requirements to implement 
controls around  the access of individuals to systems and data.

This includes “just in time” access provisioning and time-bound access to 
sensitive systems.

For a detailed example, see ch. 11.1 of the Monetary Authority of Singapore’s 
“Technology Risk Management Guidelines” (TRM Guidelines 
<http://www.mas.gov.sg/~/media/MAS/Regulations%20and%20Financial%20Stability/Regulatory%20and%20Supervisory%20Framework/Risk%20Management/TRM%20Guidelines%20%2021%20June%202013.pdf>)

"The [Financial Institution] should only grant user access to IT systems and 
networks on a need-to-use basis and within the period when the access is 
required.”

Now, these kinds of things are often vague and you can probably satisfy the 
requirements in a number of ways.

You *could* whack the admin session at the network level OR you *could* expire 
the admin principal that was used to authenticate the session (in an out of 
band process that’s been set up to manage such access) and demonstrate that 
even with a connected admin session the expired principal renders the session 
useless.

One of the key points for such controls is being able to provide evidence that 
the control is being met since it is not sufficient to do the right thing, you 
have to also be able to *prove* that you’re doing the right thing.  This is 
another can of worms entirely.

jd

Re: Installing heimdal-kdc

[Jeffrey Hutzelman]

add, add_new_key, and ank are synonyms. The last dates back to krb4


From: Robbie Harwood 
Sent: Monday, March 11, 2019 13:49
To: Lothar Schilling; kerberos@mit.edu
Subject: Re: Installing heimdal-kdc

Lothar Schilling  writes:

> I got stuck again with putting heimdal-kdc to work.
>
> Having initiated the database I logged in locally (kadmin -l). There is
> no such command as "add_principals" or "addprinc". Availabe are:
> stash, kstash / dump / init / load / merge / add, ank, add_new_key /
> passwd, cpw, change_password / delete, del, del_entry / del_enctype /
> add_enctype / ext_keytab / get, get_entry / rename / modify /
> privileges, privs / list / verify-password-quality, pwq / check / lock/
> unlock / help, ? /  exit, quit /

add_principals and addprinc are commands for MIT krb5's kadmin, not
Heimdal.  Heimdal uses different commands; I think "ank" is the right
one here, but it's been a while so I'll defer to those folk if they're
around.

Thanks,
--Robbie

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Admin session expiry

[Jeffrey Hutzelman]

No, kadmin is never authenticated by a password. It's a Kerberos-authenticated 
service and generally requires initial tickets, which means you can't use a tgt 
to get a ticket for it.  Instead, in the usual case, the kadmin client will 
obtain an initial ticket for kadmin/admin, for which purpose it generally needs 
to prompt you for a password. The ticket it obtains is kept in memory and not 
ever written to a file where you can see it, but it does exist.  And, like all 
tickets, it has a lifetime.




From: Yegui Cai 
Sent: Monday, March 11, 2019 11:42
To: Jeffrey Hutzelman
Cc: John Devitofranceschi; Greg Hudson; kerberos@mit.edu
Subject: Re: Admin session expiry

Hi Jeffrey.

I did some experiments with kadmin. It looks like by default, remote admin 
sessions are authenticated with admin password. And in that case, the sessions 
will never expired because there is no tickets in the system.

Does it mean I need to disable kadmin password authentication? if it is do-able?

Thanks,
Yegui

On Sun, Jan 13, 2019 at 11:33 AM Jeffrey Hutzelman 
mailto:jh...@cmu.edu>> wrote:
It's not necessary to disable the admin principal or expire the session to get 
this effect. The admin service is itself a Kerberos-authenticated service, and 
Kerberos tickets expire. Without valid tickets for the admin service, it is not 
possible to make a request, regardless of whether or not you happen to have a 
TCP connection open to the server.


By setting the max ticket lifetime for admin principals and/or the kadmin/admin 
service principal, you can limit the time these tickets are valid, and this the 
time during which it is possible to make admin requests.


-- Jeff


From: John Devitofranceschi mailto:j...@optonline.net>>
Sent: Sunday, January 13, 2019 10:34
To: Greg Hudson
Cc: kerberos@mit.edu<mailto:kerberos@mit.edu>
Subject: Re: Admin session expiry

On Jan 13, 2019, at 1:49 AM, Greg Hudson 
mailto:ghud...@mit.edu>> wrote:
>
> On 1/11/19 11:08 AM, Yegui Cai wrote:
>> Any plan to add the capability of expiring admin sessions into a future
>> release?
>
> We can consider it, although it would come at a complexity cost in the
> network code.  Can you describe why that feature is important in your
> deployment?
> 
> Kerberos mailing list   Kerberos@mit.edu<mailto:Kerberos@mit.edu>
> https://mailman.mit.edu/mailman/listinfo/kerberos

Banks and other highly regulated environments have requirements to implement 
controls around  the access of individuals to systems and data.

This includes “just in time” access provisioning and time-bound access to 
sensitive systems.

For a detailed example, see ch. 11.1 of the Monetary Authority of Singapore’s 
“Technology Risk Management Guidelines” (TRM Guidelines 
<http://www.mas.gov.sg/~/media/MAS/Regulations%20and%20Financial%20Stability/Regulatory%20and%20Supervisory%20Framework/Risk%20Management/TRM%20Guidelines%20%2021%20June%202013.pdf>)

"The [Financial Institution] should only grant user access to IT systems and 
networks on a need-to-use basis and within the period when the access is 
required.”

Now, these kinds of things are often vague and you can probably satisfy the 
requirements in a number of ways.

You *could* whack the admin session at the network level OR you *could* expire 
the admin principal that was used to authenticate the session (in an out of 
band process that’s been set up to manage such access) and demonstrate that 
even with a connected admin session the expired principal renders the session 
useless.

One of the key points for such controls is being able to provide evidence that 
the control is being met since it is not sufficient to do the right thing, you 
have to also be able to *prove* that you’re doing the right thing.  This is 
another can of worms entirely.

jd

Kerberos mailing list   Kerberos@mit.edu<mailto:Kerberos@mit.edu>
https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu<mailto:Kerberos@mit.edu>
https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Installing heimdal-kdc

[Jeffrey Hutzelman]

You need to tell the Kerberos library where to find your kdc. You have 
basically two options:


1) Add the following to /etc/krb5.conf on every client:


[realms]

MYDOMAIN.DE = {

  kdc = kdc.mydomain.de:88

}



2) Publish SRV records in DNS:


_kerberos._udp.mydomain.de IN SRV kdc.mydomain.de 88 1 1

_kerberos._tcp.mydomain.de IN SRV kdc.mydomain.de 88 1 1



I strongly recommend the SRV approach, particularly if you have a lot of 
clients, or expect any that you don't directly control.


From: Lothar Schilling 
Sent: Wednesday, March 6, 2019 08:30
To: kerberos@mit.edu
Subject: Installing heimdal-kdc

Hi,

being a newbie to kerberos I am trying to setup heimdal-kdc 7.1.0 on a
Debian 9.8 VM. Heimdal because we need Kerberos to be compliant with
Samba 4 acting as an ADDC. So here's what I did:

/apt-get install heimdal-kdc. /It's up and running: ps ax =>
/usr/lib/heimdal-servers/kdc --config-file=/etc/heimdal-kdc/kdc.conf/
//systemctl stop heimdal-kdc//
//
///etc/heimdal-kdc/kdc-conf//
//[libdefaults]//
//default_realm = MYDOMAIN.DE//
//[domain_realm]//
//.MYDOMAIN.DE = MYDOMAIN.DE//
//[logging]//
//kdc = FILE:/var/log/heimdal-kdc.log//
//[kdc]//
//database = {//
//  dbname = /var/lib/heimdal-kdc/heimdal//
//  kdc = KDC.MYDOMAIN.DE:88//
//  realm = MYDOMAIN.DE//
//  mkey_file = /var/lib/heimdal-kdc/m-key//
//  acl_file = /etc/heimdal-kdc/kadmind.acl//
//  log_file = /var/lib/heimdal-kdc/log//
//}//
//
//systemctl start heimdal-kdc//
/
/kadmin -l/ is working, /list */ is giving me this:
admin
default
kadmin/admin
kadmin/hprop
kadmin/changepw
krbtgt/MYDOMAIN.DE
changepw/kerberos
WELLKNOWN/ANONYMOUS
WELLKNOWN/org.h5l.fast-cookie@WELLKNOWN:ORG.H5L

But /kadmin/ (not-local) is not: kadm5_init_with_password: No KDC found
for realm MYDOMAIN.DE.

I thought it might be DNS-related, so I made sure nsswitch.conf fits the
bill, added the server's name to /etc/hosts. I even set up bind9 on that
very machine:
KDC.MYDOMAIN.DE. 43200   IN  A   192.168.27.3
Also made sure Kerberos is listening on port 88. I even tried localhost
and IP address instead of KDC.MYDOMAIN.DE in kdc.conf - didn't help either.

I've been trying now for 2 days, it's driving me nuts. Would anybody
please enlighten me what kind of mistake I make?

Thank you

Lothar Schilling

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Admin session expiry

[Jeffrey Hutzelman]

It's not necessary to disable the admin principal or expire the session to get 
this effect. The admin service is itself a Kerberos-authenticated service, and 
Kerberos tickets expire. Without valid tickets for the admin service, it is not 
possible to make a request, regardless of whether or not you happen to have a 
TCP connection open to the server.


By setting the max ticket lifetime for admin principals and/or the kadmin/admin 
service principal, you can limit the time these tickets are valid, and this the 
time during which it is possible to make admin requests.


-- Jeff


From: John Devitofranceschi 
Sent: Sunday, January 13, 2019 10:34
To: Greg Hudson
Cc: kerberos@mit.edu
Subject: Re: Admin session expiry

On Jan 13, 2019, at 1:49 AM, Greg Hudson  wrote:
>
> On 1/11/19 11:08 AM, Yegui Cai wrote:
>> Any plan to add the capability of expiring admin sessions into a future
>> release?
>
> We can consider it, although it would come at a complexity cost in the
> network code.  Can you describe why that feature is important in your
> deployment?
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Banks and other highly regulated environments have requirements to implement 
controls around  the access of individuals to systems and data.

This includes “just in time” access provisioning and time-bound access to 
sensitive systems.

For a detailed example, see ch. 11.1 of the Monetary Authority of Singapore’s 
“Technology Risk Management Guidelines” (TRM Guidelines 
)

"The [Financial Institution] should only grant user access to IT systems and 
networks on a need-to-use basis and within the period when the access is 
required.”

Now, these kinds of things are often vague and you can probably satisfy the 
requirements in a number of ways.

You *could* whack the admin session at the network level OR you *could* expire 
the admin principal that was used to authenticate the session (in an out of 
band process that’s been set up to manage such access) and demonstrate that 
even with a connected admin session the expired principal renders the session 
useless.

One of the key points for such controls is being able to provide evidence that 
the control is being met since it is not sufficient to do the right thing, you 
have to also be able to *prove* that you’re doing the right thing.  This is 
another can of worms entirely.

jd

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos n00b question.

[Jeffrey Hutzelman]

From: kerberos-boun...@mit.edu  on behalf of Robbie 
Harwood 

Sent: Thursday, January 10, 2019 2:18 PM
To: Grant Taylor; kerberos@mit.edu
Subject: Re: Kerberos n00b question.

Grant Taylor  writes:

>> You don't have to recreate them, but yes, it's a good idea to set
>> +requires_preauth.  Setting -allow_svr will I believe block the use
>> of U2U and make kvno on user principals no longer work, but this may
>> be acceptable to you
>
> I need to do some more reading on what user-to-user and kvno are to know
> if I care about them.

kvno is a number associated with each principal that keeps track of how
many times it's been rekeyed (password change and the like).  It's
useful for debugging to be able to access this information, but you can
also get it out of kadmin.

In this case, the thing that won't work is the 'kvno' program, which obtains 
and displays the kvno of a principal by fetching a ticket with that principal 
as the service, and then looking at the kvno in the resulting ticket. 
Naturally, that won't work for things which you've flagged not to be usable as 
services.

U2U, on the other hand, will work just fine. It doesn't require allow_svr on 
either user, because it works by using the session key from a TGT belonging to 
the target user, rather than by using that user's long-term key from the kdb.


> The little bit of reading that I just did on key version number (kvno)
> sounds unrelated to servers / services (what I think of with allow_svr).
> I need to do more reading.

The kvno(1) tool works by acquiring a service ticket to the given
principal.  So for instance, asking `kvno rharw...@fedoraproject.org`
acquires for rharw...@fedoraproject.org and then inspects the kvno on
the result.

Yes, exactly this. Of course, in a small installation where you're also the 
Kerberos admin, you can just use kadmin to examine a principal and find out its 
kvno.

> On the surface, I think I'd like to keep kvno functional.
>
> Would -allow_svr have any impact on protocol translation?  (I think
> that's the term.)  I.e. when a non-Kerberos aware client logs into IMAPS
> with username & password and the daemon translates / gateways / bridges
> into Kerberos on the client's behalf?  (I saw something about that in
> one of the first three videos I mentioned in a previous message.)

I don't believe so (but I haven't actually checked).

No, that use case will work just fine. But you should avoid it when you can, 
since one of Kerberos's main advantages is that you don't ever have to give 
application servers your password (or anything they could use to impersonate 
you).

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: version krb5support_0_MIT not defined

[Jeffrey Hutzelman]

On Fri, 2012-02-10 at 18:02 -0500, Tom Yu wrote:
 In the long run, there are better ways to overcome the problems you're
 experiencing, but they probably require adding new capabilities to the
 glibc runtime linker:
 
 * support for RTLD_GROUP

In practice, RTLD_DEEPBIND is usually good enough for this sort of
problem.


 * distinguishing libraries that have the same SONAME but exist as
   distinct files

I haven't followed this thread closely enough to determine if this is
actually the problem here, but if it is, that's a tricky problem.  The
best answer is to simply not have that happen. :-)

 You are expecting pam_krb5.so to resolve the symbols that it needs
 using the libraries that it would find in its RPATH.  On a Solaris
 system, if sshd had called dlopen() on pam_krb5.so using the
 RTLD_GROUP flag, this would be the case.  On RHEL, using the glibc
 runtime linker as it currently exists, that does not occur, and
 pam_krb5.so will find the versions of the symbols that already exist
 in the address space of the sshd process.

Modulo the duplicate-soname issue, this problem can be resolved using a
wrapper PAM module which opens the wrapped module with RTLD_GROUP (if
available) or RTLD_DEEPBIND.  For an example of such a module, see
/afs/cs.cmu.edu/misc/aaa/src/aaa-head/pam_isolate

-- Jeff


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: version krb5support_0_MIT not defined

[Jeffrey Hutzelman]

On Tue, 2012-02-14 at 12:23 -0600, Nico Williams wrote:
 On Tue, Feb 14, 2012 at 12:13 PM, Carson Gaspar car...@taltos.org wrote:
  On 2/14/12 7:35 AM, Jeff Blaine wrote:
  On 2/14/2012 2:41 AM, Carson Gaspar wrote:
  [ much DLL hell deleted ]
 
  In general, it is death to link any PAM module against non-system
  libraries. Just try it on Solaris, and you'll see different (but still
  fatal) errors (yes, the Solaris linker is better, but GIGO still applies).
 
  Carson, we've had MIT Kerberos built in /usr/rcf-krb5 for
  2 years now on Solaris 10 SPARC. Our pam_krb5 and pam_afs_session
  modules link to it and work fine.  Our OpenAFS client builds
  against it as well.
 
  When I tried it (long ago, back when Solaris was missing krb5 headers,
  so it may behave differently now), I was trying to link sshd against MIT
  GSSAPI libs. If the Solaris kerberos pam module was in my pam stack, it
  crashed. (Note I was doing the opposite of what you were - app with
  self-built libs, system pam with system libs).
 
 See the blog entry that Tom linked.  You must have been using Solaris
 8.  The Solaris linker has changed quite a bit since then.

... but last I checked, the PAM stack still does not use RTLD_GROUP, so
you still end up with this sort of problem if an application and PAM
module use different, incompatible versions of libraries that provide
the same symbols.  Unless you go to some effort to isolate them.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: ASN.1

[Jeffrey Hutzelman]

--On Monday, June 30, 2008 04:43:10 PM +0200 
[EMAIL PROTECTED] wrote:

 I would like to know if I can modify the ASN.1 files of kerberos.

As far as I know, you can modify anything you want in your copy of Kerberos.


However, the ASN.1 describes the Kerberos protocol, which is specified in 
RFC4120 and related documents.  If you make changes, the resulting protocol 
will no longer be Kerberos and may not interoperate correctly with existing 
and/or future implementations of the standard protocol.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: GSSAPI + IAKERB

[Jeffrey Hutzelman]

--On Wednesday, June 25, 2008 05:04:18 PM +0530 kul gupta 
[EMAIL PROTECTED] wrote:

 Hello

 I was going through IAKERB  and have some doubts
 I will be highly thankful if anyone can clear my doubts.

 1) Can someone please explain me the scenerio for using IAKERB.?

Take a look at section 1 of draft-ietf-krb-wg-iakerb-00.txt, available from
http://tools.ietf.org/html/draft-ietf-krb-wg-iakerb.  Note that the older 
draft-ietf-cat-iakerb document has not been touched in several years, and 
is superceded by the krb-wg document.

 2) I have to go fopr GSSAPI for IAKERB implementation??

Yes, IAKERB is a GSS-API mechanism.

 3) Is there any sample code available for the same?

Probably not; the new IAKERB document is still in the first stages of 
development.  If anyone knows of an implementation of this, please speak up.

If you have comments on IAKERB, please address them to the IETF Kerberos 
working group mailing list, [EMAIL PROTECTED] (this is an open list; 
subscribe at https://lists.anl.gov/mailman/listinfo/ietf-krb-wg).

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Co-chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: ticket steal possibility

[Jeffrey Hutzelman]

On Wednesday, March 21, 2007 01:25:26 PM +0200 Nikolai Tenev 
[EMAIL PROTECTED] wrote:

 On server one (server1) in krb5.conf I have a record:

  auth_to_local = {
RULE:[2:$2](support)s/^.*$/root/
  }

 On server two (server2) in krb5.conf I have a record:

  auth_to_local = {
RULE:[2:$2](support)s/^.*$/root/
RULE:[2:$2](developer)s/^.*$/root/
  }

Doing authorization this way is dangerous, because it effectively grants 
privileges based on the mere existance of a principal, and assumes that no 
principal will ever be created that should not have these privileges.  A 
better approach is to distribute lists of authorized developers and support 
staff which can be used in constructing a .k5login file for root.


 When client1 is logged in from his workstation1 as root on server2, the
 ticket  of client1 is forwarded

If you don't trust the machine you're connecting to, including all the 
people who have privileged access to it, then don't do that.  Whenever you 
type a password on a machine, or forward credentials, agent connections, or 
X11 connections, you are granting that machine, and whoever controls it, 
the power to act as you.  Giving your credentials to an untrusted machine 
is inherently unsafe; there are no tricks to get around that fact.

Most ssh clients can be configured to forward credentials, agent 
connections, and X11 connections only to specific hosts.  Your support 
staff should forward these only to trusted machines; that is, only to 
machines where only trusted staff have privileged access.  They should also 
only ever type passwords at such machines, and never at an untrusted 
machine where some other person has root access.

In our facility we go a step further; privileged users are not allowed to 
type passwords on or forward credentials to any machine where an untrusted 
person has any access, privileged or not.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: What is SPNEGO and GSSAPI / Kerberos

[Jeffrey Hutzelman]

On Thursday, March 01, 2007 01:23:19 PM +0530 Gayal 
[EMAIL PROTECTED] wrote:

 Who is officially governing the GSSAPI and SPNEGO standards? Is it IETF?

Yes.  The current GSS-API spec is RFC2743, and its C language bindings are 
specified in RFC2744 (which, unfortunately, also includes some details you 
need to know even if you are not using C).

The Kerberos V GSS-API mechanism is specified in RFC1964 and RFC4121; 
Kerberos itself is specified in RFC3961, RFC3962, and RFC4120.

SPNEGO is specified in RFC4178.

SPKM is specified in RFC2025 and in section 2 of RFC2847.

Note that the IETF is currently working on updates to both Kerberos and the 
GSS-API; both have extensions defined in documents I haven't mentioned, 
plus new versions of the base specifications that are in progress.  This 
work is being done in the Kerberos and Kitten working groups, respectively. 
There is also work ongoing to select and develop a replacement for SPKM3, 
this could turn out to be the proposed SPKM4 or one of the other proposals 
currently under consideration.  This work is proceeding on the 
[EMAIL PROTECTED] mailing list.

SSPI and NTLMSSP are Microsoft-proprietary.  Documentation is available for 
both, but I can't tell you offhand where to find it.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Jeffrey Hutzelman]

On Friday, February 02, 2007 10:05:09 AM -0500 Jim Rees [EMAIL PROTECTED] 
wrote:

 So would it be fair say this is sort of like using a smartcard in that you
 need both possession of the token and knowledge of a PIN?  And that the
 KDC guards the PIN against brute force guessing, because each guess
 requires a transaction against the KDC?  So stealing the token gets the
 attacker nothing?

No.  Smart cards are not (generally) simple storage devices.  What guards a 
smartcard PIN against brute force guessing is that you only get a limited 
number of tries before the card locks itself and becomes useless.  And what 
protects the private key is the fact that only the card knows the key, so 
if the card is not physically present (or has been locked out due to too 
many wrong PIN's), it is impossible to perform crypto operations with the 
private key.

What we're talking about here is something completely different.  Yes, you 
need both posession of a physical object and a password.  But the 
similarity ends there.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Jeffrey Hutzelman]

On Fri, 2 Feb 2007 [EMAIL PROTECTED] wrote:

 That being said I'm certainly no IETF politician.

Good.  Neither are the rest of us, for the most part.  What we are is
engineers trying to produce quality network protocol standards, preferably
in non-infinite amounts of time.  If you have something to contribute,
please do.


 Its not sexy, nor fun, like building a
 new desktop environment so there is a paucity of Open-Source interest
 in the arena.

On the contrary, I think you'll find there are plenty of people who
consider work at this level fun.  I, for one, consider things like a good
desktop environment important but have absolutely no desire to actually
work on them.  It really does take all kinds, or at least more than one
kind.

 The only organizational challenge is dealing with the user who forgot
 their CryptoCard the last time they flew to Europe and now have it
 securely duct taped to the back of their laptop, with the pin number
 written in magic marker on the duct tape so they don't forget it.

Yes; hardware tokens have some of the same challenges as softtokens; they
just manifest themselves in slightly different ways.  The comment someone
made earlier about using a thumbprint scanner in place of a PIN(*)
intrigues me, though I'm not yet convinced it's actually feasible, and of
course it doesn't apply in the situations where you want a softtoken to
avoid special hardware.


Just to be clear, I'm not suggesting that there is no place for soft
tokens, either of the traditional type which stores a private key or of
the sort you propose.  I was simply pointing out that these don't work in
the same way as hardware tokens or smartcards, or each other for that
matter.  Each technology has different features, and it's precisely
_because_ your proposal doesn't work like a smartcard that makes it
interesting in the first place.


(*) Note that what he actually proposed was using a thumbprint scanner to
produce keying material, but that's not actually workable, because the
output from such a scanner does not have enough deterministic bits to
produce a strong key.

-- Jeff


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Jeffrey Hutzelman]

On Thursday, February 01, 2007 03:06:21 PM -0600 [EMAIL PROTECTED] wrote:

 What keeps a user from copying the identity token from the USB
 device to a local or shared file system to avoid having to insert
 the USB device all the time?

 We were considering public flogging but were unsure if we could get it
 into an IETF draft.

wg chair hat on

Anyone can submit an internet-draft; just write up your proposal according 
to http://www.ietf.org/ietf/1id-guidelines.html and send it off to 
[EMAIL PROTECTED]

You should then bring up your proposal on the Kerberos Working Group 
mailing list, [EMAIL PROTECTED]  We're beginning to move into the area 
of preauthentication and improving the initial authentication exchange, and 
while I can't guarantee that your proposal will be well-received, it will 
certainly receive the same consideration as a number of others that have 
recently been raised.

wg chair hat off


 Security starts with user training and making it unnecessary for them
 to want to do things like that.

In this case, I think that is unrealistic.  The thing users want to avoid 
is Oh, damn, I have to dig out this stupid USB thing and plug it in before 
I can use my computer, what a pain.  They'll do that by copying the file 
off, especially after the first few instances of Oh, damn, I have to dig 
out this stupid USB thing and plug it in to use my laptop, and I can't 
because I'm in Europe and the USB thingy is in Pittsburgh.


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Jeffrey Hutzelman]

On Thursday, February 01, 2007 05:15:56 PM -0500 Jeffrey Hutzelman 
[EMAIL PROTECTED] wrote:



 On Thursday, February 01, 2007 03:06:21 PM -0600 [EMAIL PROTECTED] wrote:

 What keeps a user from copying the identity token from the USB
 device to a local or shared file system to avoid having to insert
 the USB device all the time?

 We were considering public flogging but were unsure if we could get it
 into an IETF draft.

 wg chair hat on

 Anyone can submit an internet-draft; just write up your proposal
 according  to http://www.ietf.org/ietf/1id-guidelines.html and send it
 off to  [EMAIL PROTECTED]

 You should then bring up your proposal on the Kerberos Working Group
 mailing list, [EMAIL PROTECTED]  We're beginning to move into the area
 of preauthentication and improving the initial authentication exchange,
 and  while I can't guarantee that your proposal will be well-received, it
 will  certainly receive the same consideration as a number of others that
 have  recently been raised.

 wg chair hat off

Of course, I should note that it's your OTI proposal that I'm suggesting 
you bring to the working group.  The bit about public flogging should be 
written up separately and sent directly to rfc-editor@rfc-editor.org, 
without prior publication as an I-D, per item 19 in the FAQ at 
http://www.rfc-editor.org/rfcfaq.html

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: If you choose to install a stash file...

[Jeffrey Hutzelman]

On Wednesday, January 10, 2007 02:16:53 PM -0500 Ken Hornstein 
[EMAIL PROTECTED] wrote:

 In addition to needing to enter a passphrase to launch krb5kdc (with
 the -m option), it looks like kdb5_util will also need a passphrase,
 understandably.

 This means that the traditional cronjob-triggered kprop - kpropd
 replication won't work either, right?

 Actually, it shouldn't need a passphrase; the dump files contain the
 encrypted keys not the decrypted ones, and that's what kprop/kpropd
 pass around.  I thought that the MIT folks told me that they run without
 a stash file, and I see they have three KDCs.

I can't speak for current code, but several years ago we ran MIT KDC's with 
only the master having a stash file, and propagation worked just fine.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kinit always warning about passw expiration

[Jeffrey Hutzelman]

On Monday, November 27, 2006 03:26:25 PM -0200 Andreas Hasenack 
[EMAIL PROTECTED] wrote:

 When I run MIT's kinit (version 1.4.3 + sec.patch) against a heimdal KDC
 (0.7, backend in ldap, no samba attributes), I always get the password
 expiration warning:

 $ kinit
 Password for [EMAIL PROTECTED]:
 Warning: Your password will expire in 364 days on Tue Nov 27 15:17:52 2007
 $

 The KDC has this attribute in this user's entry:
 krb5PasswordEnd: 20071127171752Z

 If I do the same from heimdal's kinit, I only get the warning if the
 expiration time is in 7 days or less, which is my intention.

 I suppose there is some incompatibility in the network protocol
 between the two implementations?

No.  The protocol carries information about when the password is due to 
expire; it's up to the client to decide what to do with this data (of 
course, if the password is expired, the KDC will return an error).

There are two ways in which password expiration data can be carried in the 
Kerberos protocol, both of which are optional.  In one of these cases (the 
use of last-req to carry key or account expiration data), if the data is 
provided, the MIT client code always prints a warning; in the other (the 
key-expiration field), the warning is printed only if the password expires 
within 7 days.

The Heimdal KDC provides a last-req entry for account expriation if the 
principal has an expriation date, and provides an entry for password 
expiration if the password expires within the period specified by the 
kdc_warn_expire option; if the option is not set, this data is always 
provided.

The Heimdal client prints expiration data only if the expiration date is 
within the period specified by the warn_pwexpire config option, which 
defaults to 7 days.


So, this difference is a result of a difference in client behavior, with 
the proviso that as of the version I looked at (possibly fairly old), MIT 
Kerberos does not provide any mechanism for changing the client 
configuration; it always warns about last-req data for password or account 
expiration, and warns about key-expiration only if the expiration date is 
within 7 days.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Daylight saving time changes in MIT kerberos?

[Jeffrey Hutzelman]

On Friday, October 13, 2006 09:54:19 AM -0400 Danny Mayer 
[EMAIL PROTECTED] wrote:

 What are you talking about? Timezones are local display issues. When you
 go from summer time to winter time and visa versa do you see issues? All
  applications use UTC which doesn't care about timezones.

Unfortunately, this is not entirely true.  Certain operating systems track 
local time, rather than UTC, and thus will report incorrect UTC times to 
applications if the timezone is not correct.  Further, users are prone to 
deciding that the time they see is wrong and fixing it by changing the 
time rather than selecting the correct timezone.  It seems not unlikely 
that a good portion of users will do so in response to the upcoming 
brokenness (Oh, I know the rules changed; my computer must have done it 
wrong, so I'll just set the clock now).

Of course, systems using NTP with a reliable time source should have no 
problems, as long as the user does not tamper with the clock.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: AW: Anyone has an apache running with mod_auth_kerbANDmod_auth_ldap?

[Jeffrey Hutzelman]

On Friday, October 13, 2006 07:45:17 PM +0100 Markus Moeller 
[EMAIL PROTECTED] wrote:

 I tried to use kinit [EMAIL PROTECTED]@DOMAIN.COM (\\ escapes @)
 with  MIT against AD where the userprincipalname is set to the email
 address but  failed, whereas I can login on XP using the email address. I
 found that MS  uses a principal type 10 (= enterprise name). Is this
 anywhere defined in a  standard or is this a MS extension ?

The value is assigned in RFC4120 section 7.5.8, but without details as to 
the expected name form.  What you're seeing is the most common usage for 
this name type.  Note that Kerberos principal name types are advisory; they 
generally do not need to match.

You only said I tried... but failed.  How did you fail?  Were you unable 
to type the backslash, or perhaps the at-sign?  Or did kinit print some 
error message you're not sharing with us?

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kerberized tcpserver

[Jeffrey Hutzelman]

On Friday, October 13, 2006 05:05:37 PM -0400 Wesley Chow 
[EMAIL PROTECTED] wrote:


 Is there a kerberized tcpserver or inetd program out there?  What I'd
 like to do is kerberize an rsync file transfer session without having to
  go through ssh.  It also seems like having such a program would be
 useful to kerberize any services that are already written with inetd or
 tcpserver in mind...

Kerberos only provides authentication and a shared secret.  To properly 
kerberize an application protocol, it has to protect its commands and 
data from tampering by actually _doing_ something with that secret.  There 
are a number of tools out there, including ssh, remctl, and a variety of 
TLS-based tools, which provide applications with an integrity-protected, 
encrypted data channel and which can use Kerberos authentication.  In most 
cases, these require running the application in a particular way, which is 
generally _not_ the same as what inetd does (accept a connection and pass 
the TCP socket to the application).

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Enctype Negotiation Problem

[Jeffrey Hutzelman]

On Wednesday, October 11, 2006 06:16:33 PM -0400 Marcus Watts 
[EMAIL PROTECTED] wrote:


 In the MIT kerberos source, there's a pair of routines
 select_session_keytype and dbentry_supports_enctype that are probably
 making this decision for you. Here's the comment in
 dbentry_supports_enctype:
 /*
  * If it's DES_CBC_MD5, there's a bit in the attribute mask which
  * checks to see if we support it.  For now, treat it as always
  * clear.
  *
  * In theory everything's supposed to support DES_CBC_MD5, but
  * that's not the reality
  */
 Unfortunately, that's followed immediately by
   if (enctype == ENCTYPE_DES_CBC_MD5) return 0;
 which should have the effect never use des-cbc-md5.
 Presumably the bit in the attribute mask never got implemented.
 The bit itself appears to be defined -- looks like it's called
 KRB5_KDB_SUPPORT_DESMD5 (0x4000) or support_desmd5.

Except the issue here is he's getting a DES_CBC_MD4 session key when he 
wants DES_CBC_CRC.  The why is likely in the code you're quoting - 
DES_CBC_MD4 is a better enctype, and both sides appear to support it 
(since the single-des types are interchangeable).

I'd be curious to know how the resulting ticket is not useful; that is, 
what application is being used and what error results when attempting to 
use that ticket.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Enctype Negotiation Problem

[Jeffrey Hutzelman]

On Wednesday, October 11, 2006 06:06:08 PM -0500 John Hascall 
[EMAIL PROTECTED] wrote:


 Except the issue here is he's getting a DES_CBC_MD4 session key when he
 wants DES_CBC_CRC.  The why is likely in the code you're quoting -
 DES_CBC_MD4 is a better enctype, and both sides appear to support it
 (since the single-des types are interchangeable).

 I'd be curious to know how the resulting ticket is not useful; that
 is,  what application is being used and what error results when
 attempting to  use that ticket.

 Here is the error reported by the user:

 $ telnet -fax cerberus.ait.iastate.edu
 Encryption is verbose
 Trying 129.186.145.115...
 Connected to cerberus.ait.iastate.edu.
 Escape character is '^]'.
 [ Trying mutual KERBEROS5 (host/[EMAIL PROTECTED])... ]
 [ Kerberos V5 refuses authentication because telnetd:
   krb5_rd_req failed: Encryption type not permitted ]
 [ Trying KERBEROS5 (host/[EMAIL PROTECTED])... ]
 [ Kerberos V5 refuses authentication because telnetd:
   krb5_rd_req failed: Encryption type not permitted ]

Is the telnetd also heimdal?  That sounds like either the machine running 
telnetd is configured to require des-cbc-crc, or its keytab contains only a 
des-cbc-crc key.  You can fix the latter problem by using ktutil to copy 
the keytab to a v4 srvtab and back.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Enctype Negotiation Problem

[Jeffrey Hutzelman]

On Wednesday, October 11, 2006 06:20:30 PM -0500 John Hascall 
[EMAIL PROTECTED] wrote:



  Except the issue here is he's getting a DES_CBC_MD4 session key when
  he wants DES_CBC_CRC.  The why is likely in the code you're quoting
  - DES_CBC_MD4 is a better enctype, and both sides appear to support
  it (since the single-des types are interchangeable).
 
  I'd be curious to know how the resulting ticket is not useful; that
  is,  what application is being used and what error results when
  attempting to  use that ticket.
 
  Here is the error reported by the user:
 
  $ telnet -fax cerberus.ait.iastate.edu
  Encryption is verbose
  Trying 129.186.145.115...
  Connected to cerberus.ait.iastate.edu.
  Escape character is '^]'.
  [ Trying mutual KERBEROS5
  (host/[EMAIL PROTECTED])... ] [ Kerberos V5 refuses
  authentication because telnetd:
krb5_rd_req failed: Encryption type not permitted ]
  [ Trying KERBEROS5 (host/[EMAIL PROTECTED])... ]
  [ Kerberos V5 refuses authentication because telnetd:
krb5_rd_req failed: Encryption type not permitted ]

 Is the telnetd also heimdal?  That sounds like either the machine
 running  telnetd is configured to require des-cbc-crc, or its keytab
 contains only a  des-cbc-crc key.  You can fix the latter problem by
 using ktutil to copy  the keytab to a v4 srvtab and back.

 Yes, the keytab has only a des-cbc-crc key as that's all the KDB has.

Ah, but MIT Kerberos treats des-cbc-crc, des-cbc-md4, and des-cbc-md5 as 
interchangeable in a variety of cases, and Heimdal does not.  So if you 
have an MIT KDC and Heimdal application servers, then a principal with a 
des-cbc-crc key in the KDB needs to have all three enctypes in its keytab.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kerberos password requirements

[Jeffrey Hutzelman]

On Monday, October 02, 2006 02:08:59 PM -0500 Ryan Schultz 
[EMAIL PROTECTED] wrote:

   Currently the password requirements for kerberos is 10 characters  using
 2 of 5 classes (lower, upper, numeric, punctuation, other).   Could
 someone point me to why/how this criteria came about and tell  me if this
 will remain the requirements in the future.

That's a matter of local policy, not something required by Kerberos.
Talk to your administrators.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Remembering Master Password

[Jeffrey Hutzelman]

On Wednesday, September 27, 2006 08:52:52 AM -0700 Henry B. Hotz 
[EMAIL PROTECTED] wrote:

 Heimdal uses a standard keytab file for the master password.  In
 Heimdal kadmin you can do:

 add -r M/K
 del_enc M/K all encryption types except the one you want
 ext_key -k master key stash location M/K
 delete M/K

You can, but if you do that multiple times, you'll end up with multiple 
keys with the same kvno.  Since Heimdal records for each record the version 
of the master key that was used to encrypt it (if any), it can handle 
multiple keys and do a gradual transition.  But that won't work if you keep 
reusing the same version.

Also, that's rather convoluted compared to

ktutil add -r -p M/K



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Remembering Master Password

[Jeffrey Hutzelman]

On Wednesday, September 27, 2006 01:26:22 PM -0700 Henry B. Hotz 
[EMAIL PROTECTED] wrote:


 On Sep 27, 2006, at 11:10 AM, Jeffrey Hutzelman wrote:



 On Wednesday, September 27, 2006 08:52:52 AM -0700 Henry B. Hotz
 [EMAIL PROTECTED] wrote:

 Heimdal uses a standard keytab file for the master password.  In
 Heimdal kadmin you can do:

 add -r M/K
 del_enc M/K all encryption types except the one you want
 mod --kvno==desired next version # M/K  ;-)
 ext_key -k master key stash location M/K
 delete M/K

 You can, but if you do that multiple times, you'll end up with
 multiple keys with the same kvno.  Since Heimdal records for each
 record the version of the master key that was used to encrypt it
 (if any), it can handle multiple keys and do a gradual transition.
 But that won't work if you keep reusing the same version.

 Also, that's rather convoluted compared to

 ktutil add -r -p M/K

 So it is.  You can't delete it from the master DB afterwards with
 ktutil, but I guess you're advocating just leaving it there so you  don't
 have to track the version number yourself?

'ktutil add' doesn't talk to the server at all; it only manipulates the 
keytab.  So, the entry never gets added to the database.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Remembering Master Password

[Jeffrey Hutzelman]

On Wednesday, September 27, 2006 01:54:30 PM -0700 Henry B. Hotz 
[EMAIL PROTECTED] wrote:

 I'm assuming from your omission that add will look at the existing
 kvno's and create the next one?

Well, the man page claims it will prompt for anything you don't specify; 
I'm not sure I believe that wrt enctypes, but I bet it's true for the kvno. 
So yes, you'd have to list the existing keytab and pick a new kvno.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Starting kpropd as a service in Solaris 10

[Jeffrey Hutzelman]

On Wednesday, September 13, 2006 07:29:22 PM -0700 Mike Friedman 
[EMAIL PROTECTED] wrote:

 The sysadmin has tried several times to 'refresh' inetd via smf commands,
 to no avail.

The issue here is very likely that there is already a service in smf for 
Sun's kpropd, which is conflicting with the one created as a result of your 
line in /etc/inetd.conf.  The particularly annoying bit is that the 
existing service may even use inetd to start Sun's kpropd, but the existing 
inetd-based service won't be in the same place in smf as one created by 
conversion from inetd.conf, which means they can (and do) exist at the same 
time, but yours loses because inetd knew about the other one first.

You have a couple of choices here...

- Find the existing smf service for Sun's kpropd and remove or disable it.
- Figure out what package contains Sun's kpropd and uninstall it.n

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: krb1.5 plugin interface query

[Jeffrey Hutzelman]

On Friday, September 08, 2006 03:37:33 PM -0400 Ken Raeburn 
[EMAIL PROTECTED] wrote:

 (A question I haven't investigated: Does the
 presence of an A record there and no  records mean there is no
  record, or would you still need to make that query?  My guess
 would be the latter.)

I believe the latter.  RFC3596 redefines query types that trigger type A 
additional section processing to also perform type  additional section 
processing.  However, the server is only required to return records it 
already has, not to perform additional queries to obtain records it does 
not have.  So, it's fairly easy to construct a scenario in which A records 
are returned but  records are not, even though they exist.  IMHO this 
is unfortunate, since it means that the round-trip savings realized by use 
of the additional section are lost in many cases.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: pam_krb5 can't locate my KDC

[Jeffrey Hutzelman]

On Sunday, August 20, 2006 11:19:13 PM -0400 Michael B Allen 
[EMAIL PROTECTED] wrote:

 I was just trying pam_krb5 for kicks but it can't find my KDC. My
 /etc/krb5.conf is just:

It helps a lot if you quote actual error messages, instead of paraphrasing 
them.  Similarly, it's going to be a lot easier to track down the problem 
if you send your real krb5.conf, instead of trying to obfuscate the names. 
Perhaps you could also tell us the name of the machine you're trying this 
on.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: pam_krb5 can't locate my KDC

[Jeffrey Hutzelman]

On Monday, August 21, 2006 12:05:24 PM -0400 Michael B Allen 
[EMAIL PROTECTED] wrote:

 [EMAIL PROTECTED] src]$ ssh [EMAIL PROTECTED]
 [EMAIL PROTECTED]'s password:
 Permission denied, please try again.

 There is no user5 on the local system. My expectation is that pam_krb5.so
 should use the supplied password to get a TGT thereby authenticating me
 (I'm assuming not having a shell or home directory is not interfering
 with this step).

If the user doesn't exist in /etc/passwd or whatever other source you're 
using for account information, then you're never going to be able to log 
in.  Depending on the PAM module in question, there might not be any 
communication with the KDC before that happens.

Now, if this happens with a user that does exist, that's a different issue. 
In that case, the interesting messages will be the ones in the log, rather 
than what the user gets to see.


 Perhaps my expectations are misguided? What does pam_krb5 do exactly?

There are several PAM modules that call themselves pam_krb5, so a precise 
answer to that question is not possible without more information.  But, it 
does what any PAM module does, which is to handle authentication and make 
an authorization decision.  In your first example, the authorization 
decision fails - you can't log in as user5 because there is no such user. 
In the second example, the authentication step fails, because the principal 
doesn't exist in the Kerberos database.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: FW: KERBEROS product

[Jeffrey Hutzelman]

On Monday, August 21, 2006 04:36:32 PM +0200 [EMAIL PROTECTED] 
wrote:

 We did not receive any answer, therefore we send you another email in
 order to get some feedback from you.
 Thank you very much in advance.

kerberos@mit.edu is a public mailing list, not a private contact address. 
Anything you send here will be seen by anyone subscribed to the mailing 
list and anyone who cares to look at the archives.  I would not recommend 
sending anything to that address that you do not want to become public.

In any case, your message mentioned what I assume is a Microsoft Word 
document, but did not include either a copy of the document or a pointer to 
where it might be downloaded.  It's possible it was eaten by MIT's mail 
servers, which use a somewhat overagressive (IMHO) anti-virus filter.  If 
your data is not confidential, perhaps you'll consider posting a URL for 
someplace from which the data can be downloaded.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: question about kerberos

[Jeffrey Hutzelman]

On Wednesday, August 16, 2006 08:51:45 AM -0700 Nor Mas Ayu Adam 
[EMAIL PROTECTED] wrote:

 greeting to you.

   I'm ayu, a comp science student. Currently i'm doing a research about
 Kerberos that have  been developed as part of project athenna at MIT.
   so would you give me an information about the requirement for kerberos
 and the authentication dialog in both kerberos Version 4   5.
   and also, i will feel glad if you can give me more explanation what is
 kerberos in general.
   i would like to hear from MIT soon.

If you're doing research, I suggest you do some, instead of asking someone 
else to supply you with the answers.  I'll give you three hints as to what 
might be good starting places, depending on the level of detail you need:

1. http://www.google.com/search?q=kerberos
   The first several matches here are reasonable sources on the topic.

2. http://web.mit.edu/Kerberos/dialogue.html
   Designing an Authentication System: a Dialogue in Four Scenes
   The canonical basic explanation of the how's and why's of Kerberos.
   Computer Science students should have no trouble following this.

3. RFC 4120 http://www.ietf.org/rfc/rfc4120.txt
   The official Kerberos protocol specification.



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Openssh, kerberos and Solaris 10

[Jeffrey Hutzelman]

On Wednesday, August 09, 2006 11:56:07 AM -0500 Nicolas Williams 
[EMAIL PROTECTED] wrote:

 On Wed, Aug 09, 2006 at 09:36:30AM -0700, Erich Weiler wrote:
 I am getting credentials through PAM.  That much is working.  My
 problem, very specifically, is that:

 1: I want SSH to automatically forward my krb5 credentials when I SSH
 into another machine using public keys.

 This makes no sense.  Why use public key authentication when you have
 Kerberos V?

I can see reasons why you might want to do that.  For example, your 
Kerberos credentials might not be sufficient to allow access to the remove 
machine.  However, that's beside the point.  You can't do this, no matter 
what implementation you use, because there is no provision in the SSH 
protocol to allow this -- delegation of GSS-API credentials requires the 
use of GSS-API key exchange or user authentication using the credentials 
you wish to delegate.  From a protocol standpoint, either is sufficient, 
though some implementations may not support credential delegation with 
GSS-API key exchange (stock OpenSSH doesn't support GSS-API key exchange at 
all, but the sun one does).


 2: I don't want to use Sun SSH; I would rather use OpenSSH.  The reasons
 for this are not applicable to this discussion.

 I thought they were.  You seemed to think that SUNWssh didn't support
 something that it does support.

I have to agree with Nico here.  You've said that the reason you want to 
build OpenSSH instead of using Sun's version is to get credential 
delegation.  Sun's SSH does this, and in fact has better support overall 
for both GSS-API and PAM than does OpenSSH.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Openssh, kerberos and Solaris 10

[Jeffrey Hutzelman]

On Wednesday, August 09, 2006 02:55:05 PM -0500 Douglas E. Engert 
[EMAIL PROTECTED] wrote:

 __gss_userok() is not; should it be?

 I would say yes. Every service needs to do this, and use the GSS creds
 to test if it can use the local resource. So it in that regards it is
 generic.

Actually, many services don't need to do this.  An SSH server may want a 
machenism-independent userok API to determine whether to allow access to 
a local account, but lots of services have nothing to do with local 
accounts.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: HELP!! invalid AS-REP from Linux running MIT Kerberos V5

[Jeffrey Hutzelman]

On Tuesday, July 11, 2006 07:20:18 PM -0400 Marcus Watts [EMAIL PROTECTED] 
wrote:

 Looks like it's working as coded.  All of this logic appears to have
 been in MIT since at least kerberos 1.0 in, um, 1995 --presumably
 the older clients mentioned in the comment ought not be there anymore
 so KRB5_ENCKRB5KDCREPPART_COMPAT could be not defined.

Last I checked, we actually had such broken clients _deployed_, in the form 
of Cisco terminal servers.  We run a Heimdal KDC, which has a configuration 
option to control this behavior.  We have to have it set to the 
non-compliant mode, because of the broken clients.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Use of clock_skew option on Client side krb5.conf file

[Jeffrey Hutzelman]

On Monday, July 10, 2006 12:06:12 AM -0700 [EMAIL PROTECTED] wrote:

 Hi all,

 I have a query regaqrding specifying the clock_skew in the client side
 ( kerberos client) krb5.conf file. As  I understand, the maximum
 allowable time skew is determined by KDC. Please let me know whether my
 understanding is correct.

 I want to understand the use of specifying the clock_skew in the client
 side krb5.conf file. For example on KDC krb5.conf file, the maximum
 allowable clock skew is say 600 seconds. On the client krb5.conf file I
 specify clock_skew = 1200 seconds. What will be the effect ? Will KDC
 accept the request if time difference is greater than 600 but with in
 1200 ?

 Could you please explain?

The KDC determines the amount of skew acceptable between the time the 
client _uses_ and the actual time on the KDC.  Similarly, each Kerberos 
application service determines the amount of skew acceptable between the 
time the client uses and the actual time on the machine providing the 
service.  I beliece the clock_skew value in krb5.conf actually controls the 
latter value - that is, it affects application servers, not clients.


RFC4120 describes a way to allow clients to operate with a clock that does 
not agree with the KDC, as long as the client's clock is running at more or 
less the correct _rate_, and as long as the clocks on the KDC and 
application servers are sufficiently close.  Many Kerberos implementations 
support this technique, and will apply it automatically when needed.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Windows Clients Won't Do Kerberos

[Jeffrey Hutzelman]

On Thursday, June 29, 2006 07:12:53 PM -0400 Michael B Allen 
[EMAIL PROTECTED] wrote:

 I have confirmed with a packet capture that the client never tries
 Kerberos. It just tries raw NTLMSSP. No SPNEGO.

 Finally, the installer on the Linux machine validates the keytab
 credential with krb5_get_init_creds_keytab and then does a DCE/RPC group
 lookup against the DC. It was successful. So the SPN and it's credential
 is valid.

If it's never even trying negotiate, then one of these must be true:
(1) It doesn't support it
(2) It's configured not to use it
(3) The server doesn't claim support it
(4) It can't get a ticket

Since you have another client which also fails, (1) and (2) seem unlikely. 
And, since you have other tickets, and you've demonstrated that the service 
principal exists, (4) also seems unlikely.  So, I'm going to guess that 
your server is broken, and doesn't claim to support that mechanism.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kadmin.local works but kadmin doesn't. kpasswd 'insufficient access to lock data base'

[Jeffrey Hutzelman]

On Tuesday, June 13, 2006 03:00:20 AM -0400 Ken Raeburn [EMAIL PROTECTED] 
wrote:

 On Jun 12, 2006, at 16:03, [EMAIL PROTECTED] wrote:
 The whole problem is solved. Man page for 'kerberos_selinux'
 essentailly says that selinux protection for krb5kdc and kadmind needs
 to be turned off using the following commands:

 How odd.  I don't know anything about selinux, but I find it pretty
 strange that it wouldn't let you run two services that need to share
 a database in read-write mode...

It's not operating at that level.  SELinux applies additional constraints 
on what a process can do based on the context of that process, policy 
configuration, and the labels on files the process is trying to access.  As 
far as I can tell, process context is determined by a combination of 
inheritance and the security labels on executed files.

Fedora Core systems ship with two possible policy databases, which they 
call strict and targeted.  The strict policy is a default-closed 
policy; only actions explicitly permitted by policy are permitted.  The 
targeted policy, which is the default, only applies restrictions to 
particular programs and daemons which are considered particularly risky. 
Mostly, this means things that provide network services (like kadmind) or 
run with more privileges than the user who invoked them (like su).

The OP's description indicates that when he runs kadmind by hand, it runs 
in the context 'unconfined_t', which should only happen in the 'targeted' 
policy (I'm not sure that type even exists in 'strict').  So, I'm going to 
assume that's the policy he's using.  In FC5, the 'targeted' policy allows 
kadmind write access to /var/kerberos/krb5kdc/principal.*, but not to any 
other files in that directory.

Setting the boolean 'kadmind_disable_trans' disables the transition into 
'kadmind_t' when kadmind is run by the init script.  So, it stays in 
whatever less-restrictive context the init script was running in, and can 
write to whatever file it's having problems with.



I'd suggest looking at the kadmind log and/or attaching strace to the 
running strace to see what file it's trying to access that is prohibited by 
policy.  Then adjust the policy to correct the problem.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kadmin.local works but kadmin doesn't. kpasswd 'insufficient access to lock data base'

[Jeffrey Hutzelman]

On Tuesday, June 13, 2006 06:40:56 PM +0200 Jan Iven [EMAIL PROTECTED] 
wrote:

 On Tue, 2006-06-13 at 11:17 -0400, Jeffrey Hutzelman wrote:
 ..
 I'd suggest looking at the kadmind log and/or attaching strace to the
 running strace to see what file it's trying to access that is prohibited
 by  policy.  Then adjust the policy to correct the problem.

 (btw, adjusting the policy is best done via bugzilla.redhat.com)

 In addition to the above, you may want to check /var/log/messages for
 entries like avc:  denied:   - all SELinux policy violations
 should get logged either there or in /var/log/audit/audit.log.

Not in every case.  I no longer have the policy data in front of me, but if 
I recall correctly, the policy explicitly suppresses auditing of failed 
attempts by kadmind to write to files in /var/kerberos/krb5kdc.  Similarly, 
failed attempts to write to the krb5.conf file are generally not audited, 
because the config library tests the file for writability, and whoever was 
writing the policy apparently decided that made it too chatty.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Understanding kvno better

[Jeffrey Hutzelman]

On Saturday, June 10, 2006 11:13:59 AM +0530 Srinivas Cheruku 
[EMAIL PROTECTED] wrote:

 Hi All,

 I understand that we need to change Kerberos keys at regular intervals,
 since it is not recommended to use the same keys for a long amount of
 time. When we change keys the kvno is incremented and the old keys are
 also stored in the Kerberos user repository.  Can anyone give me a
 scenario where these old keys are used?

 Also, I want a better understanding of kvno and keys usage in the below
 scenario.

 I have a key extracted in my key table file on the server say with kvno
 3. The client has got a service ticket with kvno 3. Then, i will change
 the key and extract the key into the key table file, which will be with
 kvno 4. Now, i will be having two keys with kvno 3 and kvno 4 in the key
 table file on the server.
 Since, the client had already got the service ticket with kvno 3, and the
 latest key in key table file is with kvno 4, what should happen if he
 tries to access the service?  Should the service ticket with kvno 3 be
 accepted by the server?  Or it should give an error, since the latest key
 in the key table file is with kvno 4?

Yes, the service will continue to accept tickets issued with kvno 3. 
However, since the KDC always issues tickets with the latest key version in 
the KDB, no new tickets will be issued with the version 3 key.  Eventually 
all outstanding tickets with that key will have expired, and then you can 
remove the old key from the keytab.  The result is that you've effected a 
key change without disrupting service.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC

[Jeffrey Hutzelman]

On Tuesday, May 16, 2006 05:32:45 PM -0400 Jeff Blaine 
[EMAIL PROTECTED] wrote:

 I guess this is what I want:

 http://www.ietf.org/internet-drafts/draft-zhu-kerb-enctype-nego-04.txt

Actually, this doesn't help with your problem.  The mechanism described in 
that document allows a client and server to negotiate use of an enctype for 
communications with each other even when that enctype is not supported by 
the KDC.

The problem you're having is that the KDC believes your service supports 
the des3-hmac-sha1 enctype, and so encrypts service tickets using that 
enctype.  By design, there is nothing a client can do to influence the 
enctype used by the KDC to communicate with a service.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC

[Jeffrey Hutzelman]

On Tuesday, May 16, 2006 06:40:29 PM -0400 Jeff Blaine 
[EMAIL PROTECTED] wrote:

 Yes, MIT k5 1.4.3

 The only Solaris piece I ever expect to use is pam_krb5.so

 I've yet to touch/test Linux + K5, but it will be promptly
 after I find most of the hiccups with Solaris + MIT for
 now.  Then it's on to Cyrus IMAP integration and other
 fun stuff.

 Maybe I'm just sore about it, but perhaps something should
 be mentioned about this in the docs?  I can't really wrap
 my head around how this bit me and there wasn't a pile of
 of mailing list archive chatter by other people being
 bitten (when I searched before posting...).  That is, I
 don't see that I am doing anything rare here.  I'm trying
 to use MIT K5 as a KDC in a homogenous environment.  Out
 of the box, I got bit the first time I touched anything
 that didn't come from MIT.  If nobody finds that bad,
 so be it -- I'm not going to drag it out further.

The problem is not that you touched something that didn't come from MIT.

The problem is that you have software that is old, and doesn't support as 
many enctypes as newer software.  When you added an entry for that service 
to the Kerberos database, you gave it keys for enctypes the server software 
doesn't actually support.  Neither kadmin nor the KDC have any way of 
knowing this, other than you telling it.

An easy approach that solves this problem most of the time is to make sure 
that the tools you use to register a service in the Kerberos database are 
from the same software distribution as the service itself.  That way, 
they'll support the same set of enctypes and no one will get confused.

Unfortunately, this doesn't work all the time, for several reasons.  Nico 
alluded to an issue with Solaris 9's kadmin which requires that the KDC go 
to some effort to recognize that particular client and do the right thing. 


More generally, the kadmin protocol is not standardized, so there is no 
guarantee that any client will work if it didn't come from your KDC vendor. 
That's something I hope to see change, eventually, but that depends a lot 
on the availability and willingness of people to do the work to define a 
standard admin protocol.  In the meantime, recent versions of Solaris and 
MIT kadmin interoperate, but only because those parties have gone to some 
effort to make it so.

And of course, life gets fun when you have multiple software versions that 
will share a service key  For example, if you plan to use Sun's pam_krb5 
and also run some other telnetd or sshd on the same machine, you need to 
make sure the host principal only has keys of types supported by all of 
those services.  To some extent, this becomes a matter of understanding 
exactly what's going on, and going to some effort to get it right.  It'd be 
nice for it to all Just Work(tm), but in this case it turns out to be 
tricky to get all the edge cases right.


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA



 Here's a bug, too :)

kadmin.local:  ktadd -e des-cbc-crc host/noodle.foo.com
ktadd: Invalid argument while parsing keysalts de

Well, I can't speak for MIT, but I seem to recall that at least at one 
time, the error reporting in this case had some problems.


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Simple question

[Jeffrey Hutzelman]

On Saturday, May 13, 2006 10:29:38 AM -0700 Vasken Houdoverdov 
[EMAIL PROTECTED] wrote:

 I am very interested in the Kerberos authentication protocol, and was
 simply wondering whether I needed special permission to post a quick
 overview of the protocol on my site, and link to your official MIT page.


The Kerberos protocol is the subject of ongoing standards work within the 
IETF.  The current version of the protocol is specified by RFC's 3961, 
3962, and 4120.  These are available from http://www.rfc-editor.org/, and 
verbatim copies can be freely redistributed (see the copyright notice 
included with each document for more information on redistribution of 
RFC's).

You don't need special permission from anyone to create and distribute an 
overview written in your own words.  However, I would recommend spending a 
few minutes with Google first; chances are pretty good that someone else 
has already written the sort of overview you need.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Presence/absence of the keytab

[Jeffrey Hutzelman]

On Friday, May 05, 2006 09:17:34 PM -0700 Russ Allbery [EMAIL PROTECTED] 
wrote:

 One difficulty is that if the authentication is not
 being done as root, the PAM module needs something other than the host
 keytab to use for verification

... or a setuid-0 helper program.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kinit cannot resolve network address

[Jeffrey Hutzelman]

On Tuesday, May 09, 2006 03:49:35 PM -0400 Gwen Parker 
[EMAIL PROTECTED] wrote:

 [libdefaults]
 default_realm = dcri.duke.net


 [realms]
 dcri.duke.net = {
#   kdc = vmsodium.dcri.duke.net
 kdc = 10.0.101.65
 }

Kerberos realm names are case-sensitive.  dcri.duke.net and 
DCRI.DUKE.NET are not the same realm name.  The problem here is that you 
are trying to get tickets for [EMAIL PROTECTED], and since there is no 
entry in your krb5.conf for that realm, the library tries to use the DNS to 
find a KDC for that realm.  You haven't indicated what Kerberos you're 
using or how new it is, but the most likely scenario is that it's looking 
for SRV records for _kerberos._tcp.dcri.duke.net and/or 
_kerberos._udp.dcri.duke.net, possibly followed by falling back to the 
traditional KDC hostname of kerberos.dcri.duke.net.  If it can't find any 
of these, it fails.

The solution is to fix your krb5.conf to use the correct, uppercase realm 
name.



 [domain_realms]
 .kerberos.server = dcri.duke.net

I don't think this does what you think.  The line above says that any host 
whose name ends in .kerberos.server belongs to the dcri.duke.net domain. 
Unless you have hosts whose names end in .kerberos.server, which seems 
rather unlikely, this line is doing nothing useful for you.  Assuming that 
things in both dcri.duke.edu and dcri.duke.net belong to the DCRI.DUKE.NET 
realm, you want lines like these:

.dcri.duke.edu = DCRI.DUKE.NET
.dcri.duke.net = DCRI.DUKE.NET
dcri.duke.edu = DCRI.DUKE.NET
dcri.duke.net = DCRI.DUKE.NET

(the last two lines handle the two machines whose names _are_ dcri.duke.edu 
and dcri.duke.net, rather than being below those domains.  If no such 
machines exist, you don't need those lines).


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Linux : krb5 and pam

[Jeffrey Hutzelman]

On Tuesday, April 11, 2006 08:40:10 PM +0200 Sensei [EMAIL PROTECTED] 
wrote:

 Good. One thing I noticed on many clients here is that an ntpdate at
 boot solution is not good, since it can produce large time drifts if
 you don't reboot the clients often. A cron job was my solution.

Note that neither ntpdate-at-boot nor a cron job that runs ntpdate once in 
a while really count as running NTP.  A real NTP client needs to be 
running continuously, not just for a few seconds once in a while.  Over 
time it will establish an ideal clock which closely tracks the upstream NTP 
servers.  It will then correct the system clock by slowly adjusting its 
rate, ultimately leaving it running at something resembling the correct 
rate.  Just running ntpdate cannot do this -- it's not running long enough 
to get an idea of how far off-frequency the system clock is.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Monday, April 03, 2006 11:11:14 AM -0500 Nicolas Williams 
[EMAIL PROTECTED] wrote:

 Let's uplevel a bit.

 To me PAGs provide a useful distinction between processes in some sort
 of session, sharing some common characteristics, one that is better than
 environment variables in that it is easily (cheaply) observable from the
 IPC peers.

 PAGs have, for me, at least these uses:

  - As an Identity Selection Problem tool.

Yes.

  - As a link from cred_t to user-land that can be used to extend
cred_t.

Yes.

  - As a better point for tracking extant references to network
authentication credentials than UIDs.

It's unclear to me what you mean here.



 PAGs, like group memberships, do not, IMO, make a good access control on
 process tracing, and they are orthogonal to [local] filesystem access
 controls.  It would be rather surprising if one could not trace/debug
 one's processes from different login sessions.

It would not be surprising if that's what you were expecting.  But let's 
leave the issue of paranoid people aside for a moment, on concentrate on 
PAG's as an identity selection mechanism.  You're right; that's essentially 
how they are used in AFS today, though in a roundabout way.  Essentially, 
we use PAG's to separate management and use of credentials between 
sessions.  So a user can have multiple sessions with different PAG's, and 
they don't interfere with each other.  He can create a new PAG and set 
credentials for a different identity, and processes in the new PAG get the 
new identity while processes in the old PAG get the old one.

Now, the issue is that when you're talking about a caching distributed 
filesystem, your identity affects not only what credentials are used to 
establish connections to fileservers on your behalf, but also what you are 
allowed to do with cached data and connections.  For example...

The first time I try to read a file from a given server, the AFS client 
will establish a connection to the fileserver on my behalf, using my 
credentials.  Now, established connections are not expensive, but 
establishing them is, so the client caches open connections.  The next time 
I try to access a file on that server, it uses my cached connection, even 
if the access is from a different process.  However, if I access a file on 
that server from a different PAG, a new connection must be established, 
because the new PAG might have different credentials (or none at all).  If 
the client fails to separate connections by PAG in this fashion, then it 
becomes impossible to use PAG's for identity selection wrt the filesystem, 
because you can't be assured that file accesses will actually happen with 
the credentials you selected.

In addition, the cache manager has to cache access rights associated with 
files, so that it can cache my private files without giving you access to 
them, but still keep only one copy of files to which we both have access 
(this is particularly important for consistency if we both have _write_ 
access).  Like cached connections, cached access rights data needs to be 
indexed by PAG, not by UID; otherwise processes in a new PAG get access to 
files they shouldn't, or don't get access to files they should, and 
identity selection breaks.


Now, the thing that makes PAG's more than just identity selection is that 
you can't arbitrarily select a PAG -- you can use the one you have, or ask 
for a new (empty) one, but you can't pick up one arbitrarily and use it. 
Now, I know this has no real security value as long as it is trivial to 
cross PAG boundaries, but the people who are really paranoid will do 
something about it, perhaps by disabling tracing altogether (along with 
dtrace, and the ability to load kernel modules or touch kernel memory in 
any way, etc, etc, etc).

Interestinly, while PAG's don't directly provide process group separate, it 
occurs to me that given the ability for in-kernel code to determine a 
process's PAG, they could be used to _implement_ stronger session 
separation.  I don't know enough about the internals of Solaris, but I bet 
I could write a security module for Linux that did exactly this, using AFS 
PAG's.

But again, process group separation isn't really the point.
The point, for AFS, is making identity selection work.

-- Jeff


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Monday, April 03, 2006 02:01:21 PM -0500 Nicolas Williams 
[EMAIL PROTECTED] wrote:

 On Mon, Apr 03, 2006 at 02:27:36PM -0400, Jeffrey Hutzelman wrote:
  Now, the issue is that when you're talking about a caching distributed
  filesystem, your identity affects not only what credentials are used
  to establish connections to fileservers on your behalf, but also what
  you are  allowed to do with cached data and connections.  For
  example...
 
  Yes, clearly, but this doesn't make PAGs a process group separation
  feature *locally*.  On the wire your PAGs look as though they were
  different identities; locally they are not.

 Sure.  But it turns out to be incredibly useful to have weak
 separation,  in which you have to go to some effort to use an identity
 other than the  one associated with your own PAG.  When you involve
 human users or complex  software build processes, the principle of least
 privilege becomes fairly  important.

 I won't insist on having it both ways, and I wish you didn't either :)

 Since you've agreed that PAGs are not a session separation feature I'll
 just put you firmly in that column and ignore any further protestations
 that PAGs are a form of weak separation ;) :]

Fine.  It's really just about making identity selection work in a sane way. 
The idea is that if I start a new PAG, and get reduced or no credentials in 
that PAG, then ordinary file accesses actually fail when they're supposed 
to, rather than randomly succeeded.


  If you have multi-app PAG's, then it gets harder.

 How?  A little bit of IPC to talk to the right daemon that keeps the
 PAG-network-authentication-credential association doesn't seem hard
 to me...

It gets harder (a little) because I have to actually look up the 
association.  That's not such a big deal, but...



 I just
 don't want it to be so hard that I have to do at least one upcall to
 user-mode for every vnode or file op on a file in AFS.

 Oh no, not for every vnode or file op -- for every authentication
 attempt.  Surely AFS does not do an AP exchange for every vnode or file
 op, right?  Right?!

 Please tell me that it doesn't...  If not I may have to laugh at AFS :)

No, of course not.  Actually, that's part of my point.  We avoid doing that 
by caching established connections and indexing them by PAG, and we avoid 
_using_ even the cached connection on every op by also caching metadata, 
file contents, and access rights.  But if mapping the in-kernel PAG to the 
identifier AFS actually uses requires an upcall, then I have to do the 
upcall on every vnode and file op, because that's pretty much how often I 
have to examine cached access rights (actually, it's not quite _that_ bad, 
but it's close).

I'm beginning to think that maybe there is some unstated assumption here, 
and we are talking past each other.  In your user-mode multi-app PAG world, 
what would you have me do to find the cached access rights that apply to a 
process?  Maybe your answer to this will uncover the disconnect.

 Yes, you could do that.  Those wouldn't be the same semantics as AFS,
 but  that's not necessarily a problem.  It _would_ be very similar to
 the  semantics of Kerberos file ccaches, which can also be useful.

 Since you agree that PAGs are not a session separation feature I don't
 see how the semantics of this join PAGs I own feature would be
 incompatible with the semantics of AFS PAGs, but an extension.

It's complicated, in part because different people have different 
expectations.  Step out of the world of perfect security for a moment, and 
consider the real world.  In the real world, there are people who assume 
that because we explicitly don't provide an interface for PAG-joining, you 
can't do it.  Some of those people are blissfully unaware that there are 
ways to do it anyway.  Others know full well what they're getting into, and 
consider it a problem to eventually work around.

Personally, I happen to think that being able to join your own existing 
PAG's would be fine.  But I _know_ there are AFS-using sites out there that 
feel differently.



 I should correct myself here -- the right way to implement join PAGs
 one owns in the scheme I've proposed is to find the associations of the
 PAG you want to join, join new PAG instead, and then establish all those
 associations for the new PAG.  (To keep continuity I'd make associations
 to PID before joining a new PAG -- make before break.)

Hm, so you don't get to arbitrarily change your PAG, but you do get to set 
existing associations.  That's interesting, because it could potentially 
allow each application to decide whether its ID's can be joined.  That 
might well satisfy the people who want to use PAG's for process separation.




 Well, good luck.  I think one should be rigorous, not haphazard in
 designing a kernel-level extensible authorization scheme.  I've not
 looked at these hooks in Linux, so I'll

Re: Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Monday, April 03, 2006 02:08:46 PM -0500 Nicolas Williams 
[EMAIL PROTECTED] wrote:

 File descriptors in Solaris already retain a reference to the cred_t
 used to open the file.  So UID or PAG is not relevant here.  Neither
 is processes with that UID or PAG.  What is relevant is references to
 that UID or PAG from cred_t instances.

Ah, yes.  If open files reference the cred_t, and that has a reference to 
the credentials (directly or indirectly), then you're fine.


 So does Solaris.  I believe one must in order to support various
 standard behaviours (e.g., file descriptor passing over IPC +
 distributed filesystems [NFS, AFS, CIFS, whatever]).

Well, you need to do full refcounting for that, which we don't.  In AFS, a 
reference is held on a credential while it is actually being used to 
establish a connection, but not otherwise.  It's all mark-and-sweep, 
because today's operating systems don't provide the sort of zero-reference 
notification you're talking about.

 Right.  But I'd like the OS to provide a fall to zero refcount
 facility for either cred_t instances referencing some UID or cred_t
 instances referencing some PAG.

Why either and not both?  For that matter, you could also do it for 
references to GID's, though I don't see any particular use for that.

UID's and PAG's are very nearly orthogonal.  In particular, it is _not_ the 
case that all processes in the same PAG have the same UID - PAG membership 
survives things like starting SUID binaries, which we consider a feature 
(after all, it's part of the same session).

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Friday, March 31, 2006 03:44:57 PM -0600 Douglas E. Engert 
[EMAIL PROTECTED] wrote:



 Ken Hornstein wrote:

 Why store tickets in the kernel, what's the point?  Presumably you'd not
 want anything other than TGTs in the kernel, so where do you cache
 service tickets?  Or do you want all tickets in the kernel?  (Presumably
 in pageable, accounted memory...).


 Well, actually, I'd rather have the whole ticket cache in the kernel.
 I have personally seen attacks on the current file cache; right now we
 don't use a file cache, but the scheme we do use has some issues.  One
 thing we were planning on doing was use the Linux kernel keyrings
 if/when they become suitable ... but of course those would only work
 under Linux.  I know that putting the ticket cache in the kernel isn't
 100% protection, but I think it's the best we can probably do on a
 multi-user Unix system.  The caches I see are tiny,

 Unless the the KDC is Windows, and the tickets have PACs.  A tgt is 2000
 bytes, but could go as high as 14k.

Even 14k is still tiny.
Charge the space against the user, or the PAG, like Linux keyrings do.
In fact, now that I think about it, a similar approach can be used for 
kernel PAG-appid mappings.  Simply impose a limit on the number of such 
mappings which can be associated with any given PAG.  Each mapping is 
nothing more than an application type and application ID, both of which are 
integers.  You need an mapping between application type names and their 
ID's, but _that_ can be managed in user space.  And if you find you need 
more apps per PAG, then change the system parameter - it doesn't even have 
to require a reboot, depending on how you allocate the storage.

But the issue of ticket storage is tangential to the question of PAG 
management.  In fact, as far as PAG management is concerned, ccaches are 
just another application, whether their contents are kept in the kernel or 
in some user-mode daemon or whatever.

Even if you store tickets and other credentials in user land, there are 
still kernel-mode applications like filesystem drivers that need to know 
not only what PAG a process is in, but also which PAG's map to the same 
application-level identifier.  If a user creates a new PAG to break the 
association with a single application (say, Kerberos ccaches), then it is 
_not_ OK for other applications to be forced to re-fetch cached data.




-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams 
[EMAIL PROTECTED] wrote:

 On Fri, Mar 31, 2006 at 04:56:27PM -0500, Jeffrey Hutzelman wrote:
 On Friday, March 31, 2006 03:44:57 PM -0600 Douglas E. Engert
 [EMAIL PROTECTED] wrote:
   The caches I see are tiny,
 
  Unless the the KDC is Windows, and the tickets have PACs.  A tgt is
  2000 bytes, but could go as high as 14k.

 Even 14k is still tiny.

 If you're using Kerberos V for authentication in remote administration
 protocols and have, say, 30,000 hosts to look after

Then you're atypical, and can't use an in-kernel ccache, because the kernel 
is going to limit your ccache use to, say, one page.


 Sorry, tickets don't belong in the kernel.  Even with pageable kernel
 memory, and proper accounting.

So, where do you store them now?  /tmp ?



 Even if you store tickets and other credentials in user land, there are
 still kernel-mode applications like filesystem drivers that need to know
 not only what PAG a process is in, but also which PAG's map to the same
 application-level identifier.  If a user creates a new PAG to break the
 association with a single application (say, Kerberos ccaches), then it
 is  _not_ OK for other applications to be forced to re-fetch cached data.

 Ok, this is such an argument.  I'd like to have some idea of what
 kernel-land applications actually would need PAG facilities directly, as
 opposed to indirectly through upcalling to daemons like gssd.

 NFS clients don't need direct PAG access -- see gssd.

Does your NFS client do caching?  How does it decide when it is OK to allow 
a process to access cached data?  I suppose the answer could be based on 
the uid, gid, and groups, but UID/GID namespaces might be different 
between client and server.


 NFS servers don't either -- same thing.

I don't think NFS servers need to know anything about PAG's, except that 
each nfsd thread may need to be in its own PAG, if your nfsd communicates 
credentials to exported filesystems by changing the credentials of the 
server process, as Linux does.


 What about CIFS clients and servers?

I haven't a clue.

 AFS?

AFS servers run in user mode, where a fileserver belongs.  Talk about 
extraneous complexity in the kernel!

AFS clients cache both file contents and metadata.  When a process wants to 
access a file which is in the cache, the cache mangager determines whether 
the request is permitted by examining cached information about what access 
rights that process has on that file.  This information is indexed by PAG, 
so different processes in the same PAG share the same cached access rights. 
Without this, the cache manager would have to make an RPC for _every_ file 
access to determine whether the access should be permitted, which would 
sort of defeat the purpose of caching.

Similarly, connections to fileservers are shared among processes with the 
same credentials.  If a request does require going to the server (for 
example, reading data not in the cache), then we need to find a cached 
connection with the right credentials, if there is one, and again, cached 
connections are indexed by PAG.


 What about KINK?  Would you implement KINK in the kernel?  Or in
 user-land?  IKE in Solaris is implemented in user-land, why should KINK
 not be implemented in the same fashion?

I assume you would do KINK in user-land, same as with IKE.


 What about kernel-land TLS (RFC2712?  Ick) accelerators, do they need
 direct PAG access, or can they afford to upcall to resolve the location
 of relevant certs/private keys/tokens?

I assume a kernel-land TLs accelerator would depend on the user-mode 
process for the initial handshake, and be handed the relevant keys.  So, it 
wouldn't need long-term credentials, but it _would_ need the keys used to 
protect the connection.  However, that data is per-channel, not per-PAG, 
and so not relevant to the current discussion.

 What other kernel-land applications can you think of or imagine that
 fundamentally needs direct multi-application PAG support in the kernel
 and can't upcall?

- Encrypted (local) filesystems
- Kernel-mode ticket caches
- iscsi?

Maybe PAG-based authorization for things like X server or ssh agent 
connections.  In reality, I bet those can be handled in user mode, though 
an application like that would require some trusted entity for allocating 
ID's which are unique across the system.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams 
[EMAIL PROTECTED] wrote:

 On Fri, Mar 31, 2006 at 06:17:53PM -0500, Jeffrey Hutzelman wrote:
 On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams
 [EMAIL PROTECTED] wrote:
  What other kernel-land applications can you think of or imagine that
  fundamentally needs direct multi-application PAG support in the kernel
  and can't upcall?

 - Encrypted (local) filesystems

 Orthogonal to PAGs.  The kernel needs to know keys for encrypting
 objects/filesystems, but access controls are as normal (ACLs, mode bits).

 We're planning on per-filesystem (think ZFS) keys, too, so there's no
 per-session keys to worry about.

I was thinking in terms of different users' files being encrypted with 
different keys, which would require the kernel to track keys on 
approximately a per-PAG basis.


 - Kernel-mode ticket caches

 Circular logic.

No, it's not.  We already established that ticket caches are separate from 
PAG management.  If you want kernel-mode ticket caches (and some of us do), 
then you need kernel-mode access to PAG-appid mappings.


 Maybe PAG-based authorization for things like X server or ssh agent
 connections.  In reality, I bet those can be handled in user mode,
 though  an application like that would require some trusted entity for
 allocating  ID's which are unique across the system.

 Authorization by PAG requires making changes to lots of things in the
 kernel (e.g., two procs w/ equal cred_t's but for different PAGs should
 not be allowed to trace each other w/o special privilege).

Well, yes, and in the long run, you'd want that even if there were no 
kernel-mode users of PAG's.


But I considered the filesystem-driver applications critical.  An upcall 
for every file access is just not going to be acceptable performance-wise.




Really, I think the introduction of a new process to keep track of 
PAG-appid mappings is just silly.  The number of PAG application types in 
the system is likely to be quite small, and the mappings themselves are 
small as well.  Why not just store them in the PAG structure and be done 
with it?

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Friday, March 31, 2006 06:27:22 PM -0600 Nicolas Williams 
[EMAIL PROTECTED] wrote:

 On Fri, Mar 31, 2006 at 07:07:43PM -0500, Jeffrey Hutzelman wrote:
 On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams
 [EMAIL PROTECTED] wrote:

  - Encrypted (local) filesystems
 
  Orthogonal to PAGs.  The kernel needs to know keys for encrypting
  objects/filesystems, but access controls are as normal (ACLs, mode
  bits).
 
  We're planning on per-filesystem (think ZFS) keys, too, so there's no
  per-session keys to worry about.

 I was thinking in terms of different users' files being encrypted with
 different keys, which would require the kernel to track keys on
 approximately a per-PAG basis.

 PAGs are not persistent across reboots, so, no, we can't do that.


Huh?  I wasn't suggesting using PAG's to name keys.  When a user runs 
whatever command gives the kernel the key for his files, that key should be 
associated with his PAG, so that processes which are part of his current 
session have access to the files, and other processes do not.

In other words, this should work just like other filesystems.



  - Kernel-mode ticket caches
 
  Circular logic.

 No, it's not.  We already established that ticket caches are separate
 from  PAG management.  If you want kernel-mode ticket caches (and some
 of us do),  then you need kernel-mode access to PAG-appid mappings.

 Kernel-mode ticket caches is not an application.  An application is
 something that would use them.

Kernel-mode ticket caches _is_ an application of PAG's.

There may be any number of applications of kernel-mode ticket caches; there 
certainly seem to be any number of people who want to deploy them.


 Right, but in the AFS model PAGs don't provide for access control
 (though user-mode applications could use PAGs for access control given
 APIs like door_cred(3DOOR) and getpeerucred(3C)).  I think that is a
 useful simplification.  I'd like to keep it.

In the AFS model, we more or less make the assumption that impersonating 
another PAG is hard.  Not impossible, certainly, but hard enough that doing 
it requires making finding another process that has the credentials you 
want and tracing it.  That means that PAG's are an effective means of 
limiting access to credentials in a wide variety of scenarios.  It means I 
don't have to have full access to destroy the universe in every window in 
order to perform an administrative operation in one.  It means I can 
compile software in such a way that I _know_ the build process isn't 
writing to the source area, because it doesn't have the credentials to do 
so.  And so on.

I think we agree that PAG's should not be used as a general replacement for 
UID's in all access-control situations, and don't need to be able to be 
used that way.  I'm not suggesting that kernel-supported IPC mechanisms 
gain PAG-based access control facilities.  But I do expect that various 
user-mode applications, possibly including gssd, will use them to determine 
exactly who is allowed access to what.


 I don't think you want per-file keys.  Do you really want to interact
 for every file you open?

Of course not.  Which is why the kernel needs to cache the keys.

 Or every directory?  (Never mind POSIX hard
 links.)  Per-filesystem is enough, and PAM modules can log you into
 your filesystems.

Yes, but where is it going to put the key?  Once I've logged in, how does 
the kernel distinguish between my processes, which are allowed to access 
files using the key I typed, and yours, which are not?  The answer is that 
they're in different PAG's, and the kernel associates the key I typed with 
my PAG and not with yours.

But in a multi-application PAG world, _no_ application can directly use the 
real PAG ID as an identifier, because it changes too much.  Instead they 
need an application-specific identifier.  That applies to encrypted 
filesystems, to AFS, and, I suspect, to NFS as well, though you might not 
yet recognize that.



 I'd rather keep the kernel-side of things simple.  I do care not to
 preclude interesting applications, but so far I've seen no real or
 imagined application that needs more than simple PAGs kernel-side.

Simple PAG's are fine, if you're only going to do simple PAG's.  But as 
soon as you do multi-application PAG's where changing any one application's 
appid means creating a new underlying PAG with the other applications' 
mappings shared, then you run into problems if there is _any_ application 
that is unaware of the mapping mechanism, or unable to use it.



 The encrypted filesystem argument holds no water, IMO.  Ken H. agrees
 that all other kernel-side applications can upcall to do PAG-stuff
 resolution if need be.  What's left?

Ken is wrong.  The access rights cache is consulted on every file access, 
and requires knowing AFS's identifier for the user's credentials, because 
that identifier is necessarily used to index the access cache.  So, we must 
be able to answer the question

Re: Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Wednesday, March 29, 2006 04:12:12 PM -0600 Nicolas Williams 
[EMAIL PROTECTED] wrote:

 On Wed, Mar 29, 2006 at 03:53:33PM -0600, Douglas E. Engert wrote:


 Nicolas Williams wrote:

  On Wed, Mar 29, 2006 at 03:24:24PM -0600, Will Fiveash wrote:
 
  On Wed, Mar 29, 2006 at 10:02:54AM -0600, Douglas E. Engert wrote:
 
  If you really wanted to get this to work better, add a parameter
  on to your pam_krb5 to support this, and have it set the KRB5CCNAME.
 
  Suggestion noted.
 
 
  Sure, but not enough -- the kernel-land kgssapi/krb5 code and gssd
  can't use KRB5CCNAME to find a Secure NFS client process' ccache.
 
  We really need a concept like the AFS PAG...

 Can you do anything like what DCE/DFS used to do? In response to a note
 on the OpenAFS mailing list commenting on the disjoint use of PAGS and
 ticket caches I pointed out DCE had a middle ground approach to keep the
 PAGs and ticket caches in sync.

 The last two supplementary groups add up to a PAG thing?  That won't
 go over well :)

Actually, that's what AFS does, except it's the _first_ two groups; we 
shift the others out of the way as needed.  It works reasonably well, 
provided you restrict your GID space to not otherwise use the groups AFS 
uses, and restrict your UID space to not use UID's that would conflict with 
PAG ID's (this wasn't a problem in the days of 16-bit UID's, but it is 
today).


 We need a first-class PAG-like thing.

Please!  Be the first OS vendor on your block to provide them!


 The audit session ID comes close to being that, but falls short (for
 one, it's 32 bits, so too small, but also audit isn't on by default, and
 the model is that you don't change a process' audit session ID ever once
 set).  Process contracts also come close but fall short in that a
 process can be in only one process contract and SMF use of process
 contracts would conflict with AFS/DCE-style use of PAGs.  We could build
 PAGs as extensions to process contracts, or as yet another process
 grouping mechanism (which is how PAGs look in AFS).

Right; AFS PAG's are just another kind of process group.  They happen to 
have exactly the same inheritance semantics as supplemental groups, except 
that setgroups() doesn't touch them, and any process can ask for a new one. 
(In addition, AFS let's you get a new PAG and ask for your parent to be 
moved into it with you; this lets 'newpag' be a program users can call from 
the shell.  But this behavior is considered an evil aberration that we wish 
would go away).




Anyway, what Doug is talking about is essentially keeping credentials in a 
file whose name can be derived from the PAG ID.  But there are various 
potential problems with this, among them the fact that users may not _want_ 
their credentials to be used implicitly for file accesses.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Thursday, March 30, 2006 06:08:10 PM -0600 Nicolas Williams 
[EMAIL PROTECTED] wrote:

 On Thu, Mar 30, 2006 at 06:58:39PM -0500, Jeffrey Hutzelman wrote:
 On Wednesday, March 29, 2006 04:12:12 PM -0600 Nicolas Williams wrote:
  The last two supplementary groups add up to a PAG thing?  That won't
  go over well :)

 Actually, that's what AFS does, except it's the _first_ two groups; we
 shift the others out of the way as needed.  It works reasonably well,
 provided you restrict your GID space to not otherwise use the groups AFS
 uses, and restrict your UID space to not use UID's that would conflict
 with  PAG ID's (this wasn't a problem in the days of 16-bit UID's, but
 it is  today).

 Huh?  Why should UIDs not conflict with PAGs?  What am I missing?

Because AFS identifies credentials, cached connections, and cached access 
rights by a 32-bit number which is either a UID or a PAG.  So the 
namespaces for those need to not overlap.  AFS uses 0x4100.. 0x14FF 
for PAG's, leaving the rest of the 32-bit space for UID's.

  We need a first-class PAG-like thing.

 Please!  Be the first OS vendor on your block to provide them!

 Unfortunately it's a bit harder than that.

 I have lots of uses for PAGs besides tracking krb5 tix.  I don't want a
 PAG-like item per-such use.  I want a daemon (least priv and all that)
 that tracks PAG-{whatever} associations.  It has to be lightweight and
 not easily DoSed.  And this needs an API.  And it needs to allow you to
 create a new PAG while keeping all your old associations and breaking
 only the ones you want to break, which also means some access control
 (euid will do).

The last is very tricky.  To get it right, code has to not actually track a 
process's credentials (and associated cached stuff) directly by its PAG, 
but by a per-application identifier with a many-to-one mapping between 
PAG's and application identifiers.  Any application has to be able to add a 
mapping from an existing PAG to one of its identifiers, if one doesn't 
already exist.  And, applications need to be able to ask the question is 
this still in use?.  And the fun part - these things have to be possible 
not only from user mode but also from the kernel.

In any event, the API is easy.  The hard part is the _user_ interface...


  The audit session ID comes close to being that, but falls short (for
  one, it's 32 bits, so too small, but also audit isn't on by default,
  and the model is that you don't change a process' audit session ID
  ever once set).  Process contracts also come close but fall short in
  that a process can be in only one process contract and SMF use of
  process contracts would conflict with AFS/DCE-style use of PAGs.  We
  could build PAGs as extensions to process contracts, or as yet another
  process grouping mechanism (which is how PAGs look in AFS).

 Right; AFS PAG's are just another kind of process group.  They happen to
 have exactly the same inheritance semantics as supplemental groups,
 except  that setgroups() doesn't touch them, and any process can ask for
 a new one.  (In addition, AFS let's you get a new PAG and ask for your
 parent to be  moved into it with you; this lets 'newpag' be a program
 users can call from  the shell.  But this behavior is considered an evil
 aberration that we wish  would go away).

 In Solaris the way you'd do the change parent's PAG is through /proc
 (we really need a stable, public version of the libproc API, which makes
 /proc reall easy to use...).

 In fact, you can do the AFS hack today using /proc...

Not without privileges you can't.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KDC does not accept requests through loopback interface

[Jeffrey Hutzelman]

On Wednesday, February 22, 2006 04:08:33 PM -0800 Russ Allbery 
[EMAIL PROTECTED] wrote:

 avillarrealpouw [EMAIL PROTECTED] writes:

 I have been testing the Fedora distribution of Kerberos and tripped on a
 problem: after upgrading from Fedora core 3 to Fedora core 4 in my KDC
 the KDC stopped receiving requests for tickets through the loopback
 interface.

 This means that I cannot run kinit or kadmin from the KDC,

 Why?  Why don't kinit and kadmin use the same IP address as any other
 client when run from the KDC?

Presumably the krb5.conf names the KDC's by name, and on the KDC host, 
gethostbyname() of that name returns 127.0.0.1 due to the default RedHat 
behavior of including an entry in /etc/hosts that maps the local hostname 
to the loopback address.



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Oracle Advanced Security Option and Kerberos

[Jeffrey Hutzelman]

On Friday, February 24, 2006 10:15:32 AM -0600 Douglas E. Engert 
[EMAIL PROTECTED] wrote:

 I am looking for other Kerberos sites that use Oracle with or without the
 ASO who would like to see the ASO improved. I would also be interested to
 know if you have approached Oracle on improvements, and what was their
 response.

We've been using Oracle with ANO and Kerberos for some years now.
Like you, we'd like to see support for new enctypes, the version 4 fcache 
format, and a fix to the KRB5CCNAME parsing bug.

While we don't currently have any situations where we need non-identity 
principal-username mappings, as a security protocol designer I think this 
abstraction is an important one, and it is clearly missing from Oracle.  A 
principal name length limit of 30 characters is clearly too short; we have 
plenty of principal names over that limit.  Fortunately, most of them 
belong not to users but to services which will never talk to Oracle.

More generally, the failure of Oracle to keep portions of their Kerberos 
code even remotely up to date makes me wonder how well-maintained the rest 
of it is, and how committed Oracle is to maintianing this 
security-sensitive code.  I'm always a little nervous about closed 
security protocols and code which haven't been subject to outside review, 
particularly given the amount of snake oil out there.  But the lack of 
attention paid to this particular code really is worrisome.


I'll have to check with our DBA's to see if there are any open tickets on 
these items, or on other Kerberos-related issues.


-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Validating Users With Expired Passwords

[Jeffrey Hutzelman]

On Wednesday, January 18, 2006 06:37:44 AM -0800 [EMAIL PROTECTED] wrote:

 In a nutshell, I need to take a username and an expired password and
 see if that truely was the users' last pasword.

You haven't said what Kerberos server you're using, so I'll assume you're 
using either the MIT or Heimdal servers.  If the server in question is a 
Microsoft server, then parts of what I'm about to say my be significantly 
different...

Most servers keep separate last password change and last modified 
timestamps for each principal.  The former refers specifically to the 
principal changing its own password (not having it changed by an admin). 
If you want this information to be correct for auditing purposes, then you 
want to submit a password change request on the user's behalf, rather than 
verifying the old password and making a change on your own authority.

Conveniently, this approach is also generally easier -- you just collect 
the username, old password, and new password, and then attempt a password 
change just as if you were the user.  If the old password they gave was 
invalid, then the request will fail.

If for some reason you feel you need to validate the password yourself, 
then you will want to do it correctly.  That means not just getting a 
ticket, but getting a ticket for a service whose secret key you know, so 
that you can verify that the ticket is legitimate.  Without this step, an 
attacker can give you any random string as the old password, and then 
forge the response you get from the Kerberos server to make you think the 
password is valid.  Offhand, I don't know of a way to do this from Perl; 
maybe someone else here knows of a stable set of perl modules providing 
access to the Kerberos API.


 Once I'm able to
 validate the users' expired information, I already have a system in
 place that will change their password through a web-based form...  It's
 just the authentication with expired credentials that's killing.

This is likely because the KDC will not issue tickets to a principal with 
an expired password -- doing so would sort of defeat the purpose of having 
the password expire in the first place.  Once a password is expired, the 
KDC will only issue initial tickets for services which are flagged as 
password-changing services.


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Validating Users With Expired Passwords

[Jeffrey Hutzelman]

On Thursday, January 19, 2006 03:31:53 PM -0600 John Hascall 
[EMAIL PROTECTED] wrote:

 If you present a correct but expired password to Kerberos
 you will get a 'password expired' error, which is different
 from the 'password incorrect' error you get if the password
 is not correct (expired or not).

Careful here.  Kerberos error messages are not authenticated, so you'll 
also get this error if an attacker decides to trick you into letting him 
set someone's password by sending you a false error message.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Validating Users With Expired Passwords

[Jeffrey Hutzelman]

On Thursday, January 19, 2006 04:35:26 PM -0600 John Hascall 
[EMAIL PROTECTED] wrote:


 On Thursday, January 19, 2006 03:31:53 PM -0600 John Hascall
 [EMAIL PROTECTED] wrote:
  If you present a correct but expired password to Kerberos
  you will get a 'password expired' error, which is different
  from the 'password incorrect' error you get if the password
  is not correct (expired or not).

 Careful here.  Kerberos error messages are not authenticated, so you'll
 also get this error if an attacker decides to trick you into letting him
 set someone's password by sending you a false error message.

 True, but the correct password will be needed to use the change-password
 ticket later, so it seems at best they can dick you around a bit.

True, unless the plan later is to have an admin change the password...

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Importing data?

[Jeffrey Hutzelman]

On Thursday, January 12, 2006 01:42:54 PM +0100 Bjorn Tore Sund 
[EMAIL PROTECTED] wrote:

 University of Bergen is setting up a unix/linux Kerberos realm to handle
 logons on our unix/linux clients and servers (about 1500).  Our problem
 is that all 30.000 users needs principals on the KDC, and we'd rather
 not have to run all of them through having to type their password
 somewhere.

 They're all in AD (and in NIS), can anyone advice as to a good path to
 duplicate data over, including passwords?  LDAP export and import and
 then using Heimdal's support for having an LDAP backend is the next
 thing I'll try - any better ideas out there?  Google gives me nothing
 which doesn't involve having to reenter all user passwords, but we
 can't be the first large setup to have this issue?

Well, the problem is that entries in NIS or in UNIX password files don't 
contain the password; they contain a one-way hash of the password.  Without 
some fairly time-expensive cryptographic attacks, you can't recover the 
actual password, which is needed to add keys to the Kerberos database.

When we first started using Kerberos many many years ago, we modified the 
login program so that when a user logged in who had no Kerberos prinicpal, 
he would be automatically registered.  Of course, this also required a 
special registration service and giving login some way to authenticate to 
it.

Since your users are in AD, you may have another option.  The Active 
Directory does know the users' actual passwords (except for any users who 
were imported from an NT4 domain and haven't changed their passwords 
since).  If you can extract the passwords from AD, you can build a tool 
which adds them to the Kerberos database.  However, I seem to recall that 
it is difficult-to-impossible to get AD to export password information. 
Perhaps someone who knows more on that topic will comment...

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KDC Hardware

[Jeffrey Hutzelman]

On Saturday, January 07, 2006 11:38:47 AM +0100 Turbo Fredriksson 
[EMAIL PROTECTED] wrote:

 Security? Nah, both need _extra ordinary security_ so it's easier to
 safegard ONE machine than two (* nr of slaves of course :).

On the contrary, depending on what you are using your LDAP directory for, 
it may not require any more security than any other application.  Even if 
this is not the case, traditional operational practice dictates extreme 
paranoia where KDC's are concerned, because of the massive impact of a 
compromise.

If your LDAP server is compromised, you reinstall the machine, restore the 
database from backups, and get on with life, just like for any other 
service.  Depending on what you store in the directory, it's possible the 
intruder obtained sensitive information, but that's also true of other 
services, such as a mail server.

Again, depending on what you store in the directory, it's possible that an 
intruder who gains the ability to modify the LDAP database has used that to 
gain access to other services.  Such things might be annoying to track down 
and fix, but they can be fixed.  Any changes the intruder made can be 
rolled back; any deleted data can be restored from backups, etc.


If a KDC is compromised, it becomes necessary to assume that the intruder 
has a complete copy of the Kerberos database, including the keys for every 
principal.  Recovering from such a compromise requires issuing new 
passwords to _every_ user and re-keying _every_ service -- and doing it in 
such a way that someone who knows the old keys does not discover the new 
ones.  Any service which has not been re-keyed is vulnerable to the 
attacker; since he knows the service's key, he can impersonate any user, 
EVEN IF THE KDC IS SHUT DOWN.  A similar problem applies in the reverse 
direction; an attacker can impersonate the KDC and any service to a user 
whose key he knows, EVEN IF THE REAL KDC IS SHUT DOWN.

This is such a massively bad situation that it is worth taking every effort 
to protect the Kerberos database from compromise.  Running other services 
on the same machine is simply not worth the potential pain.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KDC Hardware

[Jeffrey Hutzelman]

On Friday, January 06, 2006 12:37:51 PM +0100 Turbo Fredriksson 
[EMAIL PROTECTED] wrote:

 Quoting Jeffrey Hutzelman [EMAIL PROTECTED]:

 On Thursday, January 05, 2006 10:03:44 AM +0200 Amir Saad
 [EMAIL PROTECTED] wrote:

 i use Fedora 4, OpenLDAP and Kerberos instead of NIS
 what is the suitable hardware configuration for the KDC to support a
 network with 200 machines? thanks

 Whatever random piece of crap you have lying around will do just fine.

 Note though the 'random piece of crap' note is true when it comes
 to KERBEROS (that doesn't need ANYTHING regarding power/storage/speed)
 but not LDAP... That is a lot more demanding...

True.  The original question was about a KDC, not an LDAP server.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KDC Hardware

[Jeffrey Hutzelman]

On Thursday, January 05, 2006 06:53:27 PM + Garrett Wollman 
[EMAIL PROTECTED] wrote:

 In article
 [EMAIL PROTECTED],
 Amir Saad [EMAIL PROTECTED] wrote:
 i use Fedora 4, OpenLDAP and Kerberos instead of NIS
 what is the suitable hardware configuration for the KDC to support a
 network with 200 machines?

 You can't buy a server that small any more.

WRT54G?

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: krb5_init_context failed

[Jeffrey Hutzelman]

On Friday, December 30, 2005 06:12:48 PM -0500 Ken Raeburn 
[EMAIL PROTECTED] wrote:

 On Dec 30, 2005, at 10:39, Huub wrote:
 Hi,

 I've created a krb5.conf file but verify_krb5_conf says it fails:

 I'm not familiar with the program, but a man page I found on the web
 seems to indicate that it prints messages telling you what it thinks
 is wrong.  You mention that it fails, but you don't say how, what
 messages might've been printed, etc

I'll randomly guess that the problem is the presence of comments for which 
the '#' is not the first character on the line.  I don't know if this was 
fixed recently, but older versions of MIT Kerberos could not handle this.

-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: gss_acquire_cred() failed:

[Jeffrey Hutzelman]

On Wednesday, September 28, 2005 05:38:14 PM +0530 Nikhil Mulley 
[EMAIL PROTECTED] wrote:



can some one please respond..


This is a mailing list, not an IRC chat room.
You sent your initial message at 9:45 PM Pacific time, which is after 
midnight on the US east coast, and early morning in Europe.  None of the 
experts were awake.


Your next message came a few hours later, still in the middle of the night.

Your third message came a couple of hours after that.



It is entirely unreasonable to expect that in the space of a few hours, 
overnight, someone who recognizes your problem will read and respond.  It's 
also unreasonable, in my opinion, to ever repeatedly ask the same question 
or ask someone please respond on a public mailing list.  If someone had 
read your message who knew the answer to your question, they would have 
responded.




Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: time server

[Jeffrey Hutzelman]

On Wednesday, September 28, 2005 03:29:08 AM -0500 Gurganus, Brant L 
[EMAIL PROTECTED] wrote:



Time.rose-hulman.edu is a time server and ntpd will synchronize to it.
The time client in Leash does not recognize that as a time server
though.


I suggest you ignore the time-setting stuff in Leash, and instead run a 
proper NTP client.  Current versions of Windows ship with one, and come 
preconfigured to synchronize against either the domain controllers or a set 
of public time servers operated by Microsoft.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: GSS_ACCEPT_SECURITY_CONTEXT

[Jeffrey Hutzelman]

On Tuesday, September 27, 2005 10:11:56 AM -0500 Balakrishnan, Sivakumar 
[EMAIL PROTECTED] wrote:



I am trying to implement a custom Kerberos authentication for my IIS
application using an ISAPI filter.   I am expecting the
gss_accept_security_context tor return me AP-REP if I passed a input
token(contains AP-REQ) with mutual_authentication flag set in its
AP-options.  But in my program the gss_accept_security_context returns a
GSS-S-Complete but when I parse the output token it just contains the
Input principal and didn't contains a APP-REP.


It's unclear here whether the context token you're passing in is one you 
got from another GSSAPI, or one you constructed yourself.  The AP-REQ used 
by the Kerberos GSSAPI mechanism uses a special checksum which contains 
additional data used in negotiating the GSSAPI context (see RFC4121, 
section 4.1.1, or RFC1964 section 1.1.1).  Part of this data includes flag 
bits indicating which GSSAPI-level options were requested by the 
application.  In order for mutual authentication to happen, the 0x02 bit in 
these flags must be set.


At the GSSAPI level, the way to do this is to make sure that the 
mutual_req_flag (in C, GSS_C_MUTUAL_FLAG) is set in the call to 
GSS_Init_sec_context().


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos support in Thunderbird

[Jeffrey Hutzelman]

On Monday, September 12, 2005 15:13:27 + Jeffrey Altman 
[EMAIL PROTECTED] wrote:



This can end up causing some problems for end users.  It is entirely
possible for the GSSAPI authentication to succeed and yet the user
will be unable to access the mailbox they are attempting to reach
because the principal used is not the one which has authorization for
accessing the mailbox.


And yet, it is what nearly every Kerberized application in existance does, 
and it seems to work reasonably well.  I realize that you would like to see 
a better UI for client credential selection, but today, this is the best 
current practice.


That said, most mail software I've seen does allow the user to specify the 
authentication mechanism to use on a per-account basis.  That would seem to 
be appropriate here, as well.


-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Dump to slave fails; Password has expired while getting initial ticket

[Jeffrey Hutzelman]

On Sunday, September 04, 2005 09:21:21 + Yeechang Lee [EMAIL PROTECTED] 
wrote:




/usr/kerberos/sbin/kprop: Password has expired while getting
initial ticket


I believe the principal you're looking for is kprop/fqdn.of.master.kdc
You should probably arrange for it not to have a password expiration 
policy.  If you're really paranoid, you chould change it manually once in a 
while, but I don't think I know anyone _that_ paranoid.



On a separate note, when looking through the list of principals, I
noted a mysterious K/[EMAIL PROTECTED] I don't remember creating. Based on

Last modified: Thu Feb 24 21:04:42 PST 2005
([EMAIL PROTECTED])


That principal corresponds to the master key, which is used to encrypt keys 
stored in the database.  It's the same master key that you have to enter 
(or provide in a stash file) to get the KDC to start up.


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KDC failover

[Jeffrey Hutzelman]

On Tuesday, August 30, 2005 23:59:16 -0400 Jeff Aitken [EMAIL PROTECTED] 
wrote:



Assuming I've got that part right, here's the part that's got me
confused.  In step #2, the AS generates a session key that will be
used by the client during all future communication with the TGS;
i.e., this is the key with which the client will encrypt future
service ticket requests.  However, if the KDC that granted the TGT
to the client fails, and the client sends a service ticket request
to a different KDC, how does that second KDC validate the client?
Unless I'm missing something, the second KDC doesn't have a copy of
the session key that the client uses to encrypt the request, so he
shouldn't be able to decrypt it successfully.


The TGT is just like any other ticket; it contains information encrypted in 
the service's secret key, including a session key.  The TGS, then, is a 
single service potentially distributed over multiple machines (KDC's). 
Each machine providing that service has a copy of the service key, and thus 
can decrypt the ticket, which is provided by the client with every request.


Except for a short-lived replay cache, the KDC itself is essentially 
stateless.  It doesn't remember anything about tickets it has issued.


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: windows browsers send ntlm instead of kerberos tokens

[Jeffrey Hutzelman]

On Monday, August 29, 2005 10:28:35 -0400 Wyllys Ingersoll 
[EMAIL PROTECTED] wrote:




By default, Firefox will only perform GSSAPI (negotiate-auth)
authentication
when the protocol is 'https://'.

Check the network.negotiate-auth.delegation-uris and
network.negotiate-auth.trusted-uris parameters (under about:config)
and
make sure that you allow http://; as well as https://; if you are
accessing
non-SSL protected sites.

network.negotiate-auth.delegation-uris = https://,http://;
network.negotiate-auth.trusted-uris = https://,http://;


Aaaa!  No!  Don't do this unless you _absolutely_ need this ability.

Running HTTP negotiate over a plaintext connection is _not secure_.  It 
provides no integrity protection and is subject to a relatively easy 
man-in-the-middle attack.



If the problem is indeed that the connection is not using SSL, the correct 
solution is to change that service to use SSL.


If you absolutely must use HTTP negotiate with a service that is not using 
SSL and which you do not control, then turning on negotiate support for 
non-SSL connections may be your only choice.


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Updating encryption types

[Jeffrey Hutzelman]

On Thursday, July 07, 2005 05:46:18 PM -0700 Phil Dibowitz [EMAIL PROTECTED] 
wrote:



and the right tgt (based on Kerberos by Brian Tung), doesn't seem to be
doing anything:

[EMAIL PROTECTED]


This principal is meaningless, and is used for nothing.


and the mystery ticket is doing everything:

krbtgt/[EMAIL PROTECTED]


This principal is the local-realm ticket-granting service.

In other words, it's working exactly like it's supposed to.  It's anyone's 
guess where the meaningless principal came from.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Updating encryption types

[Jeffrey Hutzelman]

On Thursday, July 07, 2005 06:18:16 PM -0700 Phil Dibowitz [EMAIL PROTECTED] 
wrote:



On Thu, Jul 07, 2005 at 09:03:36PM -0400, Jeffrey Hutzelman wrote:



On Thursday, July 07, 2005 05:46:18 PM -0700 Phil Dibowitz
[EMAIL PROTECTED]  wrote:

 and the right tgt (based on Kerberos by Brian Tung), doesn't seem to be
 doing anything:

 [EMAIL PROTECTED]

This principal is meaningless, and is used for nothing.

 and the mystery ticket is doing everything:

 krbtgt/[EMAIL PROTECTED]

This principal is the local-realm ticket-granting service.

In other words, it's working exactly like it's supposed to.  It's
anyone's  guess where the meaningless principal came from.


So [EMAIL PROTECTED] is not what MIT krb uses as the TGT, it uses
krbtgt/[EMAIL PROTECTED] - just a discrepency between the MIT implimentation
and the Kerb book I have?


It's not what _anything_ uses, and so far as I can remember never has been. 
If the book says that, then either it's a typo or Brian was asleep when he 
wrote that part. :-)


-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Updating encryption types

[Jeffrey Hutzelman]

On Friday, July 01, 2005 02:14:02 AM -0700 Phil Dibowitz [EMAIL PROTECTED] 
wrote:



So reading through:


http://web.mit.edu/kerberos/www/krb5-1.4/krb5-1.4.1/doc/krb5-install/Upgr
ading-to-Triple-DES-and-RC4-Encryption-Keys.html#Upgrading%20to%20Triple-
DES%20and%20RC4%20Encryption%20Keys

(the upgrading encryption types page)... regarding this sentence Because
of the way the MIT Kerberos database is structured, the KDC will assume
that a service supports only those encryption types for which keys are
found in the database.

That makes me think that even if kdc.conf has:

default_tgs_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc

and krb5.conf has:

default_tkt_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
default_tgs_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc

Any principals created before the switchover will obviously be stored in
the old encryption type - but during authentication, what encryption type
will be used between the client and the KDC?

I'm a bit confused as to what all will use the new encryption types and
what will use the old encryption types.



When responding to an initial ticket request, the KDC chooses three keys:

(1) The key in which the KDC's reply to the client will be encrypted.
   This key will be of one of the enctypes the KDC supports.
   This key will be of one of the enctypes the client says it supports.
   And, this key will be one of the client's long-term keys from the
   KDB, which means it will naturally be of one of the enctypes for
   which the KDB contains a key for this client.

(2) The key in which the private parts of the new ticket will be encrypted.
   This key will be one of the enctypes the KDC supports.
   This key will be one of the service's long-term keys from the KDB,
   which means it will naturally be one of the enctypes for which the KDB
   contains a key for the requested service (usually krbtgt/[EMAIL PROTECTED]).
   The client has no ability to affect the enctype of this key (except
   that some versions of some KDC implementations contain a bug in which
   the KDC considers only keys supported by the client).

(3) The session key contained in the new ticket.
   This key will be one of the enctypes the KDC supports.
   This key will be one of the enctypes the client says it supports;
   however, it need not be one for which the client has a long-term key.
   This key will be one of the enctypes known by the KDC to be supported
   by the server.  There is nothing in the Kerberos protocol which
   requires that this be the enctype of one of the service's long-term
   keys; however, the MIT implementation uses that list to decide what
   enctypes it thinks the server supports.


When responding to an additional ticket request, the KDC chooses keys for 
the same three roles.  However, the key used in role (1) is normally the 
session key from the client's TGT, and thus its enctype was chosen at the 
time the TGT was issued (alternately, it may be a sub-session key chosen by 
the client, which may be any enctype supported by both the client and KDC. 
Of course, the only enctypes the client knows are supported by the KDC are 
those used in its TGT).  The keys used in roles (2) and (3) are chosen in 
the same way as for initial tickets.



So, communicaton during an initial ticket exchange can be protected only by 
one of the client's long-term keys in the KDB.  That means that no matter 
what enctype settings are used on either client or KDC, you can't get it to 
use an enctype for which the user doesn't have a key.  To do that, the user 
will have to change his password so the admin server can generate a key for 
him for the new enctype.



Note that there are very few good reasons to configure clients for a 
specific set of enctypes.  In fact, under normal circumstances the only 
place you should have to configure enctypes is on the admin server, which 
needs to know which enctypes to generate keys for in the KDB.  As long as 
the KDB entry for each _service_ contains only keys of enctypes actually 
supported by that service, everything should work fine.


The one major exception is if you have a client workstation on which a 
single credential cache will be shared by multiple Kerberos implementations 
which do not all support the same set of enctypes.  In that case, you may 
want or need to restrict the set of enctypes used on that client to those 
which are supported by all implementations.


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos for Wireless Authentication

[Jeffrey Hutzelman]

On Monday, June 06, 2005 09:59:56 AM -0500 Nicolas Williams 
[EMAIL PROTECTED] wrote:



On Mon, Jun 06, 2005 at 09:27:51AM -0500, Matt Crawford wrote:

 I really think that working on this axis [IAKERB/Wireless Auth.]
 should be amongst the milestones of kerberos wg.

Work area for energetic contributors, yes.  Milestones of the group,
no.  IMO, of course.


Such a mechanism could be pursued outside the KRB WG, either as an
individual submission or in another WG (AAA?), and it could receive
expert review from Kerberos V experts when and as needed.


IAKERB or something like it is clearly within the scope of this working 
group; it was an existing proposal at the time the WG was formed.  There 
is no milestone because the group decided to drop the proposal, for various 
reasons.  As others have noted, one of the main reasons why no work has 
been done recently in that space is because potential contributors are 
currently involved in other work, and only have so much time.


If there are folks that want to reopen IAKERB, are willing to spend time on 
it, and can convince the WG that this is the right approach, then I see no 
problem with carrying on such work here.  Of course, I would expect any 
GSSAPI mechanism work to be reviewed in KITTEN as well.  I think it would 
be ill-advised to pursue any such work as an indiviudal without input from 
one or both of these working groups.




A while back there was a proposal for a Kerberos EAP method which would 
have supported tunneling of Kerberos messages in a similar fashion to EAP, 
allowing a client to communicate with its KDC to obtain credentials needed 
for EAP authentication.  This looked somewhat promising, and possibly a 
better fit for network access applications than IAKERB, but to my knowledge 
no work has been done on this in a while.


It's not clear to me that work on an EAP method is in scope for this WG, 
though I'd be inclined towards yes by analogy to IAKERB.  Perhaps Sam 
would be willing to comment on this point.  It clearly is not in scope for 
the EAP WG, whose charter does not currently include standardizing new EAP 
methods.  However, I would expect any actual work in this area to be 
reviewed in both WG's, even if pursued as individual work.  Again, I think 
it would be ill-advised to pursue such work without input from members of 
one or both WG's.



I do not believe that either type of mechanism is within the scope of the 
AAA working group, though a Diameter extension to tunnel krb5 messages 
between Diameter servers likely would be.  Those determinations are 
ultimately up to the AAA chairs and the OPS AD's.



An extension to the Kerberos protocol such as Saber Zrelli proposed is 
clearly not within the scope of AAA.  Any such work should be done within 
the Kerberos WG; I would not expect approval of a standards-track extension 
to Kerberos that had passed review here.  Note that in order to convince 
this WG to take on such work, you will need to convince us that extending 
Kerberos is the right way of solving the problem you describe, and that 
your propsed extension is the right one.  If you want it to happen in a 
timely fashion, it of course would help to bring along people willing to do 
some of the work (protocol design, document editing, etc); preferably such 
people should be familiar with the Kerberos protocol and with the needs of 
network operators with respect to the problem you are trying to solve.



-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

AFS Kerberos Best Practices Workshop 2005

[Jeffrey Hutzelman]

 The Second Annual
  AFS  Kerberos
  Best Practices Workshop

 June 20-24, 2005
Carnegie Mellon University, Pittsburgh PA

   http://www.pmw.org/afsbpw05/


 Purpose of the Workshop:
 * To bring together AFS and Kerberos novices and experts
 * To learn about AFS and Kerberos tools
 * To learn about AFS and Kerberos best practices


 Target Audience:
 * People interested in AFS  Kerberos
 * AFS and Kerberos administrators: novices and experienced

 One week of AFS and Kerberos content, including:


 * One day tutorial Introduction to AFS and its Best Practices on June 20
 * One day tutorial Introduction to Kerberos on June 21
 * Three days of talks including:
* KEYNOTE SPEAKER:  Mike Kazar, NetApp
One of the original writers of the filesystem now known as
AFS, Mike Kazar is still in the filesystems business.
  * Contributed talks (30-45min)


 Possible Topics include, but are not limited to:

 * OpenAFS and Arla development status reports
 * MIT Kerberos and Heimdal development status reports
 * AFS best practices (volume naming, directory hierarchy, volume sizes, 
...)

 * AFS weaknesses (locking, ACLs on files, ...)
 * AFS performance tuning (client side, server side)
 * Benchmarking AFS
 * AFS server scaling and HW recommendations
 * AFS service monitoring
 * Migration experiences
 * AFS and Kerberos 5:
 * How to install a new cell from scratch
 * Migration from kaserver to MIT Krb5
 * Migration from kaserver to Heimdal Krb5
 * Kerberos 5 and Windows Active Directory working together
 * AFS related tools (AFS Perl, Java API, scripts, ...)
 * Kerberos related tools
 * AFS and backup (scripts, amanda, TSM, ...)
 * AFS, Kerberos and Web integration
 * Delegation of AFS administration
 * AFS on non-Unix platforms (Windows, Mac OS X)
 * Commercial support

 Please send questions to: [EMAIL PROTECTED]




Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Using Solaris 10 kadmin with MIT 1.4.1 kadmind

[Jeffrey Hutzelman]

On Friday, June 03, 2005 01:32:20 PM -0600 Heilke, Rainer 
[EMAIL PROTECTED] wrote:



P.S. What is the other issue?


Sun's lack of a ksu binary. The way we use ksu, RBAC and su simply do
not provide the same functionality. We have an RFE open on this. BTW, if
anyone else needs ksu, please add your names to the RFE.



What do you need in a ksu that you don't get from Solaris's su and a 
properly-configured PAM stack?


-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Getting single DES TGT

[Jeffrey Hutzelman]

On Thursday, April 07, 2005 05:35:59 PM -0400 Sam Hartman 
[EMAIL PROTECTED] wrote:

The best you can do is use the -e argument of the kvno program to
request a des-cbc-crc ticket for the appropriate oracle service
principal before you start Oracle.

The other thing you should do is file a TAR with Oracle on this issue, 
describing the security and interoperability issues it causes for you and 
asking them to fix the problem.  The more people who report problems caused 
by the use of such ancient Kerberos, the higher likelyhood they will fix it.


If you felt it was appropriate, you might point out that NIST is in the 
process of withdrawing FIPS 46-3, after which federal agencies will not be 
permitted to use single DES for the protection of federal information.  The 
full notice was published in the July 26, 2004 Federal Register (vol. 69, 
no. 142, pp. 44509-44510) as docket number 040602169-4169-01.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris 9 Cross Realm Authentication Problems

[Jeffrey Hutzelman]

On Friday, April 01, 2005 07:23:37 PM -0800 Darren Hoch 
[EMAIL PROTECTED] wrote:

kadmin: lisprincs
snip
krbtgt/[EMAIL PROTECTED]
krbtgt/[EMAIL PROTECTED]
krbtgt/[EMAIL PROTECTED]
The second components of each of these principal names must exactly match 
the name of the realm involved, including case.  So, for example, for a 
client in the EXAMPLE1.COM realm to authenticate to a service in the 
EXAMPLE.COM realm, you need krbtgt/[EMAIL PROTECTED] to exist.  Of 
course, it needs to exist in both realms and have the same key and kvno in 
both places.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Newbie's question

[Jeffrey Hutzelman]

On Wednesday, March 30, 2005 04:33:21 PM -0800 kaiduan xie 
[EMAIL PROTECTED] wrote:

Hi, all,
I have an application where the client needs to authenticate to the
server before carrying on further communications. The client will acquire
ticket from KDC which runs in Microsoft's Domain Controller. After
getting the ticket, the client will send the ticket and the authenticator
together to the server for authentication. My question are:
1) Can I put the authenticator and ticket into MY application's message
instead of Kerberos's Application Request message? For example, convert
the authenticator and ticket into hex-coded string and put this string
into the MY applicaiton's message.
Credential: 0fde234567abedghi
and at the server side, after receiving the authenticator and ticket from
the application's message (NOT Kerberos's Application Request message),
the server applies Kerberos algorithm to verify whether the credential is
correct or not.
Well, you _can_ do whatever you want, but if you don't use Kerberos 
messages, then the resulting protocol is not Kerberos and cannot safely be 
assumed to have the security properties of Kerberos.  For example, in the 
Kerberos AP-REQ exchange, the authenticator is both encrypted and 
integrity-protected.  The algorithms used to provide these properties are 
carefully designed to avoid a number of attacks against both the crypto and 
the protocol as a whole; without the require properties, the protocol is 
not secure.

You should not expect Kerberos libraries to give you much help if you are 
not using Kerberos messages.  The simplest and most portable interfaces are 
designed around producing and consuming Kerberos protocol messages.  If you 
choose not to use those messages, you will end up writing a lot more code.

What you probably want to do instead is use the Kerberos messages, but 
transport them in an encoded form suitable for your application.  For 
example, your Credential example above could be the hex-encoded form of a 
Kerberos AP-REQ.  However, you should bear in mind that the actual messages 
will be considerably larger than suggested by your example.  If possible, 
you should consider using a more compact encoding, such as the base-64 
encoding defined in section 3 of RFC3548.

Also, it is worth noting that unless your application message is 
integrity-protected (and possibly encrypted) in a way that is 
cryptographically bound to your authentication exchange, you haven't 
actually gained much.  Sending a Credential containing a hex-encoded 
AP-REQ may prove the client's identity, but it doesn't prove that any of 
the rest of the message actually came from that client, as opposed to from 
some attacker who modified the request in transit.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Java Pre-auth for Windows 2003 mixed case revival

[Jeffrey Hutzelman]

On Monday, February 14, 2005 01:34:20 PM -0800 Seema Malkani 
[EMAIL PROTECTED] wrote:

Maybe the next Kerberos clarifications should clarify this particular
scenario.
A large part of the problem here is that KRB-ERROR does not actually have a 
complete extension mechanism.  It has e-data, which is a single octet 
string whose meaning is implementation-defined except in the specific case 
of KDC_ERR_PREAUTH_REQUIRED, in which case it is a sequence of PA-DATA.

The next Kerberos specification will likely clean this up considerably, 
with a well-defined extension mechanism similar to those provided by 
PA-DATA and AUTHORIZATION-DATA.  For example, take a look at section 9 of
draft-ietf-krb-wg-rfc1510ter-00.txt (very much still a work in progress).

RFC1510bis (draft-ietf-krb-wg-kerberos-clarifications-07.txt) has been 
approved by the IESG and is in the RFC Editor's queue awaiting publication. 
Aside from copy-editing performed during the publication process, this 
document is not expected to change again.  If you would like to see 
additional text in RFC1510ter clarifying the handling of cases where the 
client sends the wrong preauth type, I'd suggest you make a proposal to 
that effect on the IETF Kerberos Working Group mailing list, 
ietf-krb-wg@anl.gov.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT + Heimdal + openssh == cross realm difficulties

[Jeffrey Hutzelman]

On Wednesday, February 02, 2005 07:31:44 AM -0600 Douglas E. Engert 
[EMAIL PROTECTED] wrote:

Client not found in database: [EMAIL PROTECTED]: No such entry in the database
Ask the Heimdal people, what does this message mean? With cross realm,
the server's realm should not require any knowlwdge of the user principal
and should not require it to be in its database.
It means what it said - the client is not in that KDC's database.
It does not mean that the KDC is refusing to issue a ticket.
-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Fedora Core 3: gssapi authentication module not supported?

[Jeffrey Hutzelman]

On Friday, December 10, 2004 02:18:27 -0800 Mark [EMAIL PROTECTED] wrote:
Hello!
I need to connect to some kerberos environment using gssapi, but the
ssh client on fc3 refuses to do so. What is the problem here? Is there
a trick to solve that problem?
It would help if you defined your problem a little better.  For example, 
instead of saying it refuses to do so, you could tell us what error 
message(s) you get.  You might get additional information by running ssh -v 
to get some debugging output.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Solaris using Kerberos

[Jeffrey Hutzelman]

On Tuesday, December 07, 2004 16:26:39 -0600 David A Flores 
[EMAIL PROTECTED] wrote:

Help anyone,
We are using a Windows domain controller as a KDC and we are trying to
authenticate a Solaris 9.0 OS box using Kerberos.  The following is the
command we use to create the keytab file:
ktpass -princ host/[EMAIL PROTECTED] -mapuser dean19 -pass *
-out c:\dean19.keytab
Once we create the keytab file we send it to the sever via ssh.  Attached
are the pam.conf file and the krb5.conf that we configured.  One the
computer called dean19 we ran the ktutil
rkt /etc/krb5/dean.keytab
wkt /etc/krb5/krb5.keytab
Why are you doing this, instead of just renaming the file?
After the rkt and the wkt commands we do a list and it shows a slot KVNO
Principal
You haven't quoted the whole output, so I can't be sure, but I think what 
you are describing here is the output you get when there are _no_ keys in 
the keytab -- the text you quoted is the column headers.


But when we try to login to the box we get the following error.
Dec  7 16:27:38 dean19 login: [ID 537602 auth.error] PAM-KRB5 (auth):
krb5_verify_init_creds failed: Key table entry not found
This is consistent with the key service key not being in the keytab.
-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT KDC only listening on lo

[Jeffrey Hutzelman]

On Thursday, September 23, 2004 01:57:50 +0200 Fredrik Tolf 
[EMAIL PROTECTED] wrote:

On Wed, 2004-09-22 at 19:43 -0400, Ken Raeburn wrote:
On Sep 22, 2004, at 18:50, Fredrik Tolf wrote:
 On Wed, 2004-09-22 at 22:37 +, Sam Hartman wrote:
 Fredrik == Fredrik Tolf [EMAIL PROTECTED] writes:

 Fredrik Does anyone know if the KDC is configurable to just
 Fredrik listen to 0.0.0.0, or will I have to take the time to
 Fredrik patch it?

 You'll have to patch.
Shouldn't be hard.  I think you need to dig up the code in the krb5
library (or include directory, or a copy in the KDC code? I forget
where 1.3 had it) that looks for IFF_LOOPBACK and disable it.
It would be much better if it would listen to 0.0.0.0, since if I leave
the network and then come back, I'm not always certain to be given the
same IP address by the DHCP server. If I would get a new one, I'd have
to restart the KDC to listen to it. Not a major deal, mayhap (especially
considering I could restart the KDC from some network script), but
slightly annoying, and pretty ugly.
Do you think that's wrong?
Listening on 0.0.0.0 for UDP traffic may not work for hosts with
multiple addresses, since the client code may be checking that it got
its response back from the same address to which it sent the query.
I'm sorry, but I'm not seeing the problem. When the reply is sent back,
surely the kernel fills in the interface address in the source field of
the IP header? Or am I missing something here?
Yes, you are.  In UDP there's no concept of request, reply, or 
connection.  The kernel will indeed fill in the source address.  It will 
use the interface address of whatever outgoing interface is selected based 
on the best route to the destination address.

Unfortunately, the best route to the destination address may not be out the 
same interface whose address was on the original request.  In such a 
situation, the reply will go out with the _WRONG_ source address and the 
client will likely ignore it.

Consider the situation where the KDC for EXAMPLE.COM has two interfaces: 
le0 has address 192.168.1.1, and ec0 has address 10.42.1.1.  These are both 
on networks which are connected to the (hypothetical) Internet.  Now 
consider a client with address 192.168.1.2.  It sends a request to 
10.42.1.1, because that is one of the published addresses of the KDC for 
EXAMPLE.COM.  It's a perfectly reasonable request, and the KDC receives it 
via its ec0 interface.  The request has a source address of 192.168.1.2, so 
the KDC sends the reply to that.  Now, the best route to 192.168.1.2 is out 
le0, so the kernel tacks on le0's address (192.168.1.1) as the source 
address.  The client sees this packet from 192.168.1.1 and drops it on the 
floor.

For this reason, servers providing UDP-based services from multi-homed 
hosts generally need to maintain separate sockets for each interface, so 
they can determine to which address a request was sent and to arrange for 
that same address to be used as the source address on the reply.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Looking up Kerberos error codes

[Jeffrey Hutzelman]

On Monday, September 20, 2004 21:42:21 + Jelmer Vernooij 
[EMAIL PROTECTED] wrote:

Hi,
Trying to get krb5 authentication working together with PostgreSQL, I
stumbled across a couple of error codes that I can't place.
The PostgreSQL error logs report that krb5_recvauth returns error
'103' when connecting from one host and '13' when connecting from
another, but I haven't been able to figure out what those two error
codes mean.
Where can I lookup these error codes? KRB5PLACEHOLD_103 was the only
one with value 103 I could find, but it isn't used anywhere in MIT
Kerberos 1.3.4.
Any ideas on how to debug these kinds of problems?
These sound like system-specific error codes, rather than those generated 
by Kerberos.  13 is a common value for EACCES; 103 is going to be more 
platform-dependent.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MITKRB5-SA-2004-002: double-free vulnerabilities

[Jeffrey Hutzelman]

*** WARNING ***
I'm going to start an exchange to try to determine whether Mike has the 
correct bits and why he can't verify the signature.  It should be noted 
that this entire exchange is occuring over unprotected email, and so it is 
a bad idea to rely on statements made by either of us like it works for 
me or the file has SHA-1 checksum XYZ or here is the file.

The _only_ way to ensure you have an unmodified copy of the patch is to 
verify the PGP signature, using a known-good copy of the developer's PGP 
key.


Now, on to business...

On Wednesday, September 01, 2004 08:19:33 -0700 Mike Friedman 
[EMAIL PROTECTED] wrote:

2004-002-patch_1.2.7.txt

  http://web.mit.edu/kerberos/advisories/2004-002-patch_1.2.7.txt
  The associated detached PGP signature is at:
  http://web.mit.edu/kerberos/advisories/2004-002-patch_1.2.7.txt.asc
I find that the PGP signature doesn't verify.  Is anyone else having this
problem?
Nope.  I fetched the patch and the corresponding detached signature, and 
had no problems verifying the signature.  You haven't said what tools 
you're using or what the error was, so let's start by considering the 
possibility that the bits you have don't match the ones Tom signed...

The correct patch is 6441 bytes and 247 lines.
It has UNIX-style newlines; perhaps that is the problem.
Can you send me a hash?
-- Jeff

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Key derivation with non-ASCII characters

[Jeffrey Hutzelman]

On Wednesday, September 01, 2004 07:20:00 -0700 Frank Taylor 
[EMAIL PROTECTED] wrote:

No, although an explanation of why the problem is hard and why in
general you may not be able to solve it is in
draft-ietf-krb-wg-kerberos-clarifications (successor to RFC 1510).
Thanks for the pointer... I have now found: Encryption and Checksum
Specifications for Kerberos 5 (draft-ietf-krb-wg-crypto-07.txt). I
like the way the standard was changed to agree with the
implementations of DES string-to-key rather than the other way around!
Microsoft will expect you to encode things as UTF8.  I don't know what
your implementation actually does.
The clarified draft explicitly states that the input strings (password
and salt) to string-to-key must be in  UTF-8.
Careful here.  The crypto document does require the use of UTF-8 encoding.
However, in the updated specification (as in RFC1510), these strings are 
actually restricted to 7-bit US-ASCII.  Implementations which use non-ASCII 
characters (and most do) violate RFC1510.  To the extent that this happens, 
these implementations are not interoperable -- to do the right thing with 
non-ASCII characters, you must know a priori what the implementation you're 
talking to will expect.  There is an extensive discussion of this issue in 
section 5.2.1 of the kerberos-clarifications document.

Sam has explained what the existing (pre-kerberos-clarifications) Microsoft 
implemenetation will actually do -- it will expect you to encode all 
strings as UTF-8, and does not perform any normalization.

You haven't said what enctype the key in question is, or how you're 
determining whether you have the right key (what command or function are 
you using, and what error/exception do you get?).

Note that the salt string affects the output of the string-to-key 
operation, so if you don't use the right salt, you're not going to get the 
right key.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Encryption key type order w. windows auth?

[Jeffrey Hutzelman]

On Thursday, June 17, 2004 21:49:34 -0400 David Botsch 
[EMAIL PROTECTED] wrote:

Ok... however, since Windows can come up with the other string to key
algorithm, why does authentication not work?
Because when it constructs an AS-REP, the KDC gets to choose which of the 
user's keys will be used, subject only to constraints the client provides 
about what enctypes it can handle.  There's no way for the client to say I 
can't handle the AFS string-to-key; don't use it, so the KDC is free to 
choose that key.

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Hiemdal kadmin and attributes

[Jeffrey Hutzelman]

On Thursday, April 22, 2004 18:42:46 -0700 Nick Atkins 
[EMAIL PROTECTED] wrote:

Hi,
I am using Heimdal Kerberos on SuSE 8.1 and trying to write a script
to automate adding principals.  I am using kadmin and this works
when I do something like:
kadmin -l add res/[EMAIL PROTECTED]
However, I'm trying to supply attributes on this command line so I
can specify an encryption type of des-cbc-crc only (i.e. no 3des
allowed).  Does anyone have a clue as to what can be specified with
the -attributes option?  I can't find any docs on this subject...
attributes are flags, like disallow-svr or requires-hw-auth.
There is no way to set enctypes on the command line; you need to 
temporarily modify the krb5.conf on the machine where you run kadmind (or 
kadmin -l).

-- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED]
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos