One more question WRT gssapi...

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

One more question WRT gssapi...

Jiva DeVoe
Must the account that a service is logged in as do a "kinit" as the  
principal it intends to use prior to using the GSSAPI function  
gss_acquire_cred ?  Or is it sufficient to have the key for the  
credential in question in the /etc/krb5.keytab file?


In other words, must I do:

kinit -t /etc/krb5.keytab service/[hidden email]
./myserverdaemon

? or will gssapi handle it for me?

--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management Software for Mac OS X


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Matt Crawford
> Must the account that a service is logged in as do a "kinit" as the
> principal it intends to use prior to using the GSSAPI function
> gss_acquire_cred ?  Or is it sufficient to have the key for the
> credential in question in the /etc/krb5.keytab file?

No and yes.

> In other words, must I do:
>
> kinit -t /etc/krb5.keytab service/[hidden email]
> ./myserverdaemon
>
> ? or will gssapi handle it for me?

No, and "sort of."  The service never has to contact the KDC.  Its
"credential" is a very different thing than the client's.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jiva DeVoe
Hmm, my tests do not bare this out...

Specifically, I find I MUST issue a kinit -t /etc/krb5.keytab service/
[hidden email] before attempting running my application which then does  
a gss_acquire_cred.

Is this correct?

On Jul 21, 2005, at 6:22 PM, Matt Crawford wrote:

>> Must the account that a service is logged in as do a "kinit" as  
>> the principal it intends to use prior to using the GSSAPI function  
>> gss_acquire_cred ?  Or is it sufficient to have the key for the  
>> credential in question in the /etc/krb5.keytab file?
>>
>
> No and yes.
>
>
>> In other words, must I do:
>>
>> kinit -t /etc/krb5.keytab service/[hidden email]
>> ./myserverdaemon
>>
>> ? or will gssapi handle it for me?
>>
>
> No, and "sort of."  The service never has to contact the KDC.  Its  
> "credential" is a very different thing than the client's.
>
>
--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management Software for Mac OS X


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Nicolas Williams
On Tue, Jul 26, 2005 at 05:04:07PM -0400, Jiva DeVoe wrote:
> Hmm, my tests do not bare this out...
>
> Specifically, I find I MUST issue a kinit -t /etc/krb5.keytab service/
> [hidden email] before attempting running my application which then does  
> a gss_acquire_cred.
>
> Is this correct?

For an initiator cred, yes.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jiva DeVoe
Aha!

Is this documented somewhere I can read up on it?  I clearly don't  
understand the inner workings of this, and I'd like to.


On Jul 26, 2005, at 5:17 PM, Nicolas Williams wrote:

> On Tue, Jul 26, 2005 at 05:04:07PM -0400, Jiva DeVoe wrote:
>
>> Hmm, my tests do not bare this out...
>>
>> Specifically, I find I MUST issue a kinit -t /etc/krb5.keytab  
>> service/
>> [hidden email] before attempting running my application which then does
>> a gss_acquire_cred.
>>
>> Is this correct?
>>
>
> For an initiator cred, yes.
>
--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management Software for Mac OS X


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jeffrey Altman-4
Jiva:

Why don't you explain to us what you are attempting to accomplish?

Does one of your two endpoints represent an end-user?
Or are both of your endpoints services that represent machines?

When using GSSAPI Kerberos, the initiator of the authentication must
have an initial credential (aka a Ticket Granting Ticket) prior to
the call to gss_acquire_cred() or gss_init_context().  If the initiator
represents an end user, the user typically obtains a TGT either a login
or via a kinit call.  The user provides her principal name and a
password or smart card or another form of proof of identity and the
Kerberos KDC issues an initial TGT to the user.

If the initiator does not represent a user or is running as a detached
long term background process, the process may be given access to a
keytab containing the long term key for the initiators principal.  This
keytab is then used with a kinit call to obtain an initial TGT.

The TGT is used during the gss_init_context() call to obtain a Kerberos
service ticket for the service you are attempting to authenticate to.

Jeffrey Altman


Jiva DeVoe wrote:

