Skip Menu |
 

Subject: No prompter interface for krb5_get_init_creds_keytab
Cc: krbdev@mit.edu
I discovered recently that the API krb5_get_init_creds_keytab doesn't
take a prompter argument. This makes it difficult to do things like
hardware preauthentication using a key stored in a keytab.

I propose the following API to solve the problem:

krb5_get_init_creds_keytab_prompter
KRB5_PROTOTYPE((krb5_context context,
krb5_creds *creds,
krb5_principal client,
krb5_keytab arg_keytab,
krb5_prompter_fct prompter,
void *data,
krb5_deltat start_time,
char *in_tkt_service,
krb5_get_init_creds_opt *options));

(Obviously, it looks a whole lot like the krb5_get_init_creds_keytab
API). I'm not so convinced the name is particularly great, though.

Any comments?
From: Marc Horowitz <marc@mit.edu>
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
Date: 17 Dec 2002 13:05:53 -0500
RT-Send-Cc:
"Ken Hornstein via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
>> I discovered recently that the API krb5_get_init_creds_keytab doesn't
>> take a prompter argument. This makes it difficult to do things like
>> hardware preauthentication using a key stored in a keytab.
>>
>> Any comments?

Why do you think you need this? The idea of getting initial creds
from a keytab is that a daemon or other automated task can act as a
kerberos client without user interaction. If you require user
interaction, why aren't you just using a password?

Marc
To: rt-comment@krbdev.mit.edu
Cc: krbdev@mit.edu
Subject: Re: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
Date: Tue, 17 Dec 2002 13:39:34 -0500
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
RT-Send-Cc:
Show quoted text
>Why do you think you need this? The idea of getting initial creds
>from a keytab is that a daemon or other automated task can act as a
>kerberos client without user interaction. If you require user
>interaction, why aren't you just using a password?

I need to use a host key in a keytab (hence keytab) as a user's
long-term key with a hardware token (user interaction). This is to
implement Matt Crawford's hw-auth draft. Okay, so technically I don't
need a keytab interface, but there's no way to give the API a raw key
and provide a prompter interface, and that's the real deficiency.

--Ken
From: Marc Horowitz <marc@mit.edu>
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
Date: 17 Dec 2002 14:38:33 -0500
RT-Send-Cc:
"kenh@cmf.nrl.navy.mil via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
>> I need to use a host key in a keytab (hence keytab) as a user's
>> long-term key with a hardware token (user interaction).

Why do you need to do this? When, in the real world, would this ever
happen?

Show quoted text
>> This is to implement Matt Crawford's hw-auth draft. Okay, so
>> technically I don't need a keytab interface, but there's no way to
>> give the API a raw key and provide a prompter interface, and that's
>> the real deficiency.

You haven't convinced me there's a deficiency here.

Marc
To: krbdev@mit.edu
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
Date: Tue, 17 Dec 2002 14:54:39 -0500
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.4KiB
Show quoted text
>>> I need to use a host key in a keytab (hence keytab) as a user's
>>> long-term key with a hardware token (user interaction).
>
>Why do you need to do this? When, in the real world, would this ever
>happen?

Actually, this is something we do every day here; we want the ability to
validate someone's hardware token for root access via sudo. We used the
old API before, and I was updating everything to the new API. It's not
like I was making this up, you know :-) This is all tied up in the
requirement for hardware preauthentication at DOD supercomputer sites.

Show quoted text
>>> This is to implement Matt Crawford's hw-auth draft. Okay, so
>>> technically I don't need a keytab interface, but there's no way to
>>> give the API a raw key and provide a prompter interface, and that's
>>> the real deficiency.
>
>You haven't convinced me there's a deficiency here.

