Subject: Initiator/acceptor client/server distinction

From: "Josh Howlett" <[email-masked]>
Date: Fri, 20 Mar 2009 11:30:58 -0000

Does the GSS initiator/acceptor relationship have a 1:1 mapping to the
conventional client/server model, or can a client/server adopt either
role?

I can't find these terms defined in RFC2743, hence my confusion.

TIA, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: "Josh Howlett" <[email-masked]>
Date: Fri, 20 Mar 2009 15:34:25 -0000

> Does the GSS initiator/acceptor relationship have a 1:1 
> mapping to the conventional client/server model, or can a 
> client/server adopt either role?
> 

For the benefit of the archives, I found an answer to this in Wikipedia
(so it must be true):

http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Progr
am_Interface

   Initiator/acceptor 

   The peer that sends the first token is the initiator; the other the
acceptor.
   Generally, the client program is the initiator while the server is
the acceptor.

I humbly suggest that the next revision of GSS-API provides a reference
model that explains these types of distinctions.

josh.

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Mar 2009 16:37:16 +0100 (MET)

> conventional client/server model, or can a client/server adopt either

Much more often no than yes -- I can think of the following problems:

 - when the authentication of a gssapi mechanism is only
   uni-directional, i.e. initiator->acceptor, you may not be able
   to reverse roles

 - when the credentials of the gssapi mechanism are direction-specific,
   like with traditional Kerberos 5, where an initiating credential
   is usually represented by a TGT in a ticket cache and an accepting
   credential is usually represented by a secret key in a keytab.

 - when the server doesn't know in advance which client it is talking
   to, because the initiator has to pass the acceptors name into
   gss_init_sec_context(), while the acceptor receives the initiators
   name as output from gss_accept_sec_context() after a successful
   security handshake.
   In general, servers don't know in advance who is trying to talk
   to them and want look up authenticated clients in ACLs after
   the authentication.

Therefore the mapping is usually client = initiator and server = acceptor.

It is much easier to exchange the roles of connection initiator
and connection acceptor between client and server than it is to
reverse the roles of "secure authentication initiator" and
"secure authentication acceptor" between client and server.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Mar 2009 21:34:03 +0100 (MET)

>    The peer that sends the first token is the initiator; the other the

This statement is IMHO implied by the terms "initiator" and "acceptor".

>    Generally, the client program is the initiator while the server is

I would describe it rather differently:

If the two communication peers are of type "client" and "server", then
the client will usually assume the role of the initiator and have to
assert the servers identity upfront to gss_init_sec_contest, while the
server assumes the role of the acceptor and learns the clients
authenticated identity as a result of a successful security context
establishment.

Some people infer that the peer that calls the network connect()
is the "client" and the one that calls the network accept() is the server,
but that is NOT universally true (we ship some components that do it the
other way round).

I personally think the use of the terms "client" and "server" would
be inappropriate to describe what GSS-API is doing.

-Martin

---

From: "Josh Howlett" <[email-masked]>
Date: Sat, 21 Mar 2009 16:18:23 -0000

> If the two communication peers are of type "client" and 
> "server", then the client will usually assume the role of the 
> initiator
...
> I personally think the use of the terms "client" and "server"
> would be inappropriate to describe what GSS-API is doing.

It is this /apparent/ ambiguity that I initially found confusing. As you
imply, the terms "client" and "server" probably aren't helpful when
trying to understand GSS-API and possibly misleading.

Thank you for helping to clarify this for me.

josh.