> Aha!
>
> Is this documented somewhere I can read up on it?  I clearly don't
> understand the inner workings of this, and I'd like to.
>
>
> On Jul 26, 2005, at 5:17 PM, Nicolas Williams wrote:
>
>> On Tue, Jul 26, 2005 at 05:04:07PM -0400, Jiva DeVoe wrote:
>>
>>> Hmm, my tests do not bare this out...
>>>
>>> Specifically, I find I MUST issue a kinit -t /etc/krb5.keytab  service/
>>> [hidden email] before attempting running my application which then does
>>> a gss_acquire_cred.
>>>
>>> Is this correct?
>>>
>>
>> For an initiator cred, yes.
>>
>
> --
> Jiva DeVoe
> http://www.devoesquared.com
> PowerCard - Intuitive Project Management Software for Mac OS X
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> krbdev mailing list             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jiva DeVoe
I have a long-running service... (like an ftp server, or a web server  
or whatever, though it's a program I am writing myself)... and users  
will access it using a client program (like an ftp client).

Now I assume the user would kinit prior to running the client  
program, so I can see how that works.  But in the case of the server,  
I am confused about how the server process gains it's initial TGT.

I understand that I can use a keytab file for the server process, but  
doesn't it still need to call kinit (say in it's startup script)  
prior to calling gss_acquire_cred() ?

Is there an API call for that kinit?  In my program, I've been  
calling the kinit cmd line program prior to running the program.  Do  
I need to put that into my startup script?  (This is all on Linux BTW).

On an unrelated note: Is it possible for a server process to have  
multiple TGT for different principals?  (Why?  For unit tests for my  
code - simulating the user client process/credentials and the server  
process/credentials).

On Jul 26, 2005, at 6:02 PM, Jeffrey Altman wrote:

> Jiva:
>
> Why don't you explain to us what you are attempting to accomplish?
>
> Does one of your two endpoints represent an end-user?
> Or are both of your endpoints services that represent machines?
>
> When using GSSAPI Kerberos, the initiator of the authentication must
> have an initial credential (aka a Ticket Granting Ticket) prior to
> the call to gss_acquire_cred() or gss_init_context().  If the  
> initiator
> represents an end user, the user typically obtains a TGT either a  
> login
> or via a kinit call.  The user provides her principal name and a
> password or smart card or another form of proof of identity and the
> Kerberos KDC issues an initial TGT to the user.
>
> If the initiator does not represent a user or is running as a detached
> long term background process, the process may be given access to a
> keytab containing the long term key for the initiators principal.  
> This
> keytab is then used with a kinit call to obtain an initial TGT.
>
> The TGT is used during the gss_init_context() call to obtain a  
> Kerberos
> service ticket for the service you are attempting to authenticate to.
>
> Jeffrey Altman
>
>
> Jiva DeVoe wrote:
>
>
>> Aha!
>>
>> Is this documented somewhere I can read up on it?  I clearly don't
>> understand the inner workings of this, and I'd like to.
>>
>>
>> On Jul 26, 2005, at 5:17 PM, Nicolas Williams wrote:
>>
>>
>>> On Tue, Jul 26, 2005 at 05:04:07PM -0400, Jiva DeVoe wrote:
>>>
>>>
>>>> Hmm, my tests do not bare this out...
>>>>
>>>> Specifically, I find I MUST issue a kinit -t /etc/krb5.keytab  
>>>> service/
>>>> [hidden email] before attempting running my application which then  
>>>> does
>>>> a gss_acquire_cred.
>>>>
>>>> Is this correct?
>>>>
>>>>
>>>
>>> For an initiator cred, yes.
>>>
>>>
>>
>> --
>> Jiva DeVoe
>> http://www.devoesquared.com
>> PowerCard - Intuitive Project Management Software for Mac OS X
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> krbdev mailing list             [hidden email]
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>

--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management for Mac OS X

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jeffrey Altman-4
The server should be calling gss_accept_context and does not obtain
its own initial ticket.  It uses the key stored in the keytab file
to decrypt the service ticket delivered by the client as part of the
authentication negotiation.

Have you examined the source code to the gss-client and gss-server
sample applications?

Jeffrey Altman


Jiva DeVoe wrote:

> I have a long-running service... (like an ftp server, or a web server
> or whatever, though it's a program I am writing myself)... and users
> will access it using a client program (like an ftp client).
>
> Now I assume the user would kinit prior to running the client  program,
> so I can see how that works.  But in the case of the server,  I am
> confused about how the server process gains it's initial TGT.
>
> I understand that I can use a keytab file for the server process, but
> doesn't it still need to call kinit (say in it's startup script)  prior
> to calling gss_acquire_cred() ?
>
> Is there an API call for that kinit?  In my program, I've been  calling
> the kinit cmd line program prior to running the program.  Do  I need to
> put that into my startup script?  (This is all on Linux BTW).
>
> On an unrelated note: Is it possible for a server process to have
> multiple TGT for different principals?  (Why?  For unit tests for my
> code - simulating the user client process/credentials and the server
> process/credentials).
>
> On Jul 26, 2005, at 6:02 PM, Jeffrey Altman wrote:
>
>> Jiva:
>>
>> Why don't you explain to us what you are attempting to accomplish?
>>
>> Does one of your two endpoints represent an end-user?
>> Or are both of your endpoints services that represent machines?
>>
>> When using GSSAPI Kerberos, the initiator of the authentication must
>> have an initial credential (aka a Ticket Granting Ticket) prior to
>> the call to gss_acquire_cred() or gss_init_context().  If the  initiator
>> represents an end user, the user typically obtains a TGT either a  login
>> or via a kinit call.  The user provides her principal name and a
>> password or smart card or another form of proof of identity and the
>> Kerberos KDC issues an initial TGT to the user.
>>
>> If the initiator does not represent a user or is running as a detached
>> long term background process, the process may be given access to a
>> keytab containing the long term key for the initiators principal.   This
>> keytab is then used with a kinit call to obtain an initial TGT.
>>
>> The TGT is used during the gss_init_context() call to obtain a  Kerberos
>> service ticket for the service you are attempting to authenticate to.
>>
>> Jeffrey Altman
>>
>>
>> Jiva DeVoe wrote:
>>
>>
>>> Aha!
>>>
>>> Is this documented somewhere I can read up on it?  I clearly don't
>>> understand the inner workings of this, and I'd like to.
>>>
>>>
>>> On Jul 26, 2005, at 5:17 PM, Nicolas Williams wrote:
>>>
>>>
>>>> On Tue, Jul 26, 2005 at 05:04:07PM -0400, Jiva DeVoe wrote:
>>>>
>>>>
>>>>> Hmm, my tests do not bare this out...
>>>>>
>>>>> Specifically, I find I MUST issue a kinit -t /etc/krb5.keytab  
>>>>> service/
>>>>> [hidden email] before attempting running my application which then  does
>>>>> a gss_acquire_cred.
>>>>>
>>>>> Is this correct?
>>>>>
>>>>>
>>>>
>>>> For an initiator cred, yes.
>>>>
>>>>
>>>
>>> --
>>> Jiva DeVoe
>>> http://www.devoesquared.com
>>> PowerCard - Intuitive Project Management Software for Mac OS X
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ---
>>>
>>> _______________________________________________
>>> krbdev mailing list             [hidden email]
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>
>
> --
> Jiva DeVoe
> http://www.devoesquared.com
> PowerCard - Intuitive Project Management for Mac OS X
>
> _______________________________________________
> krbdev mailing list             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Tom Yu
In reply to this post by Jiva DeVoe
>>>>> "jiva" == Jiva DeVoe <[hidden email]> writes:

jiva> I have a long-running service... (like an ftp server, or a web server
jiva> or whatever, though it's a program I am writing myself)... and users
jiva> will access it using a client program (like an ftp client).

jiva> Now I assume the user would kinit prior to running the client
jiva> program, so I can see how that works.  But in the case of the server,
jiva> I am confused about how the server process gains it's initial TGT.

jiva> I understand that I can use a keytab file for the server process, but
jiva> doesn't it still need to call kinit (say in it's startup script)
jiva> prior to calling gss_acquire_cred() ?

krb5 GSS credentials for accepting do not require running kinit; the
accepting credentials are effectively identical to the keytab.  (We'll
ignore the user-to-user auth issue for now.)  It is initiating
credentials which require running kinit.

jiva> Is there an API call for that kinit?  In my program, I've been
jiva> calling the kinit cmd line program prior to running the program.  Do
jiva> I need to put that into my startup script?  (This is all on Linux BTW).

There is the krb5_get_init_creds() API.

jiva> On an unrelated note: Is it possible for a server process to have
jiva> multiple TGT for different principals?  (Why?  For unit tests for my
jiva> code - simulating the user client process/credentials and the server
jiva> process/credentials).

Yes, but it may become rather complex to handle from a programming
perspective.

---Tom
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jiva DeVoe
In reply to this post by Jeffrey Altman-4

On Jul 26, 2005, at 10:18 PM, Jeffrey Altman wrote:

> The server should be calling gss_accept_context and does not obtain
> its own initial ticket.  It uses the key stored in the keytab file
> to decrypt the service ticket delivered by the client as part of the
> authentication negotiation.
>
> Have you examined the source code to the gss-client and gss-server
> sample applications?
>

Yep, sure have, and used those as an example of "what to do" - just  
trying to understand it.

So what about if I want to then send encrypted data to the client  
program?  Do I use the context I have gotten from accept_context for  
that?  Is there ever a case where I'd need to init_context from the  
server to the client?  I was under the impression I should  
init_context to the client in the case that I want to send data to her.

> Jeffrey Altman
>
>
> Jiva DeVoe wrote:
>
>
>> I have a long-running service... (like an ftp server, or a web server
>> or whatever, though it's a program I am writing myself)... and users
>> will access it using a client program (like an ftp client).
>>
>> Now I assume the user would kinit prior to running the client  
>> program,
>> so I can see how that works.  But in the case of the server,  I am
>> confused about how the server process gains it's initial TGT.
>>
>> I understand that I can use a keytab file for the server process, but
>> doesn't it still need to call kinit (say in it's startup script)  
>> prior
>> to calling gss_acquire_cred() ?
>>
>> Is there an API call for that kinit?  In my program, I've been  
>> calling
>> the kinit cmd line program prior to running the program.  Do  I  
>> need to
>> put that into my startup script?  (This is all on Linux BTW).
>>
>> On an unrelated note: Is it possible for a server process to have
>> multiple TGT for different principals?  (Why?  For unit tests for my
>> code - simulating the user client process/credentials and the server
>> process/credentials).
>>
>> On Jul 26, 2005, at 6:02 PM, Jeffrey Altman wrote:
>>
>>
>>> Jiva:
>>>
>>> Why don't you explain to us what you are attempting to accomplish?
>>>
>>> Does one of your two endpoints represent an end-user?
>>> Or are both of your endpoints services that represent machines?
>>>
>>> When using GSSAPI Kerberos, the initiator of the authentication must
>>> have an initial credential (aka a Ticket Granting Ticket) prior to
>>> the call to gss_acquire_cred() or gss_init_context().  If the  
>>> initiator
>>> represents an end user, the user typically obtains a TGT either  
>>> a  login
>>> or via a kinit call.  The user provides her principal name and a
>>> password or smart card or another form of proof of identity and the
>>> Kerberos KDC issues an initial TGT to the user.
>>>
>>> If the initiator does not represent a user or is running as a  
>>> detached
>>> long term background process, the process may be given access to a
>>> keytab containing the long term key for the initiators  
>>> principal.   This
>>> keytab is then used with a kinit call to obtain an initial TGT.
>>>
>>> The TGT is used during the gss_init_context() call to obtain a  
>>> Kerberos
>>> service ticket for the service you are attempting to authenticate  
>>> to.
>>>
>>> Jeffrey Altman
>>>
>>>
>>> Jiva DeVoe wrote:
>>>
>>>
>>>
>>>> Aha!
>>>>
>>>> Is this documented somewhere I can read up on it?  I clearly don't
>>>> understand the inner workings of this, and I'd like to.
>>>>
>>>>
>>>> On Jul 26, 2005, at 5:17 PM, Nicolas Williams wrote:
>>>>
>>>>
>>>>
>>>>> On Tue, Jul 26, 2005 at 05:04:07PM -0400, Jiva DeVoe wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hmm, my tests do not bare this out...
>>>>>>
>>>>>> Specifically, I find I MUST issue a kinit -t /etc/krb5.keytab
>>>>>> service/
>>>>>> [hidden email] before attempting running my application which  
>>>>>> then  does
>>>>>> a gss_acquire_cred.
>>>>>>
>>>>>> Is this correct?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> For an initiator cred, yes.
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Jiva DeVoe
>>>> http://www.devoesquared.com
>>>> PowerCard - Intuitive Project Management Software for Mac OS X
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> ---
>>>>
>>>> _______________________________________________
>>>> krbdev mailing list             [hidden email]
>>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>>
>>>
>>>
>>>
>>
>> --
>> Jiva DeVoe
>> http://www.devoesquared.com
>> PowerCard - Intuitive Project Management for Mac OS X
>>
>> _______________________________________________
>> krbdev mailing list             [hidden email]
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>