Well, let's turn this around a bit; is there a reason NOT to implement
this? Okay, I understand the generic argument of additional API calls
increasing Kerberos programming complexity (it's complex enough as is),
and I can accept that in a generic sense ... but it seems like, in
hindsight, that if we were designing this API today, I would argue that
leaving the possibility of having a prompter callback in this function
(when doing so would be trivially simple) could only be a possible
win. And I don't really see how to implement this without an API
change somewhere; it's either this, or implement something like
krb5_get_init_creds_skey.

--Ken
From: Marc Horowitz <marc@mit.edu>
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
Date: 17 Dec 2002 16:07:37 -0500
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3KiB
"kenh@cmf.nrl.navy.mil via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
>> >>> I need to use a host key in a keytab (hence keytab) as a user's
>> >>> long-term key with a hardware token (user interaction).
>> >
>> >Why do you need to do this? When, in the real world, would this ever
>> >happen?
>>
>> Actually, this is something we do every day here; we want the ability to
>> validate someone's hardware token for root access via sudo. We used the
>> old API before, and I was updating everything to the new API. It's not
>> like I was making this up, you know :-) This is all tied up in the
>> requirement for hardware preauthentication at DOD supercomputer sites.

Now I think I understand. You're just using the keytab because it's
convenient, not because you have some requirement to authenticate as
the specific key in the keytab. You're also trying to avoid making
the user type his password again, even though the user will have to do
the hardware preauth interaction.

For that matter, isn't the hardware token specific to the user? Can
you use an arbitrary user's hardware token with the key in the keytab?
How do you know which token is being used, since the client name in
the as-req is goint to be the name from the keytab? If this is
currently working as you imply, can you explain it so I can understand
it better? Then maybe I can come up with some more clever suggestion.

Marc
To: Marc Horowitz <marc@MIT.EDU>
Cc: rt@krbdev.mit.edu, krbdev@mit.edu
Subject: Re: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
From: Sam Hartman <hartmans@mit.edu>
Date: Tue, 17 Dec 2002 16:21:39 -0500
RT-Send-Cc:

Marc, read the draft (draft-ietf-krb-wg-hw-auth) if you want to
understand what is going on.

I actually think that passing in this particular key as the keytab is
wrong, but since Ken is not planning on contributing the code that
uses this preauth type, just the new get_init_creds API, I don't have
to make that evaluation.

While I agree that keytabs are commonly used to by applications that
do not want user interaction, it does not seem unreasonable to use
them in other circumstances where using a prompter is appropriate.
Certainly it is possible to store a long-term key in a keytab even if
the KDC requires preauth for that key. In the current code base there
is not client side support for this case.
To: krbdev@mit.edu
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
Date: Tue, 17 Dec 2002 23:50:09 -0500
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.8KiB
Show quoted text
>Now I think I understand. You're just using the keytab because it's
>convenient, not because you have some requirement to authenticate as
>the specific key in the keytab. You're also trying to avoid making
>the user type his password again, even though the user will have to do
>the hardware preauth interaction.