--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management for Mac OS X

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jeffrey Altman-4
The server should never have a need to execute a gss_init_context().

To send encrypted data you process it with gss_wrap() (see gss-client.c)
and the process the data with gss_unwrap() on the receiver.  Both sides
of the connection can call gss_wrap() and gss_unwrap() as well as
gss_get_mic() and gss_verify_mic().

Jeffrey Altman


Jiva DeVoe wrote:

>
> On Jul 26, 2005, at 10:18 PM, Jeffrey Altman wrote:
>
>> The server should be calling gss_accept_context and does not obtain
>> its own initial ticket.  It uses the key stored in the keytab file
>> to decrypt the service ticket delivered by the client as part of the
>> authentication negotiation.
>>
>> Have you examined the source code to the gss-client and gss-server
>> sample applications?
>>
>
> Yep, sure have, and used those as an example of "what to do" - just
> trying to understand it.
>
> So what about if I want to then send encrypted data to the client
> program?  Do I use the context I have gotten from accept_context for
> that?  Is there ever a case where I'd need to init_context from the
> server to the client?  I was under the impression I should  init_context
> to the client in the case that I want to send data to her.
>
>> Jeffrey Altman

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jiva DeVoe
Right, exactly... and for gss_wrap you have to have a context, which  
I assume you're saying should be the one sent from the client.

Ok, so that said... what about the peer to peer case?  What if I have  
two long-running server processes that need to communicate?  What's  
the "appropriate" way to handle that?

BTW, thank you very much for the info.  You can see why I was looking  
for general docs... I had several questions.  So I appreciate the info.

A server still has to do a gss_acquire_cred right?  It's just that it  
doesn't need to have done a kinit for it right?  Or does a server not  
even need to do gss_acquire_cred?

On Jul 26, 2005, at 10:49 PM, Jeffrey Altman wrote:

> The server should never have a need to execute a gss_init_context().
>
> To send encrypted data you process it with gss_wrap() (see gss-
> client.c)
> and the process the data with gss_unwrap() on the receiver.  Both  
> sides
> of the connection can call gss_wrap() and gss_unwrap() as well as
> gss_get_mic() and gss_verify_mic().
>
> Jeffrey Altman
>
>
> Jiva DeVoe wrote:
>
>
>>
>> On Jul 26, 2005, at 10:18 PM, Jeffrey Altman wrote:
>>
>>
>>> The server should be calling gss_accept_context and does not obtain
>>> its own initial ticket.  It uses the key stored in the keytab file
>>> to decrypt the service ticket delivered by the client as part of the
>>> authentication negotiation.
>>>
>>> Have you examined the source code to the gss-client and gss-server
>>> sample applications?
>>>
>>>
>>
>> Yep, sure have, and used those as an example of "what to do" - just
>> trying to understand it.
>>
>> So what about if I want to then send encrypted data to the client
>> program?  Do I use the context I have gotten from accept_context for
>> that?  Is there ever a case where I'd need to init_context from the
>> server to the client?  I was under the impression I should  
>> init_context
>> to the client in the case that I want to send data to her.
>>
>>
>>> Jeffrey Altman
>>>
>
>

--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management for Mac OS X

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Russ Allbery
Jiva DeVoe <[hidden email]> writes:

> Ok, so that said... what about the peer to peer case?  What if I have
> two long-running server processes that need to communicate?  What's the
> "appropriate" way to handle that?

In the GSSAPI world, one of them will be a client and one of them will be
a server.  It's fairly arbitrary which you designate as which, except that
the client will need to have a ticket and the server will need to have a
keytab that it can use to verify it.

In a GSSAPI authentication, there is always a client and a server.

> A server still has to do a gss_acquire_cred right?  It's just that it
> doesn't need to have done a kinit for it right?  Or does a server not
> even need to do gss_acquire_cred?

A server does not need to acquire credentials.  Step back a level and look
at it from a higher level perspective:  the client is authenticating to
the server.  The client therefore obtains credentials and presents them to
the server, which verifies them (and then does some additional work so
that the client can be assured that the server is who it claims to be).
Why would the server need credentials?  It doesn't present credentials to
anyone; only the client does that.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jeffrey Altman-4
In reply to this post by Jiva DeVoe
Jiva DeVoe wrote:

> Right, exactly... and for gss_wrap you have to have a context, which  I
> assume you're saying should be the one sent from the client.