Right, exactly. Well, it's a _bit_ more complex than that. Sam explained
it fairly well in his message, but the problem is that the host key is
taking the place of the user's long-term key. So that needs to make it
into the library ... but you can't feed a raw key into
krb5_get_init_creds_password(), and krb5_get_init_creds_keytab() doesn't
take a prompter, and so on ... I thought about something along the lines
of krb5_get_init_creds_skey(), but the problem with THAT is that you want
to be able to pass in multiple keys to match whatever the KDC sends back,
and designing an API for that seemed more work than I wanted to tackle
(and I wasn't sure it was the right answer).

Show quoted text
>For that matter, isn't the hardware token specific to the user? Can
>you use an arbitrary user's hardware token with the key in the keytab?
>How do you know which token is being used, since the client name in
>the as-req is goint to be the name from the keytab?

Well ... since you asked ...

What I did was write a half-assed implementation of a memory keytab,
just enough to make krb5_get_init_creds_keytab() work. I then read out
all of the host keys out of the on-disk keytab and placed them into the
memory keytab, but with the user's principal as the principal name in
the keytab entry. Seems to work alright. And before anyone mentions ...
yes, I know that I had to use a private API to register a new keytab
type, but it seems like the right solution there is to write a "real"
memory keytab type (since it's the only way to feed in a key to calls
like krb5_rd_req()).

--Ken
Date: Wed, 18 Dec 2002 07:30:56 -0500
From: Richard Basch <basch@mit.edu>
Subject: RE: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
To: rt-comment@krbdev.mit.edu, krb5-prs@mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.8KiB
I wonder if there should be some way of registering a "preauth" handler (ie.
callback function) into one of the opaque structures, such that when
prompting or other actions are required, the handler is called and can take
care of the issues.

I don't think we want users to pass a function pointer directly to the API,
but some type of "function" registration may be useful, such that it is
populated with a default/null handler, and advanced programmers such as Ken,
can benefit.

Thoughts?


Show quoted text
> -----Original Message-----
> From: krb5-bugs-admin@MIT.EDU [mailto:krb5-bugs-admin@MIT.EDU]On Behalf
> Of kenh@cmf.nrl.navy.mil via RT
> Sent: Tuesday, December 17, 2002 11:50 PM
> To: krb5-prs@mit.edu
> Subject: Re: [krbdev.mit.edu #1278] No prompter interface for
> krb5_get_init_creds_keytab
>
>
>
> >Now I think I understand. You're just using the keytab because it's
> >convenient, not because you have some requirement to authenticate as
> >the specific key in the keytab. You're also trying to avoid making
> >the user type his password again, even though the user will have to do
> >the hardware preauth interaction.
>
> Right, exactly. Well, it's a _bit_ more complex than that. Sam explained
> it fairly well in his message, but the problem is that the host key is
> taking the place of the user's long-term key. So that needs to make it
> into the library ... but you can't feed a raw key into
> krb5_get_init_creds_password(), and krb5_get_init_creds_keytab() doesn't
> take a prompter, and so on ... I thought about something along the lines
> of krb5_get_init_creds_skey(), but the problem with THAT is that you want
> to be able to pass in multiple keys to match whatever the KDC sends back,
> and designing an API for that seemed more work than I wanted to tackle
> (and I wasn't sure it was the right answer).
>
> >For that matter, isn't the hardware token specific to the user? Can
> >you use an arbitrary user's hardware token with the key in the keytab?
> >How do you know which token is being used, since the client name in
> >the as-req is goint to be the name from the keytab?
>
> Well ... since you asked ...
>
> What I did was write a half-assed implementation of a memory keytab,
> just enough to make krb5_get_init_creds_keytab() work. I then read out
> all of the host keys out of the on-disk keytab and placed them into the
> memory keytab, but with the user's principal as the principal name in
> the keytab entry. Seems to work alright. And before anyone mentions ...
> yes, I know that I had to use a private API to register a new keytab
> type, but it seems like the right solution there is to write a "real"
> memory keytab type (since it's the only way to feed in a key to calls
> like krb5_rd_req()).
>
> --Ken
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> http://mailman.mit.edu/mailman/listinfo/krb5-bugs
>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
From: Sam Hartman <hartmans@mit.edu>
Date: Thu, 19 Dec 2002 00:53:49 -0500
RT-Send-Cc:
So, note that there are two sides to the interaction. I think the
current interface correctly handles the case where you want the
preaauth mechanism to interact with a user using an
application-supplied prompter function.

This is mechanism-independent and similar to PAM conversation functions.

Ken pointed out that we have no way of setting this up while using a
keytab to get a long-term key. I agree that this functionality should
be offered and agreed to accept the functionality if code is
committed.

I disagree that Ken's use of the keytab interface for the hw-auth
draft is appropriate but don't believe he plans to give us that code,
so I'm not sure it matters.


None of this speaks to a related problem which is how we get preauth
mechanism specific data from an application or hardware device to that
mechanism. The current prompter interface is clearly appropriate (as
are things like PAM conversation functions within the PAM framework).
It sounds like Richard is addressing that problem rather than the user
interaction problem.