You need the context for any gss_xxx() call that you make on either side
of the connection.   On the server, the context is the output of the
gss_accept_context() call.


> Ok, so that said... what about the peer to peer case?  What if I have
> two long-running server processes that need to communicate?  What's  the
> "appropriate" way to handle that?

If you have two long term processes, one of them becomes a client and
the other is a server.   The client will call gss_init_context() and
will obtain an initial TGT using init with a keytab file.

> A server still has to do a gss_acquire_cred right?  It's just that it
> doesn't need to have done a kinit for it right?  Or does a server not
> even need to do gss_acquire_cred?

gss_acquire_cred() is called by the server.   See the gss-server.c
example server_acquire_creds() function.

Jeffrey Altman





_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jiva DeVoe
I think that pretty much explains it all then.  Thanks very much.

On Jul 26, 2005, at 11:22 PM, Jeffrey Altman wrote:

> Jiva DeVoe wrote:
>
>
>> Right, exactly... and for gss_wrap you have to have a context,  
>> which  I
>> assume you're saying should be the one sent from the client.
>>
>
> You need the context for any gss_xxx() call that you make on either  
> side
> of the connection.   On the server, the context is the output of the
> gss_accept_context() call.
>
>
>
>> Ok, so that said... what about the peer to peer case?  What if I have
>> two long-running server processes that need to communicate?  
>> What's  the
>> "appropriate" way to handle that?
>>
>
> If you have two long term processes, one of them becomes a client and
> the other is a server.   The client will call gss_init_context() and
> will obtain an initial TGT using init with a keytab file.
>
>
>> A server still has to do a gss_acquire_cred right?  It's just that it
>> doesn't need to have done a kinit for it right?  Or does a server not
>> even need to do gss_acquire_cred?
>>
>
> gss_acquire_cred() is called by the server.   See the gss-server.c
> example server_acquire_creds() function.
>
> Jeffrey Altman
>
>
>
>
>

--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management for Mac OS X

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Russ Allbery
In reply to this post by Russ Allbery
Russ Allbery <[hidden email]> writes:
> Jiva DeVoe <[hidden email]> writes:

>> A server still has to do a gss_acquire_cred right?  It's just that it
>> doesn't need to have done a kinit for it right?  Or does a server not
>> even need to do gss_acquire_cred?

> A server does not need to acquire credentials.

Sorry, ignore me and listen to Jeffrey.  I misunderstood the question.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jiva DeVoe
In reply to this post by Jeffrey Altman-4
Sorry, one more question...

When is gss_assume_identity called?


On Jul 26, 2005, at 11:22 PM, Jeffrey Altman wrote:

> Jiva DeVoe wrote:
>
>
>> Right, exactly... and for gss_wrap you have to have a context,  
>> which  I
>> assume you're saying should be the one sent from the client.
>>
>
> You need the context for any gss_xxx() call that you make on either  
> side
> of the connection.   On the server, the context is the output of the
> gss_accept_context() call.
>
>
>
>> Ok, so that said... what about the peer to peer case?  What if I have
>> two long-running server processes that need to communicate?  
>> What's  the
>> "appropriate" way to handle that?
>>
>
> If you have two long term processes, one of them becomes a client and
> the other is a server.   The client will call gss_init_context() and
> will obtain an initial TGT using init with a keytab file.
>
>
>> A server still has to do a gss_acquire_cred right?  It's just that it
>> doesn't need to have done a kinit for it right?  Or does a server not
>> even need to do gss_acquire_cred?
>>
>
> gss_acquire_cred() is called by the server.   See the gss-server.c
> example server_acquire_creds() function.
>
> Jeffrey Altman
>
>
>
>
>

--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management for Mac OS X

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jeffrey Altman-4
There is no function of that name in the GSSAPI v2 update 1 standard.

Jeffrey Altman


Jiva DeVoe wrote:

> Sorry, one more question...
>
> When is gss_assume_identity called?



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: One more question WRT gssapi...

Jiva DeVoe
Sorry, getting late, and I'm getting dopey... ignore that question. ;)

On Jul 27, 2005, at 12:09 AM, Jeffrey Altman wrote:

> There is no function of that name in the GSSAPI v2 update 1 standard.
>
> Jeffrey Altman
>
>
> Jiva DeVoe wrote:
>
>
>> Sorry, one more question...
>>
>> When is gss_assume_identity called?
>>
>
>
>

--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management for Mac OS X

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev